

Internet Engineering Task Force                         Erik Guttman
INTERNET DRAFT
Category: Informational
August 13, 2002
Expires in six months

             The serviceid: URI Scheme for Service Location
                 draft-guttman-svrloc-serviceid-02.txt

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   Comments on this document should be sent to the SLP discussion list,
   srvloc-discuss@lists.sourceforge.net.

   Internet-Drafts are draft documents of the Internet Engineering Task
   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."  See http://www.ietf.org/ietf/1id-abstracts.txt.
   Find shadow directories at http://www.ietf.org/shadow.html.

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   The Service Location Protocol (SLP) allows clients to discover
   services with little or no prior configuration.  SLP can be used to
   advertise services of any kind through the use of URLs.  However, SLP
   uses URLs for two purposes: as a LOCATOR (indicating the location of
   the service) and as an IDENTIFIER (used for subsequent operations on
   a service, such as registration, deregistration and looking up
   attributes.)  Confounding these two functions in one object leads to
   certain problems.  The serviceid: scheme separates identification
   from location, eliminating these problems.

1. Introduction

   The Service Location Protocol, Version 2 [RFC2608] [RFC2608bis]
   allows services to advertise themselves, by associating four objects
   together in a service advertisement:

    - Scope list
      A comma delimited list of strings that denote an administrative
      grouping of services.

    - Service Type
      A string representing the type of service.  The service type can
      be abstract (such as "directory-service") or concrete (such as



Guttman, E.             Expires: 3 February 2003                [Page 1]

Internet Draft            SLP Serviceid scheme               August 2002


      "ldapv3").

    - Service URL
      A URL that serves two purposes:  [1] IDENTIFICATION:  The URL is
      used to reregister, deregister or query the attributes of a
      service advertisement. [2] LOCATION:  The URL may include the
      location of the service being registered, in the form of the IP or
      other network address or the host name.

    - Attributes
      A list of attribute tag/typed value list pairs. The value list may
      be empty.

   Confounding the identification and location functions into a single
   object, namely the service URL, leads to the following problems:

     1. Identifying a logically single service available at multiple
        locations.

        Currently, separate SLP service advertisements must be made for
        each location of a service. As a result, it is impossible to
        establish the identity of a logically single service that is
        available through multiple locations. Specifically, a multihomed
        host offering the same service on multiple interfaces, or a host
        offering the same service at different ports cannot be
        distinguished from a case when separate services are offered at
        different locations. For example, are "http://a.example.com",
        "http://b.example.com" and "http://b.example.com:2346" distinct
        services or rather distinct access points for the same service?
        Since the URL is used for both location and identification,
        there is no way to determine the identity of several services
        from URLs which encode different locations.

     2. Identifying a service that is accessable through multiple
        protocols.

        Some services support multiple protocols.  For example, a single
        multiprotocol printer may support IPP, LPR, and raw tcp network
        printing job delivery.  Currently, the printer must advertise
        URLs for each protocol and each URL has only one scheme
        indicating the protocol to use to contact the printer.  Are the
        URLs "service:printer:lpr://example.com" and
        "service:printer:ipp://example.com" a single printer service
        which speaks two protocols or two distinct services?  It is not
        possible to determine, from a set of distinct URLs, whether they
        refer to different services or the same service instance
        accessable through different protocols.

     3. The service URL contains no way to indicate which transport
        protocol to use to access a service.



Guttman, E.             Expires: 3 February 2003                [Page 2]

Internet Draft            SLP Serviceid scheme               August 2002


        Some protocols can be accessed via either UDP or TCP.
        Additional transports, such as RTP, or SCTP may be used to
        access servers.  The current SLP service URL provides no way to
        determine whether a particular service is accessable through a
        particular transport protocol.  Even if the transport protocol
        were encoded in the URL, it would still not be possible to
        determine if the service supported more than one transport
        protocol, and if so, which one.  This information may be useful
        for a client capable of utilizing more than one transport
        protocol, so the client can determine which protocol to use to
        contact a particular service.

     4. Discovering the current location of particular service

        A client may need some way to specify that the location of a
        particular service should be discovered again, even if the
        service location was changed.  SLP should be able to discover
        the same printer on successive occasions, even if the printer's
        network location changes.  Currently, in SLP, there is no way to
        specify a unique identifier for the service so that a client can
        rediscover the same service.

   These problems have been difficult to overcome using the mechanisms
   SLP currently provides.

   One solution to these problems is to use a URI that is a pure
   identifier and has no locator semantics.  The service associated with
   this identifier then has a set of attributes that includes all the
   information needed to solve the five problems listed above.  This
   solution is used in the SLP service type template for IPP [IPP], but
   it is limited by the current semantics of SLP service URLs.  Having
   an identifier URL would simplify and standardize support for services
   that require separation between location and identification.

   In order to make use of the service URL scheme, a service must
   generate a unique identifier.  The service SHOULD store this
   persistently, so that the the service is always advertised the same
   id.  An example of how to generate a universally unique identifier
   (UUID) is described in [ISO-11578]; however, any method that is
   sufficiently random can be used [RFC1750].

