1 mday  1.1 
  2           
  3           Internet Engineering Task Force                         Erik Guttman
  4           INTERNET DRAFT
  5           Category: Informational
  6           August 13, 2002
  7           Expires in six months
  8           
  9                        The serviceid: URI Scheme for Service Location
 10                            draft-guttman-svrloc-serviceid-02.txt
 11           
 12           Status of this Memo
 13           
 14              This document is an Internet-Draft and is in full conformance with
 15              all provisions of Section 10 of RFC2026.
 16           
 17              Comments on this document should be sent to the SLP discussion list,
 18              srvloc-discuss@lists.sourceforge.net.
 19           
 20              Internet-Drafts are draft documents of the Internet Engineering Task
 21              valid for a maximum of six months and may be updated, replaced, or
 22 mday  1.1    obsoleted by other documents at any time.  It is inappropriate to use
 23              Internet-Drafts as reference material or to cite them other than as
 24              "work in progress."  See http://www.ietf.org/ietf/1id-abstracts.txt.
 25              Find shadow directories at http://www.ietf.org/shadow.html.
 26           
 27              Copyright (C) The Internet Society (2001).  All Rights Reserved.
 28           
 29           Abstract
 30           
 31              The Service Location Protocol (SLP) allows clients to discover
 32              services with little or no prior configuration.  SLP can be used to
 33              advertise services of any kind through the use of URLs.  However, SLP
 34              uses URLs for two purposes: as a LOCATOR (indicating the location of
 35              the service) and as an IDENTIFIER (used for subsequent operations on
 36              a service, such as registration, deregistration and looking up
 37              attributes.)  Confounding these two functions in one object leads to
 38              certain problems.  The serviceid: scheme separates identification
 39              from location, eliminating these problems.
 40           
 41           1. Introduction
 42           
 43 mday  1.1    The Service Location Protocol, Version 2 [RFC2608] [RFC2608bis]
 44              allows services to advertise themselves, by associating four objects
 45              together in a service advertisement:
 46           
 47               - Scope list
 48                 A comma delimited list of strings that denote an administrative
 49                 grouping of services.
 50           
 51               - Service Type
 52                 A string representing the type of service.  The service type can
 53                 be abstract (such as "directory-service") or concrete (such as
 54           
 55           
 56           
 57           Guttman, E.             Expires: 3 February 2003                [Page 1]
 58           
 59           Internet Draft            SLP Serviceid scheme               August 2002
 60           
 61           
 62                 "ldapv3").
 63           
 64 mday  1.1     - Service URL
 65                 A URL that serves two purposes:  [1] IDENTIFICATION:  The URL is
 66                 used to reregister, deregister or query the attributes of a
 67                 service advertisement. [2] LOCATION:  The URL may include the
 68                 location of the service being registered, in the form of the IP or
 69                 other network address or the host name.
 70           
 71               - Attributes
 72                 A list of attribute tag/typed value list pairs. The value list may
 73                 be empty.
 74           
 75              Confounding the identification and location functions into a single
 76              object, namely the service URL, leads to the following problems:
 77           
 78                1. Identifying a logically single service available at multiple
 79                   locations.
 80           
 81                   Currently, separate SLP service advertisements must be made for
 82                   each location of a service. As a result, it is impossible to
 83                   establish the identity of a logically single service that is
 84                   available through multiple locations. Specifically, a multihomed
 85 mday  1.1         host offering the same service on multiple interfaces, or a host
 86                   offering the same service at different ports cannot be
 87                   distinguished from a case when separate services are offered at
 88                   different locations. For example, are "http://a.example.com",
 89                   "http://b.example.com" and "http://b.example.com:2346" distinct
 90                   services or rather distinct access points for the same service?
 91                   Since the URL is used for both location and identification,
 92                   there is no way to determine the identity of several services
 93                   from URLs which encode different locations.
 94           
 95                2. Identifying a service that is accessable through multiple
 96                   protocols.
 97           
 98                   Some services support multiple protocols.  For example, a single
 99                   multiprotocol printer may support IPP, LPR, and raw tcp network
