INTERNET-DRAFT DNS Label Intelligence and Management System UPDATES RFC 1034 February 2001 Expires August 2001 Domain Name System (DNS) DNS Label Intelligence and Management System draft-macgowan-dnsext-label-intel-manage-00.txt Michael L. Macgowan Jr. Status of This Document This draft is intended to become a Proposed Standard RFC. Distribution of this document is unlimited. Comments should be sent to the Domain Name Server Extensions working group mailing list or to the author. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A multidimensional array of domain label analysis and extensions are offered to overcome a number of issues with the DNS and its use to locate resources on the Internet. These goals are accomplished by proposing a naming convention to add labels to domain strings. The result will be a rational relationship to the content that will provide a method for meeting the ever-increasing need to expand the namespace, while providing an efficient search system to access content in a user- friendly manner. A fundamental problem exists in the design of DNS. A user must know the domain name including the Top Level Domain, TLD, and type the Uniform Resource Locator, URL, accurately to connect to resources on the Internet. The current lookup organization of the DNS uses domain labels separated by periods to provide hierarchical levels for a resolver to seek in finding a path to an authority. A new masking technique within labels is proposed to accommodate lookups based on the request. Multiple processing trees are proposed to redistribute the requests based on the known pieces of the domain name. Rather than knowing the fully qualified domain name, FQDN, the user can search for content based upon known pieces of the string like group (business), country, area code, phone number, type of organization, street address, zip code and/or GPS location, etc.. Intelligence is added for determining the fastest route to resolution based on user weighting, number of requests, and traffic within the system. A result of the masking technique is an opportunity to provide a completely hidden label(s) for maintenance of the system. A TTL (Time to Live), version, and type of request could be keyed into a label to provide information, which remains with the client but is normally lost after a request is processed. This system could be implemented to create automatically updated records and content. Or hidden labels could be used to distinguish between version 4 and version 6 requests in the TCP/IP, Transmission Control Protocol/ Internet Protocol, rollover. Implementation of the new name system is facilitated by the addition of a client interface for building requests. Longer domain names are enhanced by smart AutoCompletes and group edit boxes. Table of Contents Status of This Document 1 Abstract 1 Table of Contents 3 1. Introduction 4 2. Inputting Request for Resolution 4 3. Resolution Processing 7 4. Processing Forest 13 5. Extended Label Uses 14 6. IANA Considerations 16 6. Security Considerations 16 References 16 Authors Address 16 Expiration and File Name 17 1. Introduction The Domain Name System (DNS) [RFC 1034, 1035] is the global hierarchical replicated distributed database system for Internet addressing, mail proxy, and other information. The DNS has been extended to phone numbers as described in [RFC 2535]. It is designed to accommodate a user-friendly name as an abstraction level over an IP address, which provides a path to the physical connection to resources and/or content on the Internet. This abstraction allows for changing the physical location of the content without an update by the client. The design, however, lacks a user-friendly method for assigning TLDs and determining which TLD a content provider will be registered under. According to COMPUTERGRAM INTERNATIONAL: January 08, 2001, over 100 million hosts are connected to the Internet with over 350 million users. ICANN has submitted plans to increase the number of TLDs to accommodate the lack of namespace, but the problem of organization and extensibility continues to exist. As the number of TLDs grows, it becomes harder for a user to input a user friendly domain name. In essence, the user must know what derivations and which TLDs were available to a provider at the time the organization chose a domain name. The method of one response, in an all or nothing request, forces precision on the part of the user that is a distraction to the original goal of a user-friendly name. Consider a user that wants to find a new theoretical health related company called Healthy Foods. Will the company be called Healthyfoods.com? Or will it have an extension like healthfoods.net, healthfoods.org, or healthfoods.health? Maybe it will be forced to be a derivation like healthf.com, healthf.net, etc. There is no user-friendly method to determine what the associated domain name might be. This is a central problem of focus and organization. The number of iterations a user must try increases with each new TLD that is added. If a user forms multiple guesses for the TLD, excess traffic is generated and the search is slowed by the inefficient nature of human typing. Further, if a system were proposed under the current root structure to allow for a search of all possible TLDs, the number of requests would grow exponentially with the addition of each new TLD. 2. Inputting Request for Resolution The key to making a New Name System, NNS, is to provide a user interface, which will accommodate a friendly method of building name requests. AutoComplete and multiple-selection drop-down, group list boxes (some editable, some not) will make more complicated names easier to input. Consider the previous example of Healthy Foods. Additional extensions could be added as labels to make the namespace exponentially larger. The web content might be reached at www.healthy.food.US2081234567.Fairview101. In this example, www is the Device label or content desired by the user. Health is the domain or Subgroup/Group name label. Food is the item under the Type label. US2081234567 is the item country/area code/number for the Global label. Sfairview101 is the street/address of the Local label. Derivations of this example provide a limitless expansion of the namespace within the physical limits of the protocol. A competitor down the block might have the same FQDN, except for the street number and phone number e.g. www.healthy.food.US2088901234.SFairview990. A second type of business could also be run from the same location by changing the type e.g. www.healthy.entertainment.US2081234567.SFairview101. A parody of the site might be offered at www.healthy.parody.us2086669999.SState103. A method of using less descriptive labels could also be used to generalize the content. For example, the site for the regional office might use only the country and area code designation e.g. .US208. A corporate address might be located at www.healthy.food.US.corporate. This way the Global and Local labels are not tied to physical locations. Or there may be an 800 or 888 number that could be used for multiple sites that are tied to multiple registrations at different street addresses in the Local label. The task of building these longer names with labels can be accomplished by updating list items from the NNS and by designing a better interface. Instead of waiting for ICANN to vote on the relative merits of a proposal for a new TLD, items could be automatically updated and added to the system by a list of requirements. This would force a relationship between labels but provide a nonbiased method without prejudice. For example, a .Bus(iness) item for the Type label would require a copy of a business license to be granted by the governing authorities for the area specified in the Global label or the address specified in the Local label. A “TM” item could separate the Intellectual Property of Trademarks and Copyrights from other registered listings issued from the government specified by the country code in the Global label. Additionally, the Academy of Motion Pictures might request an Oscar item, which would restrict membership to nominees or recipients of the coveted award. Just as the resolver gets an updated list of root servers upon first connection, the resolver could also receive an updated list of items in the Type label and return them to the client. The list could be updated by a TTL trigger and should not be editable from the user’s standpoint. The user interface should allow for multiple selections, which could be used to form separate requests for resolution. Finally, the implementation should begin with at least a list that is equal to a subject list found in the yellow pages of the phone book. This will provide a well-known classification that will greatly reduce competition for names of organizations, which are similar but provide for very different products/services. Delta.airline is readily distinguished from Delta.homeimprovement. The device label would remain largely unaffected. A list of previously connected items such as www, toasters, lock, refrigerator, etc. would facilitate input. The list would be editable. As the number of devices connected to the Internet grows, this method will be invaluable. Consider mail and faxes being sent directly to printer.mybusiness.computer.us2081234567.sfairview101. A user that needs to send a fax to a satellite office might also be able to try searching for mybusiness at its other street address or telephone number eg., printer.mybusiness.computer.us714*.sPensylvaiaave2345. Wildcards and searching are discussed in the next section. The items under the Groups/Subgroups labels would also be a list of previously connected to domains (less the TLD) such as sales.business or kitchen.home. The list would contain a history of previous connections and be editable. The Global label would have two characters to represent the country code followed optionally by all or part of a representative telephone number or mask for identifying the voice number(s) associated as items in the domain. An international code would require a rational relationship with world organizations. The interface would contain the country codes and/or area codes, but the numbers would have to be added. The Local label would require a single character to represent the type of information presented, followed by the information in a standardized form. The following codes are proposed for the Local label, “P” for Postal code, “G” for Global Satellite Positioning and “S” for street address. For example, P83706 would represent the author’s postal code, GP0445004N1162498 (since the “+” key is not valid, “p” and “n” represent positive and negative) would represent the GPS position of the author with padding to standardize degrees/min/sec or SOrchard15541 would represent the Street address (house number at the end). Note each of these would require a separate name registration. The editable list box could be a fly out list box with one of the designators specified, while the remainder would be user input. +------------------+ |Street | | Fairview101 | State101 | |Postal | |GPS | +------------------+ The added labels would exponentially expand the name space. This may cause an undesired relation to a Global or Local designation. This could hamper changes to an organization or business in the future. Hence a business might want to use a CNAME entry to reference users to a non-distinct item in a label. For instance, a corporation might want to register mybusiness.bus.In(ternational).corporate so that the corporate office could be used for email addresses and bookmarking. Content might be located at each mybusiness.bus.country.location where the company does business. This way a corporation does not have to be penalized for moving to a new physical location. The goal of the DNS was to remove a physical relationship to the network, but the need of the users is for some content to have a physical relationship to the content; which is why, in part, the NNS is proposed. The concept of an update is also discussed in section 5. The system would need to distinguish between the need for a request for a connection to single IP address versus multiple requests. In an application like a browser, traditional requests for IP resolution are all or none. Either an IP address is connected to or not. If wildcards are added to the request, multiple entries could be returned as a “hit” list. An option on the browser could determine the number of requests specified by the user. The “hits” should also be weighted. For instance, if a user wanted to find all the movie theatres in the local area he/she might submit a request for www.*.movies.US8370*.*. She/he would be more inclined to desire additional theatres at different nearby area codes than derivations of different domain names or Local label derivations for a single theatre. A simple listing of each label with an associated numerical value in an advanced option field could determine how the responses are weighted against one another. The NNS could also take into account the number of requests on the system and further limit the number of responses based upon traffic. For registration, the content provider might want to register a more global entry to be displayed on a restrictive search e.g. loans.US*.*. A business content provider might want to register mybusiness.com.US* so that requests for www.mybusiness.com.US208.* and www.mybusiness.com.us714.* both resolve to mybusiness. A process would have to be in place to copy an entry with wildcards to each of the associated branches of the processing trees as discussed in section 4. Similarly wildcard registrations should meet the rational requirements required for the known item with the generalized scope. In the previous example the provider would have to be licensed as a financial institution in each of the states of the United States. 3. Resolution Processing The key to expanding the DNS is to provide for a name space, which can be accessed quickly and efficiently. Organization is key to this process. The current DNS has one root organized by TLDs of the Type label combined with Country TLDs. If a user does not know the extension for the name, requests must be created for each one until a match is found. The NNS creates separate roots for each label that can be used for a search (see graphic on next page, description of TLDs is in section 5). Instead of one tree, a forest is created, connected by a common list of authorities for devices in the zones requested. Requests can be organized by the known piece(s) of information. For instance, if a user is trying to find Hewlett Packard and does not know that content is provided at HP, a search of www.H*.*.US*.* should be returned alphabetically from the Group label, not the Type label. However, if the type item is known to be “computer”, a search of the Type tree would be fastest. If a user wants to find a local voice number for Microsoft he/she could submit a request generalized request within the local area code for www.Microsoft.software.US208*.*. The authority would best be located by the Global processor, which might list www.Microsoft.software.US5041234567.SState123 and www.Microsoft.software.US5044567890.SredmondAve123. If the request for www.Microsoft.software.US504*.* were sent to the Local processor, every TLD would have to be queried. The result might be one phone number with separate Local label listings for the street address, GPS, and postal code. This would create unwanted traffic on the system. Root “.” Group Root “.”Type | | | | “H” TLD TLD “Computer” | | | | --- Authority for..HP.computer.US2081234567.SChinden12---- | | | | “US208” TLD TLD “SChi” | | | | Root “.” Global Root “.”Local In addition to determining which label(s) to process the request, the system would also have to take into account the weighting by the user and the traffic on the system as discussed in the previous section. When the FQDN is specified, the resolver would query the processor with the fastest expected response time. A FQDN can be resolved from any of the search processor trees. In the example oven.macgowan.private.US2081234567.SOrchard15541, it does not matter whether the request is sent to the Group, Type, Global, or Local processing tree. Each leads to the authority, macgowan.private.us2081234567.SOrchard15541. If wildcards or null characters exist in the request, the system should take into account the number of requests that might be generated. Currently the DNS does not account for the “?” and reserves the “” for the root. The “*” could replace the singe character wildcard “?” and the word “null” could be used in lieu of “”. The following table could be used to determine which processing tree should be the most desirable under such conditions: any = any combination of characters displayed in request reject= no preferred processor *= match any combination of characters for response ?= match any single character for response null= no character specified Device Sub Group T G L Result * * * * * * reject * any any any any any reject * * any any any any reject * * * any any any submit to T, G, or L * * * * any any submit to G, or L * * * * * any submit to L any * * * * * reject any any * * * * reject any any any * * * submit to group any any any any * * submit to group, or T any any any any any * submit to group, T, or G any any any any any any submit to any any * any any any any submit to any any * * any any any submit to T, G, or L any * * * any any submit to any G, or L any * * * * any submit to any L any any * any any any submit to any T, G, or L any any * * any any submit to any G, or L any any * * * any submit to any L any any any * any any submit to any group, G, or L any any any * * any submit to any group, or L any any any any * any submit to any group, T, or L any any any any * * submit to any group, or T * * * * * * reject * any*any any*any any*any any*any any*any reject * * any*any any*any any*any any*any reject * * * any*any any*any any*any submit to T, G, or L * * * * any*any any*any submit to G, or L * * * * * any*any submit to L any*any * * * * * reject any*any any*any * * * * reject any*any any*any any*any * * * submit to group any*any any*any any*any any*any * * submit to group, or T any*any any*any any*any any*any any*any * submit to group, T, or G any*any any*any any*any any*any any*any any*any reject any*any * any*any any*any any*any any*any reject any*any * * any*any any*any any*any submit to T, G, or L any*any * * * any*any any*any submit to any G, or L any*any * * * * any*any submit to any L any*any any*any * any*any any*any any*any reject any*any any*any * * any*any any*any submit to any G, or L any*any any*any * * * any*any submit to any L any*any any*any any*any * any*any any*any reject any*any any*any any*any * * any*any submit to any group, or L any*any any*any any*any any*any * any*any submit to any group, T, or L any*any any*any any*any any*any * * submit to any group, or T * * * * * * reject * any* any* any* any* any* reject * * any* any* any* any* reject * * * any* any* any* reject * * * * any* any* submit to G, or L * * * * * any* submit to L any* * * * * * reject any* any* * * * * reject any* any* any* * * * reject any* any* any* any* * * reject any* any* any* any* any* * reject any* any* any* any* any* any* reject any* * any* any* any* any* reject any* * * any* any* any* submit to T, G, or L any* * * * any* any* submit to any G, or L any* * * * * any* submit to any L any* any* * any* any* any* reject any* any* * * any* any* submit to any G, or L any* any* * * * any* submit to any L any* any* any* * any* any* reject any* any* any* * * any* submit to any group, or L any* any* any* any* * any* reject any* any* any* any* * * submit to any group, or T ?any ?any ?any ?any ?any ?any reject ?any any any any any any reject ?any ?any any any any any reject ?any ?any ?any any any any submit to T, G, or L ?any ?any ?any ?any any any submit to G, or L ?any ?any ?any ?any ?any any submit to L any ?any ?any ?any ?any ?any reject any any ?any ?any ?any ?any reject any any any ?any ?any ?any submit to group any any any any ?any ?any submit to group, or T any any any any any ?any submit to group, T, or G any any any any any any submit to any any ?any any any any any submit to any any ?any ?any any any any submit to T, G, or L any ?any ?any ?any any any submit to any G, or L any ?any ?any ?any ?any any submit to any L any any ?any any any any submit to any T, G, or L any any ?any ?any any any submit to any G, or L any any ?any ?any ?any any submit to any L any any any ?any any any submit to any group, G, or L any any any ?any ?any any submit to any group, or L any any any any ?any any submit to any group, T, or L any any any any ?any ?any submit to any group, or T any?any any?any any?any any?any any?any any?any reject any?any any any any any any submit to any any?any any?any any any any any submit to any any?any any?any any?any any any any submit to any any?any any?any any?any any?any any any submit to G, or L any?any any?any any?any any?any any?any any submit to L any any?any any?any any?any any?any any?any reject any any any?any any?any any?any any?any reject any any any any?any any?any any?any submit to group any any any any any?any any?any submit to group, or T any any any any any any?any submit to any any any any any any any submit to any any any?any any any any any submit to any any any?any any?any any any any submit to any any any?any any?any any?any any any submit to any G, or L any any?any any?any any?any any?any any submit to any L any any any?any any any any submit to any any any any?any any?any any any submit to any G, or L any any any?any any?any any?any any submit to any L any any any any?any any any submit to any any any any any?any any?any any submit to any group, or L any any any any any?any any submit to any any any any any any?any any?any submit to any group, or T any? any? any? any? any? any? reject any? any any any any any submit to any any? any? any any any any submit to any any? any? any? any any any submit to any any? any? any? any? any any submit to any any? any? any? any? any? any submit to any any any? any? any? any? any? submit to any any any any? any? any? any? submit to any any any any any? any? any? submit to any any any any any any? any? submit to any any any any any any any? submit to any any any any any any any submit to any any any? any any any any submit to any any any? any? any any any submit to any any any? any? any? any any submit to any any any? any? any? any? any submit to any any any any? any any any submit to any any any any? any? any any submit to any any any any? any? any? any submit to any any any any any? any any submit to any any any any any? any? any submit to any any any any any any? any submit to any any any any any any? any? submit to any Null any any any any any not valid any Null any any any any submit to any any any Null any any any reject any any any Null any any submit to group, G, L any any any any Null any submit to group, T, L any any any any any Null submit to group, T, G Null Null any any any any not valid any Null Null any any any reject any any Null Null any any submit to G, L any any any Null Null any submit to group, L any any any any Null Null submit to group, T Null Null Null any any any not valid any Null Null Null any any submit to G, L any any Null Null Null any submit to L any any any Null Null Null submit to group Null Null Null Null any any not valid any Null Null Null Null any submit to L any any Null Null Null Null not valid Null Null Null Null Null any not valid any Null Null Null Null Null not valid Null Null Null Null Null Null not valid 4. Processing Forest |--Group Root---| | | |---Type Root---| | | client->------Resolver ->------| |----Authority->--- return | | |--Global Root--| | | |--Local Root---| Once the resolver has determined which root to send the resolution request to, each tree should be organized according to an exhaustive replication of each name string on the route to an authority. For instance, the Group tree would be organized alphabetically with TLDs “A” through “Z” initially. Since there are a lot of organizations with business name derivations using the word “micron”, there might be a need to reorganize the “M” TLD to accommodate a “Mic” and a “Mid” TLD. Although it would be more efficient to break down each letter according to the demands of the system, it would be easier to specify one mask for the entire tree. The number of TLDs becomes a function of the permutations of the number of masked characters in the available set of usable characters rather than a select few that are added over time. The resolver can cache the TLDs and know when to use them based upon the mask for the tree. If a larger mask is needed to further distribute the load, the resolvers would have to be updated. To replicate the current DNS entries under the additional labels specified in this proposal a number of applications and uses would have to be accounted for. The ARPA listings would remain unchanged or they could be replicated under each root by recombining telephone numbers in a single label under the e164 or padding IP addresses under the inverse lookup tables without the periods separating the octets. Since the NNS uses a forest of processing trees and the current system uses only one tree, a conversion process would have to be developed to distinguish between DNS requests and NNS requests. This could be handled using a number of different methods. A version flag in the request could accomplish this. This way the resolver would be able to determine which searchable labels were used and the order of presentation by standardization. The resolver intelligence would know which labels to use for lookup or in the preferred embodiment. The resolver could also reorganize the labels to be presented under the correct processor so that the Global label is presented at the right of the name string for processing through the Global tree. Legacy requests without a version would be sent to the Type tree. Another method could accomplish the goal by combining the labels the request for the processing tree. In the previous example, the request oven.macgowan.private.US2081234567.SOrchard15541 could be recombined by the submitting processor as oven.macgowanUS2081234567SOrchard15541.private to be searched under the Type tree. Similarly it could be recombined as oven.macgowanprivateUS2081234567.SOrchard15541 to be searched under the Local tree. If a legacy DNS based system submitted a request for www.yahoo.com, it might be appended as www.yahoo.com..... The first “.” after com is to end the Type label. The second “.” Represents the null character at the end of the Global label. The third “.” is for the Local label. The fourth “.” is for the root. The last “.” is for the end of the sentence. If applications are affected by the reservation of the “.” for the root, the request could be recreated as www.yahoo.com.null.null.. A final method is to create a hidden label. Hidden labels are discussed further in extended label uses. Once the authority for a label is found within the label, the system must also determine if there are Subgroups. Subgroups can be used for a number of internal functions and/or divisions within the authority for an organization. At this point the system would continue to resolve using subgroup labels as levels as it does under the current system toward the device at the left of the name string. The remaining searchable labels would be serviced using a similar method. The Type tree would be organized as it is in the DNS with TLDs representing each item in the list. Since the items in the list are limited by the system, the mask could be set to none. The Global label should be organized by a mask, which would accommodate at least the country and area codes. The Local label would mask the PGS items until enough TLDs are derived to equal processing traffic under the other trees. Provisions should be made for the non-distinct items like “corporate” that may use characters not reserved for physical locations. In addition, a null TLD could be used to organize the remainder of name strings that have omitted labels. The null “” character or the word “null” could be used to represent legacy DNS strings under the new labels until the name strings are updated with the longer requirements. The NNS allows a FQDN to be resolved from each searchable label. Please refer to the previous example, oven.macgowan.private.US2081234567.SOrchard15541. The authority, “Macgowan.private.US2081234567.SOrchard15541” is found using the traditional method of the DNS using a Type item of “private” (mask of zero). The authority, “Macgowan.private.US2081234567.SOrchard15541” is found through the Group processor under the “Mac” branch using a mask of three characters. The “Macgowan.private.US2081234567.SOrchard15541” authority is found under “US208” using a mask of four characters within the Global processing tree. The “Macgowan.private.US2081234567.SOrchard15541” authority is also found under “SOr” of the branch masked under the Local tree. 5. Extended Label Uses The NNS is a simple design which can accommodate the future of Internet name strings by incorporating additional processing trees and a large name space organized by labels with a user friendly interface. A search engine is automatically derived from the organization within labels as opposed to across labels. In other words, you send the known pieces of the request to the processing tree that will yield the quickest results with the least amount of traffic. Once names are bookmarked or selected from a list of AutoCompletes, requests can be sent to any processing tree to balance the load on the system. The present proposal also provides an extensible path for future labels that may or may not have associated processors. A “Contact” label might always be masked during the request for resolution, but provide additional value to the user with a description about the connection or a webmaster’s email address. This has extreme value in the event a name can be resolved, but not reached by connection to the IP address. In addition to adding new labels, a group or association might request a new item under the Type label or a new area code might be added under the Group label. Therefore, one result of this system is a combination of devices and labels which expands exponentially to meet the demand for namespace with an inherent capability to adjust to future needs. An additional hidden label (mask of all) adjacent to the root could be hidden and give information for maintenance of the system and/or the listing. The most important consideration is keying the order and number of labels in the string. Or using this method, a hidden security label could help create a firewall between valid requests from users in the domain versus outsiders or tie to a public key for the destination. The hidden label could also be used to pass a request for content delivered in a specific language. With the addition of the Local and Global labels it might also be necessary to add a TTL label which could serve as a timer for the registration or the life of a bookmark or connection. The client could use this value in a history of valid connections to make a request for an updated TTL, a new IP address, and/or a trigger for replacing the name with a new string. This would allow for a change in address, phone number, new area code, etc. on the part of the provider. Just as the domain name was an abstraction layer over the IP address, the current domain string is an abstraction for a future domain string. A routine could prompt a user to change an entry in a contact/bookmark list. Services such as WWW could also automatically update links in the content or reflect changes to related destinations within the content. In use, the client could compare its value to the value at the authority. If the authority has a value of zero, the client would update its name and IP address to the new pointer returned by the resolver. An electronically updating NNS with updating links in content is a product of this system. An example of using this procedure could be applied to finding the best cell phone plan. A user buys a cell plan. The user emails contact links to friends and associates. The recipients use their link to dial the user. The user determines a new provider would be more advantageous and purchases a new plan with a new number. The user sets their old TTL to zero in the NNS and creates a new FQDN with the new cell number. Now when the recipients use the old string, they are pointed to the new string. The string with the new number is updated in the recipient’s contact list. The user is not tied to their telephone number and the recipients do not need to manually adjust their entries. Hidden labels and masking would also have to be present at the client. A business might have a lot of phone numbers or locations listed on the name servers but use a shorter version of the string for making local connections. This way all the devices under a group could be combined as a single domain name. The future direction of label intelligence and the ideas expressed here suggest that there may be numerous ways to provide abstraction levels within the label string. Even the IP address might be used as an identifier to search for the rest of the domain string or an item like the telephone number. 6. IANA Considerations The focus of the IANA will change considerably. The need to regulate name hoarders, TM infringement considerations, and the decision to implement new TLDs will be greatly reduced. The IANA might be used to determine the relationships between labels as new items are added under the requirements that provide for fair and equal addition to the Type label. 7. Security Consideration Name resolution is an inherent problem for spoofing content, but is beyond the scope of this proposal. The suggested ability to update name strings at the client also increases the need to provide secure communications between the system and the client. References [RFC 1034] - "Domain names - concepts and facilities", P. Mockapetris, 11/01/1987. [RFC 1035] - "Domain names - implementation and specification", P. Mockapetris, 11/01/1987. [RFC 2535] – “E.164 number and DNS” , P. P. Faltstrom, 9/1/2000. Authors Address Michael L. Macgowan Jr. 15541 Orchard Ave. Caldwell, ID 83607 USA Telephone: +1 208.454.1177 (h) FAX: +1 208.455.0439 EMail: mmacgowa@yahoo.com Expiration and File Name This draft expires in August 2001 Its file name is labelmanage.txt Full Copyright Statement Copyright (C) The Internet Society (February 2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Michael L. Macgowan Jr. February 2001 [Page 17] Internet Draft DNS Label Intelligence and Management System