2. URI syntax

   The URI syntax is as follows:

      service-id-uri = "service:serviceid:" 1*(HEXDIGIT / "-")

   The URI simply encodes the unique ID associated with a service.  Each
   byte of the ID is encoded as two HEXDIGIT values.  Arbitrary dashes
   ("-") may be introduced to increase human readability.  This
   identifier is not, however, intended for human readability, nor does


Guttman, E.             Expires: 3 February 2003                [Page 3]

Internet Draft            SLP Serviceid scheme               August 2002


   it encode the location of a service.  The location and description of
   the service is instead present in the attributes registered with the
   service advertisement.

3. Service Templates for Advertising Services via service:serviceid:
   URIs

   The attributes described below SHOULD be registered with any service
   that uses the 'service:serviceid:' scheme.  [RFC2609] describes the
   service template syntax and how to use it.  Note that the template
   fragment shown below is not a complete template, but rather text to
   include in any template that uses the service:serviceid: scheme.

---------------------Template fragment starts here----------------------

service-hi-name=string
# This is a human readable name of the service for purpose of
# displaying in a human interface.

service-hi-description=string O
# This is a human readable description of the service for the purpose of
# displaying in a human interface.

service-id=string
# This is a text rendering of unique identifier.  It contains the
# same value that appears in the "service:serviceid:"  URI registered
# with the service.

service-location-tcp=string M
# This attribute contains a list of strings. The strings are
# the URLs giving the location where the service can be
# accessed via the TCP transport protocol. For example:
#
#   (service-location=nfs://a.example.com,nfs://b.example.com,
#    http://b.example.com:3421,http://b.example.com:32423)
#

service-location-udp = string M
# This attribute contains a list of strings. The strings
# are the URLs giving the location where the service can
# be accessed via the UDP transport protocol.

service-location-sctp = string M
# This attribute contains a list of strings. The strings
# are the URLs giving the location where the service can
# be accessed via the SCTP transport protocol.

service-location-xxx = string M
# Should other transport protocols come into common
# use, attributes can be added that contain the URLs
# giving the location where the service can be


Guttman, E.             Expires: 3 February 2003                [Page 4]

Internet Draft            SLP Serviceid scheme               August 2002


# accessed via these transports.
----------------------Template fragment ends here-----------------------

4. How to solve common problems using 'service:serviceid' URLs

   This section describes how the service:serviceid: URI and the service
   attributes introduced in the preceding two sections solve the
   problems described in Section 1. A UA discovers a service using a
   SrvRqst, which returns the service:serviceid: URI. Either the SrvRqst
   is followed by an AttrRqst for all attributes of the service
   discovered, using that service:serviceid: URI as the locator in the
   AttrRqst, or the original SrvRqst is sent with an Attrlist Extension
   [RFC3059].

4.1. Discovering services with multiple locations

   The UA obtains an attribute list for each service discovered.  The
   transport specific service location attributes in this attribute list
   indicate the multiple locations of services associated with the
   service instance.

4.2. Discovering multiple protocols associated with a service

   The attribute list provides a list of all protocols supported by the
   service instance.

4.3. Discovering the transport protocols which a service supports

   The attribute list contains transport specific service location
   attributes containing the location through which the service is
   accessable via a specific transport.

4.4. Discovering the current location of a particular service

   The UA can construct a search filter to discover a service instance
   which has been discovered previously.  The search filter used in the
   SrvRqst contains the following term:

      "(service-id=" UUID ")"

   The UUID above is replaced by the unique id of the service previously
   discovered.  For example, a UA discovers a service:

   service type
      "smtp"

   scope
      default

   service url
      "service:serviceid:98432A98-B879E8FF-80342A89-43280B89C"


Guttman, E.             Expires: 3 February 2003                [Page 5]

