Network Working Group M. Mealling
Internet-Draft L. Daigle
Expires: May 22, 2002 VeriSign, Inc.
November 21, 2001
Service Lookup System (SLS)
draft-mealling-sls-01.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 May 22, 2002.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
Developing technology to allow for truly internationalized Internet
identifiers is proving a hard nut to crack within the framework of
the existing 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 resources. What
is not clear is whether the existing DNS can be transformed into a
service that can handle the more human oriented identification
services it is now being asked to provide. This document embraces,
extends and complements a proposal by John Klensin to address the
requirements for a directory layer above the existing DNS that can
better solve these problems. The discussion concludes by proposing a
Mealling & Daigle Expires May 22, 2002 [Page 1]
Internet-Draft Service Lookup System November 2001
strawman called the Service Lookup System (SLS).
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Problem Statement . . . . . . . . . . . . . . . . . . 3
3. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . 5
3.1 Transitioning from DNS to something else . . . . . . . . . 5
3.2 Web Browsing . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1 Never resolved but the name is known . . . . . . . . . . . 5
3.2.2 The name is known and it has been resolved before . . . . 6
3.2.3 The name is not known but other characteristics are known 7
3.3 Sending email . . . . . . . . . . . . . . . . . . . . . . 7
3.3.1 LHS and RHS names are known . . . . . . . . . . . . . . . 7
3.3.2 Full human address known and has been bookmarked . . . . . 8
3.4 A Story From the Past . . . . . . . . . . . . . . . . . . 8
4. A Strawman Proposal: The Service Lookup System (SLS) . . . 9
4.1 Network Service Record (NSR) . . . . . . . . . . . . . . . 9
4.2 Content of the NSR . . . . . . . . . . . . . . . . . . . . 10
4.3 NSR Population . . . . . . . . . . . . . . . . . . . . . . 10
4.4 Service Lookup System (SLS): Looking up NSRs . . . . . . . 11
4.5 Services . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.6 Mapping the SLS onto CNRP . . . . . . . . . . . . . . . . 12
4.6.1 An Introduction to the Common Name Resolution Protocol
(CNRP) . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.6.2 CNRP Service Definition . . . . . . . . . . . . . . . . . 14
4.6.2.1 CNRP Properties as Facets . . . . . . . . . . . . . . . . 14
4.6.2.2 Service Object XML . . . . . . . . . . . . . . . . . . . . 14
4.6.3 Contextual Uniqueness . . . . . . . . . . . . . . . . . . 15
4.6.4 Results Restrictions . . . . . . . . . . . . . . . . . . . 16
4.7 SLS Example Scenarios . . . . . . . . . . . . . . . . . . 16
4.7.1 The DNS Service . . . . . . . . . . . . . . . . . . . . . 16
4.7.2 The Web Service . . . . . . . . . . . . . . . . . . . . . 17
4.7.3 The Web Service With Ambiguous Results . . . . . . . . . . 18
4.7.4 The Web Service With Ambiguous Query and Results . . . . . 20
5. Rational . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1 Interesting DNS Characteristics . . . . . . . . . . . . . 22
5.2 Requirements Decisions . . . . . . . . . . . . . . . . . . 23
References . . . . . . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 26
A. SLS Service Provider Discovery . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . 29
Mealling & Daigle Expires May 22, 2002 [Page 2]
Internet-Draft Service Lookup System November 2001
1. Introduction
In "A Search-based access model for the DNS" [1], the author
discusses approaching the problems of international domain-names 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 and category.
Layer 3 -- Commercial, localized, and topic-specific search
environments.
This memo describes the problem statement, reviews intended usage
scenarios, provides a straw proposal for implementing a Layer 2
service, and discusses the rational that ties these elements
together.
2. The 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 (Google) and localized/topic specific directory services
(LDAP); e.g. very human and/or task specific services. 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 exactly what is the problem Layer 2
will attempt to solve?
Much of the discussion to date surrounding this topic has been
directly associated with internationalization of Internet identifiers
(specifically domain-names). For Western cultures the need for
anything beyond simple matches on characters is not immediately
apparent. Since the Internet, and DNS specifically, were designed
using Western characters, it is much easier for Western speakers to
learn to live with the limitations and thus those limitations aren't
as glaringly apparent. But when confronted with other character sets
from Asian languages, 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, at least for some not insignificant portion of the
participants, the problems that are attempting to be solved are
Mealling & Daigle Expires May 22, 2002 [Page 3]
Internet-Draft Service Lookup System November 2001
beyond DNS' capabilities. It is exactly the work being done in the
IDN Working Group that is bringing these problems to light.
It is also interesting to look at what might be the root cause of all
of these problems. In the authors' opinion, 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 used to identify complex services that have no concrete network
level representation. 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 'cnn.com'. The user's view of the process is that he/she is
requesting the current news from CNN via the Internet. The problem
is that IDN and similar efforts are attempting to force the user's
service-oriented view of the world into a network protocol view.
The various problems and feature desires discussed in the IDN process
involve some of the following:
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.
o Localization -- In some cases there are semantic differences in
what an appropriate match should be that are based on location,
jurisdiction, or region specific dialect.
o Geographic scoping -- In some 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 sugar -- 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).
Mealling & Daigle Expires May 22, 2002 [Page 4]
Internet-Draft Service Lookup System November 2001
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
above is framed in terms of the following examples.
3.1 Transitioning from DNS to something else
In order to deploy anything at Layer 2, a transition method would
have to be put in place to allow for users to a) use domain-names
within the system and b) use Layer 2 names in place of domain-names.
A usage example would look like this:
A user at a web browser wants to go to the web site for "CNN". Their
browser has rudimentary software installed that can handle the term
"CNN" as Layer 2 service name instead of a munged Layer 1 domain-name
but only by 'acting' as a shim above that browsers Layer 1 interface.
Therefore the users query 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 the
disambiguation step. The results are kept in a cache but as far as
the browser is concerned, it has still received a simlpe '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 822
[6] rules. The same shim layer is called on the Right Hand Side
(RHS) of the address only per RFC 822's rules. The query is 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
enables it then extreme care must be taken so that recursive
resolution doesn't happen between a full implementation of the
service and this 'shim'. I.e. if the result of a full enabled
client query is then input into an 'shim' then serious
usability/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 Never resolved but the name is known
One of the main uses of SLS style names is that they help solve the
'guessing' function that many users are forced to do with DNS names.
With DNS a guess is required because the most likely name is often
Mealling & Daigle Expires May 22, 2002 [Page 5]
Internet-Draft Service Lookup System November 2001
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
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 SLS name "McDonald's". This name,
plus defaults provided by the browser that the user previously
configured (location, locale, interests, etc), are sent to the users
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 tradename "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 at which
point their browser is told to request that particular URI. At the
same time, that record is also inserted into the users local cache of
service records.
3.2.2 The name is known and it has been resolved before
In this scenario the user is requesting the same SLS 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
o re-query to the current list of SLS service providers, but
displaying the users locally cached records first
Mealling & Daigle Expires May 22, 2002 [Page 6]
Internet-Draft Service Lookup System November 2001
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. In this case the user never sees the
disambiguation step and thus is immediately sent back to the same
service as before.
3.2.3 The name is not known but other characteristics are 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 an SLS name but
instead is 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
what SLS provides but augmented with additional values that helps the
user differentiate between which locksmith they're looking for.
These records also contain the SLS name for each service, thus
populating the users 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, SLS-names are used as components of SLS-enhanced
email addresses.
3.3.1 LHS and RHS names are 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
SLS service found in that referral. That local service then sends
the matches for "Ima Sample" back to the user. These records contain
Mealling & Daigle Expires May 22, 2002 [Page 7]
Internet-Draft Service Lookup System November 2001
pointers to 'real' RFC 822 addresses that the user's mail client can
actually send email to.
3.3.2 Full human address known and has been bookmarked
In the case where the address or the RHS of a previous addresss has
been previously queried for the same bevahior above can be inserted.
In the case where the RHS is in the cache but the LHS is not the
disambiguation step (if needed) would have to be done. In either
case, the results are again inserted into the users local cache and
used according to the user interface requirements.
3.4 A Story From the Past
Approximately 100,000 years ago a primitive human named Og was
sitting in his cave examining his possessions. It had been a
particularly good hunting season that year, and as a result, Og had a
large number of furs, spears, and other cave man type stuff. Og
began to be confused by the amount of stuff he had to manage so he
began to give some of this stuff a name. The fur he was wearing
became 'Og's Coat' and his spear became 'Og's Favorite Spear'.
Things became manageable once again.
One sunny prehistoric day, Og decided to take a walk. As he exited
his cave he noticed a column of smoke a few miles away and decided to
investigate, this being the unique trait of his species. As he
approached the fire he noticed that it was burning in an arrangement
similar to his own but this fire was burning next to a gracefully
flowing river. There were items similar to his own next to the fire.
As he approached closer he noticed a man sitting next to the fire
working on an animal fur.
It had been many years since Og had seen another person; thus, Og
approached cautiously. The other cave man noticed Og and, as he
approached, said "Hello. My name is Og. What is your name?" Og was
quite startled by this development since he did not know what to make
of someone claiming to be him. Perplexed by Og's silence, the other
cave man held out the fur he was working and said, "This is Og's new
fur coat. I call it 'Og's Coat'. What do you think of it?" This
further perplexed Og since 'Og's Coat' was the coat that Og was
currently wearing. Og finally broke his silence and explained this
perplexing situation to the new cave man. This situation also
concerned the new cave man since he also didn't know what to do with
the idea of someone claiming to be him.
After a few hours of halting discussion both men noticed a cave woman
walking toward them from further down the river. As she approached
she introduced herself as Og which completely fouled up each cave
Mealling & Daigle Expires May 22, 2002 [Page 8]
Internet-Draft Service Lookup System November 2001
man's sense of identity. The cave woman was amused by their reaction
and laughed out loud. The cave men stopped arguing and looked at her
and asked how she could laugh at a time like this. She sat down next
to Og's fire and began to explain to the cave men the new
technological development of qualified names. To the original Og she
said, "You are now known as Og From The Cave." To the new cave man
she said, "And you are Og By The River." She held up Og By The
River's coat and said, " The name of the coat is 'Og By The River's
Coat'."
The two men looked at each other in amazement and expressed their
gratitude to the cave woman for solving their problem. Finally they
asked, "But what is your name?". She chuckled and said, "Og That Is
Smarter Than Men".
The moral of this story is this: if our ancestors discovered the
ability of qualifying names with various facets such as location or
category why do we insist on using a technology (DNS) that doesn't
have this ability? This story has its origin with John Klensin and
has been used in numerous conversations to illustrate the need for
something above and beyond the DNS.
4. A Strawman Proposal: The Service Lookup System (SLS)
4.1 Network Service Record (NSR)
Many of the stresses and strains being put on the DNS stem from the
fact that it was designed as a simple name to number mapping system
for network machines, but is now being called upon to be the tool to
map from real world entities (companies, individuals, services) into
network services. 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.
Network Service Records (NSRs) act as the "glue" between real world
entities and network services. They do not replace the DNS in form
or function. These are administrative records, containing
information that will allow users to identify (recognize) real world
entities. They can be used on an occasional basis to obtain specific
network (machine interpretable) identifiers.
NSRs are different than URIs, which are machine interpretable names
and addresses providing specific identification. In fact, the
Mealling & Daigle Expires May 22, 2002 [Page 9]
Internet-Draft Service Lookup System November 2001
network identifiers provided in the NSR are URIs.
The results of an NSR lookup may be stored in user software (e.g.,
bookmark lists, caches, mail address books, buddy lists). Done
right, the NSR label will be interpretable by human users (perhaps
even attaining the elusive goal of "human friendliness") while DNS
and other network identifiers continue to evolve to meet technical
needs (necessarily not being "human-friendly" to the bulk of the
world's population).
The format of an NSR is undefined here since it is more likely to be
dependent on the requirements of the service used to look them up.
In the strawman SLS proposal below the format is inherited from the
ResourceDescriptor element from CNRP.
4.2 Content of the NSR
The NSR contains, minimally, an identifier label and several other
elements of descriptive information concerning the network service.
These are called "facets" of the network service. Additionally, the
NSR contains identifiers for specific network services registered in
the NSR.
NSRs are globally unique across the label AND descriptive facet data.
That is, many NSRs may have the same label, if they differ in the
values of other facet data.
4.3 NSR Population
NSRs are registered on an opt-in basis. An organization or
individual wishing to identify their network service(s) through a
particular label may register the label and associated facet
information with any NSR registry service, pursuant to the uniqueness
criteria mentioned above.
It is not expected that domain name holders, organizations, or
individuals will register an NSR for each host name within their
domain. Rather, the NSR is independent of network devices. One
service (e.g., what we today know of as an HTTP server operating for
a particular domain) may have several NSRs to reflect different
labels for the service entity. And, that may be the only "machine"
within an organizations network that has an NSR registered to
identify its services. All network services are accessible through
the traditional, existing network identifiers (host+port+protocol,
URIs, etc).
Mealling & Daigle Expires May 22, 2002 [Page 10]
Internet-Draft Service Lookup System November 2001
4.4 Service Lookup System (SLS): Looking up NSRs
The basic lookup operations that are considered valid for effecting
NSR to network service identifier mappings are:
o NSR label (required, whole string)
o NSR descriptive facets (optional, substring allowed)
o Target Service (required, from designated list of possible)
o Additional descriptive data about the user's linguistic and
geographic preferences (optional)
The NSR label is required, in full, since this is a lookup service
not a data mine. That being said, individual NSR directory services
may apply local matching heuristics to retrieve NSRs that are "like"
what the user is looking for, at their discretion, and in order to
accommodate potential difficulties in matching transcriptions.
Additionally, NSR directory services may use the additional user
descriptive information (language, locale, etc) to determine a match
against the set of NSRs it has.
The response to an NSR lookup request will be 0 or more NSRs.
4.5 Services
The target services are:
'dns' -- Any DNS record type designated by the 'dns:' URI scheme [2].
The service facet in the query for the NSR(s) is specified in the
form of 'dns:<classtype>:<querytype>'. For example, to request an
MX record the service would be 'dns:1:15'.
'web' -- The request is for the URI of a web page used for browsing
by a user. The result SHOULD either be a URI with the 'http'
scheme or a 'dns:' URI pointing to the A record(s) for the web
server.
'email' -- In general, the NSR is targeted at identifying network
services as a whole. This is useful in solving today's problem of
trying to support catchy phrases for identifying a corporation's
main website, but is not useful for replacing e-mail addresses on
business cards.
Insofar as e-mail addresses comprise identification of particulars
(string on the lefthand side of the "@") at a particular service
(SMTP), it is not a far stretch to think of developing a companion
Mealling & Daigle Expires May 22, 2002 [Page 11]
Internet-Draft Service Lookup System November 2001
standard to identify particulars within a given service. That is,
the NSR could be used to find the network location of the
particular service, and then the particular identifier would be
mapped into the local part of the network address.
Although the conventions for expressing NSR label and the
particular identifier (e.g., on a business card) are well beyond
the scope of this document, consider for example:
I might express my e-mail service as:
Leslie Daigle <not a valid e-mail address -- the space>
at
Le Chat Pensant <not a valid SMTP server name>
The SLS service will provide a DNS URI that identifies either an
MX or A record for the relevant SMTP service (thinkingcat.com) as
well as a referral to another SLS service that can map "Leslie
Daigle" to some value that is valid for that SMTP service (in this
case 'leslie'), yielding 'leslie@thinkingcat.com' to be stored in
an e-mail address book.
4.6 Mapping the SLS onto CNRP
As part of the proposal the SLS is mapped onto the Common Name
Resolution Protocol (CNRP) [3]. CNRP was designed to handle services
with many of the same requirements and thus makes an easy match for
discussing particular aspects of the proposal. One important issue
is that operational requirements may require that the XML encoding
and HTTP transports be dropped in favor of something with a smaller
network 'footprint'.
4.6.1 An Introduction to the Common Name Resolution Protocol (CNRP)
CNRP is a protocol that is encoded in XML and transported via HTTP
(as mandatory to implement, other transports are valid). The basic
component of CNRP is the 'Common Name'. This is the item that is
being looked up. In addition to the Common Name, a query can contain
Properties. Properties have names and types. A Property type is an
identifier for which controlled vocabulary the value is drawn from.
CNRP general feature list includes:
o Unicode -- While standard XML conventions allow for specifying
additional language and character set values, CNRP is required to
be expressed in Unicode using the encoding specified in the XML
Mealling & Daigle Expires May 22, 2002 [Page 12]
Internet-Draft Service Lookup System November 2001
document header.
o Referral support -- A CNRP server can send a message to the client
which tells the client what server and possible dataset an answer
might be found in.
o No requirements on the CN -- CNRP makes no other requirements on
the CN other than being expressed in Unicode.
o No requirements on match semantics -- CNRP puts no requirements on
a service provider as to what match semantics they may or may not
use. The query is series of hints only. It is up to other
standards to define services using CNRP that adhere to specific
rules.
o Only three Properties defined -- CNRP defines the Location,
Language and Category properties in addition to a process for
defining new Properties.
Results within CNRP are encoded as ordered sets of either referrals,
status codes or ResourceDescriptors. It is the ResourceDescriptor
which is used as the encoding of the NSR. The following is an
example of a ResourceDescriptor acting as an NSR returned in response
to a query for the name 'Joe's Example Mart':
<results>
<service id="i0">
<serviceuri>http://sls.bar.com/</serviceuri>
</service>
<resourcedescriptor id="i1">
<commonname>Joe's Example Mart</commonname>
<id>foo.com:234364</id>
<resourceuri>http://acme.example.com/~joe/examples/</resourceuri>
<serviceref ref="i0" />
<description>A purveyor of fine examples</description>
<property name="locale" type="rfc1766">en-uk</property>
<property name="location" type="sls">gb-ham</property>
<property name="service">web</property>
<property name="category" type="nice">380023</property>
</resourcedescriptor>
</results>
Mealling & Daigle Expires May 22, 2002 [Page 13]
Internet-Draft Service Lookup System November 2001
4.6.2 CNRP Service Definition
4.6.2.1 CNRP Properties as Facets
The concept of facets is handled with CNRP properties. Properties
have both a name and a type. Properties can be valid for either
queries or results or both.
The location property has a new type defined that is hierarchical in
nature with each level separated by a "-". The first level is taken
from ISO-3166-1 two letter country codes. The second level is taken
from ISO-3166-2. Third and subsequent levels are defined by the
previous level. For example, the city of Lubbock, Texas would use:
us-tx-lubbock.
The language property is restricted to the values found in RFC 3066
[5]
The type of the category property is 'nice' which designates the
classification of goods and services found in the Nice Agreement on
International Classification of Products and Services [4].
The service property is the type of service being requested. The
list of services is made up of the complete list of DNS QTYPEs and
QCLASS-es plus specific services defined in Section 4.5. The format
of the service designator is defined by each service.
The source service ID is a required CNRP property but it is listed
here to be sure to note that uniqueness discussed earlier includes
the source of the results as one of the facets that determine
uniqueness.
4.6.2.2 Service Object XML
SLS defines a new CNRP property called 'cnrp-service-type' which is
used to notify the client that this service adheres to the SLS
standard. This is why the service object doesn't actually need to
define all of the SLS facets as CNRP properties.
Mealling & Daigle Expires May 22, 2002 [Page 14]
Internet-Draft Service Lookup System November 2001
<?xml version="1.0"?>
<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
"http://ietf.org/dtd/cnrp-1.0.dtd">
<cnrp>
<results>
<service ttl="43200">
<serviceuri>urn:foo:bar</serviceuri>
<servers>
<server>
<serveruri>http://host1.example.com:4321</serveruri>
</server>
<server>
<serveruri>mailto:user@example.com</serveruri>
</server>
</servers>
<description>This is the ExampleCorp SLS Service</description>
<!-- This property means that this service is a SLS compliant -->
<!-- This could probably be sufficient but we'll list all -->
<!-- of the properties anyway just for completeness -->
<property name="cnrp-service-type">sls</property>
<propertyschema>
<propertydeclaration id="i1">
<propertyname>cnrp-service-type</propertyname>
<propertytype default="yes">iana</propertytype>
</propertydeclaration>
<!-- CNRP defines the location, language and category -->
<!-- properties for us -->
</propertyschema>
</service>
</results>
</cnrp>
4.6.3 Contextual Uniqueness
A CNRP service MUST have one and only one answer for any COMPLETE set
of facets. This includes the facet that is the service name itself.
This means that essentially uniqueness of a given name is at the
service level. Thus, if a query is sent to more than one service,
each one may send back valid answers. These are considered different
NSRs (because they differ in the service facet).
Also, if a particular facet is set to a higher level of some
hierarchical value or set to a wildcard type match semantic, it is
also possible to get multiple answers for the query. What this means
and how applications should deal with it is up for discussion since
this behavior is the one aspect of Layer 2 that directly affects
Mealling & Daigle Expires May 22, 2002 [Page 15]
Internet-Draft Service Lookup System November 2001
usability.
4.6.4 Results Restrictions
Results are in the form of URIs. Unlike a generic CNRP service the
schemes that can be returned are explicitly defined to match the
Service facet in the request. See Section 4.5 for the list of
Service to Results URI matchings and the semantics of those matches.
4.7 SLS Example Scenarios
The following scenarios show how a few services might be used in
'real world' situations.
4.7.1 The DNS Service
The DNS SLS service is meant more as a method for moving from the
currently deployed infrastructure to new, SLS based systems. Imagine
an English speaking user living in Lubbock, Texas who is attempting
to browse the CNN web site. The user has pre-configured two SLS
providers but her implementation does not understand any services
beyond the 'dns' service. The first provider is scoped to her
metropolitan area and the second handles names with a more global
scope. The user attempts to ask for the 'dns:1:1' service for the
name 'CNN' with their location set to 'us-tx-lubbock', their language
(locale) set to 'en-us'. They leave the category blank. The query
is sent to both the locally and globally scoped services. The
locally scoped service returns no results and the global one returns
the URI 'dns:www.cnn.com;type=a'.
The same scenario could work for leveraging legacy services such as
ftp, instant messaging and even email (if applied carefully).
The exact transaction between the client and server looks like this.
The client connects to the server (over some transport) and issues
this request:
Mealling & Daigle Expires May 22, 2002 [Page 16]
Internet-Draft Service Lookup System November 2001
C:<?xml version="1.0"?>
C: <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
C: "http://ietf.org/dtd/cnrp-1.0.dtd">
C: <cnrp>
C: <query>
C: <commonname>cnn</commonname>
C: <property name="geography" type="sls">us-tx-lubbock</property>
C: <property name="locale" type="posix">en-us</property>
C: <property name="category" type="nice"></property>
C: <property name="service" type="sls">dns:1:1</property>
C: </query>
C: </cnrp>
S:<?xml version="1.0"?>
S:<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
S: "http://ietf.org/dtd/cnrp-1.0.dtd">
S:<cnrp>
S: <results>
S: <service id="i0">
S: <serviceuri>http://example.com</serviceuri>
S: </service>
S: <resourcedescriptor>
S: <commonname>CNN</commonname>
S: <id>1333459455</id>
S: <resourceuri>dns:www.cnn.com;type=A</resourceuri>
S: <serviceref ref="i0" />
S: <description>The Cable News Network (tm)</description>
S: <property name="geography" type="sls">global</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">380012</property>
S: <property name="service" type="sls">web</property>
S: </resourcedescriptor>
S: </results>
S:</cnrp>
4.7.2 The Web Service
The end goal is a more task specific service query. Take the
previous scenario as a starting point but instead the user's client
can understand the 'web' service. In this case the user is
interested in the 'CNN Travel' name. They send the same query to
both services and again the locally scoped one returns nothing but
the globally scoped one returns the URI 'http://www.cnn.com/TRAVEL/'.
Note how the name given by the user is all lower case but it matches
the upper case. This can safely be done because the locale specifies
sorting and matching algorithms specifically. The entity that
Mealling & Daigle Expires May 22, 2002 [Page 17]
Internet-Draft Service Lookup System November 2001
registered the name can specify whether or not the name is case
sensitive or not.
Again, the actual XML sent looks like this:
C:<?xml version="1.0"?>
C: <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
C: "http://ietf.org/dtd/cnrp-1.0.dtd">
C: <cnrp>
C: <query>
C: <commonname>cnn travel</commonname>
C: <property name="geography" type="sls">us-tx-lubbock</property>
C: <property name="locale" type="posix">en-us</property>
C: <property name="category" type="nice"></property>
C: <property name="service" type="sls">web</property>
C: </query>
C: </cnrp>
S:<?xml version="1.0"?>
S:<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
S: "http://ietf.org/dtd/cnrp-1.0.dtd">
S:<cnrp>
S: <results>
S: <service id="i0">
S: <serviceuri>http://example.com</serviceuri>
S: </service>
S: <resourcedescriptor>
S: <commonname>CNN Travel</commonname>
S: <id>1333459455</id>
S: <resourceuri>http://www.cnn.com/TRAVEL/</resourceuri>
S: <serviceref ref="i0" />
S: <description>The Cable News Network: Travel
S: Section(tm)</description>
S: <property name="geography" type="sls">global</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">380012</property>
S: <property name="service" type="sls">web</property>
S: </resourcedescriptor>
S: </results>
S:</cnrp>
4.7.3 The Web Service With Ambiguous Results
Now, imagine the last scenario but with the name as "John's Computer
Repair". In this case the user still asks for the 'web' service but
the locally scoped provider returns one result and the globally
Mealling & Daigle Expires May 22, 2002 [Page 18]
Internet-Draft Service Lookup System November 2001
scoped one also returns a result. The one returned by the locally
scoped provider is for a computer repair company just down the street
from the user. The one from the globally scoped provider is for a
computer repair company that advertises around the world. The user's
client presents the user with a choice between the two and the user
chooses.
In this case the exact same query is sent to both servers:
C:<?xml version="1.0"?>
C: <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
C: "http://ietf.org/dtd/cnrp-1.0.dtd">
C: <cnrp>
C: <query>
C: <commonname>john's computer repair</commonname>
C: <property name="geography" type="sls">us-tx-lubbock</property>
C: <property name="locale" type="posix">en-us</property>
C: <property name="category" type="nice"></property>
C: <property name="service" type="sls">web</property>
C: </query>
C: </cnrp>
The locally scopped server returns this:
S:<?xml version="1.0"?>
S:<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
S: "http://ietf.org/dtd/cnrp-1.0.dtd">
S:<cnrp>
S: <results>
S: <service id="i0">
S: <serviceuri>http://lubbock-tx-example.com</serviceuri>
S: </service>
S: <resourcedescriptor>
S: <commonname>John's Computer Repair</commonname>
S: <id>1333459455</id>
S: <resourceuri>http://www.lubbocknet/~john/</resourceuri>
S: <serviceref ref="i0" />
S: <description>Serving the Lubbock, TX computer user since 1948
S: </description>
S: <property name="geography" type="sls">us-tx-lubbock</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">370166</property>
S: <property name="service" type="sls">web</property>
S: </resourcedescriptor>
S: </results>
S:</cnrp>
Mealling & Daigle Expires May 22, 2002 [Page 19]
Internet-Draft Service Lookup System November 2001
while the globally scoped one returns this:
S:<?xml version="1.0"?>
S:<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
S: "http://ietf.org/dtd/cnrp-1.0.dtd">
S:<cnrp>
S: <results>
S: <service id="i0">
S: <serviceuri>http://example.com</serviceuri>
S: </service>
S: <resourcedescriptor>
S: <commonname>John's Computer Repair</commonname>
S: <id>1333459455</id>
S: <resourceuri>http://www.computer-repair.biz/</resourceuri>
S: <serviceref ref="i0" />
S: <description>Worldwide hardware repair and software consulting
S: via mail order</description>
S: <property name="geography" type="sls">global</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">370166</property>
S: <property name="service" type="sls">web</property>
S: </resourcedescriptor>
S: </results>
S:</cnrp>
4.7.4 The Web Service With Ambiguous Query and Results
The previous example can also happen when the user specifies an
ambiguous, blank or multivalued facet. For example, since the user
never specified a category, "John's Computer Repair" could have
matched several different NSRs that had the same name but different
facet values. A more likely example would be 'Genesis' (the band and
the hydraulics company). If the user were to specify a query for
Genesis and left the category blank then the user could consievably
get a large number of answers back:
Mealling & Daigle Expires May 22, 2002 [Page 20]
Internet-Draft Service Lookup System November 2001
C:<?xml version="1.0"?>
C: <!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
C: "http://ietf.org/dtd/cnrp-1.0.dtd">
C: <cnrp>
C: <query>
C: <commonname>Gensis</commonname>
C: <property name="geography" type="sls">us-tx-lubbock</property>
C: <property name="locale" type="posix">en-us</property>
C: <property name="category" type="nice"></property>
C: <property name="service" type="sls">web</property>
C: </query>
C: </cnrp>
which would return in a series of results:
S:<?xml version="1.0"?>
S:<!DOCTYPE cnrp PUBLIC "-//IETF//DTD CNRP 1.0//EN"
S: "http://ietf.org/dtd/cnrp-1.0.dtd">
S:<cnrp>
S: <results>
S: <service id="i0">
S: <serviceuri>http://example.com</serviceuri>
S: </service>
S: <resourcedescriptor>
S: <commonname>Genesis</commonname>
S: <id>1333459455</id>
S: <resourceuri>http://www.sony.com/genesis</resourceuri>
S: <serviceref ref="i0" />
S: <description>The band</description>
S: <property name="geography" type="sls">global</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">410023</property>
S: <property name="service" type="sls">web</property>
S: </resourcedescriptor>
S: <resourcedescriptor>
S: <commonname>Genesis</commonname>
S: <id>2345432</id>
S: <resourceuri>http://www.genesis-hydraulics.com/genesis
S: </resourceuri>
S: <serviceref ref="i0" />
S: <description>Providing world wide hydraulics engineering
S: services sinde 1973</description>
S: <property name="geography" type="sls">global</property>
S: <property name="locale" type="posix">en-us</property>
S: <property name="category" type="nice">370166</property>
S: <property name="service" type="sls">web</property>
Mealling & Daigle Expires May 22, 2002 [Page 21]
Internet-Draft Service Lookup System November 2001
S: </resourcedescriptor>
S: <resourcedescriptor>
S: .... other results from other categories
S: </resourcedescriptor>
S: </results>
S:</cnrp>
5. Rational
This section discusses the proposal's underlying design rational,
derived from experience with the DNS and other naming systems.
5.1 Interesting DNS Characteristics
While the goal of Layer 2 is to be human-friendly, it is still a
lookup service that must be sufficiently deterministic so that higher
level services can be built which will give the user a consistent
experience.
Some of the DNS' current characteristics are worth emulating because
it is sufficiently deterministic to support building services. The
important characteristics are:
o limited match semantics (lookup only)
o Deterministic relationship between the name and the answer set
o all public names are globally available
o in the case of an A record, the result is service independent.
The client can use the result for multiple purposes by connecting
to any service specific port on the host instead of requiring with
a per service query.
o query routing is based on the hierarchical structure of the name
that is being looked up.
One of the fundamental differences between the DNS and a Layer 2
service is that, with DNS, the user is required to know exactly which
answer set they need in the form of the name being looked up. This
leads to practices such as putting a 'www' as a third level domain-
name in order to denote the kind of service the user is requesting.
This is primarily caused by the lack of additional parameters that
can be sent by a DNS query, resulting in any 'parameters' being part
of the name being looked up. The additional fact that a name can
only match one discrete answer set means that a client cannot ask an
intentionally ambiguous question about a name and get two complete
Mealling & Daigle Expires May 22, 2002 [Page 22]
Internet-Draft Service Lookup System November 2001
answers back or have the same name be differentiated by a parameter.
One of the goals of a good Layer 2 service would be to separate the
uniqueness of the results record set from the name used to lookup
that record set. This does result in the case where a client may be
required to disambiguate between two or more record sets when the
client does not provide sufficient information in the query for the
service to do the disambiguation. This case may arrise when the
query does not include all of the facets or when one of the facets is
intentionally not fully specified (i.e. a location that is specified
to be an entire continent instead of some specific city).
Another question is whether or not any query routing algorithms are
based on structure requirements of the names themselves. Unlike the
DNS, the Layer 2 service has facets that can be used to route
queries. In this case there is no need for that structure to be in
the name, and since such structure would be injurious to the goal of
being as human-friendly as possible, hierarchy requirements are moved
to the facet that requires it instead of into the name itself. I.e.,
the facet system is multi-hierarchical, while the names themselves
are flat.
5.2 Requirements Decisions
The above analysis simply illustrates many questions and possible
answers. The more obvious requirements from the above are:
o Names are, at the very least, encoded using the complete Unicode
codeset without restriction and without normalization.
o At the very least, locale is a supported facet, both as an
optional query component and as part of the result set.
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 no requirements that the names are structured
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.
Mealling & Daigle Expires May 22, 2002 [Page 23]
Internet-Draft Service Lookup System November 2001
o While locale in its various standardized forms does communicate
some aspects of 'location', additional information is needed in
order to support various human assumptions such as trademark law
and locality of reference (geographic and category scoping).
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.
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
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.
Questions still to be answered are:
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
Mealling & Daigle Expires May 22, 2002 [Page 24]
Internet-Draft Service Lookup System November 2001
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.
References
[1] Klensin, J., "A Search-based access model for the DNS", Internet
Draft draft-klensin-dns-search-00.txt, May 2001,
<http://www.ietf.org/internet-drafts/draft-klensin-dns-search-
00.txt>.
[2] Josefsson, S., "DNS URL scheme", Internet Draft draft-josefsson-
dns-url-01.txt, June 2001, <http://www.ietf.org/internet-
drafts/draft-josefsson-dns-url-01.txt>.
[3] Popp, N., Mealling, M. and M. Moseley, "Common Name Resolution
Protocol (CNRP)", Internet Draft draft-josefsson-dns-url-01.txt,
June 2001, <http://www.ietf.org/internet-drafts/draft-ietf-cnrp-
10.txt>.
[4] World Intellectual Property Organization, "Nice Agreement
concerning the International Classification of Goods and
Services for the Purposes of the Registration of Marks", June
1957.
[5] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
[6] Crocker, D., "Standard for the format of ARPA Internet text
Mealling & Daigle Expires May 22, 2002 [Page 25]
Internet-Draft Service Lookup System November 2001
messages", STD 11, RFC 822, August 1982.
Authors' Addresses
Michael Mealling
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: michael@verisignlabs.com
EMail: michael@neonym.net
URI: http://www.verisign.com
Leslie Daigle
VeriSign, Inc.
21345 Ridgetop Circle
Sterling, VA 20166
US
EMail: leslie@verisignlabs.com
EMail: leslie@thinkingcat.com
URI: http://www.verisign.com
Appendix A. SLS Service Provider Discovery
One of the hardest parts of the SLS system is how to discover all of
the available SLS providers in a way that is not mired in
political/social issues of ownership over spaces. The proposed
solution is a peer-to-peer style service announcement mechanism where
anyone can announce their intention to provide an SLS service. The
key to such a mechanism is being able to trust that the service has
not censored the list of advertisements. The following is a
description of such a discovery mechanism:
Components of the system:
Assertions opaque bits of data inserted into the system by Asserters.
The system makes no statements about Assertsions or checks their
validity.
Clients Those that are looking for the list of assertions. They do
not normally do verification
Asserters Systems that insert Assertions into the system and
periodically verify their existence
Advertisers The systems that handle the requests for and the
Mealling & Daigle Expires May 22, 2002 [Page 26]
Internet-Draft Service Lookup System November 2001
maintenance of the current set of all Advertisers as well as all
of the Assertions
The key here is how to make sure no one is maliciously changing the
data. The problem is that the servers advertising the data can't be
trusted with the responsibility of verifying it. The only one that
can really do it is the one who cares and who knows what the original
assertion was. Thus if Alice wants to advertise assertion X then
Alice has to request that assertion from a random number of servers
in the system at random times to verify that the assertion is
'correct' and actually being advertised.
The important case is reliably getting the "list of all servers" from
some subset of those servers in a way that makes it so that some
malicious subset can't cut the rest off. A server could filter this
list and create a constrained 'view' of the state for queriers. The
key is to apply the same method from above for server to server
verification. Servers will request the list of servers from each
other on a random basis. If they don't find themselves in a
particular server's list then they complain to other servers. The
goal here is to utilize the sense of self preservation: Mutual
Assured Destruction at a distributed systems level.
The only cryptographic part is proving that someone has done a bad
thing. This is handled by signature matches and _VERY_ specific
cases where this is done. The only two that are glaringly obvious
are:
1. a client claims that server n is not advertising the client's
assertion X.
2. server n claims that some other server is not advertising it in
the list of servers.
How do you prove these cases? Pretty easily actually. All requests
to add an assertion or to join the system of servers generate a
response in the form of the "assertion" message being timestamped and
signed by the server that handled the request. (a question here is
do assertions have expirations or are they 'deleted' on request). In
case #1 the client merely has to approach another server (or servers)
and say "see, I have the signed "ok" message". The servers then go
check that server to see if it is or is not advertising the
assertion. If it is they tell the client so. If not then they
notify the server and delist it and also notify all of the other
servers. All servers verify these notifications themselves (because
they don't trust each other).
The second case is a special case of the first. Here each server has
Mealling & Daigle Expires May 22, 2002 [Page 27]
Internet-Draft Service Lookup System November 2001
the responsibility to randomly check the other servers to make sure
they are all giving out the entire list of servers. Again, when a
server wishes to join the party it receives a signed and timestamped
response to its request. If at any time it notices that some other
server is not including it in its list it sends this signed
acknowledgment to the other servers requesting that they verify this
as well. They do so and if its true then they delist the offending
server.
There are some boundary cases here that can cause the system's sense
of trust (or distrust) to fall apart. A random time out needs to be
done on delisting so that servers who have been behind a network
outage can re-synchronize. It could be engineered so that if a
network outage does make a server inaccessible the other servers
could be considered in a 'non-conclusive' state. A response to the
"you're not doing what you're supposed to do" claim would be "I am
now!". That should be fine. Should anything happen if that's
consistently a problem? Can a server be delisted for having bad
connectivity?
This discussion is very preliminary and needs review by distributed
systems and security experts.
Mealling & Daigle Expires May 22, 2002 [Page 28]
Internet-Draft Service Lookup System November 2001
Full Copyright Statement
Copyright (C) The Internet Society (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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mealling & Daigle Expires May 22, 2002 [Page 29]