idnits 2.17.1 draft-ietf-svrloc-protocol-v2-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1813 has weird spacing: '...ing off unt...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '-' on line 461 == Unused Reference: '11' is defined on line 2061, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 2078, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1766 (ref. '7') (Obsoleted by RFC 3066, RFC 3282) ** Downref: Normative reference to an Historic RFC: RFC 1423 (ref. '8') ** Obsolete normative reference: RFC 1738 (ref. '9') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2234 (ref. '13') (Obsoleted by RFC 4234) == Outdated reference: A later version (-14) exists of draft-ietf-svrloc-service-scheme-05 -- Unexpected draft version: The latest known version of draft-ietf-asid-ldapv3-filter is -02, but you're referring to -03. ** Downref: Normative reference to an Informational RFC: RFC 2104 (ref. '16') == Outdated reference: A later version (-05) exists of draft-ietf-mboned-admin-ip-space-04 ** Obsolete normative reference: RFC 1305 (ref. '18') (Obsoleted by RFC 5905) -- Possible downref: Non-RFC (?) normative reference: ref. '20' ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '21') ** Obsolete normative reference: RFC 2279 (ref. '23') (Obsoleted by RFC 3629) Summary: 15 errors (**), 0 flaws (~~), 8 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Erik Guttman 2 INTERNET DRAFT Charles Perkins 3 21 June 1998 Sun Microsystems 4 John Veizades 5 @Home Network 6 Michael Day 7 Intel 9 Service Location Protocol, Version 2 10 draft-ietf-svrloc-protocol-v2-06.txt 12 Status of This Memo 14 This document is a submission by the Service Location Working Group 15 of the Internet Engineering Task Force (IETF). Comments should be 16 submitted to the srvloc@srvloc.org mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To view the entire list of current Internet-Drafts, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The Service Location Protocol provides a scalable framework for 39 the discovery and selection of network services. Using this 40 protocol, computers using the Internet need little or no static 41 configuration of network services for network based applications. 42 This is especially important as computers become more portable, and 43 users less tolerant or able to fulfill the demands of network system 44 administration. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 53 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 2 54 1.2. Changes to the Service Location Protocol from v1 to v2 . 2 56 2. Terminology 3 57 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Overview 4 61 4. URLs used with Service Location 5 62 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . . 6 63 4.2. Naming Authorities . . . . . . . . . . . . . . . . . . . 7 64 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. Service Attributes 7 68 6. Required Features 9 69 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . . . 10 70 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . . . 11 71 6.3. Retransmission of SLP messages . . . . . . . . . . . . . 12 72 6.4. Strings in SLP messages . . . . . . . . . . . . . . . . . 12 74 7. Errors 13 76 8. Required SLP Messages 14 77 8.1. Service Request . . . . . . . . . . . . . . . . . . . . . 15 78 8.2. Service Reply . . . . . . . . . . . . . . . . . . . . . . 17 79 8.3. Service Registration . . . . . . . . . . . . . . . . . . 18 80 8.4. Service Acknowledgment . . . . . . . . . . . . . . . . . 19 81 8.5. Directory Agent Advertisement . . . . . . . . . . . . . . 19 82 8.6. Service Agent Advertisement . . . . . . . . . . . . . . . 20 84 9. Optional Features 21 85 9.1. Service Location Protocol Extensions . . . . . . . . . . 21 86 9.2. Authentication Blocks . . . . . . . . . . . . . . . . . . 22 87 9.2.1. MD5 with RSA in Authentication Blocks . . . . . . 23 88 9.2.2. DSA with SHA-1 in Authentication Blocks . . . . . 24 89 9.2.3. Keyed HMAC with MD5 in Authentication Blocks . . 24 90 9.3. Authentication of a SrvRply . . . . . . . . . . . . . . . 25 91 9.4. Incremental Service Registration . . . . . . . . . . . . 25 92 9.5. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . . 25 94 10. Optional SLP Messages 26 95 10.1. Service Type Request . . . . . . . . . . . . . . . . . . 26 96 10.2. Service Type Reply . . . . . . . . . . . . . . . . . . . 27 97 10.3. Attribute Request . . . . . . . . . . . . . . . . . . . . 27 98 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . . 28 99 10.5. Attribute Request/Reply Examples . . . . . . . . . . . . 29 100 10.6. Service Deregistration . . . . . . . . . . . . . . . . . 30 102 11. Scopes 31 103 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . . 31 104 11.2. Administrative and User Selectable Scopes . . . . . . . . 32 105 11.3. Protected Scopes . . . . . . . . . . . . . . . . . . . . 32 107 12. Directory Agents 32 108 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . . 33 109 12.2. Directory Agent Discovery . . . . . . . . . . . . . . . . 34 110 12.2.1. Active DA Discovery . . . . . . . . . . . . . . . 34 111 12.2.2. Passive DA Advertising . . . . . . . . . . . . . 34 112 12.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . . 35 113 12.4. DA Scope Configuration . . . . . . . . . . . . . . . . . 35 114 12.5. DAs and Authentication Blocks . . . . . . . . . . . . . . 35 116 13. SLP Protocol Extensions 36 117 13.1. Required Attribute Missing Option . . . . . . . . . . . . 36 118 13.2. Cryptographic Request Option . . . . . . . . . . . . . . 36 120 14. Protocol Timing Defaults 37 122 15. Optional Configuration 38 124 16. IANA Considerations 39 126 17. Internationalization Considerations 39 128 18. Security Considerations 40 130 19. Acknowledgments 41 132 20. Full Copyright Statement 41 134 1. Introduction 136 The Service Location Protocol (SLP) provides a flexible and scalable 137 framework for providing hosts with access to information about 138 the existence, location, and configuration of networked services. 139 Traditionally, users have had to find services by knowing the name of 140 a network host (a human readable text string) which is an alias for a 141 network address. SLP eliminates the need for a user to know the name 142 of a network host supporting a service. Rather, the user supplies 143 the desired type of service and a set of attributes which describe 144 the service. Based on that description, the Service Location 145 Protocol resolves the network address of the service for the user. 147 SLP provides a dynamic configuration mechanism for applications in 148 local area networks. Applications are modeled as clients that need 149 to find servers attached to any of the available networks within an 150 enterprise. For cases where there are many different clients and/or 151 services available, the protocol is adapted to make use of nearby 152 Directory Agents that offer a centralized repository for advertised 153 services. 155 This document specifies the Service Location Protocol (SLP) in 156 two main parts. The first describes the required features of the 157 protocol. The second describes the extended features of the protocol 158 which are optional, and allow greater scalability. 160 1.1. Applicability Statement 162 SLP is intended to function within networks under cooperative 163 administrative control. Such networks permit a policy to be 164 implemented regarding security, multicast routing and organization 165 of services and clients into groups which are not be feasible on the 166 scale of the Internet as a whole. 168 SLP has been designed to serve enterprise networks with shared 169 services, and it may not necessarily scale for wide-area service 170 discovery throughout the global Internet, or in networks where 171 there are hundreds of thousands of clients or tens of thousands of 172 services. 174 1.2. Changes to the Service Location Protocol from v1 to v2 176 SLP version 2 (SLPv2) corrects race conditions present in SLPv1. 177 In addition, authentication has been reworked to provide more 178 flexibility and protection (especially for DA Advertisements). SLPv2 179 also changes the formats and definition of many flags and values 180 and reduced the number of 'required features.' SLPv2 clarifies 181 and changes the use of 'Scopes', eliminating support for 'unscoped 182 directory agents' and 'unscoped requests'. Other changes (such as 183 Language and Character set handling) adopt practices recommended by 184 the Internet Engineering Steering Group. 186 Effort has been made to make SLPv2 operate the same whether DAs 187 are present or not. For this reason, a new message (the SAAdvert) 188 has been added. This allows UAs to discover scope information in 189 the absence of administrative configuration and DAs. This was not 190 possible in SLPv1. 192 SLPv2 is incompatible in some respects with SLPv1. If a DA supports 193 both SLPv1 and SLPv2 with the same scope, services advertised by SAs 194 using either version of the protocol will be available to both SLPv1 195 and SLPv2 UAs. 197 2. Terminology 199 User Agent (UA) 200 A process working on the user's behalf to establish 201 contact with some service. The UA retrieves service 202 information from the Service Agents or Directory Agents. 204 Service Agent (SA) 205 A process working on the behalf of one or more services 206 to advertise the services. 208 Directory Agent (DA) 209 A process which collects service advertisements. There 210 can only be one DA present per given host. 212 Service Type 213 Each type of service has a unique Service Type string. 215 Naming Authority 216 The agency or group which catalogues given Service Types 217 and Attributes. The default Naming Authority is IANA. 219 Scope A set of services, typically making up a logical 220 administrative group. 222 URL A Universal Resource Locator [9]. 224 SLPv1 The version of SLP specified in RFC 2165 [22]. 226 2.1. Notation Conventions 228 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 229 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 230 document are to be interpreted as described in RFC 2119 [10]. 232 Syntax Syntax for string based protocols follow the 233 conventions defined for ABNF [13]. 235 Strings All strings are encoded using the UTF8 [23] 236 transformation of the Unicode [6] character set and 237 are NOT null terminated when transmitted. Strings 238 are preceded by a two byte length field. 240 A comma delimited list of strings with the 241 following syntax: 243 string-list = string / string `,' string-list 245 In format diagrams, any field ending with a \ indicates a variable 246 length field, given by a prior length field in the protocol. 248 3. Protocol Overview 250 SLP allows client applications to discover services. To do this, 251 User Agents issue a SrvRqst message specifying the characteristics 252 of the desired service. The service is advertised by a Service 253 Agent, automatically. The User Agent receives a Service Reply 254 which contains enough information for the client to make use of the 255 service. 257 SLP is a request-reply protocol; in a typical operation a User Agent 258 (UA) issues a request for service information and awaits one or more 259 replies containing the requested information. 261 Services on a particular host are represented by a Service Agent 262 (SA). The SA takes care of advertising the services using SLP. 264 A Directory Agent (DA) serves as a central clearinghouse of 265 information for SLP. Service advertisements are registered by SAs 266 with DAs. UAs make requests of DAs that they either discovered or 267 are configured to use. DAs announce themselves using 'Directory 268 Agent Advertisements' or DAAdvert messages. 270 Depending on the environment, replies will be sent to the UA by a SA 271 or a DA. For smaller environments, SLP allows a simple deployment 272 consisting only of UAs and SAs. For larger environments, SLP allows 273 the collection of service configuration data at one or more DAs. 275 Wants this information: 276 Client Application - - - - - - - - - - - -> Service 277 USES USES 278 User Agent -----------------------+--> Service Agent 279 Request | ^ | (Request: SrvReg 280 | | | Reply: SrvAck) 281 Reply or DAAdvert | DAAdvert v 282 <-------------------- +---> Directory Agent 284 The above diagram illustrates the relationship between SLP agents. 285 The UA either multicasts requests to SAs or unicasts them to DAs. 286 Replies are unicast. DAs multicast DAAdvertisements which are 287 received by both UAs and SAs. 289 SLP Messages are typically transmitted in datagrams using UDP/IP. 290 Requests may be unicast, multicast, or broadcast. When a UA 291 multicasts or broadcasts a request, it MAY receive more than one 292 reply. Such replies must be unicast. Requests which do not fit into 293 a datagram MUST be sent using TCP. If a reply cannot fit within a 294 datagram, the UA MAY reissue the request using TCP. 296 Strings called 'scopes' are associated with sets of services 297 and assigned to SLP agents. Scopes are used to increase the 298 protocol scalability. A UA will only discover services in scopes 299 it is configured to use. This allows 'administrative service 300 provisioning'. A scope is called 'protected' if it is associated 301 with a particular mechanism for authentication (see section 11). 303 There are required and optional messages in SLP. The only required 304 request to implement is the Service Request (which discovers service 305 instances). Optional requests include the Service Type Request 306 (which discovers all service types supported on the network) and 307 Attribute Request (which discovers all attributes of a given service 308 or of a type of service). These optional requests enable 'service 309 browser' applications to be built using SLP. 311 Hosts may be configured statically or by using DHCP options 78 and 79 312 to issue requests to specific scopes or DAs. Otherwise, SLP allows 313 a host to "bootstrap" itself, beginning with no knowledge of any 314 services or SLP agents beyond its own UA. To bootstrap itself, the 315 host must multicast or broadcast its first request. 317 A SLPv2 implementation MAY support SLPv1 [22]. 319 4. URLs used with Service Location 321 A Service URL indicates the location of a service. This URL may be 322 of the service: scheme [14] (reviewed in section 4.1), or any other 323 URL scheme conforming to the URL standard [9], except that URLs 324 without address specifications SHOULD NOT be advertised by SLP. The 325 service type for an arbitrary URL is typically its scheme name. For 326 example, the service type string for "http://www.srvloc.org" would be 327 "http". 329 Reserved characters in URLs follow the rules in [9]. 331 4.1. Service: URLs 333 Service URL syntax and semantics are defined in [14]. Any network 334 service may be encoded in a Service URL. 336 This section provides an introduction to Service URLs and an example 337 showing a simple application of them, representing standard network 338 services. 340 A Service URL may be of the form: 342 "service:""://" 344 The Service Type of this service: URL is defined to be the string up 345 to (but not including) the final `:' before , the address 346 specification. 348 is a hostname (which should be used if possible) or 349 dotted decimal notation for a hostname, followed by an optional `:' 350 and port number. 352 A service: scheme URL may be formed with any standard protocol 353 name by concatenating "service:" and the reserved port [1] 354 name. For example, "service:tftp://myhost" would indicate a 355 tftp service. An http service on a nonstandard port could be 356 "service:http://webby:8080". 358 Service Types SHOULD be defined by a "service template" [14], which 359 provides expected attributes, values and protocol behavior. An 360 abstract service type (also described in [14]) has the form 362 "service::". 364 The service type string "service:" matches all 365 services of that abstract type. If the concrete type is included 366 also, only these services match the request. For example: a 367 SrvRqst or AttrRqst which specifies "service:printer" as the 368 Service Type will match the URL service:printer:lpr://hostname 369 and service:printer:http://hostname. If the requests specified 370 "service:printer:http" they would match only the latter URL. 372 An optional substring MAY follow the last `.' character in the 373 (or in the case of an abstract service 374 type URL). This substring is the Naming Authority, as described in 375 Section 9.6. Service types with different Naming Authorities are 376 quite distinct. In other words, service:x.one and service:x.two 377 are different service types, as are service:abstract.one:y and 378 service:abstract.two:y. 380 4.2. Naming Authorities 382 A Naming Authority MAY optionally be included as part of the Service 383 Type string. The Naming Authority of a service defines the meaning 384 of the Service Types and attributes registered with and provided by 385 Service Location. The Naming Authority itself is typically a string 386 which uniquely identifies an organization. IANA is the implied 387 Naming Authority when no string is appended. "IANA" itself MUST NOT 388 be included explicitly. 390 Naming Authorities may define Service Types which are experimental, 391 proprietary or for private use. Using a Naming Authority, one 392 may either simply ignore attributes upon registration or create a 393 local-use only set of attributes for one's site. The procedure to 394 use is to create a 'unique' Naming Authority string and then specify 395 the Standard Attribute Definitions as described above. This Naming 396 Authority will accompany registration and queries, as described in 397 Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA 398 to allow for Internet-wide interoperability. 400 4.3. URL Entries 402 0 1 2 3 403 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Reserved | Lifetime | URL Length | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 |URL len, contd.| URL (variable length) \ 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 |# of URL auths | Auth. blocks (if any) \ 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 SLP stores URLs in protocol elements called URL Entries, which 413 associate a length, a lifetime, and possibly authentication 414 information along with the URL. URL Entries, defined as shown above, 415 are used in Service Replies and Service Registrations. 417 5. Service Attributes 419 A service advertisement is often accompanied by Service Attributes. 420 These attributes are used by UAs in Service Requests to select 421 appropriate services. 423 The allowable attributes which may be used are typically specified 424 by a Service Template [14] for a particular service type. Services 425 which are advertised according to a standard template MUST register 426 all service attributes which the standard template requires. URLs 427 with schemes other than "service:" MAY be registered with attributes. 428 Non-standard attribute names SHOULD begin with "x-", because no 429 standard attribute name will ever have those initial characters. 431 An attribute list is a string encoding of the attributes of a 432 service. The following ABNF [13] grammar defines attribute lists: 434 attr-list = attribute / attribute `,' attr-list 435 attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag 436 attr-val-list = attr-val / attr-val `,' attr-val-list 437 attr-tag = 1*safe-tag 438 attr-val = intval / strval / boolval / opaque 439 intval = [-]1*DIGIT 440 strval = 1*safe-val 441 boolval = "true" / "false" 442 opaque = "\FF" 1*escape-val 443 safe-val = ; Any character except reserved. 444 safe-tag = ; Any character except reserved, star and bad-tag. 445 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL 446 escape-val = `\' HEXDIGIT HEXDIGIT 447 bad-tag = CR / LF / HT / `_' 448 star =`*' 450 The , if present, MUST be scanned prior to evaluation for 451 all occurrences of the escape character `\'. Reserved characters 452 MUST be escaped (other characters MUST NOT be escaped). All escaped 453 characters must be restored to their value before attempting string 454 matching. For Opaque values, escaped characters are not converted - 455 they are interpreted as bytes. 457 Boolean Strings which have the form "true" or "false" can 458 only take one value and may only be compared with 459 '='. Booleans are case insensitive when compared. 461 Integer Strings which take the form [-] 1* and fall 462 in the range "-2147483648" to "2147483647" are 463 considered to be Integers. These are compared using 464 integer comparison. 466 String All other Strings are matched using strict lexical 467 ordering (see Section 6.4). 469 Opaque Opaque values are sequences of bytes. These are 470 distinguished from Strings since they begin with 471 the sequence "\FF". This, unescaped, is an illegal 472 UTF8 encoding, indicating that what follows is a 473 sequence of bytes expressed in escape notation which 474 constitute the binary value. For example, a '0' byte 475 is encoded "\FF\00". 477 A string which contains escaped values other than from the reserved 478 set of characters is illegal. If such a string is included in an 479 , or search filter, the SA or DA which 480 receives it MUST return a PARSE_ERROR to the message. 482 A keyword has only an , and no values. Attributes can 483 have one or multiple values. All values are expressed as strings. 485 When values have been advertised by a SA or are registered in a 486 DA, they can take on implicit typing rules for matching incoming 487 requests. 489 Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is 490 disallowed. A DA or SA receiving such an MUST return an 491 INVALID_REGISTRATION error. 493 6. Required Features 495 This section defines the minimal implementation requirements for 496 SAs and UAs as well as their interaction with DAs. A DA is not 497 required for SLP to function, but if it is present, the UA and SA 498 MUST interact with it as defined below. 500 A minimal implementation may consist of either a UA or SA or both. 501 The only required features of a UA are that it can issue SrvRqsts 502 according to the rules below and interpret DAAdverts, SAAdverts and 503 SrvRply messages. The UA MUST issue requests to DAs as they are 504 discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or 505 SAAdvert messages. The SA MUST also register with DAs as they are 506 discovered. 508 UAs perform discovery by issuing Service Request messages. SrvRqst 509 messages are issued, using UDP, following these prioritized rules: 511 1. A UA issues a request to a DA which it has been configured with 512 by DHCP. 514 2. A UA issues requests to DAs which it has been statically 515 configured with. 517 3. A UA uses multicast/convergence SrvRqsts to discover DAs, then 518 uses that set of DAs. A UA that does not know of any DAs SHOULD 519 retry DA discovery once every CONFIG_DA_FIND seconds. 521 4. A UA with no knowledge of DAs sends requests using multicast 522 convergence to SAs. SAs unicast replies to UAs according to the 523 multicast convergence algorithm. 525 UAs and SAs are configured with a list of scopes to use according to 526 these prioritized rules: 528 1. With DHCP. 530 2. With static configuration. The static configuration may be 531 explicitely set to NO SCOPE for UAs, if the User Selectable Scope 532 model is used. See section 11.2. 534 3. In the absense of configuration, the agent's scope is "DEFAULT". 536 A UA MUST issue requests with one or more of the scopes it has been 537 configured to use. 539 A UA which has been statically configured with NO SCOPE LIST will use 540 DA or SA discovery to determine its scope list dynamically. In this 541 case it uses an empty scope list to discover DAs and possibly SAs. 542 Then it uses the scope list it obtains from DAAdverts and possibly 543 SAAdverts in subsequent requests.) 545 The SA MUST register all its services with any DA it discovers, if 546 the DA advertises any of the scopes it has been configured with. A 547 SA obtains information about DAs as a UA does. In addition, the SA 548 MUST listen for multicast unsolicited DAAdverts. The SA registers 549 by sending SrvReg messages to DAs, which reply with SrvReg messages 550 to indicate success. SAs register in ALL the scopes they were 551 configured to use. 553 6.1. Use of Ports, UDP, and Multicast 555 The Service Location Protocol uses multicast by default. The 556 reserved listening port for SLP is 427. This is the destination 557 port for all SLP messages. SLP messages MAY be transmitted on an 558 ephemeral port. Replies and acknowledgements are sent to the port 559 from which the request was issued. The default maximum transmission 560 unit for UDP messages is 1400 bytes. 562 If a SLP message does not fit into a UDP datagram it MUST be 563 truncated to fit, and the OVERFLOW flag is set in the reply message. 564 A UA which receives a truncated message MAY open a TCP connection 565 (see section 6.2) with the DA or SA and retransmit the request, using 566 the same XID. It MAY also attempt to make use of the truncated reply 567 or reformulate a more restrictive request which will result in a 568 smaller reply. 570 SLP Requests messages are multicast to The Administratively Scoped 571 SLP Multicast [17] address, which is 239.255.255.253. The default 572 TTL to use for multicast is 32. 574 In isolated networks, broadcasts will work in place of multicast. 575 To that end, SAs SHOULD and DAs MUST listen for broadcast Service 576 Location messages at port 427. This allows UAs which do not support 577 multicast to use of Service Location on isolated networks. 579 Setting multicast TTL to less than 32 (the default) limits the range 580 of SLP discovery in a network, and localizes service information in 581 the network. 583 6.2. Use of TCP 585 A SrvReg or SrvDeReg may be too large to fit into a datagram. To 586 send such large SLP messages, a TCP (unicast) connection MUST be 587 established. 589 To avoid the need to implement TCP, one MUST insure that: 591 - UAs never issue requests larger than the Path MTU. SAs can omit 592 TCP support only if they never have to receive unicast requests 593 longer than the path MTU. 595 - UAs can accept replies with the 'OVERFLOW' flag set, and make use 596 of the first result included, or reformulate the request. 598 - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in 599 a single datagram. This means limiting the size of URLs, 600 the number of attributes and the number of authenticators 601 transmitted. 603 DAs MUST be able to respond to UDP and TCP requests, as well as 604 multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP 605 unless the SA will NEVER receive a request or send a reply which will 606 exceed a datagram in size (e.g., some embedded systems). 608 A TCP connection MAY be used for a single SLP transaction, or for 609 multiple transactions. Since there are length fields in the message 610 headers, SLP Agents can send multiple requests along a connection and 611 read the return stream for acknowledgments and replies. 613 The initiating agent SHOULD close the TCP connection. The DA SHOULD 614 wait at least CONFIG_CLOSE_CONN seconds before closing an idle 615 connection. DAs and SAs SHOULD close an idle TCP connection after 616 CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the 617 initiating agent neglects to close it. See Section 14 for timing 618 rules. 620 6.3. Retransmission of SLP messages 622 Requests to SAs are multicast repeatedly (with a recommended wait 623 interval of CONFIG_MC_RETRY) until there are no new responses, or 624 CONFIG_MC_MAX seconds have elapsed. DA discovery requests use 625 different timing for repeated requests, CONFIG_DA_RETRY. 627 Multicast requests SHOULD be reissued over 15 seconds (say 3 times 628 total) until a result has been obtained. UAs need only wait till 629 they obtain the first reply which matches their request. Unicast 630 requests (SrvReg or SrvRqst) to a DA should be retried until either 631 a response (which might be an error) has been obtained, or for 5 632 seconds. 634 When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, 635 they contain a of previous responders. Initially the 636 is empty. The message SHOULD be retransmitted until the 637 causes no further responses to be elicited or the previous 638 responder list and the request will not fit into a single datagram. 639 Retransmission is not required if the requesting agent is prepared to 640 use the 'first reply' instead of 'as many replies as possible within 641 a bounded time interval.' 643 Any DA or SA which sees its address in the MUST NOT respond 644 to the request. 646 UAs which retransmit a request use the same XID. This allows a DA or 647 SA to cache its reply to the original request and then send it again, 648 should a duplicate request arrive. This cached information should 649 only be held very briefly. XIDs SHOULD be randomly chosen to avoid 650 duplicate XIDs in requests if UAs restart frequently. 652 6.4. Strings in SLP messages 654 The escape character is a backslash (UTF8 0x5c) followed by the 655 two hexadecimal digits of the escaped character. Only reserved 656 characters are escaped. For example, a comma (UTF8 0x29) is escaped 657 as `\29'. String lists used in SLP define the comma to be the 658 delimiter between list elements, so commas in data strings must be 659 escaped in this manner. 661 String comparison for order and equality in SLP MUST be case 662 insensitive inside the 0x00-0x7F subrange of UTF8 (which corresponds 663 to ASCII character encoding) Case insensitivity SHOULD be supported 664 throughout the entire UTF8 encoded Unicode [6] character set. 666 White space (SPACE, CR, LF, TAB) internal to a string value is folded 667 to a single SPACE character for the sake of string comparisons. For 668 example, " Some String " matches "SOME STRING". 670 String comparisons (using comparison operators such as `<=' or `>=') 671 are done using lexical ordering in UTF8 encoded characters, not using 672 any language specific rules. 674 The reserved character `*' may precede, follow or be internal to a 675 string value in order to indicate substring matching. The query 676 including this character matches any character sequence which 677 conforms to the letters which are not wildcarded. 679 7. Errors 681 If the Error Code in a SLP reply message is nonzero, the rest of 682 the message MAY be truncated. No data is necessarily transmitted 683 or should be expected after the header and the error code, except 684 possibly for some optional extensions to clarify the error, for 685 example as in section 13.1. 687 Errors are only returned for unicast requests. Multicast requests 688 are silently discarded if they result in an error. 690 LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in 691 the scope in the AttrRqst or SrvRqst, but not in the requested 692 language. 693 PARSE_ERROR = 2: The message fails to obey SLP syntax. 694 INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero 695 lifetime or an omitted language tag. 696 SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in 697 its supported by the SA or DA. 698 AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for a 699 cryptographic algorithm or key generation it cannot support. 700 AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR 701 authentication in the SrvReg and did not receive it. 702 AUTHENTICATION_FAILED = 7: The DA detected an authentication error in 703 an Authentication block. 704 VER_NOT_SUPPORTED = 9: Unsupported version number in message header. 705 INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. 706 DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. 707 OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option 708 from the mandatory range (see section 9.1). 709 INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for 710 an unregistered service or with inconsistent Service Types. 711 MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst 712 and does not support it. 714 8. Required SLP Messages 716 SLP messages all begin with the following header: 718 0 1 2 3 719 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Version | Function-ID | Length | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Length, contd.|O|U|A|F|R| rsvd| Language Tag Length | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Next Extension Offset | XID | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Language Tag \ 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 Message Type Abbreviation Function-ID 732 Service Request SrvRqst 1 733 Service Reply SrvRply 2 734 Service Registration SrvReg 3 735 Service Deregister SrvDeReg 4 736 Service Acknowledge SrvAck 5 737 Attribute Request AttrRqst 6 738 Attribute Reply AttrRply 7 739 DA Advertisement DAAdvert 8 740 Service Type Request SrvTypeRqst 9 741 Service Type Reply SrvTypeRply 10 742 SA Advertisement SAAdvert 11 744 SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST 745 also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support 746 for other messages are OPTIONAL. 748 - Length is the length of the entire SLP message, header included. 749 - The flags are: OVERFLOW (0x80) is set when a message's length 750 exceeds what can fit into a datagram. URLSIG (0x40) is set by 751 a SA when it registers a signed URL with a DA or a signed URL 752 is passed in a SrvRply to a UA. ATTRSIG (0x20) is set by a SA 753 when signed attributes are registered with a DA. FRESH (0x10) 754 is set on every new SrvReg. REQUEST MCAST (0x08) is set when 755 multicasting or broadcasting requests. Rsvd bits MUST be 0. 756 - Lang Tag Length indicates the length of the Language Tag field. 757 - Next Extension Offset is set to 0 unless extensions are used. 758 The first extension begins at 'offset' bytes, from the message's 759 beginning, after the SLP message data. See Section 9.1 for how 760 to interpret unrecognized options. 762 - XID is set to a unique value for each unique request. If the 763 request is retransmitted, the same XID is used. Replies set 764 the XID to the same value as the xid in the request. Only 765 unsolicited DAAdverts are sent with an XID of 0. 766 - Language Tag conforms to [7]. The Language Tag in a reply MUST 767 be the same as the Language Tag in the request. This field must 768 be encoded 1*8ALPHA ["-" 1*8ALPHA]. 770 If a flag indicates an authentication block will follow, or an option 771 is specified, and these fields are not included in the message, the 772 receiver MUST respond with a PARSE_ERROR. 774 8.1. Service Request 776 0 1 2 3 777 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Service Location header (function = SrvRqst = 1) | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | length of | String \ 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | length of | String \ 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | length of | String \ 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | length of predicate string | Service Request \ 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 In order for a Service to match a SrvRqst, it must belong to at least 791 one requested scope, support the requested service type, and match 792 the predicate. If the predicate is present, the language of the 793 request (ignoring the dialect part of the Language Tag) must match 794 the advertised service. 796 is the Previous Responder List. This 797 contains either fully qualified domain names or dotted decimal 798 notation IP (v4) addresses, and is iteratively multicast to obtain 799 all possible results (see Section 6.3). UAs SHOULD implement this 800 discovery algorithm. SAs MUST use this to discover all available DAs 801 in their scope, if they are not already configured with DA addresses 802 by some other means. A SA silently drops all requests which include 803 the SA's address in the . Once a plus the request 804 exceeds the path MTU, multicast convergence stops. This algorithm 805 is not intended to find all instances; it finds 'enough' to provide 806 useful results. 808 The is a of configured scope names. SAs 809 and DAs which have been configured with any of the scopes in this 810 list will respond. DAs and SAs MUST reply to unicast requests with a 811 SCOPE_NOT_SUPPORTED error if the is omitted or fails to 812 include a scope they support (see Section 11). The only exceptions 813 to this are described in Section 11.2. 815 The string is discussed in Section 4. Normally, 816 a SrvRqst elicits a SrvRply. There are two exceptions: If 817 the is set to "service:directory-agent", DAs 818 respond to the SrvRqst with a DAAdvert (see Section 8.5.) If 819 set to "service:service-agent", SAs respond with a SAAdvert (see 820 Section 8.6.) 822 The is a LDAPv3 search filter [15]. This field may be 823 omitted if services are to be discovered simply by type and scope. 824 Otherwise, services are discovered which satisfy the . 825 If present, it is compared to each registered service. If the 826 attribute in the filter has been registered with multiple values, the 827 filter is compared to each value and the results are ORed together, 828 i.e., "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" 829 matches (y=0,1) since Y can be nonzero. Note the matching is case 830 insensitive. Keywords (i.e., attributes without values) are matched 831 with a "presence" filter, as in "(keyword=*)". 833 An incoming request term MUST have the same type as the attribute 834 in a registration in order to match. Thus, "(x=33)" will not 835 match 'x=true', etc. while "(y=foo)" will match 'y=FOO'. 836 "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be 837 satisfied, because of the `|' (boolean disjunction). 839 Wildcard matching can ONLY be done with the '=' filter. In any 840 other case, a PARSE_ERROR is returned. Request terms which include 841 wildcards are interpreted to be Strings. That is, (x=34*) would 842 match 'x=34foo', but not 'x=3432' since the first value is a String 843 while the second value is an Integer; Strings don't match Integers. 845 Examples of Predicates follow. indicates the service type of 846 the SrvRqst, gives the and