Internet Draft            SLP Serviceid scheme               August 2002


   attribute list
      (service-hi-name=west), (service-hi-description=west coast campus
      smpt server), (service-id=98432A98-B879E8FF-80342A89-43280B89C),
      (service-location-tcp=smtp://west.example.com)

   The UA discovers the location of the service subsequently by issuing
   an SrvRqst with an Attrlist extension:

   service type
      smtp

   scope
      default

   search filter
      (service-id=98432A98-B879E8FF-80342A89-43280B89C)

   Or, an AttrRqst for

   service url
      service-id:98432A98-B879E8FF-80342A89-43280B89C

   scope
      default

   If the attributes are successfully retrieved, the current attribute
   list includes the location of the service,
    which may have changed since the last time it was discovered.

4.5 Ease of use

   The service-hi-name and service-hi-description attribute values
   simplify producing human interfaces for service browsing.   The user
   need never see the unique identifer attribute, as there is a human
   readable name provided for display.  Since attributes can be
   registered in multiple languages, the name and description can be
   internationalized, as appropriate.

5. Relating Attributes to Specific Service Locations

   The attributes advertised along with a service:serviceid URI express
   the attributes of the service irrespective of the access protocol
   used.  For most purposes this is appropriate.  The location, capacity
   and so forth of a server doesn't depend on the access protocol.

   In cases where the attributes vary depending on the service access
   protocol used, the following convention is used.  The URI is
   associated with an attribute list.  The attribute name is formed with
   by concatenating the URI to an attribute prefix 'service-info-".
   This attribute list must first be escaped using the rules in RFC
   2608.  For example the attribute list


Guttman, E.             Expires: 3 February 2003                [Page 6]

Internet Draft            SLP Serviceid scheme               August 2002


      "(read-only=true),anonymous"

   would become the string

      "\28read-only\3Dtrue\29\2Canonymous"

   For example, if there are three ways to access file service, one
   could add attributes specific to each.  (This example is for
   illustrative purposes only.  The service type 'fileserver' has not
   been registered at the time of this writing.)

   Service advertisement:

     Service type = fileserver
     Service URI  =
        service:serviceid:92348911-2990652A-BB234C93-FF113322
     Scope        = default
     Attributes   =
       (service-hi-name=Fileserver),
       (service-hi-description=Remote access to files),
       (service-id=92348911-2990652A-BB234C93-FF113322),
       (service-location-tcp=nfs://a.example.com, http://a.example.com,
        ftp://a.example.com),
       (service-info-http://a.example.com=
         \28read-only\3Dtrue\29\2Canonymous),
       (service-info-nfs://a.example.com=anonymous)

   In the example above, file access via the nfs URL is 'anonymous.'
   File access using the http URL is 'anonymous' and 'read-only=true.'

   Care must be taken to unescape the attribute list values associated
   with service-info attributes before further processing.

Acknowledgments

   James Kempf and Jim Mayer contributed significantly to this
   specification.

References


[IPP] Flemming, P., et. al., "Internet Printing Protocol (IPP):
         LDAP Schema for Printer Services", draft-ietf-ipp-ldap-printer-
        schema-05.txt, a work in progress.

[ISO-11578] ISO (International Organization for Standardization).
        ISO/IEC 11578:1996. "Information technology - Open Systems
        Interconnection - Remote Procedure Call (RPC)"

[RFC1750] Eastlake, D., et. al, "Randomness Recommendations for
        Security", RFC 1750, September 1994.


Guttman, E.             Expires: 3 February 2003                [Page 7]

Internet Draft            SLP Serviceid scheme               August 2002


[RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

[RFC 2608] Guttman, E., et. al, "Service Location Protocol version 2",
        RFC 2608, June 1999.

        See also: Guttman, E., Kempf, J., "Service Location Protocol,
        Version 2", draft-guttman-svrloc-rfc2608bis-03.txt, August 2002,
        A work in progress.

[RFC2608bis] Guttman, E, Kempf, J., "Service Location Protocol, Version
        2", draft-guttman-svrloc-rfc2608bis-01.txt, December 2001, a
        work in progress.

[RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
        service: Schemes", RFC 2609, June 1999.

[RFC3059] Guttman, E., "Attribute List Extension for the Service
        Location Protocol", RFC 3059, February 2001.

Author's Contact Information

   Erik Guttman
   Sun Microsystems
   Eichhoelzelstr. 7
   74915 Waibstadt Germany

   erik.guttman@sun.com

























Guttman, E.             Expires: 3 February 2003                [Page 8]
