idnits 2.17.1 draft-ietf-svrloc-protocol-v2-15.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 the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 54 pages 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 == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2165, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC2165, updated by this document, for RFC5378 checks: 1997-06-01) -- 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: 'RFC 2165' on line 158 -- Looks like a reference, but probably isn't: '-' on line 542 -- 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) ** Obsolete normative reference: RFC 2396 (ref. '8') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2234 (ref. '11') (Obsoleted by RFC 4234) -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2254 (ref. '14') (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 2251 (ref. '15') (Obsoleted by RFC 4510, RFC 4511, RFC 4512, RFC 4513) ** Obsolete normative reference: RFC 2255 (ref. '16') (Obsoleted by RFC 4510, RFC 4516) ** Obsolete normative reference: RFC 2434 (ref. '18') (Obsoleted by RFC 5226) -- Possible downref: Non-RFC (?) normative reference: ref. '19' -- Possible downref: Non-RFC (?) normative reference: ref. '20' == Outdated reference: A later version (-07) exists of draft-ietf-dhc-slp-06 ** Obsolete normative reference: RFC 2279 (ref. '23') (Obsoleted by RFC 3629) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 15 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 20 April 1999 Sun Microsystems 4 Updates: RFC 2165 John Veizades 5 @Home Network 6 Michael Day 7 Madison River Technologies 9 Service Location Protocol, Version 2 10 draft-ietf-svrloc-protocol-v2-15.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 and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at: 33 http://www.ietf.org/ietf/1id-abstracts.txt 35 The list of Internet-Draft Shadow Directories can be accessed at: 37 http://www.ietf.org/shadow.html. 39 Abstract 41 The Service Location Protocol provides a scalable framework for 42 the discovery and selection of network services. Using this 43 protocol, computers using the Internet need little or no static 44 configuration of network services for network based applications. 45 This is especially important as computers become more portable, and 46 users less tolerant or able to fulfill the demands of network system 47 administration. 49 Contents 51 Status of This Memo i 53 Abstract i 55 1. Introduction 1 56 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 2 58 2. Terminology 2 59 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 61 3. Protocol Overview 3 63 4. URLs used with Service Location 7 64 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . . 7 65 4.2. Naming Authorities . . . . . . . . . . . . . . . . . . . 8 66 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 9 68 5. Service Attributes 9 70 6. Required Features 11 71 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . . . 12 72 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . . . 13 73 6.3. Retransmission of SLP messages . . . . . . . . . . . . . 14 74 6.4. Strings in SLP messages . . . . . . . . . . . . . . . . . 14 75 6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . . 15 77 7. Errors 16 79 8. Required SLP Messages 16 80 8.1. Service Request . . . . . . . . . . . . . . . . . . . . . 18 81 8.2. Service Reply . . . . . . . . . . . . . . . . . . . . . . 20 82 8.3. Service Registration . . . . . . . . . . . . . . . . . . 21 83 8.4. Service Acknowledgment . . . . . . . . . . . . . . . . . 22 84 8.5. Directory Agent Advertisement . . . . . . . . . . . . . . 23 85 8.6. Service Agent Advertisement . . . . . . . . . . . . . . . 24 87 9. Optional Features 25 88 9.1. Service Location Protocol Extensions . . . . . . . . . . 26 89 9.2. Authentication Blocks . . . . . . . . . . . . . . . . . . 27 90 9.2.1. SLP Message Authentication Rules . . . . . . . . 28 91 9.2.2. DSA with SHA-1 in Authentication Blocks . . . . . 29 92 9.3. Incremental Service Registration . . . . . . . . . . . . 29 93 9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . . 30 95 10. Optional SLP Messages 30 96 10.1. Service Type Request . . . . . . . . . . . . . . . . . . 31 97 10.2. Service Type Reply . . . . . . . . . . . . . . . . . . . 31 98 10.3. Attribute Request . . . . . . . . . . . . . . . . . . . . 32 99 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . . 33 100 10.5. Attribute Request/Reply Examples . . . . . . . . . . . . 33 101 10.6. Service Deregistration . . . . . . . . . . . . . . . . . 35 103 11. Scopes 36 104 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . . 36 105 11.2. Administrative and User Selectable Scopes . . . . . . . . 37 107 12. Directory Agents 37 108 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . . 38 109 12.2. Directory Agent Discovery . . . . . . . . . . . . . . . . 38 110 12.2.1. Active DA Discovery . . . . . . . . . . . . . . . 39 111 12.2.2. Passive DA Advertising . . . . . . . . . . . . . 39 112 12.3. Reliable Unicast to DAs and SAs . . . . . . . . . . . . . 40 113 12.4. DA Scope Configuration . . . . . . . . . . . . . . . . . 40 114 12.5. DAs and Authentication Blocks . . . . . . . . . . . . . . 40 116 13. Protocol Timing Defaults 42 118 14. Optional Configuration 42 120 15. IANA Considerations 44 122 16. Internationalization Considerations 45 124 17. Security Considerations 46 126 A. Appendix: Changes to the Service Location Protocol from v1 to v2 47 128 B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 47 130 C. Appendix: DAAdverts with arbitrary URLs 48 132 D. Appendix: SLP Protocol Extensions 49 133 D.1. Required Attribute Missing Option . . . . . . . . . . . . 49 135 E. Full Copyright Statement 52 137 1. Introduction 139 The Service Location Protocol (SLP) provides a flexible and scalable 140 framework for providing hosts with access to information about 141 the existence, location, and configuration of networked services. 142 Traditionally, users have had to find services by knowing the name of 143 a network host (a human readable text string) which is an alias for a 144 network address. SLP eliminates the need for a user to know the name 145 of a network host supporting a service. Rather, the user supplies 146 the desired type of service and a set of attributes which describe 147 the service. Based on that description, the Service Location 148 Protocol resolves the network address of the service for the user. 150 SLP provides a dynamic configuration mechanism for applications in 151 local area networks. Applications are modeled as clients that need 152 to find servers attached to any of the available networks within an 153 enterprise. For cases where there are many different clients and/or 154 services available, the protocol is adapted to make use of nearby 155 Directory Agents that offer a centralized repository for advertised 156 services. 158 This document updates SLPv1 [RFC 2165], correcting protocol errors, 159 adding some enhancements and removing some requirements. This 160 specification has two parts. The first describes the required 161 features of the protocol. The second describes the extended features 162 of the protocol which are optional, and allow greater scalability. 164 1.1. Applicability Statement 166 SLP is intended to function within networks under cooperative 167 administrative control. Such networks permit a policy to be 168 implemented regarding security, multicast routing and organization 169 of services and clients into groups which are not be feasible on the 170 scale of the Internet as a whole. 172 SLP has been designed to serve enterprise networks with shared 173 services, and it may not necessarily scale for wide-area service 174 discovery throughout the global Internet, or in networks where 175 there are hundreds of thousands of clients or tens of thousands of 176 services. 178 2. Terminology 180 User Agent (UA) 181 A process working on the user's behalf to establish 182 contact with some service. The UA retrieves service 183 information from the Service Agents or Directory Agents. 185 Service Agent (SA) 186 A process working on the behalf of one or more services 187 to advertise the services. 189 Directory Agent (DA) 190 A process which collects service advertisements. There 191 can only be one DA present per given host. 193 Service Type 194 Each type of service has a unique Service Type string. 196 Naming Authority 197 The agency or group which catalogues given Service Types 198 and Attributes. The default Naming Authority is IANA. 200 Scope A set of services, typically making up a logical 201 administrative group. 203 URL A Universal Resource Locator [8]. 205 2.1. Notation Conventions 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119 [9]. 211 Syntax Syntax for string based protocols follow the 212 conventions defined for ABNF [11]. 214 Strings All strings are encoded using the UTF-8 [23] 215 transformation of the Unicode [6] character set and 216 are NOT null terminated when transmitted. Strings 217 are preceded by a two byte length field. 219 A comma delimited list of strings with the 220 following syntax: 222 string-list = string / string `,' string-list 224 In format diagrams, any field ending with a \ indicates a variable 225 length field, given by a prior length field in the protocol. 227 3. Protocol Overview 229 The Service Location Protocol supports a framework by which client 230 applications are modeled as 'User Agents' and services are advertised 231 by 'Service Agents.' A third entity, called a 'Directory Agent' 232 provides scalability to the protocol. 234 The User Agent issues a 'Service Request' (SrvRqst) on behalf of the 235 client application, specifying the characteristics of the service 236 which the client requires. The User Agent will receive a Service 237 Reply (SrvRply) specifying the location of all services in the 238 network which satisfy the request. 240 The Service Location Protocol framework allows the User Agent to 241 directly issue requests to Service Agents. In this case the request 242 is multicast. Service Agents receiving a request for a service which 243 they advertise unicast a reply containing the service's location. 245 +------------+ ----Multicast SrvRqst----> +---------------+ 246 | User Agent | | Service Agent | 247 +------------+ <----Unicast SrvRply------ +---------------+ 249 In larger networks, one or more Directory Agents are used. The 250 Directory Agent functions as a cache. Service Agents send register 251 messages (SrvReg) containing all the services they advertise to 252 Directory Agents and receive acknowledgements in reply (SrvAck). 253 These advertisements must be refreshed with the Directory Agent 254 or they expire. User Agents unicast requests to Directory Agents 255 instead of Service Agents if any Directory Agents are known. 257 +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ 258 | User | | Directory | |Service | 259 | Agent | | Agent | | Agent | 260 +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ 262 User and Service Agents discover Directory Agents two ways. First, 263 they issue a multicast Service Request for the 'Directory Agent' 264 service when they start up. Second, the Directory Agent sends 265 an unsolicited advertisement infrequently, which the User and 266 Service Agents listen for. In either case the Agents receive a DA 267 Advertisement (DAAdvert). 269 +---------------+ --Multicast SrvRqst-> +-----------+ 270 | User or | <--Unicast DAAdvert-- | Directory | 271 | Service Agent | | Agent | 272 +---------------+ <-Multicast DAAdvert- +-----------+ 274 Services are grouped together using 'scopes'. These are strings 275 which identify services which are administratively identified. A 276 scope could indicate a location, administrative grouping, proximity 277 in a network topology or some other category. Service Agents and 278 Directory Agents are always assigned a scope string. 280 A User Agent is normally assigned a scope string (in which case the 281 User Agent will only be able to discover that particular grouping 282 of services). This allows a network administrator to 'provision' 283 services to users. Alternatively, the User Agent may be configured 284 with no scope at all. In that case, it will discover all available 285 scopes and allow the client application to issue requests for any 286 service available on the network. 288 +---------+ Multicast +-----------+ Unicast +-----------+ 289 | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | 290 | Agent | | Agent | | Agent | 291 | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | 292 +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+ 294 In the above illustration, the User Agent is configured with scopes X 295 and Y. If a service is sought in scope X, the request is multicast. 296 If it is sought in scope Y, the request is unicast to the DA. 297 Finally, if the request is to be made in both scopes, the request 298 must be both unicast and multicast. 300 Service Agents and User Agents may verify digital signatures provided 301 with DAAdverts. User Agents and Directory Agents may verify service 302 information registered by Service Agents. The keying material to 303 use to verify digital signatures is identified using a SLP Security 304 Parameter Index, or SLP SPI. 306 Every host configured to generate a digital signature includes the 307 SLP SPI used to verify it in the Authentication Block it transmits. 308 Every host which can verify a digital signature must be configured 309 with keying material and other parameters corresponding with the SLP 310 SPI such that it can perform verifying calculations. 312 SAs MUST accept multicast service requests and unicast service 313 requests. SAs MAY accept other requests (Attribute and Service Type 314 Requests). SAs MUST listen for multicast DA Advertisements. 316 The features described up to this point are required to implement. 317 A minimum implementation consists of a User Agent, Service Agent or 318 both. 320 There are several optional features in the protocol. Note that 321 DAs MUST support all these message types, but DA support is itself 322 optional to deploy on networks using SLP. UAs and SAs MAY support 323 these message types. These operations are primarily for interactive 324 use (browsing or selectively updating service registrations.) UAs 325 and SAs either support them or not depending on the requirements and 326 constraints of the environment where they will be used. 328 Service Type Request A request for all types of service on the 329 network. This allows generic service browsers 330 to be built. 332 Service Type Reply A reply to a Service Type Request. 334 Attribute Request A request for attributes of a given type of 335 service or attributes of a given service. 337 Attribute Reply A reply to an Attribute Request. 339 Service Deregister A request to deregister a service or some 340 attributes of a service. 342 Service Update A subsequent SrvRqst to an advertisement. 343 This allows individual dynamic attributes to 344 be updated. 346 SA Advertisement In the absense of Directory Agents, a User 347 agent may request Service Agents in order 348 to discover their scope configuration. The 349 User Agent may use these scopes in requests. 351 In the absense of Multicast support, Broadcast MAY be used. The 352 location of DAs may be staticly configured, discovered using SLP as 353 described above, or configured using DHCP. If a message is too large, 354 it may be unicast using TCP. 356 A SLPv2 implementation SHOULD support SLPv1 [22]. This support 357 includes: 359 1. SLPv2 DAs are deployed, phasing out SLPv1 DAs. 361 2. Unscoped SLPv1 requests are considered to be of DEFAULT scope. 362 SLPv1 UAs MUST be reconfigured to have a scope if possible. 364 3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1 365 DA. SLPv1 SAs MUST be reconfigured to have a scope if possible. 367 4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 368 requests with SLPv2 replies. 370 5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same 371 way. That is, incoming requests from agents using either version 372 of the protocol will be matched against this common set of 373 registered services. 375 6. SLPv2 registrations which use Language Tags which are greater 376 than 2 characters long will be inaccessible to SLPv1 UAs. 378 7. SLPv2 DAs MUST return only service type strings in SrvTypeRply 379 messages which conform to SLPv1 service type string syntax, ie. 380 they MUST NOT return Service Type strings for abstract service 381 types. 383 8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service 384 URLs with abstract service types. They only match Service URLs 385 with concrete service types. 387 SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will 388 not receive replies from SLPv1 SAs. In order to interoperate UAs and 389 SAs of different versions require a SLPv2 DA to be present on the 390 network which supports both protocols. 392 The use of abstract service types in SLPv2 presents a backward 393 compatibility issue for SLPv1. It is possible that a SLPv1 UA will 394 request a service type which is actually an abstract service type. 395 Based on the rules above, the SLPv1 UA will never receive an abstract 396 Service URL reply. For example, the service type 'service:x' in a 397 SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'. 398 If the request was made with SLPv2, it would return the attributes of 399 this service. 401 4. URLs used with Service Location 403 A Service URL indicates the location of a service. This URL may be 404 of the service: scheme [13] (reviewed in section 4.1), or any other 405 URL scheme conforming to the URI standard [8], except that URLs 406 without address specifications SHOULD NOT be advertised by SLP. The 407 service type for an 'generic' URL is its scheme name. For example, 408 the service type string for "http://www.srvloc.org" would be "http". 410 Reserved characters in URLs follow the rules in RFC 2396 [8]. 412 4.1. Service: URLs 414 Service URL syntax and semantics are defined in [13]. Any network 415 service may be encoded in a Service URL. 417 This section provides an introduction to Service URLs and an example 418 showing a simple application of them, representing standard network 419 services. 421 A Service URL may be of the form: 423 "service:""://" 425 The Service Type of this service: URL is defined to be the string up 426 to (but not including) the final `:' before , the address 427 specification. 429 is a hostname (which should be used if possible) or 430 dotted decimal notation for a hostname, followed by an optional `:' 431 and port number. 433 A service: scheme URL may be formed with any standard protocol 434 name by concatenating "service:" and the reserved port [1] 435 name. For example, "service:tftp://myhost" would indicate a 436 tftp service. A tftp service on a nonstandard port could be 437 "service:tftp://bad.glad.org:8080". 439 Service Types SHOULD be defined by a "Service Template" [13], which 440 provides expected attributes, values and protocol behavior. An 441 abstract service type (also described in [13]) has the form 443 "service::". 445 The service type string "service:" matches all 446 services of that abstract type. If the concrete type is included 447 also, only these services match the request. For example: a 448 SrvRqst or AttrRqst which specifies "service:printer" as the 449 Service Type will match the URL service:printer:lpr://hostname 450 and service:printer:http://hostname. If the requests specified 451 "service:printer:http" they would match only the latter URL. 453 An optional substring MAY follow the last `.' character in the 454 (or in the case of an abstract service 455 type URL). This substring is the Naming Authority, as described in 456 Section 9.6. Service types with different Naming Authorities are 457 quite distinct. In other words, service:x.one and service:x.two 458 are different service types, as are service:abstract.one:y and 459 service:abstract.two:y. 461 4.2. Naming Authorities 463 A Naming Authority MAY optionally be included as part of the Service 464 Type string. The Naming Authority of a service defines the meaning 465 of the Service Types and attributes registered with and provided by 466 Service Location. The Naming Authority itself is typically a string 467 which uniquely identifies an organization. IANA is the implied 468 Naming Authority when no string is appended. "IANA" itself MUST NOT 469 be included explicitly. 471 Naming Authorities may define Service Types which are experimental, 472 proprietary or for private use. Using a Naming Authority, one 473 may either simply ignore attributes upon registration or create a 474 local-use only set of attributes for one's site. The procedure to 475 use is to create a 'unique' Naming Authority string and then specify 476 the Standard Attribute Definitions as described above. This Naming 477 Authority will accompany registration and queries, as described in 478 Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA 479 to allow for Internet-wide interoperability. 481 4.3. URL Entries 483 0 1 2 3 484 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 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | Reserved | Lifetime | URL Length | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 |URL len, contd.| URL (variable length) \ 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 |# of URL auths | Auth. blocks (if any) \ 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 SLP stores URLs in protocol elements called URL Entries, which 494 associate a length, a lifetime, and possibly authentication 495 information along with the URL. URL Entries, defined as shown above, 496 are used in Service Replies and Service Registrations. 498 5. Service Attributes 500 A service advertisement is often accompanied by Service Attributes. 501 These attributes are used by UAs in Service Requests to select 502 appropriate services. 504 The allowable attributes which may be used are typically specified 505 by a Service Template [13] for a particular service type. Services 506 which are advertised according to a standard template MUST register 507 all service attributes which the standard template requires. URLs 508 with schemes other than "service:" MAY be registered with attributes. 509 Non-standard attribute names SHOULD begin with "x-", because no 510 standard attribute name will ever have those initial characters. 512 An attribute list is a string encoding of the attributes of a 513 service. The following ABNF [11] grammar defines attribute lists: 515 attr-list = attribute / attribute `,' attr-list 516 attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag 517 attr-val-list = attr-val / attr-val `,' attr-val-list 518 attr-tag = 1*safe-tag 519 attr-val = intval / strval / boolval / opaque 520 intval = [-]1*DIGIT 521 strval = 1*safe-val 522 boolval = "true" / "false" 523 opaque = "\FF" 1*escape-val 524 safe-val = ; Any character except reserved. 525 safe-tag = ; Any character except reserved, star and bad-tag. 526 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL 527 escape-val = `\' HEXDIG HEXDIG 528 bad-tag = CR / LF / HTAB / `_' 529 star = `*' 531 The , if present, MUST be scanned prior to evaluation for 532 all occurrences of the escape character `\'. Reserved characters 533 MUST be escaped (other characters MUST NOT be escaped). All escaped 534 characters must be restored to their value before attempting string 535 matching. For Opaque values, escaped characters are not converted - 536 they are interpreted as bytes. 538 Boolean Strings which have the form "true" or "false" can 539 only take one value and may only be compared with 540 '='. Booleans are case insensitive when compared. 542 Integer Strings which take the form [-] 1* and fall 543 in the range "-2147483648" to "2147483647" are 544 considered to be Integers. These are compared using 545 integer comparison. 547 String All other Strings are matched using strict lexical 548 ordering (see Section 6.4). 550 Opaque Opaque values are sequences of bytes. These are 551 distinguished from Strings since they begin with 552 the sequence "\FF". This, unescaped, is an illegal 553 UTF-8 encoding, indicating that what follows is a 554 sequence of bytes expressed in escape notation which 555 constitute the binary value. For example, a '0' byte 556 is encoded "\FF\00". 558 A string which contains escaped values other than from the reserved 559 set of characters is illegal. If such a string is included in an 560 , or search filter, the SA or DA which 561 receives it MUST return a PARSE_ERROR to the message. 563 A keyword has only an , and no values. Attributes can 564 have one or multiple values. All values are expressed as strings. 566 When values have been advertised by a SA or are registered in a 567 DA, they can take on implicit typing rules for matching incoming 568 requests. 570 Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is 571 disallowed. A DA or SA receiving such an MUST return an 572 INVALID_REGISTRATION error. 574 6. Required Features 576 This section defines the minimal implementation requirements for 577 SAs and UAs as well as their interaction with DAs. A DA is not 578 required for SLP to function, but if it is present, the UA and SA 579 MUST interact with it as defined below. 581 A minimal implementation may consist of either a UA or SA or both. 582 The only required features of a UA are that it can issue SrvRqsts 583 according to the rules below and interpret DAAdverts, SAAdverts and 584 SrvRply messages. The UA MUST issue requests to DAs as they are 585 discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or 586 SAAdvert messages. The SA MUST also register with DAs as they are 587 discovered. 589 UAs perform discovery by issuing Service Request messages. SrvRqst 590 messages are issued, using UDP, following these prioritized rules: 592 1. A UA issues a request to a DA which it has been configured with 593 by DHCP. 595 2. A UA issues requests to DAs which it has been statically 596 configured with. 598 3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses 599 that set of DAs. A UA that does not know of any DAs SHOULD retry 600 DA discovery, increasing the waiting interval between subsequent 601 attempts exponentially (doubling the wait interval each time.) 602 The recommended minimum waiting interval is CONFIG_DA_FIND 603 seconds. 605 4. A UA with no knowledge of DAs sends requests using multicast 606 convergence to SAs. SAs unicast replies to UAs according to the 607 multicast convergence algorithm. 609 UAs and SAs are configured with a list of scopes to use according to 610 these prioritized rules: 612 1. With DHCP. 614 2. With static configuration. The static configuration may be 615 explicitely set to NO SCOPE for UAs, if the User Selectable Scope 616 model is used. See section 11.2. 618 3. In the absense of configuration, the agent's scope is "DEFAULT". 620 A UA MUST issue requests with one or more of the scopes it has been 621 configured to use. 623 A UA which has been statically configured with NO SCOPE LIST will use 624 DA or SA discovery to determine its scope list dynamically. In this 625 case it uses an empty scope list to discover DAs and possibly SAs. 626 Then it uses the scope list it obtains from DAAdverts and possibly 627 SAAdverts in subsequent requests. 629 The SA MUST register all its services with any DA it discovers, if 630 the DA advertises any of the scopes it has been configured with. A 631 SA obtains information about DAs as a UA does. In addition, the SA 632 MUST listen for multicast unsolicited DAAdverts. The SA registers 633 by sending SrvReg messages to DAs, which reply with SrvReg messages 634 to indicate success. SAs register in ALL the scopes they were 635 configured to use. 637 6.1. Use of Ports, UDP, and Multicast 639 DAs MUST accept unicast requests and multicast directory 640 agent discovery service requests (for the service type 641 "service:directory-agent"). 643 SAs MUST accept multicast requests and unicast requests both. The SA 644 can distinguish between them by whether the REQUEST MCAST flag is set 645 in the SLP Message header. 647 The Service Location Protocol uses multicast for discovering DAs and 648 for issuing requests to SAs by default. 650 The reserved listening port for SLP is 427. This is the destination 651 port for all SLP messages. SLP messages MAY be transmitted on an 652 ephemeral port. Replies and acknowledgements are sent to the port 653 from which the request was issued. The default maximum transmission 654 unit for UDP messages is 1400 bytes excluding UDP and other headers. 656 If a SLP message does not fit into a UDP datagram it MUST be 657 truncated to fit, and the OVERFLOW flag is set in the reply message. 658 A UA which receives a truncated message MAY open a TCP connection 659 (see section 6.2) with the DA or SA and retransmit the request, using 660 the same XID. It MAY also attempt to make use of the truncated reply 661 or reformulate a more restrictive request which will result in a 662 smaller reply. 664 SLP Requests messages are multicast to The Administratively Scoped 665 SLP Multicast [17] address, which is 239.255.255.253. The default 666 TTL to use for multicast is 255. 668 In isolated networks, broadcasts will work in place of multicast. 669 To that end, SAs SHOULD and DAs MUST listen for broadcast Service 670 Location messages at port 427. This allows UAs which do not support 671 multicast the use of Service Location on isolated networks. 673 Setting multicast TTL to less than 255 (the default) limits the range 674 of SLP discovery in a network, and localizes service information in 675 the network. 677 6.2. Use of TCP 679 A SrvReg or SrvDeReg may be too large to fit into a datagram. To 680 send such large SLP messages, a TCP (unicast) connection MUST be 681 established. 683 To avoid the need to implement TCP, one MUST insure that: 685 - UAs never issue requests larger than the Path MTU. SAs can omit 686 TCP support only if they never have to receive unicast requests 687 longer than the path MTU. 689 - UAs can accept replies with the 'OVERFLOW' flag set, and make use 690 of the first result included, or reformulate the request. 692 - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in 693 a single datagram. This means limiting the size of URLs, 694 the number of attributes and the number of authenticators 695 transmitted. 697 DAs MUST be able to respond to UDP and TCP requests, as well as 698 multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP 699 unless the SA will NEVER receive a request or send a reply which will 700 exceed a datagram in size (e.g., some embedded systems). 702 A TCP connection MAY be used for a single SLP transaction, or for 703 multiple transactions. Since there are length fields in the message 704 headers, SLP Agents can send multiple requests along a connection and 705 read the return stream for acknowledgments and replies. 707 The initiating agent SHOULD close the TCP connection. The DA SHOULD 708 wait at least CONFIG_CLOSE_CONN seconds before closing an idle 709 connection. DAs and SAs SHOULD close an idle TCP connection after 710 CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the 711 initiating agent neglects to close it. See Section 13 for timing 712 rules. 714 6.3. Retransmission of SLP messages 716 Requests which fail to elicit a response are retransmitted. The 717 initial retransmission occurs after a CONFIG_RETRY wait period. 718 Retransmissions MUST be made with exponentially increasing wait 719 intervals (doubling the wait each time). This applies to unicast as 720 well as multicast SLP requests. 722 Unicast requests to a DA or SA should be retransmitted until either 723 a response (which might be an error) has been obtained, or for 724 CONFIG_RETRY_MAX seconds. 726 Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds 727 until a result has been obtained. UAs need only wait till they 728 obtain the first reply which matches their request. That is, 729 retransmission is not required if the requesting agent is prepared to 730 use the 'first reply' instead of 'as many replies as possible within 731 a bounded time interval.' 733 When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, 734 they contain a of previous responders. Initially the 735 is empty. When these requests are unicast, the 736 is always empty. 738 Any DA or SA which sees its address in the MUST NOT respond 739 to the request. 741 The message SHOULD be retransmitted until the causes 742 no further responses to be elicited or the previous responder 743 list and the request will not fit into a single datagram or until 744 CONFIG_MC_MAX seconds elapse. 746 UAs which retransmit a request use the same XID. This allows a DA or 747 SA to cache its reply to the original request and then send it again, 748 should a duplicate request arrive. This cached information should 749 only be held very briefly. XIDs SHOULD be randomly chosen to avoid 750 duplicate XIDs in requests if UAs restart frequently. 752 6.4. Strings in SLP messages 754 The escape character is a backslash (UTF-8 0x5c) followed by the 755 two hexadecimal digits of the escaped character. Only reserved 756 characters are escaped. For example, a comma (UTF-8 0x29) is escaped 757 as `\29', and a backslash `\' is escaped as `\5c'. String lists used 758 in SLP define the comma to be the delimiter between list elements, so 759 commas in data strings must be escaped in this manner. Backslashes 760 are the escape character so they also must always be escaped when 761 included in a string literally. 763 String comparison for order and equality in SLP MUST be case 764 insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds 765 to ASCII character encoding). Case insensitivity SHOULD be supported 766 throughout the entire UTF-8 encoded Unicode [6] character set. 768 The case insensitivity rule applies to all string matching in SLPv2, 769 including Scope strings, SLP SPI strings, service types, attribute 770 tags and values in query handling, language tags, previous responder 771 lists. Comparisons of URL strings, however, is case sensitive. 773 White space (SPACE, CR, LF, TAB) internal to a string value is folded 774 to a single SPACE character for the sake of string comparisons. 775 White space preceding or following a string value is ignored for 776 the purposes of string comparison. For example, " Some String " 777 matches "SOME STRING". 779 String comparisons (using comparison operators such as `<=' or `>=') 780 are done using lexical ordering in UTF-8 encoded characters, not 781 using any language specific rules. 783 The reserved character `*' may precede, follow or be internal to a 784 string value in order to indicate substring matching. The query 785 including this character matches any character sequence which 786 conforms to the letters which are not wildcarded. 788 6.4.1. Scope Lists in SLP 790 Scope Lists in SLPv2 have the following grammar: 792 scope-list = scope-val / scope-val `,' scope-list 793 scope-val = 1*safe 794 safe = ; Any character except reserved. 795 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL 796 / `;' / `*' / `+' 797 escape-val = `\' HEXDIG HEXDIG 799 Scopes which include any reserved characters must replace the escaped 800 character with the escaped-val format. 802 7. Errors 804 If the Error Code in a SLP reply message is nonzero, the rest of 805 the message MAY be truncated. No data is necessarily transmitted 806 or should be expected after the header and the error code, except 807 possibly for some optional extensions to clarify the error, for 808 example as in section D.1. 810 Errors are only returned for unicast requests. Multicast requests 811 are silently discarded if they result in an error. 813 LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in 814 the scope in the AttrRqst or SrvRqst, but not in the requested 815 language. 816 PARSE_ERROR = 2: The message fails to obey SLP syntax. 817 INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero 818 lifetime or an omitted Language Tag. 819 SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in 820 its supported by the SA or DA. 821 AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an 822 unsupported SLP SPI. 823 AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR 824 authentication in the SrvReg and did not receive it. 825 AUTHENTICATION_FAILED = 7: The DA detected an authentication error in 826 an Authentication block. 827 VER_NOT_SUPPORTED = 9: Unsupported version number in message header. 828 INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. 829 DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. 830 OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option 831 from the mandatory range (see section 9.1). 832 INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for 833 an unregistered service or with inconsistent Service Types. 834 MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst 835 and does not support it. 836 REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a 837 DA more frequently than the DA's min-refresh-interval. 839 8. Required SLP Messages 841 All length fields in SLP messages are in network byte order. Where 842 'tuples' are defined, these are sequences of bytes, in the precise 843 order listed, in network byte order. 845 SLP messages all begin with the following header: 847 0 1 2 3 848 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 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Version | Function-ID | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Length, contd.|O|F|R| reserved |Next Ext Offset| 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Next Extension Offset, contd.| XID | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Language Tag Length | Language Tag \ 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 Message Type Abbreviation Function-ID 861 Service Request SrvRqst 1 862 Service Reply SrvRply 2 863 Service Registration SrvReg 3 864 Service Deregister SrvDeReg 4 865 Service Acknowledge SrvAck 5 866 Attribute Request AttrRqst 6 867 Attribute Reply AttrRply 7 868 DA Advertisement DAAdvert 8 869 Service Type Request SrvTypeRqst 9 870 Service Type Reply SrvTypeRply 10 871 SA Advertisement SAAdvert 11 873 SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST 874 also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support 875 for other messages are OPTIONAL. 877 - Length is the length of the entire SLP message, header included. 878 - The flags are: OVERFLOW (0x80) is set when a message's length 879 exceeds what can fit into a datagram. FRESH (0x40) is set on 880 every new SrvReg. REQUEST MCAST (0x20) is set when multicasting 881 or broadcasting requests. Reserved bits MUST be 0. 882 - Next Extension Offset is set to 0 unless extensions are used. 883 The first extension begins at 'offset' bytes, from the message's 884 beginning. It is placed after the SLP message data. See 885 Section 9.1 for how to interpret unrecognized SLP Extensions. 886 - XID is set to a unique value for each unique request. If the 887 request is retransmitted, the same XID is used. Replies set 888 the XID to the same value as the xid in the request. Only 889 unsolicited DAAdverts are sent with an XID of 0. 890 - Lang Tag Length is the length in bytes of the Language Tag field. 891 - Language Tag conforms to [7]. The Language Tag in a reply MUST 892 be the same as the Language Tag in the request. This field must 893 be encoded 1*8ALPHA *("-" 1*8ALPHA). 895 If an option is specified, and not included in the message, the 896 receiver MUST respond with a PARSE_ERROR. 898 8.1. Service Request 900 0 1 2 3 901 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 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Service Location header (function = SrvRqst = 1) | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | length of | String \ 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | length of | String \ 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 | length of | String \ 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | length of predicate string | Service Request \ 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | length of string | String \ 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 In order for a Service to match a SrvRqst, it must belong to at least 917 one requested scope, support the requested service type, and match 918 the predicate. If the predicate is present, the language of the 919 request (ignoring the dialect part of the Language Tag) must match 920 the advertised service. 922 is the Previous Responder List. This 923 contains dotted decimal notation IP (v4) addresses, and is 924 iteratively multicast to obtain all possible results (see 925 Section 6.3). UAs SHOULD implement this discovery algorithm. SAs 926 MUST use this to discover all available DAs in their scope, if they 927 are not already configured with DA addresses by some other means. 929 A SA silently drops all requests which include the SA's address 930 in the . An SA which has multiple network interfaces 931 MUST check if any of the entries in the equal any of its 932 interfaces. An entry in the PRList which does not conform to an IPv4 933 dotted decimal address is ignored: The rest of the is 934 processed normally and an error is not returned. 936 Once a plus the request exceeds the path MTU, multicast 937 convergence stops. This algorithm is not intended to find all 938 instances; it finds 'enough' to provide useful results. 940 The is a of configured scope names. SAs 941 and DAs which have been configured with any of the scopes in this 942 list will respond. DAs and SAs MUST reply to unicast requests with a 943 SCOPE_NOT_SUPPORTED error if the is omitted or fails to 944 include a scope they support (see Section 11). The only exceptions 945 to this are described in Section 11.2. 947 The string is discussed in Section 4. Normally, 948 a SrvRqst elicits a SrvRply. There are two exceptions: If 949 the is set to "service:directory-agent", DAs 950 respond to the SrvRqst with a DAAdvert (see Section 8.5.) If 951 set to "service:service-agent", SAs respond with a SAAdvert (see 952 Section 8.6.) If this field is omitted, a PARSE_ERROR is returned - 953 as this field is REQUIRED. 955 The is a LDAPv3 search filter [14]. This field is 956 OPTIONAL. Services may be discovered simply by type and scope. 957 Otherwise, services are discovered which satisfy the . 958 If present, it is compared to each registered service. If the 959 attribute in the filter has been registered with multiple values, the 960 filter is compared to each value and the results are ORed together, 961 i.e., "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" 962 matches (y=0,1) since Y can be nonzero. Note the matching is case 963 insensitive. Keywords (i.e., attributes without values) are matched 964 with a "presence" filter, as in "(keyword=*)". 966 An incoming request term MUST have the same type as the attribute 967 in a registration in order to match. Thus, "(x=33)" will not 968 match 'x=true', etc. while "(y=foo)" will match 'y=FOO'. 969 "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be 970 satisfied, because of the `|' (boolean disjunction). 972 Wildcard matching MUST be done with the '=' filter. In any other 973 case, a PARSE_ERROR is returned. Request terms which include 974 wildcards are interpreted to be Strings. That is, (x=34*) would 975 match 'x=34foo', but not 'x=3432' since the first value is a String 976 while the second value is an Integer; Strings don't match Integers. 978 Examples of Predicates follow. indicates the service type of 979 the SrvRqst, gives the and