100                   printing job delivery.  Currently, the printer must advertise
101                   URLs for each protocol and each URL has only one scheme
102                   indicating the protocol to use to contact the printer.  Are the
103                   URLs "service:printer:lpr://example.com" and
104                   "service:printer:ipp://example.com" a single printer service
105                   which speaks two protocols or two distinct services?  It is not
106 mday  1.1         possible to determine, from a set of distinct URLs, whether they
107                   refer to different services or the same service instance
108                   accessable through different protocols.
109           
110                3. The service URL contains no way to indicate which transport
111                   protocol to use to access a service.
112           
113           
114           
115           Guttman, E.             Expires: 3 February 2003                [Page 2]
116           
117           Internet Draft            SLP Serviceid scheme               August 2002
118           
119           
120                   Some protocols can be accessed via either UDP or TCP.
121                   Additional transports, such as RTP, or SCTP may be used to
122                   access servers.  The current SLP service URL provides no way to
123                   determine whether a particular service is accessable through a
124                   particular transport protocol.  Even if the transport protocol
125                   were encoded in the URL, it would still not be possible to
126                   determine if the service supported more than one transport
127 mday  1.1         protocol, and if so, which one.  This information may be useful
128                   for a client capable of utilizing more than one transport
129                   protocol, so the client can determine which protocol to use to
130                   contact a particular service.
131           
132                4. Discovering the current location of particular service
133           
134                   A client may need some way to specify that the location of a
135                   particular service should be discovered again, even if the
136                   service location was changed.  SLP should be able to discover
137                   the same printer on successive occasions, even if the printer's
138                   network location changes.  Currently, in SLP, there is no way to
139                   specify a unique identifier for the service so that a client can
140                   rediscover the same service.
141           
142              These problems have been difficult to overcome using the mechanisms
143              SLP currently provides.
144           
145              One solution to these problems is to use a URI that is a pure
146              identifier and has no locator semantics.  The service associated with
147              this identifier then has a set of attributes that includes all the
148 mday  1.1    information needed to solve the five problems listed above.  This
149              solution is used in the SLP service type template for IPP [IPP], but
150              it is limited by the current semantics of SLP service URLs.  Having
151              an identifier URL would simplify and standardize support for services
152              that require separation between location and identification.
153           
154              In order to make use of the service URL scheme, a service must
155              generate a unique identifier.  The service SHOULD store this
156              persistently, so that the the service is always advertised the same
157              id.  An example of how to generate a universally unique identifier
158              (UUID) is described in [ISO-11578]; however, any method that is
159              sufficiently random can be used [RFC1750].
160           
161           2. URI syntax
162           
163              The URI syntax is as follows:
164           
165                 service-id-uri = "service:serviceid:" 1*(HEXDIGIT / "-")
166           
167              The URI simply encodes the unique ID associated with a service.  Each
168              byte of the ID is encoded as two HEXDIGIT values.  Arbitrary dashes
169 mday  1.1    ("-") may be introduced to increase human readability.  This
170              identifier is not, however, intended for human readability, nor does
171           
172           
173           Guttman, E.             Expires: 3 February 2003                [Page 3]
174           
175           Internet Draft            SLP Serviceid scheme               August 2002
176           
177           
178              it encode the location of a service.  The location and description of
179              the service is instead present in the attributes registered with the
180              service advertisement.
181           
182           3. Service Templates for Advertising Services via service:serviceid:
183              URIs
184           
185              The attributes described below SHOULD be registered with any service
186              that uses the 'service:serviceid:' scheme.  [RFC2609] describes the
187              service template syntax and how to use it.  Note that the template
188              fragment shown below is not a complete template, but rather text to
189              include in any template that uses the service:serviceid: scheme.
190 mday  1.1 
191           ---------------------Template fragment starts here----------------------
192           
193           service-hi-name=string
194           # This is a human readable name of the service for purpose of
195           # displaying in a human interface.
196           
197           service-hi-description=string O
198           # This is a human readable description of the service for the purpose of
199           # displaying in a human interface.
200           
201           service-id=string
202           # This is a text rendering of unique identifier.  It contains the
203           # same value that appears in the "service:serviceid:"  URI registered
204           # with the service.
205           
206           service-location-tcp=string M
207           # This attribute contains a list of strings. The strings are
208           # the URLs giving the location where the service can be
209           # accessed via the TCP transport protocol. For example:
210           #
211 mday  1.1 #   (service-location=nfs://a.example.com,nfs://b.example.com,
212           #    http://b.example.com:3421,http://b.example.com:32423)
213           #
214           
215           service-location-udp = string M
216           # This attribute contains a list of strings. The strings
217           # are the URLs giving the location where the service can
218           # be accessed via the UDP transport protocol.
219           
220           service-location-sctp = string M
221           # This attribute contains a list of strings. The strings
222           # are the URLs giving the location where the service can
223           # be accessed via the SCTP transport protocol.
224           
225           service-location-xxx = string M
226           # Should other transport protocols come into common
227           # use, attributes can be added that contain the URLs
228           # giving the location where the service can be
229           
230           
231           Guttman, E.             Expires: 3 February 2003                [Page 4]
232 mday  1.1 
233           Internet Draft            SLP Serviceid scheme               August 2002
234           
235           
236           # accessed via these transports.
237           ----------------------Template fragment ends here-----------------------
238           
239           4. How to solve common problems using 'service:serviceid' URLs
240           
241              This section describes how the service:serviceid: URI and the service
242              attributes introduced in the preceding two sections solve the
243              problems described in Section 1. A UA discovers a service using a
244              SrvRqst, which returns the service:serviceid: URI. Either the SrvRqst
245              is followed by an AttrRqst for all attributes of the service
246              discovered, using that service:serviceid: URI as the locator in the
247              AttrRqst, or the original SrvRqst is sent with an Attrlist Extension
248              [RFC3059].
249           
250           4.1. Discovering services with multiple locations
251           
252              The UA obtains an attribute list for each service discovered.  The
253 mday  1.1    transport specific service location attributes in this attribute list
254              indicate the multiple locations of services associated with the
255              service instance.
256           
257           4.2. Discovering multiple protocols associated with a service
258           
259              The attribute list provides a list of all protocols supported by the
260              service instance.
261           
262           4.3. Discovering the transport protocols which a service supports
263           
264              The attribute list contains transport specific service location
265              attributes containing the location through which the service is
266              accessable via a specific transport.
267           
268           4.4. Discovering the current location of a particular service
269           
270              The UA can construct a search filter to discover a service instance
271              which has been discovered previously.  The search filter used in the
272              SrvRqst contains the following term:
273           
274 mday  1.1       "(service-id=" UUID ")"
275           
276              The UUID above is replaced by the unique id of the service previously
277              discovered.  For example, a UA discovers a service:
278           
279              service type
280                 "smtp"
281           
282              scope
283                 default
284           
285              service url
286                 "service:serviceid:98432A98-B879E8FF-80342A89-43280B89C"
287           
288           
289           Guttman, E.             Expires: 3 February 2003                [Page 5]
290           
291           Internet Draft            SLP Serviceid scheme               August 2002
292           
293           
294              attribute list
295 mday  1.1       (service-hi-name=west), (service-hi-description=west coast campus
296                 smpt server), (service-id=98432A98-B879E8FF-80342A89-43280B89C),
297                 (service-location-tcp=smtp://west.example.com)
298           
299              The UA discovers the location of the service subsequently by issuing
300              an SrvRqst with an Attrlist extension:
301           
302              service type
303                 smtp
304           
305              scope
306                 default
307           
308              search filter
309                 (service-id=98432A98-B879E8FF-80342A89-43280B89C)
310           
311              Or, an AttrRqst for
312           
313              service url
314                 service-id:98432A98-B879E8FF-80342A89-43280B89C
315           
316 mday  1.1    scope
317                 default
318           
319              If the attributes are successfully retrieved, the current attribute
320              list includes the location of the service,
321               which may have changed since the last time it was discovered.
322           
323           4.5 Ease of use
324           
325              The service-hi-name and service-hi-description attribute values
326              simplify producing human interfaces for service browsing.   The user
327              need never see the unique identifer attribute, as there is a human
328              readable name provided for display.  Since attributes can be
329              registered in multiple languages, the name and description can be
330              internationalized, as appropriate.
331           
332           5. Relating Attributes to Specific Service Locations
333           
334              The attributes advertised along with a service:serviceid URI express
335              the attributes of the service irrespective of the access protocol
336              used.  For most purposes this is appropriate.  The location, capacity
337 mday  1.1    and so forth of a server doesn't depend on the access protocol.
338           
339              In cases where the attributes vary depending on the service access
340              protocol used, the following convention is used.  The URI is
341              associated with an attribute list.  The attribute name is formed with
342              by concatenating the URI to an attribute prefix 'service-info-".
343              This attribute list must first be escaped using the rules in RFC
344              2608.  For example the attribute list
345           
346           
347           Guttman, E.             Expires: 3 February 2003                [Page 6]
348           
349           Internet Draft            SLP Serviceid scheme               August 2002
350           
351           
352                 "(read-only=true),anonymous"
353           
354              would become the string
355           
356                 "\28read-only\3Dtrue\29\2Canonymous"
357           
358 mday  1.1    For example, if there are three ways to access file service, one
359              could add attributes specific to each.  (This example is for
360              illustrative purposes only.  The service type 'fileserver' has not
361              been registered at the time of this writing.)
362           
363              Service advertisement:
364           
365                Service type = fileserver
366                Service URI  =
367                   service:serviceid:92348911-2990652A-BB234C93-FF113322
368                Scope        = default
369                Attributes   =
370                  (service-hi-name=Fileserver),
371                  (service-hi-description=Remote access to files),
372                  (service-id=92348911-2990652A-BB234C93-FF113322),
373                  (service-location-tcp=nfs://a.example.com, http://a.example.com,
374                   ftp://a.example.com),
375                  (service-info-http://a.example.com=
376                    \28read-only\3Dtrue\29\2Canonymous),
377                  (service-info-nfs://a.example.com=anonymous)
378           
379 mday  1.1    In the example above, file access via the nfs URL is 'anonymous.'
380              File access using the http URL is 'anonymous' and 'read-only=true.'
381           
382              Care must be taken to unescape the attribute list values associated
383              with service-info attributes before further processing.
384           
385           Acknowledgments
386           
387              James Kempf and Jim Mayer contributed significantly to this
388              specification.
389           
390           References
391           
392           
393           [IPP] Flemming, P., et. al., "Internet Printing Protocol (IPP):
394                    LDAP Schema for Printer Services", draft-ietf-ipp-ldap-printer-
395                   schema-05.txt, a work in progress.
396           
397           [ISO-11578] ISO (International Organization for Standardization).
398                   ISO/IEC 11578:1996. "Information technology - Open Systems
399                   Interconnection - Remote Procedure Call (RPC)"
400 mday  1.1 
401           [RFC1750] Eastlake, D., et. al, "Randomness Recommendations for
402                   Security", RFC 1750, September 1994.
403           
404           
405           Guttman, E.             Expires: 3 February 2003                [Page 7]
406           
407           Internet Draft            SLP Serviceid scheme               August 2002
408           
409           
410           [RFC2234] Crocker, D., Overell, P., "Augmented BNF for Syntax
411                   Specifications: ABNF", RFC 2234, November 1997.
412           
413           [RFC 2608] Guttman, E., et. al, "Service Location Protocol version 2",
414                   RFC 2608, June 1999.
415           
416                   See also: Guttman, E., Kempf, J., "Service Location Protocol,
417                   Version 2", draft-guttman-svrloc-rfc2608bis-03.txt, August 2002,
418                   A work in progress.
419           
420           [RFC2608bis] Guttman, E, Kempf, J., "Service Location Protocol, Version
421 mday  1.1         2", draft-guttman-svrloc-rfc2608bis-01.txt, December 2001, a
422                   work in progress.
423           
424           [RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
425                   service: Schemes", RFC 2609, June 1999.
426           
427           [RFC3059] Guttman, E., "Attribute List Extension for the Service
428                   Location Protocol", RFC 3059, February 2001.
429           
430           Author's Contact Information
431           
432              Erik Guttman
433              Sun Microsystems
434              Eichhoelzelstr. 7
435              74915 Waibstadt Germany
436           
437              erik.guttman@sun.com
438           
439           
440           
441           
442 mday  1.1 
443           
444           
445           
446           
447           
448           
449           
450           
451           
452           
453           
454           
455           
456           
457           
458           
459           
460           
461           
462           
463 mday  1.1 Guttman, E.             Expires: 3 February 2003                [Page 8]