[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02

Network Working Group                                        M. Mealling
Internet-Draft                                                 L. Daigle
Expires: January 11, 2002                                 VeriSign, Inc.
                                                           July 13, 2001


                      Service Lookup System (SLS)
                         draft-mealling-sls-00

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 January 11, 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 January 11, 2002                [Page 1]


Internet-Draft            Service Lookup System                July 2001


   strawman called the Service Lookup System (SLS).

1. 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
   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'."




Mealling & Daigle       Expires January 11, 2002                [Page 2]


Internet-Draft            Service Lookup System                July 2001


   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.

2. 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 discusses the technical and policy problems and solutions
   for a Layer 2 service.

3. 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



Mealling & Daigle       Expires January 11, 2002                [Page 3]


Internet-Draft            Service Lookup System                July 2001


   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
   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



Mealling & Daigle       Expires January 11, 2002                [Page 4]


Internet-Draft            Service Lookup System                July 2001


      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).


3.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
   answers back or have the same name be differentiated by a parameter.



Mealling & Daigle       Expires January 11, 2002                [Page 5]


Internet-Draft            Service Lookup System                July 2001


   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.

3.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.

   o  While locale in its various standardized forms does communicate



Mealling & Daigle       Expires January 11, 2002                [Page 6]


Internet-Draft            Service Lookup System                July 2001


      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
      not, then is the requirement that _all_ character sets be



Mealling & Daigle       Expires January 11, 2002                [Page 7]


Internet-Draft            Service Lookup System                July 2001


      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.


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



Mealling & Daigle       Expires January 11, 2002                [Page 8]


Internet-Draft            Service Lookup System                July 2001


   and addresses providing specific identification.  In fact, the
   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 January 11, 2002                [Page 9]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 10]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 11]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 12]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 13]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 14]


Internet-Draft            Service Lookup System                July 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 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 January 11, 2002               [Page 15]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 16]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 17]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 18]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 19]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 20]


Internet-Draft            Service Lookup System                July 2001


   S:     </resourcedescriptor>
   S:     <resourcedescriptor>
   S:              .... other results from other categories
   S:     </resourcedescriptor>
   S:  </results>
   S:</cnrp>

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.


Authors' Addresses

   Michael Mealling
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

   EMail: michael@research.netsol.com
   URI:   http://www.verisign.com









Mealling & Daigle       Expires January 11, 2002               [Page 21]


Internet-Draft            Service Lookup System                July 2001


   Leslie Daigle
   VeriSign, Inc.
   21345 Ridgetop Circle
   Sterling, VA  20166
   US

   EMail: leslie@research.netsol.com
   URI:   http://www.verisign.com











































Mealling & Daigle       Expires January 11, 2002               [Page 22]


Internet-Draft            Service Lookup System                July 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 January 11, 2002               [Page 23]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/