Internet DRAFT - draft-hollenbeck-sls-rationale
draft-hollenbeck-sls-rationale
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]
