Network Working Group S. Hollenbeck Internet-Draft VeriSign, Inc. Expires: April 7, 2006 L. Daigle Cisco Systems M. Mealling Refactored Networks, LLC October 4, 2005 Rationale for the Service Lookup System (SLS) draft-hollenbeck-sls-rationale-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on April 7, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract Developing technology to support truly internationalized Internet identifiers is proving difficult within the framework of the existing Domain Name System (DNS). At the same time, the DNS continues to do an excellent job at serving its original mandate for providing efficient mappings between machine-readable labels and network Hollenbeck, et al. Expires April 7, 2006 [Page 1] Internet-Draft SLS Rationale October 2005 resources. However, it is clear that the existing DNS cannot be transformed into a service that can handle the more human-oriented identification services it is now being asked to provide. This document describes the rationale for a directory layer above the existing DNS that can better solve these problems. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Service Providers . . . . . . . . . . . . . . . . . . . . 6 2.3. Unanswered Questions . . . . . . . . . . . . . . . . . . . 7 3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Transition From DNS to Something Else . . . . . . . . . . 8 3.2. Web Browsing . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. Name Known, Never Resolved . . . . . . . . . . . . . . 8 3.2.2. Name Known, Resolved Before . . . . . . . . . . . . . 9 3.2.3. Name Not Known, Other Characteristics Known . . . . . 10 3.3. Sending Email . . . . . . . . . . . . . . . . . . . . . . 10 3.3.1. LHS and RHS Names Known . . . . . . . . . . . . . . . 10 3.3.2. Full Human Address Known, Bookmarked . . . . . . . . . 11 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Intellectual Property and Copyright Statements . . . . . . . . . . 13 Hollenbeck, et al. Expires April 7, 2006 [Page 2] Internet-Draft SLS Rationale October 2005 1. Introduction In "A Search-based access model for the DNS" [I-D.klensin-dns- search], the author discusses approaching the problems of internationalized domain names (IDNs) and enhanced DNS with a layered approach that leaves the current DNS' form and function unmodified. The three layers are: Layer 1: The DNS, with the existing lookup mechanisms. Layer 2: A restricted lookup system where the identifiers are qualified by additional attributes called facets. Facets include concepts such as locale, category, and language. Layer 3: Localized and topic-specific search environments. This document describes the problem statement, reviews possible usage scenarios, and provides the rational that ties these elements together. It is based significantly on an older document originally written by Michael Mealling and Leslie Daigle titled "Service Lookup System (SLS)". Most of the text that appears here was copied liberally. Portions of the older document have been dropped or re- written to reflect changes in thought over time. 2. Problem Statement Roughly stated, the goal of Layer 1 is to provide unique, machine friendly identifiers for network level resources that can be used as protocol elements. Layer 3 is for search services such as search engines and localized/topic specific directory services; e.g. very human and/or task specific services where the queries and results are not universally standardizable. Layer 2 attempts to be a bridge between Layer 1 and Layer 3. The problem is: what is the functional and deployable middle ground? This includes even the fundamental question of "What exactly is the problem that Layer 2 will attempt to solve?". Much of the discussion to date has dealt with internationalization of Internet identifiers, domain names in particular. The need for anything beyond simple matches on characters is not immediately apparent for identifiers that can be represented entirely in the English language using US-ASCII characters. Since the Internet, and DNS specifically, were designed using US-ASCII characters, it is much easier for English-speakers to learn to live with the limitations and thus those limitations aren't as glaringly apparent. Limitations become more obvious when languages that are represented Hollenbeck, et al. Expires April 7, 2006 [Page 3] Internet-Draft SLS Rationale October 2005 using non-US-ASCII characters are considered. German, for example, can be approximated with some limitations. When confronted with non- ASCII character sets from Asian languages, however, the simple "match on characters" semantic quickly becomes unworkable and in many cases fundamentally cannot address the identification requirements of the user. Requirements such as "match based on the locale of the querier" and "order of the name components to match user expectation" have been common enough to illustrate that the problems that are attempting to be solved are beyond the capabilities of the DNS. It is also interesting to look at what might be the root cause of all of these problems. Many of these problems stem from the disconnect between what the DNS was meant to identify and what it is actually being used for. In many cases the DNS is being forced into service as a way to identify complex services that have no concrete network level representation. For example, when a user types "cnn.com" into a web browser they are not explicitly asking for the index.html file at the root level context of the HTTP server running on the default port of the host whose A record is returned from the DNS query for "cnn.com". The user's view of the process is that he/she is requesting the current news from CNN via the Internet. The disconnect between these two different interpretations of the same action is where the problem lies. The problem is that the DNS and by extension IDN and similar efforts are attempting to use a simple name to number mapping system for network identifiers as a tool for mapping real world entities (companies, individuals, services) into network services (not identifiers). Since networks are designed and evolve to meet technical and network administration needs, their evolution is often at odds with that of the services that real world entities (individuals, organizations) wish to communicate about. This stress is particularly noticeable in the identifier strings themselves (domain and host names) -- companies, individuals, and services must be named using labeling conventions that were devised for network machines. This simply doesn't fit. 2.1. Requirements The problems and features discussed in [I-D.klensin-dns-search] suggest a system with certain behaviors. This document continues that discussion by describing specific requirements for that system. In order to do so, some of the unanswered questions in the document need to discussed: Hollenbeck, et al. Expires April 7, 2006 [Page 4] Internet-Draft SLS Rationale October 2005 o Character sets: Full Unicode support at a minimum. There is some desire to enable other character sets but most comments have said that mapping into Unicode is acceptable as long as there can be some method for communicating what locale was used for doing that mapping and which normalization steps were taken. It has become evident that, in order to know what normalization steps occurred, the client may need to describe the original character set used as input into the normalization step. It has even been suggested that the exact software vendor and version implementing that normalization may be needed for some languages. o Localization: In many cases there are semantic differences in what an appropriate match should be based on location, jurisdiction, or region-specific dialect. o Geographic scoping: In other cases, it is appropriate to distinguish between identifiers based on the region or geographical scope of applicability. For example, trademarks have traditionally been scoped by geographical boundaries. o Category based scoping: To fully handle most trademark law and the human habit of using the same word to mean two different things, names also need to be scoped by the category they fit into. The problem here is to figure out which categories to use since there is no single taxonomy in which all things can be categorized. o Syntactic flexibililty: If at all possible, the system should not place synthetic syntactic restrictions or requirements on identifiers. One main reason is that there are no common syntactic elements among all languages. This includes both computational, structured syntax (e.g. dot separators) and no requirements or constraints on the interpretation of the identifier (e.g. any Unicode character is valid). o DNS characteristics worth preserving: Since the DNS provides some of the motivation for a Layer 2 service, it is worth looking at in terms of characteristics that are worth emulating: - Limited match semantics (lookup only), - Deterministic relationship between the name and the answer set, - All public names are globally available, and Hollenbeck, et al. Expires April 7, 2006 [Page 5] Internet-Draft SLS Rationale October 2005 - In the case of an A record, the result is service-independent. o Uniqueness is an important characteristic of DNS that should be emulated by some aspects of the system, though which aspects and how are uncertain. It is at least a requirement that a given name/facet set/service tuple be unique. o There are requirements that facets be structured, highly standardized, limited in number, and with values that come from controlled vocabularies. o It should be possible for a result to identify a service independent network node so that the client may contact that node for multiple services without having to re-query the Layer 2 service again and again for each different service. o While locale in its various standardized forms does communicate some aspects of "location", additional information (geographic and category scoping) is needed in order to support various human assumptions such as trademark law and locality of reference. o Entries must be globally unique, but 2 entries may be distinguishable by as little information as the service through which they are made available. In other words, names and their facets, as a whole, are unique within a service and are scoped to that service. o A result must return its entire context. This includes not only the name and the identification component but ALL of the facets that made up the match. o There are no requirements or restrictions on the entities that can be identified. A name can apply to a human, a corporation, etc. Some services may not make sense for a given entity but that it simply reflected in that name simply not begin registered with a provider for that service type. o It is expected that Layer 2 services will be provided on a competitive basis. This means multiple service providers that may cover the same areas and who compete directly with each other. 2.2. Service Providers The concept of Layer 2 "service providers" has been mentioned several times so far and needs to be discussed itself. In order to avoid requiring a single, structured global delegation of registration and lookup servers, we start from the assumption that there will be multiple independent collections of name/facets. Name/facet tuples Hollenbeck, et al. Expires April 7, 2006 [Page 6] Internet-Draft SLS Rationale October 2005 must be globally unique across all publicly accessible collections. This is accomplished by including the service provider as one of the facets, essentially making name/facet tuples unique to their provider. Beyond this there is no other defined relationship between service providers. Whether providers coordinate or compete with each other is beyond the scope of this document. The only material effect is that we need to determine whether "discovery" is a required component of the Layer 2 query protocol. There may be a requirement that a tuple have a service provider independent and globally unique identifier to allow for a tuple to "migrate" from provider to provider but this is more of a policy requirement than a technical one. 2.3. Unanswered Questions Questions still to be answered include: o Is Unicode sufficient? If not by itself, then is a mapping from the local character set onto Unicode provided the mapping used is communicated to the service via the locale facet sufficient? If not, then is the requirement that _all_ character sets be supported? o In many cases "locale" is a combination of pieces of information. The value associated with any Posix locale setting is a combination of the ISO 3166-1 two-letter country code and a two- letter language code. Is this concept of locale sufficient for the boundary cases found in some languages? Does the definition need to be augmented by ISO 3166-2 subregion codes? Are the standard two letter language codes also sufficient? o Is uniqueness based on the name/facet-set/service tuple sufficient? o If it is, is there a requirement that the results of a query be exhaustive? This requirement would create a situation where all service providers would have to be discoverable. o Is there a real requirement for supporting the trademark law concepts of name scoping by geographic and category boundaries? If so, then requirements for the location and category facets need to be investigated further. 3. Usage Scenarios Since it is much easier to discuss these goals in terms of specific usage scenarios instead of vague general desires, the discussion Hollenbeck, et al. Expires April 7, 2006 [Page 7] Internet-Draft SLS Rationale October 2005 above is framed in terms of the following examples. 3.1. Transition From DNS to Something Else In order to deploy anything at Layer 2, a transition method would have to be required to allow for users to a) use domain names within the system, and b) to use Layer 2 names in place of domain names. A usage example might look like this: A user at a web browser wants to visit the web site for "CNN". Their browser has rudimentary software installed that can handle the term "CNN" as a Layer 2 service name instead of a partial Layer 1 domain name, but only by "acting" as a shim above that browser's Layer 1 interface. Therefore the user's queries are specified so that the results are nothing more than pointers to regular DNS records. If the results contain more than one answer then the user is given a disambiguation step. The results are kept in a cache but as far as the browser is concerned, it has still received a simple DNS "A" record. The same could be done for an enhanced email address. In this case a seemingly normal email address is decomposed using regular RFC 2822 [RFC2822] rules. The same shim layer is called on the Right Hand Side (RHS) of the address per RFC 2822's rules. A DNS query is then performed for an MX or A record. If there is a disambiguation step required the user is given that choice. The result of the query will be an MX or A record that is handed back to the user's application. This is simply a scenario. If a solution is deployed that actually works this way then extreme care must be taken so that recursive resolution doesn't happen between a full implementation of the service and this "shim". If the result of a fully enabled client query is then input into a "shim" then serious usability or interoperability problems can occur. 3.2. Web Browsing The following scenarios discuss the use of an SLS-like system for naming services used via web browsers. 3.2.1. Name Known, Never Resolved One of the main uses of Layer 2-style names is that they help solve the "guessing" function that many users are forced to perform with DNS names. With DNS a guess is required because the most likely name is often already taken, causing other services to have to pick sub- optimal domain names. This causes the user to have to guess at that sub-optimal name in order to find the other services. This scenario Hollenbeck, et al. Expires April 7, 2006 [Page 8] Internet-Draft SLS Rationale October 2005 involves the case where the user is attempting to browse the public page of a service they have heard about but never actually visited or queried for. In this case the user enters the Layer 2 name "McDonald's". This name, plus defaults provided by the browser that the user previously configured (location, locale, interests, etc), are sent to the user's configured SLS servers. The servers respond with the various results and those results are displayed to the user. In this particular case the user lives in an area that has a locksmith business called "McDonald's Doors" as well as a computer upgrade and repair business called "McDonald's and Associates". All of these companies and the fairly famous restaurant with over a billion served both have the use of the trade name "McDonald's". The user is presented with these results: McDonald's: A worldwide system of restaurants which prepare, assemble, package and sell a limited menu of value-priced foods. http://www.mcdonalds.com/ McDonald & Associates: current pricing on standard memory modules, a list of proprietary upgrades available, a memory FAQ, and articles on upgrading memory and types of memory. http://www.buymemory.com/ McDonalds Doors: offers security, safety, and protection in doors and locking systems. http://www.mcdonaldsdoors.co.uk/ Based on this list of results the user selects the locksmith, and their browser is told to request that particular URI. At the same time, that record is also inserted into the user's local cache of service records. 3.2.2. Name Known, Resolved Before In this scenario the user is requesting the same Layer 2 name as before: "McDonald's". At this point the user interface designer has three main choices: o Immediately follow the service description found in the first hit in the users local cache. Hollenbeck, et al. Expires April 7, 2006 [Page 9] Internet-Draft SLS Rationale October 2005 o Re-query the current list of SLS service providers, but display the user's locally-cached records first. o Ignore the users local cache entirely. The usability issue here is the tradeoff between the easiest way for the user to use frequently-used names without needing to disambiguate yet again and allowing the user to signal that they wish to do a novel name lookup regardless of what they have done in the past. In this scenario we will assume that the browser handles this situation to the user's satisfaction. The user never sees the disambiguation step and thus is immediately sent back to the same service as before. 3.2.3. Name Not Known, Other Characteristics Known In this scenario the user does not know the actual name of the service she is looking for but she does know that it is a locksmith in her local area. In this case the query is not for a Layer 2 name, but instead a query sent to a local Layer 3 service such as a local yellow pages provider. The results are sent back in the same basic form as provided by SLS, but augmented with additional values that help the user differentiate between which locksmith they are looking for. These records also contain the Layer 2 name for each service, thus populating the user's local cache with the correct names for future queries. The key point here is that there is a general requirement that Layer 2 and Layer 3 service be interoperable to some degree. 3.3. Sending Email In these scenarios, Layer 2 names are used as components of SLS- enhanced email addresses. 3.3.1. LHS and RHS Names Known In this scenario the user has been presented with the SLS-enhanced email address of a friend on their business card. The address is "Ima Sample@Example Technologies, Inc". The user enters this address into their SLS-enhanced mailer which then decomposes the email address into its Right and Left Hand Side components. The RHS is sent to the same SLS providers as above and the results are provided to the user. In this case the user knows that there are several companies with that name but she is aware that this particular one is an aerospace contractor in England. In some cases the results contain a referral to an SLS service that is specific to that email service. The user picks a record that has such a referral and the mail agent then sends an SLS query for the LHS of the address to the Hollenbeck, et al. Expires April 7, 2006 [Page 10] Internet-Draft SLS Rationale October 2005 SLS service found in that referral. That local service then sends the matches for "Ima Sample" back to the user. These records contain pointers to "real" RFC 2822 addresses that the user's mail client can actually use to send email. 3.3.2. Full Human Address Known, Bookmarked In the case the address or the RHS of a previous address that has been previously queried for the same behavior above can be inserted. In the case where the RHS is in the cache but the LHS is not the disambiguation step might have to be done. In either case, the results are again inserted into the user's local cache and used according to user interface requirements. 4. IANA Considerations This document does not require IANA action. 5. Security Considerations TBD 6. Acknowledgements The authors would like to thank the following people who have provided significant contributions to the development of this document: TBD. 7. Informative References [I-D.klensin-dns-search] Klensin, J., "A Search-based access model for the DNS", draft-klensin-dns-search-06 (work in progress), February 2004. [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. Hollenbeck, et al. Expires April 7, 2006 [Page 11] Internet-Draft SLS Rationale October 2005 Authors' Addresses Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 USA Email: shollenbeck@verisign.com Leslie L. Daigle Cisco Systems 13600 Dulles Technology Drive Herndon, VA 20171 USA Phone: +1 703 484 0076 Email: leslie@thinkingcat.com, ledaigle@cisco.com Michael Mealling Refactored Networks, LLC 1635 Old Hwy 41 Suite 112, Box 138 Kennesaw, GA 30152 USA Phone: +1 678 581 9656 Email: michael@refactored-networks.com URI: http://www.refactored-networks.com Hollenbeck, et al. Expires April 7, 2006 [Page 12] Internet-Draft SLS Rationale October 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Hollenbeck, et al. Expires April 7, 2006 [Page 13]