Internet Engineering Task Force Erik Guttman INTERNET DRAFT Category: Informational December 18, 2001 Expires in six months The serviceid: URI Scheme for Service Location draft-guttman-svrloc-serviceid-00.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 advertise services of any kind, through the use of URLs. These URLs are used 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.) The serviceid: scheme separates identification from location, which is advantageous. 1. Introduction The Service Location Protocol, Version 2 [RFC2608] [RFC2608bis] allows services to advertise themselves, by associating four things together: - Scope list A comma delimited list of strings which indicate administrative groupings, such as location, organization or function. - Service Type A string representing a type of service. This could be abstract (such as "directory-service") or concrete (such as "ldapv3"). Guttman, E. Expires: 19 June 2002 [Page 1] Internet Draft SLPv2 Revision December 2001 - Service URL This URL serves two purposes: [1] IDENTIFICATION: This URL is used to reregister, deregister or query the attributes of a service instance. [2] LOCATION: This URL may include the location of the service being registered. - Attributes A list of attributes, each of which may have zero or more values. The fact that the URL is used for two purposes creates several problems. 1. Expressing the identity of services with multiple locations Currently, separate SLP service advertisements are made for each location of a service. This makes it impossible to discover that a service with multiple locations (say from a multihomed host, or a host which offers a service from multiple ports) is the same. Are "http://a.example.com", "http://b.example.com" and "http://b.example.com:2346" distinct services or simple distinct access points for the same service? Since the URL is used for both location and identification, there is no way to determine identity of several services from URLs which encode different locations. 2. Expressing the identity of services which support multiple protocols Some services support multiple protocols. For example, a multiprotocol printer may support IPP, LPR, and raw tcp network printing job delivery protocols. Each URL has only one scheme (indicating which protocol to use to contact a 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. 3. It is not possible to determine which transport protocols can be used for protocols that support more than one transport protocol Some protocols can be used via either UDP or TCP. In the future, additional transports may be commonly used, for example, SCTP. There is no way to determine whether a particular service supports more than one transport protocol. Even if the transport protocol were encoded in the URL, it would not be possible to determine if the service supported more than one transport protocol, and if so, which one. Guttman, E. Expires: 19 June 2002 [Page 2] Internet Draft SLPv2 Revision December 2001 This information may be useful for a client capable of supporting more than one transport protocol, to determine which protocol to use to contact a particular service. 4. Discovering the current location of particular service When a user discovers a particular service, she often wishes to use it again. SLP should be able to discover the same printer on successive occasions, even if the printer's location changes. Currently, in SLP, there is no way to specify a unique identifier for the service which a client can use to rediscover the same service. These problems have been difficult to overcome using the mechanisms SLP currently provides. The solution to these problems is to use a URI which is a pure identifier, which has no locator properties. The service associated with this identifier will have a set of attributes which will include all the information needed to solve the five problems listed above. A service must generate a unique identifier to make use of the serviceid URI scheme. It SHOULD store this persistently, so that the next time that the service becomes available and is advertised via SLP, the same id will be used. An example of how to generate a universally unique identifier (UUID) is described in [ISO-11578]. Any method which is sufficiently random can be used, however. [RFC1750] 2. URI syntax The URI syntax is as follows: service-id-uri = "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 slashes ("-") may be introduced to increase human readability. This identifier is not, however intended for human readability, nor does it encode the location of a service. This information is instead present in the attributes registered with a service. 3. Service Templates for advertising services via serviceid: URIs It is suggested that the attributes described below should be registered with any service which uses 'serviceid:' URIs. [RFC2609] describes 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 which uses the serviceid: scheme approach. Guttman, E. Expires: 19 June 2002 [Page 3] Internet Draft SLPv2 Revision December 2001 ---------------------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. This is the same value # which appears after the "serviceid:" scheme registered with the # service. This will allow the same service discovered at a previous # time to be discovered subsequently. service-location=string M # This attribute has string values which have the following ABNF syntax # (see [RFC2234]). # # loc-value = "{" transport "}" url # transport = 1*ALPHA # ; This is a transport protocol name, as "TCP" or "UDP" # url = ; See [RFC2396]. This is the actual locator for the # ; service. # # There is one value for each protocol and location associated with a # particular service. For example, a file service could have the # following values for service-location (encoded in a SLPv2 attribute # list form): # # (service-location={TCP}nfs://a.example.com,{UDP}nfs://a.example.com, # {TCP}http://b.example.com:3421,{TCP}http://b.example.com:32423) # # Note in this example, that the same service can support different # transport protocols for the same application protocol, different # application protocols, or different nonstandard ports for the same # protocol using this syntax. ----------------------Template fragment ends here----------------------- 4. How to solve common problems using 'serviceid' URLs This section describes how the serviceid: URI and the service attributes introduced in the preceding two sections solve the problems described in Section 1. 4.1. Discovering services with multiple locations A UA discovers a service using a SrvRqst, which returns the serviceid: URI. Either that request is followed by an AttrRqsts for Guttman, E. Expires: 19 June 2002 [Page 4] Internet Draft SLPv2 Revision December 2001 all attributes of the service discovered (with that serviceid: URI), or the SrvRqst is sent with an Attrlist Extension [RFC3059]. Either way, the UA obtains attribute list for each service discovered. The service-location attribute in this attribute list indicates the multiple locations of services associated with the service instance. 4.2. Discovering multiple protocols associated with a service The attribute list, obtained as described in Section 4.1, provides a list of all protocols supported by the service instance. 4.3. Discovering the transport protocols which a service supports The attribute list, obtained as described in Section 4.1, associates a transport protocol with each service location value. 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:98432A98-B879E8FF-80342A89-43280B89C" attribute list (service-hi-name=west), (service-hi-description=west coast campus smpt server), (service-id=98432A98-B879E8FF-80342A89-43280B89C), (service-location=smtp://west.example.com) The UA could discover its current location subsequently, by issuing an SrvRqst with an Attrlist extension: service type smtp scope default search filter Guttman, E. Expires: 19 June 2002 [Page 5] Internet Draft SLPv2 Revision December 2001 (service-id=98432A98-B879E8FF-80342A89-43280B89C) Or, an AttrRqst for service url service-id:98432A98-B879E8FF-80342A89-43280B89C scope default If this is successful, the current attribute list of the service is retrieved, including 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 will aid in 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. Open issues One alternative to the "serviceid:" scheme would be to simply use the "data:" URL scheme and include the unique ID data following it. [RFC2397] This would not necessitate the standardization of a new URL scheme, but it would be a bit less clear what the registered URI was for. References [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. [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC 2608] E. Guttman, et. al, "Service Location Protocol version 2", RFC 2608, June 1999. [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 Guttman, E. Expires: 19 June 2002 [Page 6] Internet Draft SLPv2 Revision December 2001 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: 19 June 2002 [Page 7]