is the predicate 980 string. 982 =service:http =DEFAULT

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

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

=(&(q<=3)(speed>=1000)) 992 This returns the backup service which has a queue length 993 less than 3 and a speed greater than 1000. It will 994 return this only for services registered with the BLDG 32 995 scope. 997 =service:directory-agent =DEFAULT

= 998 This returns DAAdverts for all DAs in the DEFAULT scope. 1000 DAs are discovered by sending a SrvRqst with the service type set 1001 to "service:directory-agent". If a predicate is included in the 1002 SrvRqst, the DA SHOULD respond only if the predicate can be satisfied 1003 with the DA's attributes. The MUST contain all scopes 1004 configured for the UA or SA which is discovering DAs. 1006 The string indicates a SLP SPI that the requester has 1007 been configured with. If this string is omitted, the responder 1008 does not include any Authentication Blocks in its reply. If it is 1009 included, the responder MUST return a reply which has an associated 1010 authentication block with the SLP SPI in the SrvRqst. If no replies 1011 may be returned because the SLP SPI is not supported, the responder 1012 returns an AUTHENTICATION_UNKNOWN error. 1014 8.2. Service Reply 1016 0 1 2 3 1017 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 1018 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1019 | Service Location header (function = SrvRply = 2) | 1020 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1021 | Error Code | URL Entry count | 1022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1023 | ... \ 1024 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 The service reply contains zero or more URL entries (see 1027 Section 4.3). A service reply with zero URL entries MUST be returned 1028 in response to a unicast Service Request, if no matching URLs are 1029 present. A service reply with zero URL entries MUST NOT be sent in 1030 response to a multicast or broadcast service request (instead, if 1031 there was no match found or an error processing the request, the 1032 service reply should not be generated at all). 1034 If the reply overflows, the UA MAY simply use the first URL Entry 1035 in the list. A URL obtained by SLP may not be cached longer than 1036 Lifetime seconds, unless there is a URL Authenticator block present. 1038 In that case, the cache lifetime is indicated by the Timestamp in the 1039 URL Authenticator (see Section 9.2). 1041 An authentication block is returned in the URL Entries, including 1042 the SLP SPI in the SrvRqst. If no SLP SPI was included in the 1043 request, no Authentication Blocks are returned in the reply. URL 1044 Authentication Blocks are defined in Section 9.2.1. 1046 If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless 1047 it fits entirely without truncation. 1049 8.3. Service Registration 1051 0 1 2 3 1052 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 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | Service Location header (function = SrvReg = 3) | 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | \ 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | length of service type string | \ 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 | length of | \ 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1062 | length of attr-list string | \ 1063 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1064 |# of AttrAuths |(if present) Attribute Authentication Blocks...\ 1065 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 The is a URL Entry (see section 4.3). The Lifetime defines 1068 how long a DA can cache the registration. SAs SHOULD reregister 1069 before this lifetime expires (but SHOULD NOT more often than once 1070 per second). The Lifetime MAY be set to any value between 0 and 1071 0xffff (maximum, around 18 hours). Long-lived registrations remain 1072 stale longer if the service fails and the SA does not deregister the 1073 service. 1075 The defines the service type of the URL to be 1076 registered, regardless of the scheme of the URL. The 1077 MUST contain the names of all scopes configured for the SA, which 1078 the DA it is registering with supports. The default value for the 1079 is "DEFAULT" (see Section 11). 1081 The SA MUST register consistently with all DAs. If a SA is 1082 configured with scopes X and Y and there are three DAs, whose scopes 1083 are "X", "Y" and "X,Y" respectively, the SA will register the with 1084 all three DAs in their respective scopes. All future updates and 1085 deregistrations of the service must be sent to the same set of DAs in 1086 the same scopes the service was initially registered in. 1088 The , if present, specifies the attributes and values to 1089 be associated with the URL by the DA (see Section 5). 1091 A SA configured with the ability to sign service registrations MUST 1092 sign each of the URLs and Attribute Lists using each of the keys it 1093 is configured to use, and the DA it is registering with accepts. 1094 (The SA MUST aquire DAAdverts for all DAs it will register with 1095 to obtain the DA's SLP SPI list and attributes, as described in 1096 Section 8.5). The SA supplies a SLP SPI in each authentication block 1097 indicating the SLP SPI configuration required to verify the digital 1098 signature. The format of the digital signatures used is defined in 1099 section 9.2.1. 1101 Subsequent registrations of previously registered services MUST 1102 contain the same list of SLP SPIs as previous ones or else DAs will 1103 reject them, replying with an AUTHENTICATION_ABSENT error. 1105 A registration with the FRESH flag set will replace *entirely* any 1106 previous registration for the same URL in the same language. If 1107 the FRESH flag is not set, the registration is an "incremental" 1108 registration (see Section 9.3). 1110 8.4. Service Acknowledgment 1112 0 1 2 3 1113 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 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 | Service Location header (function = SrvAck = 5) | 1116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1117 | Error Code | 1118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1120 A DA returns a SrvAck to an SA after a SrvReg. It carries only a two 1121 byte Error Code (see Section 7). 1123 8.5. Directory Agent Advertisement 1125 0 1 2 3 1126 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 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Service Location header (function = DAAdvert = 8) | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 | Error Code | DA Stateless Boot Timestamp | 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 |DA Stateless Boot Time,, contd.| Length of URL | 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 \ URL \ 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Length of | \ 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | Length of | \ 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1140 | Length of | String \ 1141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1142 | # Auth Blocks | Authentication block (if any) \ 1143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 The Error Code is set to 0 when the DAAdvert is multicast. If the 1146 DAAdvert is being returned due to a unicast SrvRqst (ie. a request 1147 without the REQUEST MCAST flag set) the DA returns the same errors a 1148 SrvRply would. 1150 The of the SrvRqst must either be omitted or include 1151 a scope which the DA supports. The DA Stateless Boot Timestamp 1152 indicates the state of the DA (see section 12.1). 1154 The DA MAY include a list of its attributes in the DAAdvert. This 1155 list SHOULD be kept short, as the DAAdvert must fit into a datagram 1156 in order to be multicast. 1158 A potential scaling problem occurs in SLPv2 if SAs choose too low a 1159 Lifetime. In this case, an onerous amount of reregistration occurs 1160 as more services are deployed. SLPv2 allows DAs to control SAs 1161 frequency of registration. A DA MAY reissue a DAAdvert with a new 1162 set of attributes at any time, to change the reregistration behavior 1163 of SAs. These apply only to subsequent registrations; existing 1164 service registrations with the DA retain their registered lifetimes. 1166 If the DAAdvert includes the attribute "min-refresh-interval" it MUST 1167 be set to a single Integer value indicating a number of seconds. If 1168 this attribute is present SAs MUST NOT refresh any particular service 1169 advertisement more frequently than this value. If SrvReg with the 1170 FRESH FLAG not set or SrvDereg with a non-empty tag list updating a 1171 particular service are received more often than the value for the 1172 DA's advertised "min-refresh-interval" attribute the DA SHOULD reject 1173 the message and return a REFRESH_REJECTED error in the SrvAck. 1175 The URL is "service:directory-agent://" of the DA, where 1176 is the dotted decimal numeric address of the DA. The 1177 of the DA MUST NOT be NULL. 1179 The SLP SPI List is the list of SPIs that the DA is capable of 1180 verifying. SAs MUST NOT register services with authentication 1181 blocks for those SLP SPIs which are not on the list. DAs will 1182 reject service registrations which they cannot verify, returning an 1183 AUTHENTICATION_UNKNOWN error. 1185 The format of DAAdvert signatures is defined in Section 9.2.1. 1187 The SLP SPI which is used to verify the DAAdvert is included in 1188 the Authentication Block. When DAAdverts are multicast, they may 1189 have to transmit multiple DAAdvert Authentication Blocks. If the 1190 DA is configured to be able to generate signatures for more than 1191 one SPI, the DA MUST include one Authentication Block for each SPI. 1192 If all these Authentication Blocks do not fit in a single datagram 1193 (to multicast or broadcast) the DA MUST send separate DAAdverts so 1194 that Authentication Blocks for all the SPIs the DA is capable of 1195 generating are sent. 1197 If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert 1198 contains only the authentication block with the SLP SPI in the 1199 SrvRqst, if the DA is configured to be able to produce digital 1200 signatures using that SLP SPI. If the SrvRqst is unicast to the DA 1201 (the REQUEST MCAST flag in the header is not set) and an unsupported 1202 SLP SPI is included, the DA replies with a DAAdvert with the Error 1203 Code set to an AUTHENTICATION_UNKNOWN error. 1205 UAs SHOULD be configured with SLP SPIs that will allow them to 1206 verify DA Advertisements. If the UA is configured with SLP SPIs and 1207 receives a DAAdvert which fails to be verified using one of them, the 1208 UA MUST discard it. 1210 8.6. Service Agent Advertisement 1212 User Agents MUST NOT solicit SA Advertisements if they have been 1213 configured to use a particular DA, if they have been configured 1214 with a or if DAs have been discovered. UAs solicit 1215 SA Advertisements only when they are explicitly configured to use 1216 User Selectable scopes (see Section 11.2) in order to discover the 1217 scopes that SAs support. This allows UAs without scope configuration 1218 to make use of either DAs or SAs without any functional difference 1219 except performance. 1221 A SA MAY be configured with attributes, and SHOULD support the 1222 attribute 'service-type' whose value is all the service types 1223 of services represented by the SA. SAs MUST NOT respond if the 1224 SrvRqst predicate is not satisfied. For example, only SAs offering 1225 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for 1226 service type "service:service-agent" which includes a predicate 1227 "(service-type=nfs)". 1229 0 1 2 3 1230 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 1231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1232 | Service Location header (function = SAAdvert = 11) | 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Length of URL | URL \ 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Length of | \ 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 | Length of | \ 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 | # auth blocks | authentication block (if any) \ 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 The SA responds only to multicast SA discovery requests which either 1244 include no or a scope which they are configured to use. 1246 The SAAdvert MAY include a list of attributes the SA supports. This 1247 attribute list SHOULD be kept short so that the SAAdvert will not 1248 exceed the path MTU in size. 1250 The URL is "service:service-agent://" of the SA, where 1251 is the dotted decimal numeric address of the SA. The of 1252 the SA MUST NOT be null. 1254 The SAAdvert contains one SAAdvert Authentication block for each SLP 1255 SPI the SA can produce Authentication Blocks for. If the UA can 1256 verify the Authentication Block of the SAAdvert, and the SAAdvert 1257 fails to be verified, the UA MUST discard it. 1259 9. Optional Features 1261 The features described in this section are not mandatory. Some are 1262 useful for interactive use of SLP (where a user rather than a program 1263 will select services, using a browsing interface for example) and for 1264 scalability of SLP to larger networks. 1266 9.1. Service Location Protocol Extensions 1268 The format of a Service Location Extension is: 1270 0 1 2 3 1271 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 1272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1273 | Extension ID | Next Extension Offset | 1274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 | Offset, contd.| Extension Data \ 1276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 Extension IDs are assigned in the following way: 1280 0x0000-0x3FFF Standardized. Optional to implement. Ignore if 1281 unrecognized. 1282 0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA 1283 which receives this option in a reply and does not understand 1284 it MUST silently discard the reply. A DA or SA which receives 1285 this option in a request and does not understand it MUST return 1286 an OPTION_NOT_UNDERSTOOD error. 1287 0x8000-0x8FFF For private use (not standardized). Optional to 1288 implement. Ignore if unrecognized. 1289 0x9000-0xFFFF Reserved. 1291 The three byte offset to next extension indicates the position of the 1292 next extension as offset from the beginning of the SLP message. 1294 The offset value is 0 if there are no extensions following the 1295 current extension. 1297 If the offset is 0, the length of the current Extension Data is 1298 determined by subtracting total length of the SLP message as given in 1299 the SLP message header minus the offset of the current extension. 1301 Extensions defined in this document are in Section D. See section 15 1302 for procedures that are required when specifying new SLP extensions. 1304 9.2. Authentication Blocks 1306 0 1 2 3 1307 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 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Block Structure Descriptor | Authentication Block Length | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Timestamp | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | SLP SPI String Length | SLP SPI String \ 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Structured Authentication Block ... \ 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Authentication blocks are returned with certain SLP messages to 1319 verify that the contents have not been modified, and have been 1320 transmitted by an authorized agent. The authentication data 1321 (contained in the Structured Authentication Block) is typically 1322 case sensitive. Even though SLP registration data (e.g., attribute 1323 values) are typically are not case sensitive, the case of the 1324 registration data has to be preserved by the registering DA so that 1325 UAs will be able to verify the data used for calculating digital 1326 signature data. 1328 The Block Structure Descriptor (BSD) identifies the format of the 1329 Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained 1330 by IANA. BSDs 0x8000-0x8FFF are for private use. 1332 The Authentication Block Length is the length of the entire block, 1333 starting with the BSD. 1335 The Timestamp is the time that the authenticator expires (to prevent 1336 replay attacks.) The Timestamp is a 32-bit unsigned fixed-point 1337 number of seconds relative to 0h on 1 January 1970. SAs use this 1338 value to indicate when the validity of the digital signature expires. 1339 This Timestamp will wrap back to 0 in the year 2106. Once the value 1340 of the Timestamp wraps, the time at which the Timestamp is relative 1341 to resets. For example, after 06h28 and 16 seconds 5 February 2106, 1342 all Timestamp values will be relative to that epoch date. 1344 The SLP Security Parameters Index (SPI) string identifies the key 1345 length, algorithm parameters and keying material to be used by agents 1346 to verify the signature data in the Structured Authentication Block. 1347 The SLP SPI string has the same grammar as the defined 1348 in Section 6.4.1. 1350 Reserved characters in SLP SPI strings must be escaped using the same 1351 convention as used throughout SLPv2. 1353 SLP SPIs deployed in a site MUST be unique. An SLP SPI used for 1354 BSD=0x0002 must not be the same as used for some other BSD. 1356 All SLP agents MUST implement DSA [20] (BSD=0x0002). SAs MUST 1357 register services with DSA authentication blocks, and they 1358 MAY register them with other authentication blocks using other 1359 algorithms. SAs MUST use DSA authentication blocks in SrvDeReg 1360 messages and DAs MUST use DSA authentication blocks in unsolicited 1361 DAAdverts. 1363 9.2.1. SLP Message Authentication Rules 1365 The sections below define how to calculate the value to apply to the 1366 algorithm identified by the BSD value. The components listed are 1367 used as if they were a contiguous single byte aligned buffer in the 1368 order given. 1370 URL 1371 16-bit Length of SLP SPI String, SLP SPI String. 1372 16-bit Length of URL, URL, 1373 32-bit Timestamp. 1375 Attribute List 1376 16-bit Length of SLP SPI String, SLP SPI String, 1377 16-bit length of , , 1378 32-bit Timestamp. 1380 DAAdvert 1381 16-bit Length of SLP SPI String, SLP SPI String, 1382 32-bit DA Stateless Boot Timestamp, 1383 16-bit Length of URL, URL, 1384 16-bit Length of , , 1385 16-bit Length of DA's , DA's , 1386 16-bit Length of DA's , DA's , 1387 32-bit Timestamp. 1389 The first SLP SPI is the SLP SPI in the Authentication 1390 Block. This SLP SPI indicates the keying material and other 1391 parameters to use to verify the DAAdvert. The SLP SPI List is 1392 the list of SLP SPIs the DA itself supports, and is able to 1393 verify. 1395 SAAdvert 1396 16-bit Length of SLP SPI String, SLP SPI String, 1397 16-bit Length of URL, URL, 1398 16-bit Length of , , 1399 16-bit Length of , , 1400 32-bit Timestamp. 1402 9.2.2. DSA with SHA-1 in Authentication Blocks 1404 BSD=0x0002 is defined to be DSA with SHA-1. The signature 1405 calculation is defined by [20]. The signature format conforms to 1406 that in the X.509 v3 certificate: 1408 1. The signature algorithm identifier (an OID) 1409 2. The signature value (an octet string) 1410 3. The certificate path. 1412 All data is represented in ASN.1 encoding: 1414 id-dsa-with-sha1 ID ::= { 1415 iso(1) member-body(2) us(840) x9-57 (10040) 1416 x9cm(4) 3 } 1418 i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately 1419 by: 1421 Dss-Sig-Value ::= SEQUENCE { 1422 r INTEGER, 1423 s INTEGER } 1425 i.e., the binary ASN.1 encoding of r and s computed using DSA 1426 and SHA-1. This is followed by a certificate path, as defined by 1427 X.509 [10], [2], [3], [4], [5]. 1429 Authentication Blocks for BSD=0x0002 have the following format. In 1430 the future, BSDs may be assigned which have different formats. 1432 0 1 2 3 1433 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 1434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1435 | ASN.1 encoded DSA signature \ 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 9.3. Incremental Service Registration 1440 Incremental registrations update attribute values for a previously 1441 registered service. Incremental service registrations are useful 1442 when only a single attribute has changed, for instance. In an 1443 incremental registration, the FRESH flag in the SrvReg header is NOT 1444 set. 1446 The new registration's attributes replace the previous 1447 registration's, but do not affect attributes which were 1448 included previously and are not present in the update. 1450 For example, suppose service:x://a.org has been registered with 1451 attributes A=1, B=2, C=3. If an incremental registration comes for 1452 service:x://a.org with attributes C=30, D=40, then the attributes for 1453 the service after the update are A=1, B=2, C=30, D=40. 1455 Incremental registrations MUST NOT be performed for services 1456 registered with Authentication Blocks. These must be registered 1457 with ALL attributes, with the FRESH flag in the SrvReg header 1458 set. DAs which receive such registration messages return an 1459 AUTHENTICATION_FAILED error. 1461 If the FRESH flag is not set and the DA does not have a prior 1462 registration for the service, the incremental registration fails with 1463 error code INVALID_UPDATE. 1465 The SA MUST use the same in an update message as was 1466 used in the prior registration. If this is not done, the DA returns 1467 a SCOPE_NOT_SUPPORTED error. In order to change the scope of a 1468 service advertisement it MUST be deregistered first and reregistered 1469 with a new . 1471 The SA MUST use the same in an update message as was 1472 used in a prior registration of the same URL. If this is not done, 1473 the DA returns an INVALID_UPDATE error. 1475 9.4. Tag Lists 1477 Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a 1478 item is: 1480 tag-filter = simple-tag / substring 1481 simple-tag = 1*filt-char 1482 substring = [initial] any [final] 1483 initial = 1*filt-char 1484 any = `*' *(filt-char `*') 1485 final = 1*filt-char 1486 filt-char = Any character excluding and (see 1487 grammar in Section 5). 1489 Wild card characters in a item match arbitrary sequences 1490 of characters. For instance "*bob*" matches "some bob I know", 1491 "bigbob", "bobby" and "bob". 1493 10. Optional SLP Messages 1495 The additional requests provide features for user interaction and for 1496 efficient updating of service advertisements with dynamic attributes. 1498 10.1. Service Type Request 1500 The Service Type Request (SrvTypeRqst) allows a UA to discover all 1501 types of service on a network. This is useful for general purpose 1502 service browsers. 1504 0 1 2 3 1505 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 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | Service Location header (function = SrvTypeRqst = 9) | 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1509 | length of PRList | String \ 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | length of Naming Authority | \ 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | length of | String \ 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1516 The list and are interpreted as in 1517 Section 8.1. 1519 The Naming Authority string, if present in the request, will 1520 limit the reply to Service Type strings with the specified Naming 1521 Authority. If the Naming Authority string is absent, the IANA 1522 registered service types will be returned. If the length of the 1523 Naming Authority is set to 0xFFFF, the Naming Authority string is 1524 omitted and ALL Service Types are returned, regardless of Naming 1525 Authority. 1527 10.2. Service Type Reply 1529 0 1 2 3 1530 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 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1532 | Service Location header (function = SrvTypeRply = 10) | 1533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 | Error Code | length of | 1535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 | \ 1537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1539 The service-type Strings (as described in Section 4.1) are provided 1540 in , which is a . 1542 If a service type has a Naming Authority other than IANA it MUST be 1543 returned following the service type string and a `.' character. 1544 Service types with the IANA Naming Authority do not include a Naming 1545 Authority string. 1547 10.3. Attribute Request 1549 The Attribute Request (AttrRqst) allows a UA to discover attributes 1550 of a given service (by supplying its URL) or for an entire service 1551 type. The latter feature allows the UA to construct a query for an 1552 available service by selecting desired features. The UA may request 1553 that all attributes are returned, or only a subset of them. 1555 0 1 2 3 1556 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 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | Service Location header (function = AttrRqst = 6) | 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | length of PRList | String \ 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | length of URL | URL \ 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1564 | length of | string \ 1565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 | length of string | string \ 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1568 | length of string | string \ 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1571 The , and string are interpreted as 1572 in Section 8.1. 1574 The URL field can take two forms. It can simply be a Service Type 1575 (see Section 4.1), such as "http" or "service:tftp". In this case, 1576 all attributes and the full range of values for each attribute of all 1577 services of the given Service Type is returned. 1579 The URL field may alternatively be a full URL, such as 1580 "service:printer:lpr://igore.wco.ftp.com:515/draft" or 1581 "nfs://max.net/znoo". In this, only the registered attributes for 1582 the specified URL are returned. 1584 The field is a of attribute tags, as 1585 defined in Section 9.4 which indicates the attributes to return 1586 in the AttrRply. If is omitted, all attributes are 1587 returned. MUST be omitted and a full URL MUST be 1588 included when attributes when a SLP SPI List string is included, 1589 otherwise the DA will reply with an AUTHENTICATION_FAILED error. 1591 10.4. Attribute Reply 1593 0 1 2 3 1594 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 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Service Location header (function = AttrRply = 7) | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | Error Code | length of | 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | \ 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 |# of AttrAuths | Attribute Authentication Block (if present) \ 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 The format of the and the Authentication Block is as 1606 specified for SrvReg (see Section 9.2.1). 1608 Attribute replies SHOULD be returned with the original case of the 1609 string registration intact, as they are likely to be human readable. 1610 In the case where the AttrRqst was by service type, all attributes 1611 defined for the service type, and all their values are returned. 1613 Although white space is folded for string matching, attribute 1614 tags and values MUST be returned with their original white space 1615 preserved. 1617 Only one copy of each attribute tag or String value should be 1618 returned, arbitrarily choosing one version (with respect to upper 1619 and lower case and white space internal to the strings): Duplicate 1620 attributes and values SHOULD be removed. An arbitrary version of the 1621 string value and tag name is chosen for the merge. For example: 1622 "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)". 1624 10.5. Attribute Request/Reply Examples 1626 Suppose that printer services have been registered as follows: 1628 Registered Service: 1629 URL = service:printer:lpr://igore.wco.ftp.com/draft 1630 scope-list = Development 1631 Lang. Tag = en 1632 Attributes = (Name=Igore),(Description=For developers only), 1633 (Protocol=LPR),(location-description=12th floor), 1634 (Operator=James Dornan \3cdornan@monster\3e), 1635 (media-size=na-letter),(resolution=res-600),x-OK 1637 URL = service:printer:lpr://igore.wco.ftp.com/draft 1638 scope-list = Development 1639 Lang. Tag = de 1640 Attributes = (Name=Igore),(Description=Nur fuer Entwickler), 1641 (Protocol=LPR),(location-description=13te Etage), 1642 (Operator=James Dornan \3cdornan@monster\3e), 1643 (media-size=na-letter),(resolution=res-600),x-OK 1645 URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn 1646 scope-list = Development 1647 Lang. Tag = en 1648 Attributes = (Name=Not),(Description=Experimental IPP printer), 1649 (Protocol=http),(location-description=QA bench), 1650 (media-size=na-letter),(resolution=other),x-BUSY 1652 Notice the first printer, "Igore" is registered in both English and 1653 German. The `<' and `>' characters in the Operator attribute value 1654 which are part of the Email address had to be escaped, as they are 1655 reserved characters for values. 1657 Attribute tags are not translated, though attribute values may be, 1658 see [13]. 1660 The attribute Request: 1662 URL = service:printer:lpr://igore.wco.ftp.com/draft 1663 scope-list = Development 1664 Lang. Tag = de 1665 tag-list = resolution,loc* 1667 receives the Attribute Reply: 1669 (location-description=13te Etage),(resolution=res-600) 1671 The attribute Request: 1673 URL = service:printer 1674 scope-list = Development 1675 Lang. Tag = en 1676 tag-list = x-*,resolution,protocol 1678 receives an Attribute Reply containing: 1680 (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY 1682 The first request is by service instance and returns the requested 1683 values, in German. The second request is by abstract service type 1684 (see Section 4) and returns values from both "Igore" and "Not". 1686 An attribute Authentication Block is returned if an authentication 1687 block with the SLP SPI in the AttrRqst can be returned. Note that 1688 the returned from a DA with an Authentication Block MUST 1689 be identical to the registered by a SA, in order for the 1690 authentication verification calculations to be possible. 1692 A SA or DA only returns an Attribute Authentication Block if the 1693 AttrRqst included a full URL in the request and no tag list. 1695 If an SLP SPI is specified in a unicast request (the REQUEST MCAST 1696 flag in the header is not set) and the SA or DA cannot return an 1697 Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN 1698 error is returned. The # of Attr Auths field is set to 0 if there 1699 no Authentication Block is included, or 1 if an Authentication Block 1700 follows. 1702 10.6. Service Deregistration 1704 A DA deletes a service registration when its Lifetime expires. 1705 Services SHOULD be deregistered when they are no longer available, 1706 rather than leaving the registrations to time out. 1708 0 1 2 3 1709 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 1710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 | Service Location header (function = SrvDeReg = 4) | 1712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 | Length of | \ 1714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1715 | URL Entry \ 1716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1717 | Length of | \ 1718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 The is a (see section 2.1). 1722 The SA MUST retry if there is no response from the DA, see Section 1723 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA 1724 receives an acknowledgment indicating success, the service and/or 1725 attributes are no longer advertised by the DA. The DA deregisters 1726 the service or service attributes from every scope specified in the 1727 SrvDeReg which it was previously registered in. 1729 The SA MUST deregister all services with the same scope list used to 1730 register the service with a DA. If this is not done in the SrvDeReg 1731 message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime 1732 field in the URL Entry is ignored for the purposes of the SrvDeReg. 1734 The is a of attribute tags to deregister 1735 as defined in Section 9.4. If no is present, the 1736 SrvDeReg deregisters the service in all languages it has been 1737 registered in. If the is present, the SrvDeReg 1738 deregisters the attributes whose tags are listed in the tag spec. 1739 Services registered with Authentication Blocks MUST NOT include 1740 a in a SrvDeReg message: A DA will respond with an 1741 AUTHENTICATION_FAILED error in this case. 1743 If the service to be deregistered was registered with an 1744 authentication block or blocks, a URL authentication block for 1745 each of the SLP SPIs registered must be included in the SrvDeReg. 1746 Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the 1747 message fails to be verified by the DA, an AUTHENTICATION_FAILED 1748 error is returned by the DA. 1750 11. Scopes 1752 Scopes are sets of services. The primary use of Scopes is to provide 1753 the ability to create administrative groupings of services. A set 1754 of services may be assigned a scope by network administrators. A 1755 client seeking services is configured to use one or more scopes. The 1756 user will only discover those services which have been configured 1757 for him or her to use. By configuring UAs and SAs with scopes, 1758 administrators may provision services. Scopes strings are case 1759 insensitive. The default SCOPE string is "DEFAULT". 1761 Scopes are the primary means an administrator has to scale SLP 1762 deployments to larger networks. When DAs with NON-DEFAULT scopes are 1763 present on the network, further gains can be had by configuring UAs 1764 and SAs to have a predefined non-default scope. These agents can 1765 then perform DA discovery and make requests using their scope. This 1766 will limit the number of replies. 1768 11.1. Scope Rules 1770 SLP messages which fail to contain a scope that the receiving Agent 1771 is configured to use are dropped (if the request was multicast) or a 1772 SCOPE_NOT_SUPPORTED error is returned (if the request was unicast). 1773 Every SrvRqst (except for DA and SA discovery requests), SrvReg, 1774 AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a 1775 . 1777 A UA MUST unicast its SLP messages to a DA which supports the desired 1778 scope, in preference to multicasting a request to SAs. A UA MAY 1779 multicast the request if no DA is available in the scope it is 1780 configured to use. 1782 11.2. Administrative and User Selectable Scopes 1784 All requests and services are scoped. The two exceptions are 1785 SrvRqsts for "service:directory-agent" and "service:service-agent". 1786 These MAY have a zero-length when used to enable the 1787 user to make scope selections. In this case UAs obtain their scope 1788 list from DAAdverts (or if DAs are not available, from SAAdverts.) 1790 Otherwise, if SAs and UAs are to use any scope other than the default 1791 (i.e., "DEFAULT"), the UAs and SAs are configured with lists of 1792 scopes to use by system administrators, perhaps automatically by way 1793 of DHCP option 78 or 79 [21]. Such administrative scoping allows 1794 services to be provisioned, so that users will only see services they 1795 are intended to see. 1797 User configurable scopes allow a user to discover any service, but 1798 require them to do their own selection of scope. This is similar to 1799 the way AppleTalk [12] and SMB [19] networking allow user selection 1800 of AppleTalk Zone or workgroups. 1802 Note that the two configuration choices are not compatible. One 1803 model allows administrators control over service provision. The 1804 other delegates this to users (who may not be prepared to do any 1805 configuration of their system). 1807 12. Directory Agents 1809 DAs cache service location and attribute information. They exist to 1810 enhance the performance and scalability of SLP. Multiple DAs provide 1811 further scalability and robustness of operation, since they can each 1812 store service information for the same SAs, in case one of the DAs 1813 fails. 1815 A DA provides a centralized store for service information. This is 1816 useful in a network with several subnets or with many SLP Agents. 1817 The DA address can be dynamically configured with UAs and SAs using 1818 DHCP, or by using static configuration. 1820 SAs configured to use DAs with DHCP or static configuration MUST 1821 unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst 1822 omits the scope list and sets the service type of the request to 1823 "service:directory-agent". The DA will return a DAAdvert with its 1824 attributes, SLP SPI list, and other parameters which are essential 1825 for proper SA to DA communication. 1827 Passive detection of DAs by SAs enables services to be advertised 1828 consistently among DAs of the same scope. Advertisements expire if 1829 not renewed, leaving only transient stale registrations in DAs, even 1830 in the case of a failure of a SA. 1832 A single DA can support many UAs. UAs send the same requests to DAs 1833 that they would send to SAs and expect the same results. DAs reduce 1834 the load on SAs, making simpler implementations of SAs possible. 1836 UAs MUST be prepared for the possibility that the service information 1837 they obtain from DAs is stale. 1839 12.1. Directory Agent Rules 1841 When DAs are present, each SA MUST register its services with DAs 1842 that support one or more of its scope(s). 1844 UAs MUST unicast requests directly to a DA (when scoping rules 1845 allow), hence avoiding using the multicast convergence algorithm, to 1846 obtain service information. This decreases network utilization and 1847 increases the speed at which UAs can obtain service information. 1849 DAs MUST flush service advertisements once their lifetime expires or 1850 their URL Authentication Block "Timestamp" of expiration is past. 1852 DAAdverts MUST include DA Stateless Boot Timestamp, in the same 1853 format as the Authentication Block (see Section 9.2). The Timestamp 1854 in the Authentication Block indicates the time at which all previous 1855 registrations were lost (i.e., the last stateless reboot). The 1856 Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the 1857 DA is going down. DAs MUST NOT use equal or lesser Boot Timestamps 1858 to previous ones, if they go down and restart without service 1859 registration state. This would mislead SAs to not reregister with 1860 the DA. 1862 DAs which receive a multicast SrvRqst for the service type 1863 "service:directory-agent" MUST silently discard it if the 1864 is (a) not omitted and (b) does not include a scope 1865 they are configured to use. Otherwise the DA MUST respond with a 1866 DAAdvert. 1868 DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are 1869 OPTIONAL only for SAs, not DAs.) 1871 12.2. Directory Agent Discovery 1873 UAs can discover DAs using static configuration, DHCP options 78 and 1874 79, or by multicasting (or broadcasting) Service Requests using the 1875 convergence algorithm in Section 6.3. 1877 See Section 6 regarding unsolicited DAAdverts. Section 12.2.2 1878 describes how SAs may reduce the number of times they must reregister 1879 with DAs in response to unsolicited DAAdverts. 1881 DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An 1882 unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, 1883 passively, as described in Section 8.5. UAs MAY do this. If they do 1884 not listen for unsolicited DAAdverts, however, they will not discover 1885 DAs as they become available. UAs SHOULD, in this case, do periodic 1886 active DA discovery, see Section 6. 1888 A URL with the scheme "service:directory-agent" indicates 1889 the DA's location as defined in Section 8.5. For example: 1890 "service:directory-agent://foobawooba.org". 1892 The following sections suggest timing algorithms which enhance the 1893 scalability of SLP. 1895 12.2.1. Active DA Discovery 1897 After a UA or SA restarts, its initial DA discovery request SHOULD 1898 be delayed for some random time uniformly distributed from 0 to 1899 CONFIG_START_WAIT seconds. 1901 The UA or SA sends the DA Discovery request using a SrvRqst, as 1902 described in Section 8.1. DA Discovery requests MUST include a 1903 Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT 1904 be sent more than once per CONFIG_DA_FIND seconds. 1906 After discovering a new DA, a SA MUST wait a random time between 0 1907 and CONFIG_REG_ACTIVE seconds before registering their services. 1909 12.2.2. Passive DA Advertising 1911 A DA MUST multicast (or broadcast) an unsolicited DAAdvert every 1912 CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to 1913 prevent DAAdverts from using more than 1% of the available bandwidth. 1915 All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine 1916 its DA stateless Boot Timestamp. If it is set to 0, the DA is going 1917 down and no further messages should be sent to it. 1919 If a SA detects a DA it has never encountered (with a nonzero 1920 timestamp,) the SA must register with it. SAs MUST examine the 1921 DAAdvert's timestamp to determine if the DA has had a stateless 1922 reboot since the SA last registered with it. If so it registers 1923 with the DA. SAs MUST wait a random interval between 0 and 1924 CONFIG_REG_PASSIVE before beginning DA registration. 1926 12.3. Reliable Unicast to DAs and SAs 1928 If a DA or SA fails to respond to a unicast UDP message in 1929 CONFIG_RETRY seconds, the message should be retried. The wait 1930 interval for each subsequent retransmission MUST exponentially 1931 increase, doubling each time. If a DA or SA fails to respond after 1932 CONFIG_RETRY_MAX seconds, the sender should consider the receiver 1933 to have gone down. The UA should use a different DA. If no such DA 1934 responds, DA discovery should be used to find a new DA. If no DA is 1935 available, multicast requests to SAs are used. 1937 12.4. DA Scope Configuration 1939 By default, DAs are configured with the "DEFAULT" scope. 1940 Administrators may add other configured scopes, in order to support 1941 UAs and SAs in non default scopes. The default configuration MUST 1942 NOT be removed from the DA unless: 1944 - There are other DAs which support the "DEFAULT" scope, or 1946 - All UAs and SAs have been configured with non-default scopes. 1948 Non-default scopes can be phased-in as the SLP deployment grows. 1949 Default scopes should be phased out only when the non-default scopes 1950 are universally configured. 1952 If a DA and SA are coresident on a host (quite possibly implemented 1953 by the same process), configuration of the host is considerably 1954 simplified if the SA supports only scopes also supported by the DA. 1955 That is, the SA SHOULD NOT advertise services in any scopes which are 1956 not supported by the coresident DA. This means that incoming requests 1957 can be answered by a single data store; the SA and DA registrations 1958 do not need to be kept separately. 1960 12.5. DAs and Authentication Blocks 1962 DAs are not configured to sign service registrations or attribute 1963 lists. They simply cache services registered by Service Agents. DAs 1964 MUST NOT accept registrations including authentication blocks for SLP 1965 SPIs which it is not configured with, see Section 8.5. 1967 A DA protects registrations which are made with authentication 1968 blocks using SLP SPIs it is configured to use. If a service S 1969 is registered, a subsequent registration (which will replace the 1970 adertisement) or a deregistration (which will remove it) MUST 1971 include an Authentication Block with the corresponding SLP SPI, see 1972 Section 8.3 and Section 10.6. 1974 Example: 1976 A DA is configured to be able to verify Authentication Blocks with 1977 SLP SPIs "X,Y", that is X and Y. 1979 An SA registers a service with an Authentication Block with SPI "Z". 1980 The DA stores the registration, but discards the Authentication 1981 Block. If a UA requests a service with an SLP SPI string "Z", the DA 1982 will respond with an AUTHENTICATION_UNKNOWN error. 1984 An SA registers a service S with Authentication Blocks including SLP 1985 SPIs "X" and "Y". If a UA requests a service with an SLP SPI string 1986 "X" the DA will be able to return S (if the service type, language, 1987 scope and predicate of the SrvRqst match S) The DA will also return 1988 the Authentication Block with SLP SPI set to "X". If the DA receives 1989 a subsequent SrvDeReg for S (which will remove the advertisement) 1990 or a subsequent SrvReg for S (which will replace it), the message 1991 must include two URL Authentication Blocks, one each for SPIs "X" 1992 and "Y". If either of these were absent, the DA would return an 1993 AUTHENTICATION_ABSENT error. 1995 13. Protocol Timing Defaults 1997 Interval name Section Default Value Meaning 1998 ------------------- ------- ------------- ------------------------ 1999 CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a 2000 complete multicast query 2001 response (all values.) 2002 CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA 2003 discovery on reboot. 2004 CONFIG_RETRY 12.3 2 seconds Wait interval before 2005 initial retransmission 2006 of multicast or unicast 2007 requests. 2008 CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast 2009 request retransmission. 2010 CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs 2011 passively detect new DAs. 2012 CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait 2013 before repeating Active 2014 DA discovery. 2015 CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services 2016 on passive DA discovery. 2017 CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services 2018 on active DA discovery. 2019 CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle 2020 connections. 2022 14. Optional Configuration 2024 Broadcast Only 2025 Any SLP agent SHOULD be configurable to use broadcast 2026 only. See Sections 6.1 and 12.2. 2028 Predefined DA 2029 A UA or SA SHOULD be configurable to use a predefined DA. 2031 No DA Discovery 2032 The UA or SA SHOULD be configurable to ONLY use 2033 predefined and DHCP-configured DAs and perform no active 2034 or passive DA discovery. 2036 Multicast TTL 2037 The default multicast TTL is 255. Agents SHOULD be 2038 configurable to use other values. A lower value will 2039 focus the multicast convergence algorithm on smaller 2040 subnetworks, decreasing the number of responses and 2041 increases the performance of service location. This 2042 may result in UAs obtaining different results for the 2043 identical requests depending on where they are connected 2044 to the network. 2046 Timing Values 2047 Time values other than the default MAY be configurable. 2048 See Section 13. 2050 Scopes 2051 A UA MAY be configurable to support User Selectable 2052 scopes by omitting all predefined scopes. See 2053 Section 11.2. A UA or SA MUST be configurable to use 2054 specific scopes by default. Additionally, a UA or SA 2055 MUST be configurable to use specific scopes for requests 2056 for and registrations of specific service types. The 2057 scope or scopes of a DA MUST be configurable. The 2058 default value for a DA is to have the scope "DEFAULT" if 2059 not otherwise configured. 2061 DHCP Configuration 2062 DHCP options 78 and 79 may be used to configure SLP. If 2063 DA locations are configured using DHCP, these SHOULD 2064 be used in preference to DAs discovered actively or 2065 passively. One or more of the scopes configured using 2066 DHCP MUST be used in requests. The entire configured 2067 MUST be used in registration and DA 2068 configuration messages. 2070 Service Template 2071 UAs and SAs MAY be configured by using Service Templates. 2072 Besides simplifying the specification of attribute 2073 values, this also allows them to enforce the inclusion 2074 of 'required' attributes in SrvRqst, SrvReg and SrvDeReg 2075 messages. DAs MAY be configured with templates to 2076 allow them to WARN UAs and SAs in these cases. See 2077 Section 10.4. 2079 SLP SPI for service discovery 2080 Agents SHOULD be configurable to support SLP SPIs using 2081 the following parameters: BSD=2 (DSA with SHA-1) and 2082 a public key identified by the SLP SPI String. In 2083 the future, when a Public Key Infrastructure exists, 2084 SLP Agents may be able to obtain public keys and 2085 cryptographic parameters corresponding to the names used 2086 in SLP SPI Strings. 2088 Note that if the SLP SPI string chosen is identical 2089 to a scope string, it is effectively the same as a 2090 Protected Scope in SLPv1. Namely, every SA advertising 2091 in that scope would be configured with the same Private 2092 Key. Every DA and UA of that scope would be configured 2093 with the appropriate Public Key to verify signatures 2094 produced by those SAs. This is a convenient way to 2095 configure SLP deployments in the absense of a Public Key 2096 Infrastructure. Currently, it would be too difficult to 2097 manage the keying of UAs and DAs if each SA had its own 2098 key. 2100 SLP SPI for Directory Agent discovery 2101 Agents SHOULD be configurable to support SLP SPIs as 2102 above, to be used when discovering DAs. This SPI SHOULD 2103 be sent in SrvRqsts to discover DAs and be used to verify 2104 multicast DAAdvert messages. 2106 SA and DA Private Key 2107 SAs and DAs which can generate digital signatures require 2108 a Private Key and a corresponding SLP SPI indentifier 2109 to include in the Authentication Block. The SLP SPI 2110 identifies the Public Key to use to verify the digital 2111 signature in the Authentication Block. 2113 15. IANA Considerations 2115 SLP includes four sets of identifiers which may be registered with 2116 IANA. The policies for these registrations (See [18]) are noted in 2117 each case. 2119 The Block Structure Descriptor (BSD) identifies the format of the 2120 Authenticator which follows. BSDs 0x8000-0x8FFF are for Private Use. 2122 Further Block Structured Descriptor (BSD) values, from the range 2123 0x0003-0x7FFF may be standardized in the future by submitting a 2124 document which describes: 2126 - The data format of the Structured Authenticator block. 2128 - Which cryptographic algorithm to use (including a reference 2129 to a technical specification of the algorithm.) 2131 - The format of any keying material required for 2132 preconfiguring UAs, DAs and SAs. Also include any 2133 considerations regarding key distribution. 2135 - Security considerations to alert others to the strengths and 2136 weaknesses of the approach. 2138 The IANA will assign Cryptographic BSD numbers on the basis of IETF 2139 Consenus. 2141 New function-IDs, in the range 12-255, may be standardized by the 2142 method of IETF Consensus. 2144 New SLP Extensions with types in the range 2-65535 may be registered 2145 following review by a Designated Expert. 2147 New error numbers in the range 15-65535 are assigned on the basis of 2148 a Standards Action. 2150 Protocol elements used with Service Location Protocol may also 2151 require IANA registration actions. SLP is used in conjunction with 2152 "service:" URLs and Service Templates [13]. These are standardized 2153 by review of a Designated Expert and a mailing list (See [13].) 2155 16. Internationalization Considerations 2157 SLP messages support the use of multiple languages by providing a 2158 Language Tag field in the common message header (see Section 8). 2160 Services MAY be registered in multiple languages. This provides 2161 attributes so that users with different language skills may select 2162 services interactively. 2164 Attribute tags are not translated. Attribute values may be 2165 translated unless the Service Template [13] defines the attribute 2166 values to be 'literal'. 2168 A service which is registered in multiple languages may be queried in 2169 multiple languages. The language of the SrvRqst or AttrRqst is used 2170 to satisfy the request. If the requested language is not supported, 2171 a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply 2172 messages are always in the same language of the request. 2174 A DA or SA MAY be configured with translations of Service Templates 2175 [13] for the same service type. This will allow the DA or SA to 2176 translate a request (say in Italian) to the language of the service 2177 advertisement (say in English) and then translate the reply back to 2178 Italian. Similarly, a UA MAY use templates to translate outgoing 2179 requests and incoming replies. 2181 The dialect field in the Language Tag MAY be used: Requests which 2182 can be fulfilled by matching a language and dialect will be preferred 2183 to those which match only the language portion. Otherwise, dialects 2184 have no effect on matching requests. 2186 17. Security Considerations 2188 SLP provides for authentication of service URLs and service 2189 attributes. This provides UAs and DAs with knowledge of the 2190 integrity of service URLs and attributes included in SLP messages. 2191 The only systems which can generate digital signatures are those 2192 which have been configured by administrators in advance. Agents 2193 which verify signed data may assume it is 'trustworthy' inasmuch as 2194 administrators have ensured the cryptographic keying of SAs and DAs 2195 reflects 'trustworthiness.' 2197 Service Location does not provide confidentiality. Because the 2198 objective of this protocol is to advertise services to a community 2199 of users, confidentiality might not generally be needed when this 2200 protocol is used in non-sensitive environments. Specialized schemes 2201 might be able to provide confidentiality, if needed in the future. 2202 Sites requiring confidentiality should implement the IP Encapsulating 2203 Security Payload (ESP) [3] to provide confidentiality for Service 2204 Location messages. 2206 If Agents are not configgured to generate Authentication Blocks and 2207 Agents are not configured to verify them, an adversary might easily 2208 use this protocol to advertise services on servers controlled by the 2209 adversary and thereby gain access to users' private information. 2210 Further, an adversary using this protocol will find it much easier 2211 to engage in selective denial of service attacks. Sites that are in 2212 potentially hostile environments (e.g., are directly connected to 2213 the Internet) should consider the advantages of distributing keys 2214 associated with SLP SPIs prior to deploying the sensitive directory 2215 agents or service agents. 2217 SLP is useful as a bootstrap protocol. It may be used in 2218 environments in which no preconfiguration is possible. In such 2219 situations, a certain amount of "blind faith" is required: Without 2220 any prior configuration it is impossible to use any of the security 2221 mechanisms described above. SLP will make use of the mechanisms 2222 provided by the Security Area of the IETF for key distribution as 2223 they become available. At this point it would only be possible to 2224 gain the benefits associated with the use of Authentication Blocks if 2225 cryptographic information and SLP SPIs can be preconfigured with the 2226 end systems before they use SLP. 2228 SLPv2 enables a number of security policies with the mechanisms it 2229 includes. A SLPv2 UA could, for instance, reject any SLP message 2230 which did not carry an authentication block which it could verify. 2231 This is not the only policy which is possible to implement. 2233 A. Appendix: Changes to the Service Location Protocol from v1 to v2 2235 SLP version 2 (SLPv2) corrects race conditions present in SLPv1 2236 [22]. In addition, authentication has been reworked to provide more 2237 flexibility and protection (especially for DA Advertisements). SLPv2 2238 also changes the formats and definition of many flags and values 2239 and reduces the number of 'required features.' SLPv2 clarifies 2240 and changes the use of 'Scopes', eliminating support for 'unscoped 2241 directory agents' and 'unscoped requests'. SLPv2 uses LDAPv3 2242 compatible string encodings of attributes and search filters. Other 2243 changes (such as Language and Character set handling) adopt practices 2244 recommended by the Internet Engineering Steering Group. 2246 Effort has been made to make SLPv2 operate the same whether DAs 2247 are present or not. For this reason, a new message (the SAAdvert) 2248 has been added. This allows UAs to discover scope information in 2249 the absence of administrative configuration and DAs. This was not 2250 possible in SLPv1. 2252 SLPv2 is incompatible in some respects with SLPv1. If a DA which 2253 supports both SLPv1 and SLPv2 with the same scope is present, 2254 services advertised by SAs using either version of the protocol will 2255 be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased 2256 out and replace with SLPv2 DAs which support both versions of the 2257 protocol. 2259 SLPv1 allows services to be advertised and requested without a scope. 2260 Further, DAs can be configured without a scope. This is incompatible 2261 with SLPv2 and presents scalability problems. To facilitate this 2262 forward migration, SLPv1 agents MUST use scopes for all registrations 2263 and requests. SLPv1 DAs MUST be configured with a scope list. This 2264 constitutes a revision of RFC 2165 [22]. 2266 B. Appendix: Service Discovery by Type: Minimal SLPv2 Features 2268 Service Agents may advertise services without attributes. This will 2269 enable only discovery of services by type. Service types discovered 2270 this way will have a Service Template [13] defined which specifies 2271 explicitely that no attributes are associated with the service 2272 advertisement. Service types associated with Service Templates which 2273 specify attributes MUST NOT be advertised by SAs which do not support 2274 attributes. 2276 While discovery of service by service type is a subset of the 2277 features possible using SLPv2 this form of discovery is consistent 2278 with the current generation of products that allow simple browsing 2279 of all services in a 'zone' or 'workgroup' by type. In some cases, 2280 attribute discovery, security and feature negotiation is handled 2281 by application layer protocols - all that is required is the basic 2282 discovery of services that support a certain service. 2284 UAs requesting only service of that service type would only need 2285 to support service type and scope fields of the Service Request. 2286 UAs would still perform DA discovery and unicast SLPv2 SrvRqst 2287 messages to DAs in their scope once they were discovered instead of 2288 multicasting them. 2290 SAs would also perform DA discovery and use a SLPv2 SrvReg to 2291 register all their advertised services with SLPv2 DAs in their scope. 2292 These advertisements would needless to say contain no attribute 2293 string. 2295 These minimal SAs could ignore the Language Tag in requests since 2296 SrvRqst messages would contain no attributes, hence no strings would 2297 be internationalized. Further, any non-null predicate string would 2298 fail to match a service advertisement with no attributes, so these 2299 SAs would not have to parse and interpret search filters. Overflow 2300 will never occur in SrvRqst, SrvRply or SrvReg messages so TCP 2301 message handling would not have to be implemented. Finally, all 2302 AttrRqst messages could be dropped by the SA, since no attributes are 2303 supported. 2305 C. Appendix: DAAdverts with arbitrary URLs 2307 Using Active DA Discovery, a SrvRqst with its service type field 2308 set to "service:directory-agent". DAs will respond with a DAAdvert 2309 containing a URL with the "service:directory-agent:" scheme. This is 2310 the same DAAdvert that such a DA would multicast in unsolicited DA 2311 advertisements. 2313 A UA or SA which receives an unsolicited DAAdvert MUST examine the 2314 URL to determine if it has a recognized scheme. If the UA or SA does 2315 not recognize the DAAdvert's URL scheme, the DAAdvert is silently 2316 discarded. This document specifies only how to use URLs with the 2317 "service:directory-agent:" scheme. 2319 This provides the possibility for forward compatibility with future 2320 versions of SLP and enables other services to advertise their ability 2321 to serve as a clearinghouse for service location information. 2323 For example, if LDAPv3 [15] is used for service registration and 2324 discovery by a set of end systems, they could interpret a LDAP 2325 URL [16] to passively discover the LDAP server to use for this 2326 purpose. This document does not specify how this is done: SLPv2 2327 agents without further support would simply discard this DAAdvert. 2329 D. Appendix: SLP Protocol Extensions 2331 D.1. Required Attribute Missing Option 2333 0 1 2 3 2334 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 2335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2336 | Extension Type = 0x0001 | Extension Length | 2337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2338 | Template IDVer Length | Template IDVer String \ 2339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2340 |Required Attr Length| Required Attr \ 2341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2343 Required attributes and the format of the IDVer string are defined 2344 by [13]. 2346 If a SA or DA receives a SrvRqst or a SrvReg which fails to include 2347 a Required Attribute for the requested Service Type (according 2348 to the Service Template), it MAY return the Required Attribute 2349 Extension in addition to the reply corresponding to the message. The 2350 sender SHOULD reissue the message with a search filter including 2351 the attributes listed in the returned Required Attribute Extension. 2352 Similarly, the Required Attribute Extension may be returned in 2353 response to a SrvDereg message that contains a required attribute 2354 tag. 2356 The Template IDVer String is the name and version number string of 2357 the Service Template which defines the given attribute as required. 2358 It SHOULD be included, but can be omitted if a given SA or DA has 2359 been individually configured to have 'required attributes.' 2361 The Required Attribute MUST NOT include wild cards. 2363 Acknowledgments 2365 This document incorporates ideas from work on several discovery 2366 protocols, including RDP by Perkins and Harjono, and PDS by Michael 2367 Day. We are grateful for contributions by Ye Gu and Peter Ford. 2368 John Veizades was instrumental in the standardization of the Service 2369 Location Protocol. Implementors at Novell, Axis Communications and 2370 Sun Microsystems have contributed significantly to make this a much 2371 clearer and more consistent document. 2373 References 2375 [1] Port numbers, July 1997. 2376 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 2378 [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2379 DAM 4 to ISO/IEC 9594-2, December 1996. 2381 [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2382 DAM 2 to ISO/IEC 9594-6, December 1996. 2384 [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2385 DAM 1 to ISO/IEC 9594-7, December 1996. 2387 [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2388 DAM 1 to ISO/IEC 9594-8, December 1996. 2390 [6] Unicode Technical Report #8. The Unicode Standard, version 2.1. 2391 Technical report, The Unicode Consortium, 1998. 2393 [7] H. Alvestrand. Tags for the Identification of Languages. RFC 2394 1766, March 1995. 2396 [8] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 2397 Identifiers (URI): Generic Syntax. RFC 2396, August 1998. 2399 [9] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 2400 Levels. RFC 2119, March 1997. 2402 [10] CCITT. The Directory Authentication Framework. Recommendation 2403 X.509, 1988. 2405 [11] D. Crocker and P. Overell. Augmented BNF for Syntax 2406 Specifications: ABNF. RFC 2234, November 1997. 2408 [12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. 2409 Addison-Wesley, 1990. 2411 [13] E. Guttman, C. Perkins, and J. Kempf. Service Templates and 2412 service: Schemes. draft-ietf-svrloc-service-scheme-14.txt, 2413 January 1999. (work in progress). 2415 [14] T. Howes. The String Representation of LDAP Search Filters. 2416 RFC 2254, December 1997. 2418 [15] M. Wahl, T. Howes, S. Kille. Lighttweight Directory Access 2419 Protocol (v3) RFC 2251, December 1997. 2421 [16] T. Howes, M. Smith The LDAP URL Format RFC 2255, December 2422 1997. 2424 [17] D. Meyer. Administratively Scoped IP Multicast. RFC 2365, July 2425 1998. 2427 [18] T. Narten and H. Alvestrand. RFC 2434: Guidelines for writing 2428 an IANA considerations section in RFCs, October 1998. Status: 2429 BEST CURRENT PRACTICE. 2431 [19] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0, 2432 Document Version 1.09, November 1989. 2434 [20] National Institute of Standards and Technology. Digital 2435 signature standard. Technical Report NIST FIPS PUB 186, U.S. 2436 Department of Commerce, May 1994. 2438 [21] C. Perkins and E. Guttman. DHCP Options for Service Location 2439 Protocol. draft-ietf-dhc-slp-06.txt, December 1998. (work in 2440 progress). 2442 [22] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2443 Location Protocol. RFC 2165, July 1997. 2445 [23] F. Yergeau. UTF-8, a transformation format of ISO 10646. RFC 2446 2279, January 1998. 2448 E. Full Copyright Statement 2450 Copyright (C) The Internet Society (1997). All Rights Reserved. 2452 This document and translations of it may be copied and furnished to 2453 others, and derivative works that comment on or otherwise explain it 2454 or assist in its implementation may be prepared, copied, published 2455 and distributed, in whole or in part, without restriction of any 2456 kind, provided that the above copyright notice and this paragraph 2457 are included on all such copies and derivative works. However, 2458 this document itself may not be modified in any way, such as by 2459 removing the copyright notice or references to the Internet Society 2460 or other Internet organizations, except as needed for the purpose 2461 of developing Internet standards in which case the procedures 2462 for copyrights defined in the Internet Standards process must be 2463 followed, or as required to translate it into languages other than 2464 English. 2466 The limited permissions granted above are perpetual and will not be 2467 revoked by the Internet Society or its successors or assigns. 2469 This document and the information contained herein is provided on an 2470 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2471 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2472 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2473 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2474 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2476 Authors' Addresses 2478 Erik Guttman Charles Perkins 2479 Sun Microsystems Sun Microsystems 2480 Bahnstr. 2 901 San Antonio Road 2481 74915 Waibstadt Palo Alto, CA 94040 2482 Germany USA 2484 Phone: +49 7263 911 701 +1 650 786 6464 2485 Email: Erik.Guttman@sun.com cperkins@sun.com 2487 John Veizades Michael Day 2488 @Home Network Madison River Technologies, Inc. 2489 425 Broadway 840 North 1415 East 2490 Redwood City, CA 94043 Orem, Utah 84097 2491 USA USA 2493 Phone: +1 650 569 5243 +1 801 802 0706 2494 Email: veizades@home.net Michael.Day@madisonriv.com