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