is the predicate 847 string. 849 =service:http =DEFAULT

= (empty string) 850 This is a minimal request string. It matches all http 851 services advertised with the default scope. 853 =service:pop3 =SALES,DEFAULT

=(user=wump) 854 This is a request for all pop3 services available in 855 the SALES or DEFAULT scope which serve mail to the user 856 `wump'. 858 =service:backup =BLDG 32

=(&(q<=3)(speed>=1000)) 859 This returns the backup service which has a queue length 860 less than 3 and a speed greater than 1000. It will 861 return this only for services registered with the BLDG 32 862 scope. 864 DAs are discovered by sending a SrvRqst with the service 865 type set to "service:directory-agent". If a predicate is 866 included in the SrvRqst, the DA SHOULD respond only if 867 the predicate can be satisfied with the DA's attributes. 868 The SHOULD contain all scopes configured 869 for the service. If omitted, see Section 11.2. For 870 example: 872 =service:directory-agent =DEFAULT

= 873 This returns DAAdverts for all DAs in the DEFAULT scope. 875 8.2. Service Reply 877 0 1 2 3 878 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Service Location header (function = SrvRply = 2) | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Error Code | URL Entry count | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | ... \ 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 887 The service reply contains one or more URL entries (see Section 4.3) 888 that satisfy a SrvRqst. If the reply overflows, the UA MAY 889 simply use the first URL Entry in the list. A URL obtained by 890 SLP may not be cached longer than Lifetime seconds, unless there 891 is a URL Authenticator block present. In that case, the cache 892 lifetime is indicated by the Timestamp in the URL Authenticator 893 (see Section 9.2). One authentication block is returned for each 894 protected scope the service was registered in which was present in 895 the of the SrvRqst. If a SrvRply is sent by UDP, 896 a URL Entry MUST NOT be included unless it fits entirely without 897 truncation. 899 8.3. Service Registration 901 0 1 2 3 902 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Service Location header (function = SrvReg = 3) | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | \ 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | length of service type string | \ 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | length of | \ 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 912 | length of attr-list string | \ 913 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 914 |# of AttrAuths |(if present) Attribute Authentication Blocks...\ 915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 The is a URL Entry (see section 4.3). The Lifetime defines 918 how long a DA can cache the registration. SAs SHOULD reregister 919 before this lifetime expires (but SHOULD NOT more often than once 920 per second). The Lifetime MAY be set to any value between 0 and 921 0xffff (maximum, around 18 hours). Long-lived registrations remain 922 stale longer if the service fails and the SA does not deregister the 923 service. 925 The defines the service type of the URL to be 926 registered, regardless of the scheme of the URL. The 927 MUST be contain the names of all scopes configured for the SA. The 928 default value is "DEFAULT" (see Section 11). The , if 929 present, specifies the attributes and values to be associated with 930 the URL by the DA (see Section 5). 932 If the registration occurs in a protected scope, the ATTRSIG flag is 933 set in the header, and an Authentication block (see Section 9.2) is 934 included for each protected scope, for each Key Generation Number 935 supported. It is calculated over the ordered tuple (16-bit length of 936 , , timestamp, 16-bit length of scope string, 937 scope string), where the timestamp is taken from the Authentication 938 block. 940 A registration with the FRESH flag set will replace *entirely* any 941 previous registration for the same URL in the same language. If 942 the FRESH flag is not set, the registration is an "incremental" 943 registration (see Section 9.4). 945 8.4. Service Acknowledgment 947 0 1 2 3 948 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Service Location header (function = SrvAck = 4) | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 952 | Error Code | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 A DA returns a SrvAck to an SA after a SrvReg. It carries only a two 956 byte Error Code (see Section 7). 958 8.5. Directory Agent Advertisement 960 0 1 2 3 961 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Service Location header (function = DAAdvert = 8) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | DA Stateless Boot Timestamp | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Length of URL | URL \ 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Length of | \ 970 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 971 | # Auth Blocks | Authentication block (if any) \ 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 DAs respond with DAAdverts only to SrvRqsts with the MCAST RQST 975 flag set. The of the SrvRqst must either be omitted 976 or include a scope which the DA supports. The DA Stateless Boot 977 Timestamp indicates the state of the DA (see section 12.2.2). 979 The URL is "service:directory-agent://" of the DA, where 980 is the dotted decimal numeric address of the DA. The 981 of the DA MUST NOT be null. 983 The DAAdvert MAY contain a URL authenticator, which will be generated 984 using a DA Advertising private key. This authenticator is calculated 985 over the following ordered tuple: (DA Stateless Boot Timestamp, 986 Length of URL, URL, Length of , , 987 Timestamp), where the Timestamp is taken from the Authentication 988 block. The Protected Scope String of the authentication block is 989 omitted in a DAAdvert (i.e., the Protected Scope String Length is 990 zero). The Authenticator Timestamp is set to the time when the 991 DAAdvert expires (may no longer be cached). 993 If multiple Key Generation Numbers are supported for DAAdvert 994 authenication, the DA MUST include one Authentication Block for each 995 generation number. See Section 9.2. 997 UAs SHOULD be configured with DA Advertisement public keys so they 998 can verify the authenticity of DAAdverts. If the UA detects a 999 authentication failure of the DAAdvert, the UA MUST discard it. 1001 8.6. Service Agent Advertisement 1003 User Agents MUST NOT solicit SA Advertisements if they have been 1004 configured to use a particular DA, if they have been configured 1005 with a or if DAs have been discovered. UAs solicit 1006 SA Advertisements only when they are explicitly configured to use 1007 User Selectable scopes (see Section 11.2) in order to discover the 1008 scopes that SAs support. This allows UAs without scope configuration 1009 to make use of either DAs or SAs without any functional difference 1010 except performance. 1012 A SA MAY be configured with attributes, and SHOULD support the 1013 attribute 'service-type' whose value is all the service types 1014 of services represented by the SA. SAs MUST NOT respond if the 1015 SrvRqst predicate is not satisfied. For example, only SAs offering 1016 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for 1017 service type "service:service-agent" which includes a predicate 1018 "(service-type=nfs)". 1020 0 1 2 3 1021 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | Service Location header (function = SAAdvert = 11) | 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 | Length of URL | URL \ 1026 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1027 | Length of | \ 1028 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 | # auth blocks | authentication block (if any) \ 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1032 The SA responds only to multicast SA discovery requests which either 1033 include no or a scope which they are configured to use. 1035 The URL is "service:service-agent://" of the SA, where 1036 is the dotted decimal numeric address of the SA. The of 1037 the SA MUST NOT be null. 1039 The SAAdvert contains a URL Authentication block for each protected 1040 scope the SA supports. If the UA can verify the protected scope 1041 SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard 1042 it. 1044 9. Optional Features 1046 The features described in this section are not mandatory. Some are 1047 useful for interactive use of SLP (where a user rather than a program 1048 will select services, using a browsing interface for example) and for 1049 scalability of SLP to larger networks. 1051 9.1. Service Location Protocol Extensions 1053 The format of a Service Location Extension is: 1055 0 1 2 3 1056 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Extension ID | Extension Length | 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | Extension Data \ 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 The offset to next extension is 0 if there are no extensions 1064 following or is set to the length of the current Extension Data. 1065 If the offset is 0, the length of the current Extension Data is 1066 determined implicitly by use of the total length of the SLP message 1067 as given in the SLP message header. 1069 Extension IDs are assigned in the following way: 1071 0x0000-0x3FFF Standardized. Optional to implement. Ignore if 1072 unrecognized. 1073 0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA 1074 which receives this option in a reply and does not understand 1075 it MUST silently discard the reply. A DA or SA which receives 1076 this option in a request and does not understand it MUST return 1077 an OPTION_NOT_UNDERSTOOD error. 1078 0x8000-0x8FFF For private use (not standardized). Optional to 1079 implement. Ignore if unrecognized. 1080 0x9000-0xFFFF Reserved. 1082 Extensions defined in this document are in Section 13. See 1083 section 16 for procedures that are required when specifying new SLP 1084 extensions. 1086 9.2. Authentication Blocks 1088 0 1 2 3 1089 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1090 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1091 | Block Structure Descriptor | Authentication Block Length | 1092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1093 | Key Generation Number | Protected Scope String Length | 1094 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1095 \ Protected Scope String \ 1096 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 | Timestamp | 1098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1099 | Structured Authentication Block ... \ 1100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1102 Authentication blocks are returned with certain SLP messages to 1103 verify that the contents have not been modified, and have been 1104 transmitted by an authorized agent. The authentication data 1105 (contained in the Structured Authentication Block) is typically 1106 case sensitive. Even though SLP registration data (e.g., attribute 1107 values) are typically are not case sensitive even for protected 1108 scopes, the case of the registration data has to be preserved by the 1109 registering DA so that UAs will be able to verify the authentication 1110 data. 1112 The Block Structure Descriptor (BSD) identifies the format of the 1113 Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained 1114 by IANA. BSDs 0x8000-0x8FFF are for private use. 1116 The Authentication Block Length is the length of the entire block, 1117 starting with the BSD. 1119 The Key Generation Number (KGN) identifies the 'generation' of the 1120 key associated with the Protected Scope string which follows. The 1121 value 0 MUST NOT be used and the values 1-255 are reserved. 1123 There may be several 'key generations' deployed in a network 1124 simultaneously. This allows gradual rekeying of a network. For 1125 example, a network is keyed with keys for protected scope 'foo' 1126 with KGN 1022. Later, SAs are rekeyed to also have KGN '1023'. 1127 Eventually, when all UAs and DAs in the network are rekeyed with keys 1128 with KGN '1023', SAs need no longer support KGN '1022' keys. 1130 A SA which supports multiple KGNs for a protected scope MUST register 1131 Authentication Blocks generated with each KGN with DAs. DAs and SAs 1132 MUST include authentication blocks in each KGN associated with a 1133 protected scope unless the UA which initiated the request includes a 1134 Cryptographic Request Option specifying a particular KGN. 1136 Note that many SLP messages are sent using UDP datagrams. These have 1137 a limited payload so few Authentication Blocks will fit into a SLP 1138 message. For this reason, as few Key Generations as possible should 1139 be supported simultaneously: Ideally only ONE should be used except 1140 during transitions. 1142 The Protected scope string identifies the keying material to be 1143 used by agents to verify the signature data in the Structured 1144 Authentication Block. 1146 The Timestamp is the time that the authenticator expires (to 1147 prevent replay attacks.) The Timestamp is a 32-bit unsigned 1148 fixed-point number of seconds relative to 0h on 1 January 1900, in 1149 NTP format [18]. SAs and DAs MAY use this value to indicate how 1150 long they expect the service to be available for (for instance, in 1151 DAAdverts and SAAdverts). 1153 All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST 1154 register services with DSA authentication blocks, and they 1155 MAY register them with other authentication blocks using other 1156 algorithms. SAs MUST use DSA authentication blocks in SrvDeReg 1157 messages and DAs MUST use DSA authentication blocks in unsolicited 1158 DAAdverts. 1160 9.2.1. MD5 with RSA in Authentication Blocks 1162 BSD=0x0001 indicates that md5WithRSAEncryption is selected as the 1163 authentication algorithm for the Structured Authentication Block. 1164 The Authentication Block will start with the ASN.1 Distinguished 1165 Encoding (DER) [11] for "md5WithRSAEncryption", which has as its 1166 value the bytes (MSB first in hex): 1168 "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00" 1170 This is then immediately followed by an ASN.1 Distinguished Encoding 1171 (as a "Bitstring") of the RSA encryption (using the protected 1172 scope's private key) of a bitstring consisting of the OID for "MD5" 1173 concatenated by the MD5 [21] message digest computed over the fields 1174 above. The exact construction of the MD5 OID and digest can be found 1175 in RFC 1423 [8]. 1177 9.2.2. DSA with SHA-1 in Authentication Blocks 1179 BSD=0x0002 is defined to be DSA with SHA-1. The signature 1180 calculation is defined by [20]. The signature format conforms to 1181 that in the X.509 v3 certificate: 1183 1. The signature algorithm identifier (an OID) 1184 2. The signature value (an octet string) 1185 3. The certificate path. 1187 All data is represented in ASN.1 encoding: 1189 id-dsa-with-sha1 ID ::= { 1190 iso(1) member-body(2) us(840) x9-57 (10040) 1191 x9cm(4) 3 } 1193 i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately 1194 by: 1196 Dss-Sig-Value ::= SEQUENCE { 1197 r INTEGER, 1198 s INTEGER } 1200 i.e., the binary ASN.1 encoding of r and s computed using DSA 1201 and SHA-1. This is followed by a certificate path, as defined by 1202 X.509 [12], [2], [3], [4], [5]. 1204 9.2.3. Keyed HMAC with MD5 in Authentication Blocks 1206 BSD=0x0003 is defined to be HMAC [16] using keyed-MD5 [21]. 1208 Given a secret key K and the data to authenticate, the Authentication 1209 Block is computed as follows: 1210 1. opad := 0x36363636363636363636363636363636 (128 bits) 1211 2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits) 1212 3. zero_extended_key := K extended by zeroes to be 128 bits long 1213 4. opadded_key := zero_extended_key XOR opad 1214 5. ipadded_key := zero_extended_key XOR ipad 1215 6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data)) 1217 The authenticator is the 128-bit value HMAC_result. 1219 Note that this authentication scheme works for peer-to-peer 1220 implementations (where hosts can both verify and generate 1221 authenticators) but not for client-server applications where clients 1222 are NOT trusted to create authenticators for services of a protected 1223 scope. In this case, public key cryptography is used. 1225 9.3. Authentication of a SrvRply 1227 A SrvRply containing a URL from a service in a protected scope MUST 1228 include an Authentication Block for each protected scope. The 1229 Authentication data MUST be calculated over the following ordered 1230 tuple: (Length of URL, URL, Timestamp, 16-bit Length of Scope 1231 String, Scope String). The Authentication block is calculated 1232 according to the algorithm indicated by the BSD value using the 1233 cryptographic key identified by the protected scope string and Key 1234 Generation Number in the Authentication Block. 1236 9.4. Incremental Service Registration 1238 Incremental registrations update attribute values for a previously 1239 registered service. Incrmental service registrations are useful when 1240 only a single attribute has changed, for instance. In an incremental 1241 registration, the FRESH flag in the SrvReg header is NOT set. 1243 The new registration's attributes replace the previous 1244 registration's, but do not affect attributes which were 1245 included previously and are not present in the update. 1247 For example, suppose service:x://a.org has been registered with 1248 attributes A=1, B=2, C=3. If an incremental registration comes for 1249 service:x://a.org with attributes C=30, D=40, then the attributes for 1250 the service after the update are A=1, B=2, C=30, D=40. 1252 Incremental registrations MUST NOT be performed for services 1253 registered in protected scopes. These must be registered with 1254 ALL attributes, with the "FRESH" flag in the SrvReg header 1255 set. DAs which receive such registration messages return an 1256 AUTHENTICATION_FAILED error. 1258 If the "FRESH" flag is not set and the DA does not have a prior 1259 registration for the service, the incremental registration fails with 1260 error code INVALID_UPDATE. 1262 If the update includes a other than the one in the 1263 prior registration, the DA returns a SCOPE_NOT_SUPPORTED error. In 1264 order to change the scope of a service advertisement it MUST be 1265 deregistered first and reregistered with a new . 1267 9.5. Tag Lists 1269 Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a 1270 item is: 1272 tag-filter = simple-tag / substring 1273 simple-tag = 1*filt-char 1274 substring = [initial] any [final] 1275 initial = 1*filt-char 1276 any = `*' *(filt-char `*') 1277 final = 1*filt-char 1278 filt-char = Any character excluding and (see 1279 grammar in Section 5). 1281 Wild card characters in a item match arbitrary sequences 1282 of characters. For instance "*bob*" matches "some bob I know", 1283 "bigbob", "bobby" and "bob". 1285 10. Optional SLP Messages 1287 The additional requests provide features for user interaction and for 1288 efficient updating of service advertisements with dynamic attributes. 1290 10.1. Service Type Request 1292 The Service Type Request (SrvTypeRqst) allows a UA to discover all 1293 types of service on a network. This is useful for general purpose 1294 service browsers. 1296 0 1 2 3 1297 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1299 | Service Location header (function = SrvTypeRqst = 9) | 1300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1301 | length of PRList | String \ 1302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1303 | length of Naming Authority | \ 1304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1305 | length of | String \ 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 The list and are interpreted as in 1309 Section 8.1. 1311 The Naming Authority string, if present in the request, will 1312 limit the reply to Service Type strings with the specified Naming 1313 Authority. If the Naming Authority string is absent, the IANA 1314 registered service types will be returned. If the length of the 1315 Naming Authority is set to 0xFFFF, the Naming Authority string is 1316 omitted and ALL Service Types are returned, regardless of Naming 1317 Authority. 1319 10.2. Service Type Reply 1321 0 1 2 3 1322 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1324 | Service Location header (function = SrvTypeRply = 10) | 1325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1326 | Error Code | length of | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1328 | \ 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 The service-type Strings (as described in Section 4.1) are provided 1332 in , which is a . 1334 If a service type has a Naming Authority other than IANA it MUST be 1335 returned following the service type string and a `.' character. 1336 Service types with the IANA Naming Authority do not include a Naming 1337 Authority string. 1339 10.3. Attribute Request 1341 The Attribute Request (AttrRqst) allows a UA to discover attributes 1342 of a given service (by supplying its URL) or for an entire service 1343 type. The latter feature allows the UA to construct a query for an 1344 available service by selecting desired features. The UA may request 1345 that all attributes are returned, or only a subset of them. 1347 0 1 2 3 1348 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | Service Location header (function = AttrRqst = 6) | 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1352 | length of PRList | String \ 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1354 | length of URL | URL \ 1355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1356 | length of | string \ 1357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1358 | length of string | string \ 1359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1361 The and are interpreted as in Section 8.1. 1363 The URL field can take two forms. It can simply be a Service Type 1364 (see Section 4.1), such as "http" or "service:tftp". In this case, 1365 all attributes and the full range of values for each attribute of all 1366 services of the given Service Type is returned. 1368 The URL field may alternatively be a full URL, such as 1369 "service:printer:lpr://igore.wco.ftp.com:515/draft" or 1370 "nfs://max.net/znoo". In this, only the registered attributes for 1371 the specified URL are returned. 1373 The field is a of attribute tags, as 1374 defined in Section 9.5 which indicates the attributes to return 1375 in the AttrRply. If is omitted, all attributes are 1376 returned. MUST be omitted and a full URL MUST be 1377 included when attributes are requested in a protected scope from a 1378 DA, otherwise the DA will reply with an AUTHENTICATION_FAILED error. 1380 10.4. Attribute Reply 1382 0 1 2 3 1383 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Service Location header (function = AttrRply = 7) | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Error Code | length of | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | \ 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | # Auth Blocks |(if present) Attribute Authentication Blocks...\ 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 The format of the and the Authentication Block is as 1395 specified for SrvReg (see Section 9.2). 1397 Attribute replies SHOULD be returned with the original case of the 1398 string registration intact, as they are likely to be human readable. 1399 In the case where the AttrRqst was by service type, all attributes 1400 defined for the service type, and all their values are returned. 1402 Only one copy of each attribute tag or String value should be 1403 returned, arbitrarily choosing one version (with respect to upper 1404 and lower case and white space internal to the strings): Duplicate 1405 attributes and values SHOULD be removed. An arbitrary version of the 1406 string value and tag name is chosen for the merge. For example: 1407 "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)". 1409 One Attribute Authentication Block is returned for each protected 1410 scope in the , for each Key Generation number supported. 1411 Note that the returned from a DA in a protected scope 1412 MUST be identical to the registered by a SA, in order 1413 for the authentication to be successful. 1415 10.5. Attribute Request/Reply Examples 1417 Suppose that printer services have been registered as follows: 1419 Registered Service: 1420 URL = service:printer:lpr://igore.wco.ftp.com/draft 1421 scope-list = Development 1422 Lang. Tag = en 1423 Attributes = (Name=Igore),(Description=For developers only), 1424 (Protocol=LPR),(location-description=12th floor), 1425 (Operator=James Dornan \3cdornan@monster\3e), 1426 (media-size=na-letter),(resolution=res-600),x-OK 1428 URL = service:printer:lpr://igore.wco.ftp.com/draft 1429 scope-list = Entwicklung 1430 Lang. Tag = de 1431 Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler), 1432 (Protocol=LPR),(Standort-beschreibung=13te Etage), 1433 (Techniker=James Dornan \3cdornan@monster\3e), 1434 (Format=na-letter),(Resolution=res-600),x-OK 1436 URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn 1437 scope-list = Development 1438 Lang. Tag = en 1439 Attributes = (Name=Not),(Description=Experimental IPP printer), 1440 (Protocol=http),(location-description=QA bench), 1441 (media-size=na-letter),(resolution=other),x-BUSY 1443 Notice the first printer, "Igore" is registered in both English and 1444 German. The `<' and `>' characters in the Operator attribute value 1445 which are part of the Email address had to be escaped, as they are 1446 reserved characters for values. 1448 The string "PROTOCOL" is 'literal' so it is not translated to 1449 different languages, see [14]. 1451 The attribute Request: 1453 URL = service:printer:lpr://igore.wco.ftp.com/draft 1454 scope-list = Entwicklung 1455 Lang. Tag = de 1456 tag-list = Resolution,St* 1458 receives the Attribute Reply: 1460 (Standort-beschreibung=13te Etage),(Resolution=res-600) 1462 The attribute Request: 1464 URL = service:printer 1465 scope-list = Development 1466 Lang. Tag = en 1467 tag-list = x-*,resolution,protocol 1469 receives an Attribute Reply containing: 1471 (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY 1473 The first request is by service instance and returns the requested 1474 values, in German. The second request is by abstract service type 1475 (see Section 4) and returns values from both "Igore" and "Not". 1477 10.6. Service Deregistration 1479 A DA deletes a service registration when its Lifetime expires. 1480 Services SHOULD be deregistered when they are no longer available, 1481 rather than leaving the registrations to time out. 1483 0 1 2 3 1484 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | Service Location header (function = SrvDeReg = 5) | 1487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1488 | Length of | \ 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1490 | URL Entry \ 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 | Length of | \ 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1495 The is a (see section 2.1). 1497 The SA MUST retry if there is no response from the DA, see Section 1498 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA 1499 receives an acknowledgment indicating success, the service and/or 1500 attributes are no longer advertised by the DA. The DA deregisters 1501 the service or service attributes from every scope specified in the 1502 SrvDeReg which it was previously registered in. 1504 If the URL has not been registered with the DA in the scope specified 1505 in the SrvDeReg message, an INVALID_REGISTRATION error is returned. 1506 The Lifetime field in the URL Entry is ignored for the purposes of 1507 the SrvDeReg. 1509 The is a of attribute tags to deregister 1510 as defined in Section 9.5. If no is present, the 1511 SrvDeReg deregisters the service in all languages it has been 1512 registered in. If the is present, the SrvDeReg 1513 deregisters the attributes whose tags are listed in the tag 1514 spec. Services registered in protected scopes MUST NOT include 1515 a in a SrvDeReg message: A DA will respond with an 1516 AUTHENTICATION_FAILED error in this case. 1518 If the service to be deregistered was registered in a protected 1519 scope, a URL authentication block for that protected scope and Key 1520 Generation Number MUST be included. Otherwise, the DA returns an 1521 AUTHENTICATION_ABSENT error is returned. If the message fails to be 1522 verified by the DA, an AUTHENTICATION_FAILED error is returned by the 1523 DA. 1525 11. Scopes 1527 Scopes are sets of services. The primary use of Scopes is to provide 1528 the ability to create administrative groupings of services. A set 1529 of services may be assigned a scope by network administrators. A 1530 client seeking services is configured to use one or more scopes. The 1531 user will only discover those services which have been configured 1532 for him or her to use. By configuring UAs and SAs with scopes, 1533 administrators may provision services. Scopes strings are case 1534 insensitive. The default SCOPE string is "DEFAULT". 1536 Scopes are the primary means an administrator has to scale SLP 1537 deployments to larger networks. When DAs with NON-DEFAULT scopes are 1538 present on the network, further gains can be had by configuring UAs 1539 and SAs to have a predefined non-default scope. These agents can 1540 then perform DA discovery and make requests using their scope. This 1541 will limit the number of replies. 1543 11.1. Scope Rules 1545 SLP messages which fail to contain a scope that the receiving Agent 1546 is configured to use are dropped (if the request was multicast) or a 1547 SCOPE_NOT_SUPPORTED error is returned (if the request was unicast). 1548 Every SrvRqst (except for DA and SA discovery requests), SrvReg, 1549 AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a 1550 . 1552 A UA MUST unicast its SLP messages to a DA which supports the desired 1553 scope, in preference to multicasting a request to SAs. A UA MAY 1554 multicast the request if no DA is available in the scope it is 1555 configured to use. 1557 11.2. Administrative and User Selectable Scopes 1559 All requests and services are scoped. The two exceptions are 1560 SrvRqsts for "service:directory-agent" and "service:service-agent". 1561 These MAY have a zero-length when used to enable the 1562 user to make scope selections. In this case UAs obtain their scope 1563 list from DAAdverts (or if DAs are not available, from SAAdverts.) 1565 Otherwise, if SAs and UAs are to use any scope other than the default 1566 (i.e., "DEFAULT"), the UAs and SAs are configured with lists of 1567 scopes to use by system administrators, perhaps automatically by way 1568 of DHCP option 78 or 79. Such administrative scoping allows services 1569 to be provisioned, so that users will only see services they are 1570 intended to see. 1572 User configurable scopes allow a user to discover any service, but 1573 require them to do their own selection of scope. This is similar to 1574 the way AppleTalk and LanManager networking allow user selection of 1575 AppleTalk Zone or Windows Workgroups. 1577 Note that the two configuration choices are not compatible. One 1578 model allows administrators control over service provision. The 1579 other delegates this to users (who may not be prepared to do any 1580 configuration of their system). 1582 11.3. Protected Scopes 1584 A protected scope is identical to a nonprotected scope except that 1585 it requires authentication of service information. If a `protected 1586 scope' is configured, it must be accompanied by a key for the 1587 authentication calculation. Typically, public key cryptography is 1588 used to avoid excessive disclosure of any private shared key with a 1589 possibly large collection of UAs. 1591 In protected scopes, certain SLP functions are restricted: AttrRqst 1592 and SrvDeReg messages MUST NOT contain a . DAs MUST 1593 verify SrvReg and SrvDeReg messages sent by SAs which select 1594 protected scopes. UAs MUST verify SrvRply and AttrRply messages sent 1595 using protected scopes before returning them to client processes. 1597 12. Directory Agents 1599 DAs cache service location and attribute information. They exist to 1600 enhance the performance and scalability of SLP. Multiple DAs provide 1601 further scalability and robustness of operation, since they can each 1602 store service information for the same SAs, in case one of the DAs 1603 fails. 1605 For use in networks with multiple subnets, a DA provides a 1606 centralized store for service information. The DA address can be 1607 dynamically configured with UAs and DAs using DHCP, or by using 1608 static configuration. 1610 Passive detection of DAs by SAs enables services to be advertised 1611 consistently among DAs of the same scope. Advertisements expire if 1612 not renewed, leaving only transient stale registrations in DAs, even 1613 in the case of a failure of a SA. 1615 A single DA can support many UAs. UAs send the same requests to DAs 1616 that they would send to SAs and expect the same results. DAs reduce 1617 the load on SAs, making simpler implementations of SAs possible. 1619 UAs be prepared for the possibility that the service information they 1620 obtain from DAs is stale. 1622 12.1. Directory Agent Rules 1624 When DAs are present, each SA MUST register its services with DAs 1625 that support one or more of its scope(s). 1627 UAs SHOULD unicast requests directly to a DA (when scoping rules 1628 allow), hence avoiding using the multicast convergence algorithm, to 1629 obtain service information. This decreases network utilization and 1630 increases the speed at which UAs can obtain service information. 1632 DAs MUST flush service advertisements once their lifetime expires or 1633 their URL Authentication Block "Timestamp" of expiration is past. 1635 DAAdverts MUST include DA Stateless Boot Timestamp, in the same 1636 format as the Authentication Block (see Section 9.2). The Timestamp 1637 in the Authentication Block indicates the time at which all previous 1638 registrations were lost (i.e., the last stateless reboot). The 1639 Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA 1640 is going down. 1642 DAs which receive a multicast SrvRqst for the service type 1643 "service:directory-agent" MUST silently discard it if the 1644 is (a) not omitted and (b) does not include a scope 1645 they are configured to use. Otherwise the DA MUST respond with a 1646 DAAdvert. 1648 DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are 1649 OPTIONAL only for SAs, not DAs.) 1651 12.2. Directory Agent Discovery 1653 UAs can discover DAs using static configuration, DHCP options 78 and 1654 79, or by multicasting (or broadcasting) Service Requests using the 1655 convergence algorithm in Section 6.3. 1657 See Section 6 regarding unsolicited DAAdverts. Section 12.2.2 1658 describes how SAs may reduce the number of times they must reregister 1659 with DAs in response to unsolicited DAAdverts. 1661 DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An 1662 unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, 1663 passively, as described in Section 8.5. UAs SHOULD do this. 1665 A URL with the scheme "service:directory-agent" indicates 1666 the DA's location as defined in Section 8.5. For example: 1667 "service:directory-agent://foobawooba.org". 1669 The following sections suggest timing algorithms which enhance the 1670 scalability of SLP. 1672 12.2.1. Active DA Discovery 1674 After a UA or SA restarts, its initial DA discovery request SHOULD 1675 be delayed for some random time uniformly distributed from 0 to 1676 CONFIG_START_WAIT seconds. 1678 The UA or SA sends the DA Discovery request using a SrvRqst, as 1679 described in Section 8.1. DA Discovery requests MUST include a 1680 Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT 1681 be sent more than once per CONFIG_DA_FIND seconds. 1683 After discoverying a new DA, a SA MUST wait a random time between 0 1684 and CONFIG_REG_ACTIVE seconds before registering their services. 1686 12.2.2. Passive DA Advertising 1688 A DA MUST multicast (or broadcast) an unsolicited DAAdvert every 1689 CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to 1690 prevent DAAdverts from using more than 1% of the available bandwidth. 1692 All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine 1693 its DA stateless Boot Timestamp. If it is set to 0, the DA is going 1694 down and no further messages should be sent to it. 1696 If a SA detects a DA it has never encountered (with a nonzero 1697 timestamp,) the SA must register with it. SAs MUST examine the 1698 DAAdvert's timestamp to determine if the DA has had a stateless 1699 reboot since the SA last registered with it. If so it registers 1700 with the DA. SAs MUST wait a random interval between 0 and 1701 CONFIG_REG_PASSIVE before beginning DA registration. 1703 12.3. Reliable Unicast to DAs 1705 If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY 1706 seconds, the message should be retried. If a DA fails to respond 1707 after CONFIG_DA_MAX seconds, the SA should consider the DA to have 1708 gone down. The UA should use a different DA. If no such DA responds, 1709 DA discovery should be used to find a new DA. If no DA is available, 1710 multicast is used. 1712 12.4. DA Scope Configuration 1714 By default, DAs are configured with the "DEFAULT" scope. 1715 Administrators may add other configured scopes, in order to support 1716 UAs and SAs in non default scopes. The default configuration MUST 1717 NOT be removed from the DA unless: 1719 - There are other DAs which support the "DEFAULT" scope, or 1721 - All UAs and SAs have been configured with non-default scopes. 1723 Non-default scopes can be phased-in as the SLP deployment grows. 1724 Default scopes should be phased out only when the non-default scopes 1725 are universally configured. 1727 If a DA and SA are coresident on a host (quite possibly implemented 1728 by the same process), configuration of the host is considerably 1729 simplified if the SA supports only scopes also supported by the DA. 1730 That is, the SA SHOULD NOT advertise services in any scopes which are 1731 not supported by the coresident DA. This means that incoming requests 1732 can be answered by a single data store; the SA and DA registrations 1733 do not need to be kept separately. 1735 12.5. DAs and Authentication Blocks 1737 DAs are not configured with protected scope private keys. This means 1738 they will not be able to sign URLs and s, but only cache 1739 them for SAs, forwarding them to UAs. Consequently, in a protected 1740 scope the DA will not accept: SrvReg without the FRESH flag set or 1741 AttrRqst or SrvDeReg with a included. In these cases an 1742 AUTHENTICATION_FAILED error is returned. 1744 13. SLP Protocol Extensions 1746 13.1. Required Attribute Missing Option 1748 0 1 2 3 1749 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | Extension Type = 0x0001 | Extension Length | 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Template IDVer Length | Template IDVer String \ 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 |Required Attr Length| Required Attr \ 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 Required attributes and the format of the IDVer string are defined 1759 by [14]. 1761 If a SA or DA receives a SrvRqst or a SrvReg which fails to include 1762 a Required Attribute for the requested Service Type (according 1763 to the service template), it MAY return the Required Attribute 1764 Extension in addition to the reply corresponding to the message. The 1765 sender SHOULD reissue the message with a search filter including 1766 the attributes listed in the returned Required Attribute Extension. 1767 Similarly, the Required Attribute Extension may be returned in 1768 response to a SrvDereg message that contains a required attribute 1769 tag. 1771 The Template IDVer String is the name and version number string of 1772 the service template which defines the given attribute as required. 1773 It SHOULD be included, but can be omitted if a given SA or DA has 1774 been individually configured to have 'required attributes.' 1776 The Required Attribute may not include wild cards. 1778 13.2. Cryptographic Request Option 1780 If a UA wishes to obtain an Authentication Block using a non-default 1781 algorithm (i.e., not using DSA), it SHOULD include a SLP Extension 1782 requesting a particular BSD and optionally a Key Generation Number. 1784 0 1 2 3 1785 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1787 | Extension Type = 0x0002 | Extension Length | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1789 | Desired BSD |Key Generation Number(optional)| 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+ 1792 The Desired BSD (see Section 9.1) is a two byte value. If the DA 1793 or SA does not support this OPTIONAL extension, it will ignore it 1794 and return a DSA authentication block. If it supports the Extension 1795 and the algorithm identified by the Desired BSD it will return an 1796 Authentication block using the desired algorithm. 1798 If a Key Generation Number is included, the host receiving the 1799 request MUST reply with an Authentication Block which uses the key 1800 with the requested Key Generation Number (see Section 9.2). To omit 1801 a Key Generation Number in the Cryptographic Request Option, the Key 1802 Generation Number field is set to 0. 1804 If the SA or DA supports this option and receives a multicast request 1805 for a Key Generation Number or a cryptographic algorithm it does not 1806 support, it returns an AUTHENTICATION_UNKNOWN error. 1808 14. Protocol Timing Defaults 1810 Interval name Section Default Value Meaning 1811 ------------------- ------- ------------- ------------------------ 1812 CONFIG_MC_RETRY 6.3 each second, Retry multicast query 1813 backing off until no new values 1814 gradually arrive. 1815 CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a 1816 complete multicast query 1817 response (all values.) 1818 CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA 1819 discovery on reboot. 1820 CONFIG_DA_RETRY 12.3 2 seconds Retransmit DA discovery, 1821 try it 3 times. 1822 CONFIG_DA_MAX 12.3 6 seconds Give up on requests sent 1823 to a DA. 1824 CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs 1825 passively detect new DAs. 1826 CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait 1827 before repeating Active 1828 DA discovery. 1829 CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services 1830 on passive DA discovery. 1831 CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services 1832 on active DA discovery. 1833 CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle 1834 connections. 1836 15. Optional Configuration 1838 Broadcast Only 1839 Any SLP agent SHOULD be configurable to use broadcast 1840 only. See Sections 6.1 and 12.2. 1842 Predefined DA 1843 A UA or SA SHOULD be configurable to use a predefined DA. 1845 No DA Discovery 1846 The UA or SA SHOULD be configurable to ONLY use 1847 predefined and DHCP-configured DAs and perform no active 1848 or passive DA discovery. 1850 Multicast TTL 1851 The default multicast TTL is 32. Agents SHOULD be 1852 configurable to use other values. A lower value will 1853 focus the multicast convergence algorithm on smaller 1854 subnetworks, decreasing the number of responses and 1855 increases the performance of service location. This 1856 may result in UAs obtaining different results for the 1857 identical requests depending on where they are connected 1858 to the network. 1860 Timing Values 1861 Time values other than the default MAY be configurable. 1862 See Section 14. 1864 Scopes 1865 A UA MAY be configurable to support User Selectable 1866 scopes by omitting all predefined scopes. See 1867 Section 11.2. A UA or SA MUST be configurable to use 1868 specific scopes by default. Additionally, a UA or SA 1869 MUST be configurable to use specific scopes for requests 1870 for and registrations of specific service types. The 1871 scope or scopes of a DA MUST be configurable. The 1872 default value for a DA is to have the scope "DEFAULT" if 1873 not otherwise configured. 1875 DHCP Configuration 1876 DHCP options 78 and 79 may be used to configure SLP. If 1877 DA locations are configured using DHCP, these SHOULD 1878 be used in preference to DAs discovered actively or 1879 passively. One or more of the scopes configured using 1880 DHCP MUST be used in requests. The entire configured 1881 MUST be used in registration and DA 1882 configuration messages. 1884 Service Template 1885 UAs and SAs MAY be configured by using Service Templates. 1886 Besides simplifying the specification of attribute 1887 values, this also allows them to enforce the inclusion 1888 of 'required' attributes in SrvRqst, SrvReg and SrvDeReg 1889 messages. DAs MAY be configured with templates to 1890 allow them to WARN UAs and SAs in these cases. See 1891 Section 10.4. 1893 16. IANA Considerations 1895 Further Block Structured Descriptor (BSD) values may be standardized 1896 in the future by submitting a document which describes: 1898 - The data format of the Structured Authenticator block. 1900 - Which cryptographic algorithm to use (including a reference 1901 to a technical specification of the algorithm.) 1903 - The format of any keying material required for 1904 preconfiguring UAs, DAs and SAs. Also include any 1905 considerations regarding key distribution. 1907 - Security considerations to alert others to the strengths and 1908 weaknesses of the approach. 1910 The IANA will assign BSD numbers (from the range 0x0003 to 0x7FFF) on 1911 a first come, first served basis. 1913 New function-IDs, in the range 12-255, may be standardized by the 1914 method of IETF Consensus [19]. Similarly, new extensions with types 1915 in the range 3-65535 may be standardized by the method of IETF 1916 Consensus. Specification and Expert Review is required for the 1917 assignment of new error numbers in the range of 15-65535. 1919 Protocol elements used with Service Location Protocol may also 1920 require IANA registration actions. SLP is used in conjunction with 1921 "service:" URLs and service templates [14]. These are standardized 1922 by the method of a Designated Expert and a mailing list (see [14].) 1924 17. Internationalization Considerations 1926 SLP messages support the use of multiple languages by providing a 1927 Language Tag field in the common message header (see Section 8). 1929 Services MAY be registered in multiple languages. This provides 1930 attributes so that users with different language skills may select 1931 services interactively. 1933 A service which is registered in multiple languages may be queried in 1934 multiple languages. The language of the SrvRqst or AttrRqst is used 1935 to satisfy the request. If the requested language is not supported, 1936 a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply 1937 messages are always in the same language of the request. 1939 A DA or SA MAY be configured with translations of Service Templates 1940 [14] for the same service type. This will allow the DA or SA to 1941 translate a request (say in Italian) to the language of the service 1942 advertisement (say in English) and then translate the reply back to 1943 Italian. Similarly, a UA MAY use templates to translate outgoing 1944 requests and incoming replies. 1946 The dialect field in the Language Tag MAY be used: Requests which 1947 can be fulfilled by matching a language and dialect will be preferred 1948 to those which match only the language portion. Otherwise, dialects 1949 have no effect on matching requests. 1951 18. Security Considerations 1953 SLP provides for authentication of service URLs and service 1954 attributes. This provides UAs and DAs with knowledge of the 1955 integrity of service URLs and attributes included in SLP messages. 1956 The only systems which can generate digital signatures are those 1957 which have been configured by administrators in advance. Agents 1958 which verify signed data may assume it is 'trustworthy' inasmuch as 1959 administrators have ensured the cryptographic keying of SAs and DAs 1960 reflects 'trustworthiness.' 1962 Service Location does not provide confidentiality. Because the 1963 objective of this protocol is to advertise services to a community 1964 of users, confidentiality might not generally be needed when this 1965 protocol is used in non-sensitive environments. Specialized schemes 1966 might be able to provide confidentiality, if needed in the future. 1967 Sites requiring confidentiality should implement the IP Encapsulating 1968 Security Payload (ESP) [3] to provide confidentiality for Service 1969 Location messages. 1971 Using unprotected scopes, an adversary might easily use this protocol 1972 to advertise services on servers controlled by the adversary and 1973 thereby gain access to users' private information. Further, an 1974 adversary using this protocol will find it much easier to engage in 1975 selective denial of service attacks. Sites that are in potentially 1976 hostile environments (e.g., are directly connected to the Internet) 1978 should consider the advantages of distributing keys associated with 1979 protected scopes prior to deploying the sensitive directory agents or 1980 service agents. 1982 Service Location is useful as a bootstrap protocol. It may be used 1983 in environments in which no preconfiguration is possible. In such 1984 situations, a certain amount of "blind faith" is required: Without 1985 any prior configuration it is impossible to use any of the security 1986 mechanisms described above. Service Location will make use of 1987 the mechanisms provided by the Security Area of the IETF for key 1988 distribution as they become available. At this point it would only 1989 be possible to gain the benefits associated with the use of protected 1990 scopes if some cryptographic information can be preconfigured with 1991 the end systems before they use Service Location. 1993 19. Acknowledgments 1995 This document incorporates ideas from work on several discovery 1996 protocols, including RDP by Perkins and Harjono, and PDS by 1997 Michael Day. 1999 20. Full Copyright Statement 2001 Copyright (C) The Internet Society (1997). All Rights Reserved. 2003 This document and translations of it may be copied and furnished to 2004 others, and derivative works that comment on or otherwise explain it 2005 or assist in its implementation may be prepared, copied, published 2006 and distributed, in whole or in part, without restriction of any 2007 kind, provided that the above copyright notice and this paragraph 2008 are included on all such copies and derivative works. However, 2009 this document itself may not be modified in any way, such as by 2010 removing the copyright notice or references to the Internet Society 2011 or other Internet organizations, except as needed for the purpose 2012 of developing Internet standards in which case the procedures 2013 for copyrights defined in the Internet Standards process must be 2014 followed, or as required to translate it into languages other than 2015 English. 2017 The limited permissions granted above are perpetual and will not be 2018 revoked by the Internet Society or its successors or assigns. 2020 This document and the information contained herein is provided on an 2021 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2022 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2023 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2024 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2025 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2027 References 2029 [1] Port numbers, July 1997. 2030 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 2032 [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2033 DAM 4 to ISO/IEC 9594-2, December 1996. 2035 [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2036 DAM 2 to ISO/IEC 9594-6, December 1996. 2038 [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2039 DAM 1 to ISO/IEC 9594-7, December 1996. 2041 [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2042 DAM 1 to ISO/IEC 9594-8, December 1996. 2044 [6] Unicode Technical Report #4. The unicode standard, version 2.0. 2045 Technical Report ISBN 0-201-48345-9, The Unicode Consortium, 2046 1996. 2048 [7] H. Alvestrand. Tags for the Identification of Languages. RFC 2049 1766, March 1995. 2051 [8] D. Balenson. Privacy Enhancement for Internet Electronic 2052 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 2053 February 1993. 2055 [9] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 2056 Locators (URL). RFC 1738, December 1994. 2058 [10] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 2059 Levels. RFC 2119, March 1997. 2061 [11] CCITT. Specification of the Abstract Syntax Notation One 2062 (ASN.1). Recommendation X.208, 1988. 2064 [12] CCITT. The Directory Authentication Framework. Recommendation 2065 X.509, 1988. 2067 [13] D. Crocker and P. Overell. Augmented BNF for Syntax 2068 Specifications: ABNF. RFC 2234, November 1997. 2070 [14] E. Guttman, C. Perkins, and J. Kempf. Service Templates and 2071 service: Schemes. draft-ietf-svrloc-service-scheme-05.txt, 2072 November 1997. (work in progress). 2074 [15] T. Howes. The string representation of LDAP search filters. 2075 draft-ietf-asid-ldapv3-filter-03.txt, October 1997. (work in 2076 progress). 2078 [16] H. Krawczyk, M. Bellare, and R. Cannetti. HMAC: Keyed-Hashing 2079 for Message Authentication. RFC 2104, February 1997. 2081 [17] D. Meyer. Administratively Scoped IP Multicast. draft-ietf- 2082 mboned-admin-ip-space-04.txt, November 1997. (work in progress). 2084 [18] D. Mills. Network Time Protocol (Version 3): Specification, 2085 Implementation and Analysis. RFC 1305, March 1992. 2087 [19] T. Narten, H. Alvestrand. Guidelines for Writing an IANA 2088 Considerations Section in RFCs. draft-iesg-iana-considerations 2089 -04.txt, May 1998. (work in progress). 2091 [20] National Institute of Standards and Technology. Digital 2092 signature standard. Technical Report NIST FIPS PUB 186, U.S. 2093 Department of Commerce, May 1994. 2095 [21] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, April 2096 1992. 2098 [22] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2099 Location Protocol. RFC 2165, July 1997. 2101 [23] F. Yergeau. UTF-8, a transformation format of ISO 10646. RFC 2102 2279, January 1998. 2104 Authors' Addresses 2106 Erik Guttman Charles Perkins 2107 Sun Microsystems Sun Microsystems 2108 Bahnstr. 2 901 San Antonio Road 2109 74915 Waibstadt Palo Alto, CA 94040 2110 Germany USA 2112 Phone: +49 7263 911 701 +1 650 786 6464 2113 Email: Erik.Guttman@sun.com cperkins@sun.com 2115 John Veizades Michael Day 2116 @Home Network Intel 2117 385 Ravendale Dr. 734 E. Utah Valley Dr., Ste. 300 2118 Mountain View, CA 94043 American Fork, Utah, 84003 2119 USA USA 2121 Phone: +1 650 569 5243 +1 801 763 2341 2122 Email: veizades@home.net Michael_Day@ccm.ut.intel.com