idnits 2.17.1 draft-ietf-svrloc-protocol-v2-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == 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 == Line 1988 has weird spacing: '...ing off unt...' (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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '-' on line 560 == Unused Reference: '16' is defined on line 2305, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 1766 (ref. '7') (Obsoleted by RFC 3066, RFC 3282) ** 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' == Outdated reference: A later version (-14) exists of draft-ietf-svrloc-service-scheme-12 ** Obsolete normative reference: RFC 2254 (ref. '14') (Obsoleted by RFC 4510, RFC 4515) ** Obsolete normative reference: RFC 1779 (ref. '16') (Obsoleted by RFC 2253, RFC 3494) -- Possible downref: Non-RFC (?) normative reference: ref. '17' -- Possible downref: Non-RFC (?) normative reference: ref. '18' -- Possible downref: Non-RFC (?) normative reference: ref. '19' ** Obsolete normative reference: RFC 2279 (ref. '21') (Obsoleted by RFC 3629) Summary: 13 errors (**), 0 flaws (~~), 7 warnings (==), 16 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 09 October 1998 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-10.txt 12 Status of This Memo 14 This document is a submission by the Service Location Working Group 15 of the Internet Engineering Task Force (IETF). Comments should be 16 submitted to the srvloc@srvloc.org mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To view the entire list of current Internet-Drafts, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The Service Location Protocol provides a scalable framework for 39 the discovery and selection of network services. Using this 40 protocol, computers using the Internet need little or no static 41 configuration of network services for network based applications. 42 This is especially important as computers become more portable, and 43 users less tolerant or able to fulfill the demands of network system 44 administration. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 53 1.1. Applicability Statement . . . . . . . . . . . . . . . . . 2 54 1.2. Changes to the Service Location Protocol from v1 to v2 . 2 56 2. Terminology 3 57 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 59 3. Protocol Overview 4 61 4. URLs used with Service Location 7 62 4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . . 8 63 4.2. Naming Authorities . . . . . . . . . . . . . . . . . . . 9 64 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. Service Attributes 9 68 6. Required Features 11 69 6.1. Use of Ports, UDP, and Multicast . . . . . . . . . . . . 12 70 6.2. Use of TCP . . . . . . . . . . . . . . . . . . . . . . . 13 71 6.3. Retransmission of SLP messages . . . . . . . . . . . . . 14 72 6.4. Strings in SLP messages . . . . . . . . . . . . . . . . . 15 73 6.4.1. Scope Lists in SLP . . . . . . . . . . . . . . . 15 75 7. Errors 16 77 8. Required SLP Messages 16 78 8.1. Service Request . . . . . . . . . . . . . . . . . . . . . 18 79 8.2. Service Reply . . . . . . . . . . . . . . . . . . . . . . 20 80 8.3. Service Registration . . . . . . . . . . . . . . . . . . 21 81 8.4. Service Acknowledgment . . . . . . . . . . . . . . . . . 22 82 8.5. Directory Agent Advertisement . . . . . . . . . . . . . . 22 83 8.6. Service Agent Advertisement . . . . . . . . . . . . . . . 24 85 9. Optional Features 25 86 9.1. Service Location Protocol Extensions . . . . . . . . . . 25 87 9.2. Authentication Blocks . . . . . . . . . . . . . . . . . . 26 88 9.2.1. SLP Message Authentication Rules . . . . . . . . 27 89 9.2.2. DSA with SHA-1 in Authentication Blocks . . . . . 28 90 9.3. Incremental Service Registration . . . . . . . . . . . . 29 91 9.4. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . . 30 93 10. Optional SLP Messages 30 94 10.1. Service Type Request . . . . . . . . . . . . . . . . . . 30 95 10.2. Service Type Reply . . . . . . . . . . . . . . . . . . . 31 96 10.3. Attribute Request . . . . . . . . . . . . . . . . . . . . 32 97 10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . . 33 98 10.5. Attribute Request/Reply Examples . . . . . . . . . . . . 33 99 10.6. Service Deregistration . . . . . . . . . . . . . . . . . 35 101 11. Scopes 36 102 11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . . 36 103 11.2. Administrative and User Selectable Scopes . . . . . . . . 37 105 12. Directory Agents 37 106 12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . . 38 107 12.2. Directory Agent Discovery . . . . . . . . . . . . . . . . 38 108 12.2.1. Active DA Discovery . . . . . . . . . . . . . . . 39 109 12.2.2. Passive DA Advertising . . . . . . . . . . . . . 39 110 12.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . . 40 111 12.4. DA Scope Configuration . . . . . . . . . . . . . . . . . 40 112 12.5. DAs and Authentication Blocks . . . . . . . . . . . . . . 40 114 13. Protocol Timing Defaults 41 116 14. Optional Configuration 42 118 15. IANA Considerations 43 120 16. Internationalization Considerations 44 122 17. Year 2000 Considerations 45 124 18. Security Considerations 45 126 A. Appendix: SLP Protocol Extensions 47 127 A.1. Required Attribute Missing Option . . . . . . . . . . . . 47 129 B. Full Copyright Statement 50 131 1. Introduction 133 The Service Location Protocol (SLP) provides a flexible and scalable 134 framework for providing hosts with access to information about 135 the existence, location, and configuration of networked services. 136 Traditionally, users have had to find services by knowing the name of 137 a network host (a human readable text string) which is an alias for a 138 network address. SLP eliminates the need for a user to know the name 139 of a network host supporting a service. Rather, the user supplies 140 the desired type of service and a set of attributes which describe 141 the service. Based on that description, the Service Location 142 Protocol resolves the network address of the service for the user. 144 SLP provides a dynamic configuration mechanism for applications in 145 local area networks. Applications are modeled as clients that need 146 to find servers attached to any of the available networks within an 147 enterprise. For cases where there are many different clients and/or 148 services available, the protocol is adapted to make use of nearby 149 Directory Agents that offer a centralized repository for advertised 150 services. 152 This document specifies the Service Location Protocol (SLP) in 153 two main parts. The first describes the required features of the 154 protocol. The second describes the extended features of the protocol 155 which are optional, and allow greater scalability. 157 1.1. Applicability Statement 159 SLP is intended to function within networks under cooperative 160 administrative control. Such networks permit a policy to be 161 implemented regarding security, multicast routing and organization 162 of services and clients into groups which are not be feasible on the 163 scale of the Internet as a whole. 165 SLP has been designed to serve enterprise networks with shared 166 services, and it may not necessarily scale for wide-area service 167 discovery throughout the global Internet, or in networks where 168 there are hundreds of thousands of clients or tens of thousands of 169 services. 171 1.2. Changes to the Service Location Protocol from v1 to v2 173 SLP version 2 (SLPv2) corrects race conditions present in SLPv1 174 [20]. In addition, authentication has been reworked to provide more 175 flexibility and protection (especially for DA Advertisements). SLPv2 176 also changes the formats and definition of many flags and values 177 and reduces the number of 'required features.' SLPv2 clarifies 178 and changes the use of 'Scopes', eliminating support for 'unscoped 179 directory agents' and 'unscoped requests'. Other changes (such as 180 Language and Character set handling) adopt practices recommended by 181 the Internet Engineering Steering Group. 183 Effort has been made to make SLPv2 operate the same whether DAs 184 are present or not. For this reason, a new message (the SAAdvert) 185 has been added. This allows UAs to discover scope information in 186 the absence of administrative configuration and DAs. This was not 187 possible in SLPv1. 189 SLPv2 is incompatible in some respects with SLPv1. If a DA which 190 supports both SLPv1 and SLPv2 with the same scope is present, 191 services advertised by SAs using either version of the protocol will 192 be available to both SLPv1 and SLPv2 UAs. SLPv1 DAs SHOULD be phased 193 out and replace with SLPv2 DAs which support both versions of the 194 protocol. 196 SLPv1 allows services to be advertised and requested without a scope. 197 Further, DAs can be configured without a scope. This is incompatible 198 with SLPv2 and presents scalability problems. To facilitate this 199 forward migration, SLPv1 agents MUST use scopes for all registrations 200 and requests. SLPv1 DAs MUST be configured with a scope list. This 201 constitutes a revision of RFC 2165 [20]. 203 2. Terminology 205 User Agent (UA) 206 A process working on the user's behalf to establish 207 contact with some service. The UA retrieves service 208 information from the Service Agents or Directory Agents. 210 Service Agent (SA) 211 A process working on the behalf of one or more services 212 to advertise the services. 214 Directory Agent (DA) 215 A process which collects service advertisements. There 216 can only be one DA present per given host. 218 Service Type 219 Each type of service has a unique Service Type string. 221 Naming Authority 222 The agency or group which catalogues given Service Types 223 and Attributes. The default Naming Authority is IANA. 225 Scope A set of services, typically making up a logical 226 administrative group. 228 URL A Universal Resource Locator [8]. 230 2.1. Notation Conventions 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in RFC 2119 [9]. 236 Syntax Syntax for string based protocols follow the 237 conventions defined for ABNF [11]. 239 Strings All strings are encoded using the UTF8 [21] 240 transformation of the Unicode [6] character set and 241 are NOT null terminated when transmitted. Strings 242 are preceded by a two byte length field. 244 A comma delimited list of strings with the 245 following syntax: 247 string-list = string / string `,' string-list 249 In format diagrams, any field ending with a \ indicates a variable 250 length field, given by a prior length field in the protocol. 252 3. Protocol Overview 254 The Service Location Protocol supports a framework by which client 255 applications are modeled as 'User Agents' and services are advertised 256 by 'Service Agents.' A third entity, called a 'Directory Agent' 257 provides scalability to the protocol. 259 The User Agent issues a 'Service Request' (SrvRqst) on behalf of the 260 client application, specifying the characteristics of the service 261 which the client requires. The User Agent will receive a Service 262 Reply (SrvRply) specifying the location of all services in the 263 network which satisfy the request. 265 The Service Location Protocol framework allows the User Agent to 266 directly issue requests to Service Agents. In this case the request 267 is multicast. Service Agents receiving a request for a service which 268 they advertise unicast a reply containing the service's location. 270 +------------+ ----Multicast SrvRqst----> +---------------+ 271 | User Agent | | Service Agent | 272 +------------+ <----Unicast SrvRply------ +---------------+ 274 In larger networks, one or more Directory Agents are used. The 275 Directory Agent functions as a cache. Service Agents send register 276 messages (SrvReg) containing all the services they advertise to 277 Directory Agents and receive acknowledgements in reply (SrvAck). 278 These advertisements must be refreshed with the Directory Agent 279 or they expire. User Agents unicast requests to Directory Agents 280 instead of Service Agents if any Directory Agents are known. 282 +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ 283 | User | | Directory | |Service | 284 | Agent | | Agent | | Agent | 285 +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ 287 User and Service Agents discover Directory Agents two ways. First, 288 they issue a multicast Service Request for the 'Directory Agent' 289 service when they start up. Second, the Directory Agent sends 290 an unsolicited advertisement infrequently, which the User and 291 Service Agents listen for. In either case the Agents receive a DA 292 Advertisement (DAAdvert). 294 +---------------+ --Multicast SrvRqst-> +-----------+ 295 | User or | <--Unicast DAAdvert-- | Directory | 296 | Service Agent | | Agent | 297 +---------------+ <-Multicast DAAdvert- +-----------+ 299 Services are grouped together using 'scopes'. These are strings 300 which identify services which are administratively identified. A 301 scope could indicate a location, administrative grouping, proximity 302 in a network topology or some other category. Service Agents and 303 Directory Agents are always assigned a scope string. 305 A User Agent is normally assigned a scope string (in which case the 306 User Agent will only be able to discover that particular grouping 307 of services). This allows a network administrator to 'provision' 308 services to users. Alternatively, the User Agent may be configured 309 with no scope at all. In that case, it will discover all available 310 scopes and allow the client application to issue requests for any 311 service available on the network. 313 +---------+ Multicast +-----------+ Unicast +-----------+ 314 | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | 315 | Agent | | Agent | | Agent | 316 | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | 317 +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+ 319 In the above illustration, the User Agent is configured with scopes X 320 and Y. If a service is sought in scope X, the request is multicast. 321 If it is sought in scope Y, the request is unicast to the DA. 322 Finally, if the request is to be made in both scopes, the request 323 must be both unicast and multicast. 325 Service Agents and User Agents may verify digital signatures provided 326 with DAAdverts. User Agents and Directory Agents may verify service 327 information registered by Service Agents. The keying material to 328 use to verify digital signatures is identified using a SLP Security 329 Parameter Index, or SLP SPI. 331 Every host configured to generate a digital signature includes the 332 SLP SPI used to verify it in the Authentication Block it transmits. 333 Every host which can verify a digital signature must be configured 334 with keying material and other parameters corresponding with the SLP 335 SPI such that it can perform verifying calculations. 337 SAs MUST accept multicast service requests and DAAdverts and unicast 338 service requests. 340 The features described up to this point are required to implement. 341 A minimum implementation consists of a User Agent, Service Agent or 342 both. 344 There are several optional features in the protocol. 346 Service Type Request A request for all types of service on the 347 network. This allows generic service browsers 348 to be built. 350 Service Type Reply A reply to a Service Type Request. 352 Attribute Request A request for attributes of a given type of 353 service or attributes of a given service. 355 Attribute Reply A reply to an Attribute Request. 357 Service Deregister A request to deregister a service or some 358 attributes of a service. 360 Service Update A subsequent SrvRqst to an advertisement. 361 This allows individual dynamic attributes to 362 be updated. 364 SA Advertisement In the absense of Directory Agents, a User 365 agent may request Service Agents in order 366 to discover their scope configuration. The 367 User Agent may use these scopes in requests. 369 In the absense of Multicast support, Broadcast MAY be used. The 370 location of DAs may be staticly configured, discovered using SLP as 371 described above, or configured using DHCP. If a message is too large, 372 it may be unicast using TCP. 374 A SLPv2 implementation SHOULD support SLPv1 [20]. This support 375 includes: 377 1. SLPv2 DAs are deployed, phasing out SLPv1 DAs. 379 2. Unscoped SLPv1 requests are considered to be of DEFAULT scope. 380 SLPv1 UAs MUST be reconfigured to have a scope if possible. 382 3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1 383 DA. SLPv1 SAs MUST be reconfigured to have a scope if possible. 385 4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2 386 requests with SLPv2 replies. 388 5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same 389 way. That is, incoming requests from agents using either version 390 of the protocol will be matched against this common set of 391 registered services. 393 6. SLPv2 registrations which use Language Tags which are greater 394 than 2 characters long will be inaccessible to SLPv1 UAs. 396 7. SLPv2 DAs MUST return only service type strings in SrvTypeRply 397 messages which conform to SLPv1 service type string syntax, ie. 398 they MUST NOT return Service Type strings for abstract service 399 types. 401 8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service 402 URLs with abstract service types. They only match Service URLs 403 with concrete service types. 405 SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will 406 not receive replies from SLPv1 SAs. In order to interoperate UAs and 407 SAs of different versions require a SLPv2 DA to be present on the 408 network which supports both protocols. 410 The use of abstract service types in SLPv2 presents a backward 411 compatibility issue for SLPv1. It is possible that a SLPv1 UA will 412 request a service type which is actually an abstract service type. 413 Based on the rules above, the SLPv1 UA will never receive an abstract 414 Service URL reply. For example, the service type 'service:x' in a 415 SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'. 416 If the request was made with SLPv2, it would return the attributes of 417 this service. 419 4. URLs used with Service Location 421 A Service URL indicates the location of a service. This URL may be 422 of the service: scheme [13] (reviewed in section 4.1), or any other 423 URL scheme conforming to the URI standard [8], except that URLs 424 without address specifications SHOULD NOT be advertised by SLP. The 425 service type for an 'generic' URL is its scheme name. For example, 426 the service type string for "http://www.srvloc.org" would be "http". 428 Reserved characters in URLs follow the rules in RFC 2396 [8]. 430 4.1. Service: URLs 432 Service URL syntax and semantics are defined in [13]. Any network 433 service may be encoded in a Service URL. 435 This section provides an introduction to Service URLs and an example 436 showing a simple application of them, representing standard network 437 services. 439 A Service URL may be of the form: 441 "service:""://" 443 The Service Type of this service: URL is defined to be the string up 444 to (but not including) the final `:' before , the address 445 specification. 447 is a hostname (which should be used if possible) or 448 dotted decimal notation for a hostname, followed by an optional `:' 449 and port number. 451 A service: scheme URL may be formed with any standard protocol 452 name by concatenating "service:" and the reserved port [1] 453 name. For example, "service:tftp://myhost" would indicate a 454 tftp service. An tftp service on a nonstandard port could be 455 "service:tftp://bad.glad.org:8080". 457 Service Types SHOULD be defined by a "service template" [13], which 458 provides expected attributes, values and protocol behavior. An 459 abstract service type (also described in [13]) has the form 461 "service::". 463 The service type string "service:" matches all 464 services of that abstract type. If the concrete type is included 465 also, only these services match the request. For example: a 466 SrvRqst or AttrRqst which specifies "service:printer" as the 467 Service Type will match the URL service:printer:lpr://hostname 468 and service:printer:http://hostname. If the requests specified 469 "service:printer:http" they would match only the latter URL. 471 An optional substring MAY follow the last `.' character in the 472 (or in the case of an abstract service 473 type URL). This substring is the Naming Authority, as described in 474 Section 9.6. Service types with different Naming Authorities are 475 quite distinct. In other words, service:x.one and service:x.two 476 are different service types, as are service:abstract.one:y and 477 service:abstract.two:y. 479 4.2. Naming Authorities 481 A Naming Authority MAY optionally be included as part of the Service 482 Type string. The Naming Authority of a service defines the meaning 483 of the Service Types and attributes registered with and provided by 484 Service Location. The Naming Authority itself is typically a string 485 which uniquely identifies an organization. IANA is the implied 486 Naming Authority when no string is appended. "IANA" itself MUST NOT 487 be included explicitly. 489 Naming Authorities may define Service Types which are experimental, 490 proprietary or for private use. Using a Naming Authority, one 491 may either simply ignore attributes upon registration or create a 492 local-use only set of attributes for one's site. The procedure to 493 use is to create a 'unique' Naming Authority string and then specify 494 the Standard Attribute Definitions as described above. This Naming 495 Authority will accompany registration and queries, as described in 496 Sections 8.1 and 8.3. Service Types SHOULD be registered with IANA 497 to allow for Internet-wide interoperability. 499 4.3. URL Entries 501 0 1 2 3 502 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 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Reserved | Lifetime | URL Length | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 |URL len, contd.| URL (variable length) \ 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 |# of URL auths | Auth. blocks (if any) \ 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 SLP stores URLs in protocol elements called URL Entries, which 512 associate a length, a lifetime, and possibly authentication 513 information along with the URL. URL Entries, defined as shown above, 514 are used in Service Replies and Service Registrations. 516 5. Service Attributes 518 A service advertisement is often accompanied by Service Attributes. 519 These attributes are used by UAs in Service Requests to select 520 appropriate services. 522 The allowable attributes which may be used are typically specified 523 by a Service Template [13] for a particular service type. Services 524 which are advertised according to a standard template MUST register 525 all service attributes which the standard template requires. URLs 526 with schemes other than "service:" MAY be registered with attributes. 527 Non-standard attribute names SHOULD begin with "x-", because no 528 standard attribute name will ever have those initial characters. 530 An attribute list is a string encoding of the attributes of a 531 service. The following ABNF [11] grammar defines attribute lists: 533 attr-list = attribute / attribute `,' attr-list 534 attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag 535 attr-val-list = attr-val / attr-val `,' attr-val-list 536 attr-tag = 1*safe-tag 537 attr-val = intval / strval / boolval / opaque 538 intval = [-]1*DIGIT 539 strval = 1*safe-val 540 boolval = "true" / "false" 541 opaque = "\FF" 1*escape-val 542 safe-val = ; Any character except reserved. 543 safe-tag = ; Any character except reserved, star and bad-tag. 544 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL 545 escape-val = `\' HEXDIG HEXDIG 546 bad-tag = CR / LF / HTAB / `_' 547 star = `*' 549 The , if present, MUST be scanned prior to evaluation for 550 all occurrences of the escape character `\'. Reserved characters 551 MUST be escaped (other characters MUST NOT be escaped). All escaped 552 characters must be restored to their value before attempting string 553 matching. For Opaque values, escaped characters are not converted - 554 they are interpreted as bytes. 556 Boolean Strings which have the form "true" or "false" can 557 only take one value and may only be compared with 558 '='. Booleans are case insensitive when compared. 560 Integer Strings which take the form [-] 1* and fall 561 in the range "-2147483648" to "2147483647" are 562 considered to be Integers. These are compared using 563 integer comparison. 565 String All other Strings are matched using strict lexical 566 ordering (see Section 6.4). 568 Opaque Opaque values are sequences of bytes. These are 569 distinguished from Strings since they begin with 570 the sequence "\FF". This, unescaped, is an illegal 571 UTF8 encoding, indicating that what follows is a 572 sequence of bytes expressed in escape notation which 573 constitute the binary value. For example, a '0' byte 574 is encoded "\FF\00". 576 A string which contains escaped values other than from the reserved 577 set of characters is illegal. If such a string is included in an 578 , or search filter, the SA or DA which 579 receives it MUST return a PARSE_ERROR to the message. 581 A keyword has only an , and no values. Attributes can 582 have one or multiple values. All values are expressed as strings. 584 When values have been advertised by a SA or are registered in a 585 DA, they can take on implicit typing rules for matching incoming 586 requests. 588 Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is 589 disallowed. A DA or SA receiving such an MUST return an 590 INVALID_REGISTRATION error. 592 6. Required Features 594 This section defines the minimal implementation requirements for 595 SAs and UAs as well as their interaction with DAs. A DA is not 596 required for SLP to function, but if it is present, the UA and SA 597 MUST interact with it as defined below. 599 A minimal implementation may consist of either a UA or SA or both. 600 The only required features of a UA are that it can issue SrvRqsts 601 according to the rules below and interpret DAAdverts, SAAdverts and 602 SrvRply messages. The UA MUST issue requests to DAs as they are 603 discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or 604 SAAdvert messages. The SA MUST also register with DAs as they are 605 discovered. 607 UAs perform discovery by issuing Service Request messages. SrvRqst 608 messages are issued, using UDP, following these prioritized rules: 610 1. A UA issues a request to a DA which it has been configured with 611 by DHCP. 613 2. A UA issues requests to DAs which it has been statically 614 configured with. 616 3. A UA uses multicast/convergence SrvRqsts to discover DAs, then 617 uses that set of DAs. A UA that does not know of any DAs SHOULD 618 retry DA discovery once every CONFIG_DA_FIND seconds. 620 4. A UA with no knowledge of DAs sends requests using multicast 621 convergence to SAs. SAs unicast replies to UAs according to the 622 multicast convergence algorithm. 624 UAs and SAs are configured with a list of scopes to use according to 625 these prioritized rules: 627 1. With DHCP. 629 2. With static configuration. The static configuration may be 630 explicitely set to NO SCOPE for UAs, if the User Selectable Scope 631 model is used. See section 11.2. 633 3. In the absense of configuration, the agent's scope is "DEFAULT". 635 A UA MUST issue requests with one or more of the scopes it has been 636 configured to use. 638 A UA which has been statically configured with NO SCOPE LIST will use 639 DA or SA discovery to determine its scope list dynamically. In this 640 case it uses an empty scope list to discover DAs and possibly SAs. 641 Then it uses the scope list it obtains from DAAdverts and possibly 642 SAAdverts in subsequent requests. 644 The SA MUST register all its services with any DA it discovers, if 645 the DA advertises any of the scopes it has been configured with. A 646 SA obtains information about DAs as a UA does. In addition, the SA 647 MUST listen for multicast unsolicited DAAdverts. The SA registers 648 by sending SrvReg messages to DAs, which reply with SrvReg messages 649 to indicate success. SAs register in ALL the scopes they were 650 configured to use. 652 6.1. Use of Ports, UDP, and Multicast 654 DAs MUST accept unicast requests and multicast directory 655 agent discovery service requests (for the service type 656 "service:directory-agent"). 658 SAs MUST accept multicast requests and unicast requests both. The SA 659 can distinguish between them by whether the MCAST RQST flag is set in 660 the SLP Message header. 662 The Service Location Protocol uses multicast for discovering DAs and 663 for issuing requests to SAs by default. 665 The reserved listening port for SLP is 427. This is the destination 666 port for all SLP messages. SLP messages MAY be transmitted on an 667 ephemeral port. Replies and acknowledgements are sent to the port 668 from which the request was issued. The default maximum transmission 669 unit for UDP messages is 1400 bytes. 671 If a SLP message does not fit into a UDP datagram it MUST be 672 truncated to fit, and the OVERFLOW flag is set in the reply message. 673 A UA which receives a truncated message MAY open a TCP connection 674 (see section 6.2) with the DA or SA and retransmit the request, using 675 the same XID. It MAY also attempt to make use of the truncated reply 676 or reformulate a more restrictive request which will result in a 677 smaller reply. 679 SLP Requests messages are multicast to The Administratively Scoped 680 SLP Multicast [15] address, which is 239.255.255.253. The default 681 TTL to use for multicast is 255. 683 In isolated networks, broadcasts will work in place of multicast. 684 To that end, SAs SHOULD and DAs MUST listen for broadcast Service 685 Location messages at port 427. This allows UAs which do not support 686 multicast the use of Service Location on isolated networks. 688 Setting multicast TTL to less than 255 (the default) limits the range 689 of SLP discovery in a network, and localizes service information in 690 the network. 692 6.2. Use of TCP 694 A SrvReg or SrvDeReg may be too large to fit into a datagram. To 695 send such large SLP messages, a TCP (unicast) connection MUST be 696 established. 698 To avoid the need to implement TCP, one MUST insure that: 700 - UAs never issue requests larger than the Path MTU. SAs can omit 701 TCP support only if they never have to receive unicast requests 702 longer than the path MTU. 704 - UAs can accept replies with the 'OVERFLOW' flag set, and make use 705 of the first result included, or reformulate the request. 707 - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in 708 a single datagram. This means limiting the size of URLs, 709 the number of attributes and the number of authenticators 710 transmitted. 712 DAs MUST be able to respond to UDP and TCP requests, as well as 713 multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP 714 unless the SA will NEVER receive a request or send a reply which will 715 exceed a datagram in size (e.g., some embedded systems). 717 A TCP connection MAY be used for a single SLP transaction, or for 718 multiple transactions. Since there are length fields in the message 719 headers, SLP Agents can send multiple requests along a connection and 720 read the return stream for acknowledgments and replies. 722 The initiating agent SHOULD close the TCP connection. The DA SHOULD 723 wait at least CONFIG_CLOSE_CONN seconds before closing an idle 724 connection. DAs and SAs SHOULD close an idle TCP connection after 725 CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the 726 initiating agent neglects to close it. See Section 13 for timing 727 rules. 729 6.3. Retransmission of SLP messages 731 Requests to SAs are multicast repeatedly (with a recommended wait 732 interval of CONFIG_MC_RETRY) until there are no new responses, or 733 CONFIG_MC_MAX seconds have elapsed. DA discovery requests use 734 different timing for repeated requests, CONFIG_DA_RETRY. 736 Multicast requests SHOULD be reissued over 15 seconds (say 3 times 737 total) until a result has been obtained. UAs need only wait till 738 they obtain the first reply which matches their request. Unicast 739 requests (SrvReg or SrvRqst) to a DA should be retried until either 740 a response (which might be an error) has been obtained, or for 5 741 seconds. 743 When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, 744 they contain a of previous responders. Initially the 745 is empty. The message SHOULD be retransmitted until the 746 causes no further responses to be elicited or the previous 747 responder list and the request will not fit into a single datagram. 748 Retransmission is not required if the requesting agent is prepared to 749 use the 'first reply' instead of 'as many replies as possible within 750 a bounded time interval.' 752 Any DA or SA which sees its address in the MUST NOT respond 753 to the request. 755 UAs which retransmit a request use the same XID. This allows a DA or 756 SA to cache its reply to the original request and then send it again, 757 should a duplicate request arrive. This cached information should 758 only be held very briefly. XIDs SHOULD be randomly chosen to avoid 759 duplicate XIDs in requests if UAs restart frequently. 761 6.4. Strings in SLP messages 763 The escape character is a backslash (UTF8 0x5c) followed by the 764 two hexadecimal digits of the escaped character. Only reserved 765 characters are escaped. For example, a comma (UTF8 0x29) is escaped 766 as `\29', and a backslash `\' is escaped as `\5c'. String lists used 767 in SLP define the comma to be the delimiter between list elements, so 768 commas in data strings must be escaped in this manner. Backslashes 769 are the escape character so they also must always be escaped when 770 included in a string literally. 772 String comparison for order and equality in SLP MUST be case 773 insensitive inside the 0x00-0x7F subrange of UTF8 (which corresponds 774 to ASCII character encoding). Case insensitivity SHOULD be supported 775 throughout the entire UTF8 encoded Unicode [6] character set. 777 The case insensitivity rule applies to all string matching in SLPv2, 778 including Scope strings, SLP SPI strings, service types, attribute 779 tags and values in query handling, language tags, previous responder 780 lists. Comparisons of URL strings, however, is case sensitive. 782 White space (SPACE, CR, LF, TAB) internal to a string value is folded 783 to a single SPACE character for the sake of string comparisons. 784 White space preceding or following a string value is ignored for 785 the purposes of string comparison. For example, " Some String " 786 matches "SOME STRING". 788 String comparisons (using comparison operators such as `<=' or `>=') 789 are done using lexical ordering in UTF8 encoded characters, not using 790 any language specific rules. 792 The reserved character `*' may precede, follow or be internal to a 793 string value in order to indicate substring matching. The query 794 including this character matches any character sequence which 795 conforms to the letters which are not wildcarded. 797 6.4.1. Scope Lists in SLP 799 Scope Lists in SLPv2 have the following grammar: 801 scope-list = scope-val / scope-val `,' scope-list 802 scope-val = 1*safe 803 safe = ; Any character except reserved. 804 reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL 805 / `;' / `*' / `+' 806 escape-val = `\' HEXDIG HEXDIG 807 Scopes which include any reserved characters must replace the escaped 808 character with the the escaped-val format. 810 7. Errors 812 If the Error Code in a SLP reply message is nonzero, the rest of 813 the message MAY be truncated. No data is necessarily transmitted 814 or should be expected after the header and the error code, except 815 possibly for some optional extensions to clarify the error, for 816 example as in section A.1. 818 Errors are only returned for unicast requests. Multicast requests 819 are silently discarded if they result in an error. 821 LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in 822 the scope in the AttrRqst or SrvRqst, but not in the requested 823 language. 824 PARSE_ERROR = 2: The message fails to obey SLP syntax. 825 INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero 826 lifetime or an omitted Language Tag. 827 SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in 828 its supported by the SA or DA. 829 AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an 830 unsupported SLP SPI. 831 AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR 832 authentication in the SrvReg and did not receive it. 833 AUTHENTICATION_FAILED = 7: The DA detected an authentication error in 834 an Authentication block. 835 VER_NOT_SUPPORTED = 9: Unsupported version number in message header. 836 INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. 837 DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. 838 OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option 839 from the mandatory range (see section 9.1). 840 INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for 841 an unregistered service or with inconsistent Service Types. 842 MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst 843 and does not support it. 844 INVALID_LIFETIME = 15: The SA registered a service with a lifetime 845 the DA has disallowed in its DAAdvert. 847 8. Required SLP Messages 849 All length fields in SLP messages are in network byte order. Where 850 'tuples' are defined, these are sequences of bytes, in the precise 851 order listed, in network byte order. 853 SLP messages all begin with the following header: 855 0 1 2 3 856 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 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | Version | Function-ID | Length | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | Length, contd.|O|F|R| reserved |Next Ext Offset| 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Next Extension Offset, contd.| XID | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 864 | Language Tag Length | Language Tag \ 865 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 867 Message Type Abbreviation Function-ID 869 Service Request SrvRqst 1 870 Service Reply SrvRply 2 871 Service Registration SrvReg 3 872 Service Deregister SrvDeReg 4 873 Service Acknowledge SrvAck 5 874 Attribute Request AttrRqst 6 875 Attribute Reply AttrRply 7 876 DA Advertisement DAAdvert 8 877 Service Type Request SrvTypeRqst 9 878 Service Type Reply SrvTypeRply 10 879 SA Advertisement SAAdvert 11 881 SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert. SAs MUST 882 also support SrvReg, SAAdvert and SrvAck. For UAs and SAs, support 883 for other messages are OPTIONAL. 885 - Length is the length of the entire SLP message, header included. 886 - The flags are: OVERFLOW (0x80) is set when a message's length 887 exceeds what can fit into a datagram. FRESH (0x40) is set on 888 every new SrvReg. REQUEST MCAST (0x20) is set when multicasting 889 or broadcasting requests. Reserved bits MUST be 0. 890 - Next Extension Offset is set to 0 unless extensions are used. 891 The first extension begins at 'offset' bytes, from the message's 892 beginning. It is placed after the SLP message data. See 893 Section 9.1 for how to interpret unrecognized options. 894 - XID is set to a unique value for each unique request. If the 895 request is retransmitted, the same XID is used. Replies set 896 the XID to the same value as the xid in the request. Only 897 unsolicited DAAdverts are sent with an XID of 0. 898 - Lang Tag Length is the length in bytes of the Language Tag field. 899 - Language Tag conforms to [7]. The Language Tag in a reply MUST 900 be the same as the Language Tag in the request. This field must 901 be encoded 1*8ALPHA ["-" 1*8ALPHA]. 903 If an option is specified, and not included in the message, the 904 receiver MUST respond with a PARSE_ERROR. 906 8.1. Service Request 908 0 1 2 3 909 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 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | Service Location header (function = SrvRqst = 1) | 912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 | length of | String \ 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 | length of | String \ 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | length of | String \ 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | length of predicate string | Service Request \ 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | length of string | String \ 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 In order for a Service to match a SrvRqst, it must belong to at least 925 one requested scope, support the requested service type, and match 926 the predicate. If the predicate is present, the language of the 927 request (ignoring the dialect part of the Language Tag) must match 928 the advertised service. 930 is the Previous Responder List. This 931 contains either fully qualified domain names or dotted decimal 932 notation IP (v4) addresses, and is iteratively multicast to obtain 933 all possible results (see Section 6.3). UAs SHOULD implement this 934 discovery algorithm. SAs MUST use this to discover all available DAs 935 in their scope, if they are not already configured with DA addresses 936 by some other means. A SA silently drops all requests which include 937 the SA's address in the . Once a plus the request 938 exceeds the path MTU, multicast convergence stops. This algorithm 939 is not intended to find all instances; it finds 'enough' to provide 940 useful results. 942 The is a of configured scope names. SAs 943 and DAs which have been configured with any of the scopes in this 944 list will respond. DAs and SAs MUST reply to unicast requests with a 945 SCOPE_NOT_SUPPORTED error if the is omitted or fails to 946 include a scope they support (see Section 11). The only exceptions 947 to this are described in Section 11.2. 949 The string is discussed in Section 4. Normally, 950 a SrvRqst elicits a SrvRply. There are two exceptions: If 951 the is set to "service:directory-agent", DAs 952 respond to the SrvRqst with a DAAdvert (see Section 8.5.) If 953 set to "service:service-agent", SAs respond with a SAAdvert (see 954 Section 8.6.) If this field is omitted, a PARSE_ERROR is returned - 955 as this field is REQUIRED. 957 The is a LDAPv3 search filter [14]. This field is 958 OPTIONAL. Services may be discovered simply by type and scope. 959 Otherwise, services are discovered which satisfy the . 960 If present, it is compared to each registered service. If the 961 attribute in the filter has been registered with multiple values, the 962 filter is compared to each value and the results are ORed together, 963 i.e., "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" 964 matches (y=0,1) since Y can be nonzero. Note the matching is case 965 insensitive. Keywords (i.e., attributes without values) are matched 966 with a "presence" filter, as in "(keyword=*)". 968 An incoming request term MUST have the same type as the attribute 969 in a registration in order to match. Thus, "(x=33)" will not 970 match 'x=true', etc. while "(y=foo)" will match 'y=FOO'. 971 "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be 972 satisfied, because of the `|' (boolean disjunction). 974 Wildcard matching MUST be done with the '=' filter. In any other 975 case, a PARSE_ERROR is returned. Request terms which include 976 wildcards are interpreted to be Strings. That is, (x=34*) would 977 match 'x=34foo', but not 'x=3432' since the first value is a String 978 while the second value is an Integer; Strings don't match Integers. 980 Examples of Predicates follow. indicates the service type of 981 the SrvRqst, gives the and

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

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

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

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

= 1000 This returns DAAdverts for all DAs in the DEFAULT scope. 1002 DAs are discovered by sending a SrvRqst with the service type set 1003 to "service:directory-agent". If a predicate is included in the 1004 SrvRqst, the DA SHOULD respond only if the predicate can be satisfied 1005 with the DA's attributes. The SHOULD contain all 1006 scopes configured for the service. The DA responds to this SrvRqst 1007 if the or string has been omitted. 1009 The string indicates a SLP SPI that the requester has 1010 been configured with. If this string is omitted, the responder 1011 does not include any Authentication Blocks in its reply. If it is 1012 included, the responder MUST return a reply which has an associated 1013 authentication block with the SLP SPI in the SrvRqst. If no replies 1014 may be returned because the SLP SPI is not supported, the responder 1015 returns an AUTHENTICATION_UNKNOWN error. 1017 8.2. Service Reply 1019 0 1 2 3 1020 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 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Service Location header (function = SrvRply = 2) | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1024 | Error Code | URL Entry count | 1025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1026 | ... \ 1027 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1029 The service reply contains one or more URL entries (see Section 4.3) 1030 that satisfy a SrvRqst. If the reply overflows, the UA MAY simply 1031 use the first URL Entry in the list. A URL obtained by SLP may 1032 not be cached longer than Lifetime seconds, unless there is a URL 1033 Authenticator block present. In that case, the cache lifetime 1034 is indicated by the Timestamp in the URL Authenticator (see 1035 Section 9.2). 1037 An authentication block is returned in the URL Entries, including 1038 the SLP SPI in the SrvRqst. If no SLP SPI was included in the 1039 request, no Authentication Blocks are returned in the reply. URL 1040 Authentication Blocks are defined in Section 9.2.1. 1042 If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless 1043 it fits entirely without truncation. 1045 8.3. Service Registration 1047 0 1 2 3 1048 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 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | Service Location header (function = SrvReg = 3) | 1051 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1052 | \ 1053 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1054 | length of service type string | \ 1055 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1056 | length of | \ 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | length of attr-list string | \ 1059 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1060 |# of AttrAuths |(if present) Attribute Authentication Blocks...\ 1061 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 The is a URL Entry (see section 4.3). The Lifetime defines 1064 how long a DA can cache the registration. SAs SHOULD reregister 1065 before this lifetime expires (but SHOULD NOT more often than once 1066 per second). The Lifetime MAY be set to any value between 0 and 1067 0xffff (maximum, around 18 hours). Long-lived registrations remain 1068 stale longer if the service fails and the SA does not deregister the 1069 service. 1071 The defines the service type of the URL to be 1072 registered, regardless of the scheme of the URL. The 1073 MUST be contain the names of all scopes configured for the SA, which 1074 the DA it is registering with supports. The default value for the 1075 is "DEFAULT" (see Section 11). 1077 The SA MUST register consistently with all DAs. If a SA is 1078 configured with scopes X and Y and there are three DAs, whose scopes 1079 are "X", "Y" and "X,Y" respectively, the SA will register the with 1080 all three DAs in their respective scopes. All future updates and 1081 deregistrations of the service must be sent to the same set of DAs in 1082 the same scopes the service was initially registered in. 1084 The , if present, specifies the attributes and values to 1085 be associated with the URL by the DA (see Section 5). 1087 A SA configured with the ability to sign service registrations MUST 1088 sign each of the URLs and Attribute Lists using each of the keys it 1089 is configured to use, and the DA it is registering with accepts. 1090 (The SA MUST aquire DAAdverts for all DAs it will register with 1091 to obtain the DA's SLP SPI list and attributes, as described in 1092 Section 8.5). The SA supplies a SLP SPI in each authentication block 1093 indicating the SLP SPI configuration required to verify the digital 1094 signature. The format of the digital signatures used is defined in 1095 section 9.2.1. 1097 Subsequent registrations of previously registered services MUST 1098 contain the same list of SLP SPIs as previous ones or else DAs will 1099 reject them, replying with an AUTHENTICATION_ABSENT error. 1101 A registration with the FRESH flag set will replace *entirely* any 1102 previous registration for the same URL in the same language. If 1103 the FRESH flag is not set, the registration is an "incremental" 1104 registration (see Section 9.3). 1106 8.4. Service Acknowledgment 1108 0 1 2 3 1109 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 1110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1111 | Service Location header (function = SrvAck = 4) | 1112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1113 | Error Code | 1114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1116 A DA returns a SrvAck to an SA after a SrvReg. It carries only a two 1117 byte Error Code (see Section 7). 1119 8.5. Directory Agent Advertisement 1121 0 1 2 3 1122 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 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | Service Location header (function = DAAdvert = 8) | 1125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 | Error Code | DA Stateless Boot Timestamp | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 |DA Stateless Boot Time,, contd.| Length of URL | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 \ URL \ 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1132 | Length of | \ 1133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1134 | Length of | \ 1135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1136 | Length of | String \ 1137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1138 | # Auth Blocks | Authentication block (if any) \ 1139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 The Error Code is set to 0 unless the DAAdvert is being returned due 1142 to a SrvRqst without the MCAST REQEST flag set. In this case it 1143 returns the same errors a SrvRply would. 1145 The of the SrvRqst must either be omitted or include 1146 a scope which the DA supports. The DA Stateless Boot Timestamp 1147 indicates the state of the DA (see section 12.1). 1149 The DA MAY include a list of its attributes in the DAAdvert. This 1150 list SHOULD be kept short, as the DAAdvert must fit into a datagram 1151 in order to be multicast. 1153 A potential scaling problem occurs in SLPv2 if SAs choose too low a 1154 Lifetime. In this case, an onerous amount of reregistration occurs 1155 as more services are deployed. SLPv2 allows DAs to control SAs 1156 frequency of registration. A DA MAY reissue a DAAdvert with a new 1157 set of attributes at any time, to change the reregistration behavior 1158 of SAs. These apply only to subsequent registrations; existing 1159 service registrations with the DA retain their registered lifetimes. 1161 If the DAAdvert includes the attribute "min-lifetime" it MUST be set 1162 to a single Integer value. If this attribute is present SAs MUST NOT 1163 set registered service lifetimes to be shorter than this value (in 1164 seconds). Further, SAs MUST NOT refresh the advertisement less often 1165 than 80% of this interval. If the DAAdvert includes the attribute 1166 "max-lifetime", it MUST be set to a single Integer value. SAs MUST 1167 NOT set registered service lifetimes to be longer than this value 1168 (in seconds). If a registered lifetime is below the min-lifetime 1169 or above the max-lifetime advertised by the DA it will reject the 1170 registration and return a INVALID_LIFETIME error in the SrvAck. 1172 The URL is "service:directory-agent://" of the DA, where 1173 is the dotted decimal numeric address of the DA. The 1174 of the DA MUST NOT be NULL. 1176 The SLP SPI List is the list of SPIs that the DA is capable of 1177 verifying. SAs MUST NOT register services with authentication 1178 blocks for those SLP SPIs which are not on the list. DAs will 1179 reject service registrations which they cannot verify, returning an 1180 AUTHENTICATION_UNKNOWN error. 1182 The format of DAAdvert signatures is defined in Section 9.2.1. 1184 The SLP SPI which is used to verify the DAAdvert is included in 1185 the Authentication Block. When DAAdverts are multicast, they may 1186 have to transmit multiple DAAdvert Authentication Blocks. If the 1187 DA is configured to be able to generate signatures for more than 1188 one SPI, the DA MUST include one Authentication Block for each SPI. 1189 If all these Authentication Blocks do not fit in a single datagram 1190 (to multicast or broadcast) the DA MUST send separate DAAdverts so 1191 that Authentication Blocks for all the SPIs the DA is capable of 1192 generating are sent. 1194 If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert 1195 contains only the authentication block with the SLP SPI in the 1196 SrvRqst, if the DA is configured to be able to produce digital 1197 signatures using that SLP SPI. If the SrvRqst is sent to the DA 1198 without the MCAST RQST flag set and an unsupported SLP SPI is 1199 included, the DA replies with a DAAdvert with the Error Code set to 1200 an AUTHENTICATION_UNKNOWN error. 1202 UAs SHOULD be configured with SLP SPIs that will allow them to 1203 verify DA Advertisements. If the UA is configured with SLP SPIs and 1204 receives a DAAdvert which fails to be verified using one of them, the 1205 UA MUST discard it. 1207 8.6. Service Agent Advertisement 1209 User Agents MUST NOT solicit SA Advertisements if they have been 1210 configured to use a particular DA, if they have been configured 1211 with a or if DAs have been discovered. UAs solicit 1212 SA Advertisements only when they are explicitly configured to use 1213 User Selectable scopes (see Section 11.2) in order to discover the 1214 scopes that SAs support. This allows UAs without scope configuration 1215 to make use of either DAs or SAs without any functional difference 1216 except performance. 1218 A SA MAY be configured with attributes, and SHOULD support the 1219 attribute 'service-type' whose value is all the service types 1220 of services represented by the SA. SAs MUST NOT respond if the 1221 SrvRqst predicate is not satisfied. For example, only SAs offering 1222 'nfs' services SHOULD respond with a SAAdvert to a SrvRqst for 1223 service type "service:service-agent" which includes a predicate 1224 "(service-type=nfs)". 1226 0 1 2 3 1227 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 1228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1229 | Service Location header (function = SAAdvert = 11) | 1230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1231 | Length of URL | URL \ 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1233 | Length of | \ 1234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1235 | Length of | \ 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | # auth blocks | authentication block (if any) \ 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 The SA responds only to multicast SA discovery requests which either 1241 include no or a scope which they are configured to use. 1243 The SAAdvert MAY include a list of attributes the SA supports. This 1244 attribute list SHOULD be kept short so that the SAAdvert will not 1245 exceed the path MTU in size. 1247 The URL is "service:service-agent://" of the SA, where 1248 is the dotted decimal numeric address of the SA. The of 1249 the SA MUST NOT be null. 1251 The SAAdvert contains one SAAdvert Authentication block for each SLP 1252 SPI the SA can produce Authentication Blocks for. If the UA can 1253 verify the Authentication Block of the SAAdvert, and the SAAdvert 1254 fails to be verified, the UA MUST discard it. 1256 9. Optional Features 1258 The features described in this section are not mandatory. Some are 1259 useful for interactive use of SLP (where a user rather than a program 1260 will select services, using a browsing interface for example) and for 1261 scalability of SLP to larger networks. 1263 9.1. Service Location Protocol Extensions 1265 The format of a Service Location Extension is: 1267 0 1 2 3 1268 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 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | Extension ID | Next Extension Offset | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Offset, contd.| Extension Data \ 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1275 Extension IDs are assigned in the following way: 1277 0x0000-0x3FFF Standardized. Optional to implement. Ignore if 1278 unrecognized. 1279 0x4000-0x7FFF Standardized. Mandatory to implement. A UA or SA 1280 which receives this option in a reply and does not understand 1281 it MUST silently discard the reply. A DA or SA which receives 1282 this option in a request and does not understand it MUST return 1283 an OPTION_NOT_UNDERSTOOD error. 1284 0x8000-0x8FFF For private use (not standardized). Optional to 1285 implement. Ignore if unrecognized. 1286 0x9000-0xFFFF Reserved. 1288 The three byte offset to next extension indicates the position of the 1289 next extension as offset from the beginning of the SLP message. 1291 The offset value is 0 if there are no extensions following the 1292 current extension. 1294 If the offset is 0, the length of the current Extension Data is 1295 determined by subtracting total length of the SLP message as given in 1296 the SLP message header minus the offset of the current extension. 1298 Extensions defined in this document are in Section A. See section 15 1299 for procedures that are required when specifying new SLP extensions. 1301 9.2. Authentication Blocks 1303 0 1 2 3 1304 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 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Block Structure Descriptor | Authentication Block Length | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Timestamp | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | SLP SPI String Length | SLP SPI String \ 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Structured Authentication Block ... \ 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 Authentication blocks are returned with certain SLP messages to 1316 verify that the contents have not been modified, and have been 1317 transmitted by an authorized agent. The authentication data 1318 (contained in the Structured Authentication Block) is typically 1319 case sensitive. Even though SLP registration data (e.g., attribute 1320 values) are typically are not case sensitive, the case of the 1321 registration data has to be preserved by the registering DA so that 1322 UAs will be able to verify the data used for calculating digital 1323 signature data. 1325 The Block Structure Descriptor (BSD) identifies the format of the 1326 Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained 1327 by IANA. BSDs 0x8000-0x8FFF are for private use. 1329 The Authentication Block Length is the length of the entire block, 1330 starting with the BSD. 1332 The Timestamp is the time that the authenticator expires (to prevent 1333 replay attacks.) The Timestamp is a 32-bit unsigned fixed-point 1334 number of *minutes* relative to 0h on 1 January 1900. SAs use this 1335 value to indicate when the validity of the digital signature expires. 1336 This timestamp will wrap back to 0 in the year 10,066. 1338 The SLP Security Parameters Index (SPI) string identifies the key 1339 length, algorithm parameters and keying material to be used by agents 1340 to verify the signature data in the Structured Authentication Block. 1341 The SLP SPI string has the same grammar as the defined 1342 in Section 6.4.1. 1344 Reserved characters in SLP SPI strings must be escaped using the same 1345 convention as used throughout SLPv2. 1347 SLP SPIs deployed in a site MUST be unique. An SLP SPI used for 1348 BSD=0x0002 must not be the same as used for some other BSD. 1350 All SLP agents MUST implement DSA [19] (BSD=0x0002). SAs MUST 1351 register services with DSA authentication blocks, and they 1352 MAY register them with other authentication blocks using other 1353 algorithms. SAs MUST use DSA authentication blocks in SrvDeReg 1354 messages and DAs MUST use DSA authentication blocks in unsolicited 1355 DAAdverts. 1357 9.2.1. SLP Message Authentication Rules 1359 The sections below define how to calculate the value to apply to the 1360 algorithm identified by the BSD value. The components listed are 1361 used as if they were a contiguous single byte aligned buffer in the 1362 order given. 1364 URL 1365 16-bit Length of SLP SPI String, SLP SPI String. 1366 16-bit Length of URL, URL, 1367 32-bit Timestamp. 1369 Attribute List 1370 16-bit Length of SLP SPI String, SLP SPI String, 1371 16-bit length of , , 1372 32-bit Timestamp. 1374 DAAdvert 1375 16-bit Length of SLP SPI String, SLP SPI String, 1376 32-bit DA Stateless Boot Timestamp, 1377 16-bit Length of URL, URL, 1378 16-bit Length of , , 1379 16-bit Length of DA's , DA's , 1380 16-bit Length of DA's , DA's , 1381 32-bit Timestamp. 1383 The first SLP SPI is the SLP SPI in the Authentication 1384 Block. This SLP SPI indicates the keying material and other 1385 parameters to use to verify the DAAdvert. The SLP SPI List is 1386 the list of SLP SPIs the DA itself supports, and is able to 1387 verify. 1389 SAAdvert 1390 16-bit Length of SLP SPI String, SLP SPI String, 1391 16-bit Length of URL, URL, 1392 16-bit Length of , , 1393 16-bit Length of , , 1394 32-bit Timestamp. 1396 9.2.2. DSA with SHA-1 in Authentication Blocks 1398 BSD=0x0002 is defined to be DSA with SHA-1. The signature 1399 calculation is defined by [19]. The signature format conforms to 1400 that in the X.509 v3 certificate: 1402 1. The signature algorithm identifier (an OID) 1403 2. The signature value (an octet string) 1404 3. The certificate path. 1406 All data is represented in ASN.1 encoding: 1408 id-dsa-with-sha1 ID ::= { 1409 iso(1) member-body(2) us(840) x9-57 (10040) 1410 x9cm(4) 3 } 1412 i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately 1413 by: 1415 Dss-Sig-Value ::= SEQUENCE { 1416 r INTEGER, 1417 s INTEGER } 1419 i.e., the binary ASN.1 encoding of r and s computed using DSA 1420 and SHA-1. This is followed by a certificate path, as defined by 1421 X.509 [10], [2], [3], [4], [5]. 1423 Authentication Blocks for BSD=0x0002 have the following format. In 1424 the future, BSDs may be assigned which have different formats. 1426 0 1 2 3 1427 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 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | ASN.1 encoded DSA signature \ 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 9.3. Incremental Service Registration 1434 Incremental registrations update attribute values for a previously 1435 registered service. Incremental service registrations are useful 1436 when only a single attribute has changed, for instance. In an 1437 incremental registration, the FRESH flag in the SrvReg header is NOT 1438 set. 1440 The new registration's attributes replace the previous 1441 registration's, but do not affect attributes which were 1442 included previously and are not present in the update. 1444 For example, suppose service:x://a.org has been registered with 1445 attributes A=1, B=2, C=3. If an incremental registration comes for 1446 service:x://a.org with attributes C=30, D=40, then the attributes for 1447 the service after the update are A=1, B=2, C=30, D=40. 1449 Incremental registrations MUST NOT be performed for services 1450 registered with Authentication Blocks. These must be registered 1451 with ALL attributes, with the FRESH flag in the SrvReg header 1452 set. DAs which receive such registration messages return an 1453 AUTHENTICATION_FAILED error. 1455 If the FRESH flag is not set and the DA does not have a prior 1456 registration for the service, the incremental registration fails with 1457 error code INVALID_UPDATE. 1459 The SA MUST use the same in an update message as was 1460 used in the prior registration. If this is not done, the DA returns 1461 a SCOPE_NOT_SUPPORTED error. In order to change the scope of a 1462 service advertisement it MUST be deregistered first and reregistered 1463 with a new . 1465 The SA MUST use the same in an update message as was 1466 used in a prior registration of the same URL. If this is not done, 1467 the DA returns an INVALID_UPDATE error. 1469 9.4. Tag Lists 1471 Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a 1472 item is: 1474 tag-filter = simple-tag / substring 1475 simple-tag = 1*filt-char 1476 substring = [initial] any [final] 1477 initial = 1*filt-char 1478 any = `*' *(filt-char `*') 1479 final = 1*filt-char 1480 filt-char = ; Any character excluding and (see 1481 ; grammar in Section 5). 1483 Wild card characters in a item match arbitrary sequences 1484 of characters. For instance "*bob*" matches "some bob I know", 1485 "bigbob", "bobby" and "bob". 1487 10. Optional SLP Messages 1489 The additional requests provide features for user interaction and for 1490 efficient updating of service advertisements with dynamic attributes. 1492 10.1. Service Type Request 1494 The Service Type Request (SrvTypeRqst) allows a UA to discover all 1495 types of service on a network. This is useful for general purpose 1496 service browsers. 1498 0 1 2 3 1499 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 1500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 | Service Location header (function = SrvTypeRqst = 9) | 1502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1503 | length of PRList | String \ 1504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1505 | length of Naming Authority | \ 1506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1507 | length of | String \ 1508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 The list and are interpreted as in 1511 Section 8.1. 1513 The Naming Authority string, if present in the request, will 1514 limit the reply to Service Type strings with the specified Naming 1515 Authority. If the Naming Authority string is absent, the IANA 1516 registered service types will be returned. If the length of the 1517 Naming Authority is set to 0xFFFF, the Naming Authority string is 1518 omitted and ALL Service Types are returned, regardless of Naming 1519 Authority. 1521 10.2. Service Type Reply 1523 0 1 2 3 1524 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 1525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1526 | Service Location header (function = SrvTypeRply = 10) | 1527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 | Error Code | length of | 1529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1530 | \ 1531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 The service-type Strings (as described in Section 4.1) are provided 1534 in , which is a . 1536 If a service type has a Naming Authority other than IANA it MUST be 1537 returned following the service type string and a `.' character. 1538 Service types with the IANA Naming Authority do not include a Naming 1539 Authority string. 1541 10.3. Attribute Request 1543 The Attribute Request (AttrRqst) allows a UA to discover attributes 1544 of a given service (by supplying its URL) or for an entire service 1545 type. The latter feature allows the UA to construct a query for an 1546 available service by selecting desired features. The UA may request 1547 that all attributes are returned, or only a subset of them. 1549 0 1 2 3 1550 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 1551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1552 | Service Location header (function = AttrRqst = 6) | 1553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1554 | length of PRList | String \ 1555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1556 | length of URL | URL \ 1557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1558 | length of | string \ 1559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1560 | length of string | string \ 1561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 | length of string | string \ 1563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 The , and string are interpreted as 1566 in Section 8.1. 1568 The URL field can take two forms. It can simply be a Service Type 1569 (see Section 4.1), such as "http" or "service:tftp". In this case, 1570 all attributes and the full range of values for each attribute of all 1571 services of the given Service Type is returned. 1573 The URL field may alternatively be a full URL, such as 1574 "service:printer:lpr://igore.wco.ftp.com:515/draft" or 1575 "nfs://max.net/znoo". In this, only the registered attributes for 1576 the specified URL are returned. 1578 The field is a of attribute tags, as 1579 defined in Section 9.4 which indicates the attributes to return 1580 in the AttrRply. If is omitted, all attributes are 1581 returned. MUST be omitted and a full URL MUST be 1582 included when attributes when a SLP SLP List string is included, 1583 otherwise the DA will reply with an AUTHENTICATION_FAILED error. 1585 10.4. Attribute Reply 1587 0 1 2 3 1588 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 1589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1590 | Service Location header (function = AttrRply = 7) | 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | Error Code | length of | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1594 | \ 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 |# of AttrAuths | Attribute Authentication Block (if present) \ 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 The format of the and the Authentication Block is as 1600 specified for SrvReg (see Section 9.2.1). 1602 Attribute replies SHOULD be returned with the original case of the 1603 string registration intact, as they are likely to be human readable. 1604 In the case where the AttrRqst was by service type, all attributes 1605 defined for the service type, and all their values are returned. 1607 Although white space is folded for string matching, attribute 1608 tags and values MUST be returned with their original white space 1609 preserved. 1611 Only one copy of each attribute tag or String value should be 1612 returned, arbitrarily choosing one version (with respect to upper 1613 and lower case and white space internal to the strings): Duplicate 1614 attributes and values SHOULD be removed. An arbitrary version of the 1615 string value and tag name is chosen for the merge. For example: 1616 "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)". 1618 10.5. Attribute Request/Reply Examples 1620 Suppose that printer services have been registered as follows: 1622 Registered Service: 1623 URL = service:printer:lpr://igore.wco.ftp.com/draft 1624 scope-list = Development 1625 Lang. Tag = en 1626 Attributes = (Name=Igore),(Description=For developers only), 1627 (Protocol=LPR),(location-description=12th floor), 1628 (Operator=James Dornan \3cdornan@monster\3e), 1629 (media-size=na-letter),(resolution=res-600),x-OK 1631 URL = service:printer:lpr://igore.wco.ftp.com/draft 1632 scope-list = Entwicklung 1633 Lang. Tag = de 1634 Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler), 1635 (Protocol=LPR),(Standort-beschreibung=13te Etage), 1636 (Techniker=James Dornan \3cdornan@monster\3e), 1637 (Format=na-letter),(Resolution=res-600),x-OK 1639 URL = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn 1640 scope-list = Development 1641 Lang. Tag = en 1642 Attributes = (Name=Not),(Description=Experimental IPP printer), 1643 (Protocol=http),(location-description=QA bench), 1644 (media-size=na-letter),(resolution=other),x-BUSY 1646 Notice the first printer, "Igore" is registered in both English and 1647 German. The `<' and `>' characters in the Operator attribute value 1648 which are part of the Email address had to be escaped, as they are 1649 reserved characters for values. 1651 The string "PROTOCOL" is 'literal' so it is not translated to 1652 different languages, see [13]. 1654 The attribute Request: 1656 URL = service:printer:lpr://igore.wco.ftp.com/draft 1657 scope-list = Entwicklung 1658 Lang. Tag = de 1659 tag-list = Resolution,St* 1661 receives the Attribute Reply: 1663 (Standort-beschreibung=13te Etage),(Resolution=res-600) 1665 The attribute Request: 1667 URL = service:printer 1668 scope-list = Development 1669 Lang. Tag = en 1670 tag-list = x-*,resolution,protocol 1672 receives an Attribute Reply containing: 1674 (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY 1676 The first request is by service instance and returns the requested 1677 values, in German. The second request is by abstract service type 1678 (see Section 4) and returns values from both "Igore" and "Not". 1680 An attribute Authentication Block is returned if an authentication 1681 block with the SLP SPI in the AttrRqst can be returned. Note that 1682 the returned from a DA with an Authentication Block MUST 1683 be identical to the registered by a SA, in order for the 1684 authentication verification calculations to be possible. 1686 A SA or DA only returns an Attribute Authentication Block if the 1687 AttrRqst included a full URL in the request and no tag list. 1689 If an SLP SPI is specified in a request which does not have the MCAST 1690 RQST flag set, and the SA or DA cannot return an Authentication Block 1691 with that SLP SPI, an AUTHENTICATION_UNKNOWN error is returned. The 1692 # of Attr Auths field is set to 0 if there no Authentication Block is 1693 included, or 1 if an Authentication Block follows. 1695 10.6. Service Deregistration 1697 A DA deletes a service registration when its Lifetime expires. 1698 Services SHOULD be deregistered when they are no longer available, 1699 rather than leaving the registrations to time out. 1701 0 1 2 3 1702 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 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | Service Location header (function = SrvDeReg = 5) | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1706 | Length of | \ 1707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1708 | URL Entry \ 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1710 | Length of | \ 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 The is a (see section 2.1). 1715 The SA MUST retry if there is no response from the DA, see Section 1716 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA 1717 receives an acknowledgment indicating success, the service and/or 1718 attributes are no longer advertised by the DA. The DA deregisters 1719 the service or service attributes from every scope specified in the 1720 SrvDeReg which it was previously registered in. 1722 The SA MUST deregister all services with the same scope list used to 1723 register the service with a DA. If this is not done in the SrvDeReg 1724 message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime 1725 field in the URL Entry is ignored for the purposes of the SrvDeReg. 1727 The is a of attribute tags to deregister 1728 as defined in Section 9.4. If no is present, the 1729 SrvDeReg deregisters the service in all languages it has been 1730 registered in. If the is present, the SrvDeReg 1731 deregisters the attributes whose tags are listed in the tag spec. 1732 Services registered with Authentication Blocks MUST NOT include 1733 a in a SrvDeReg message: A DA will respond with an 1734 AUTHENTICATION_FAILED error in this case. 1736 If the service to be deregistered was registered with an 1737 authentication block or blocks, a URL authentication block for 1738 each of the SLP SPIs registered must be included in the SrvDeReg. 1739 Otherwise, the DA returns an AUTHENTICATION_ABSENT error. If the 1740 message fails to be verified by the DA, an AUTHENTICATION_FAILED 1741 error is returned by the DA. 1743 11. Scopes 1745 Scopes are sets of services. The primary use of Scopes is to provide 1746 the ability to create administrative groupings of services. A set 1747 of services may be assigned a scope by network administrators. A 1748 client seeking services is configured to use one or more scopes. The 1749 user will only discover those services which have been configured 1750 for him or her to use. By configuring UAs and SAs with scopes, 1751 administrators may provision services. Scopes strings are case 1752 insensitive. The default SCOPE string is "DEFAULT". 1754 Scopes are the primary means an administrator has to scale SLP 1755 deployments to larger networks. When DAs with NON-DEFAULT scopes are 1756 present on the network, further gains can be had by configuring UAs 1757 and SAs to have a predefined non-default scope. These agents can 1758 then perform DA discovery and make requests using their scope. This 1759 will limit the number of replies. 1761 11.1. Scope Rules 1763 SLP messages which fail to contain a scope that the receiving Agent 1764 is configured to use are dropped (if the request was multicast) or a 1765 SCOPE_NOT_SUPPORTED error is returned (if the request was unicast). 1766 Every SrvRqst (except for DA and SA discovery requests), SrvReg, 1767 AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a 1768 . 1770 A UA MUST unicast its SLP messages to a DA which supports the desired 1771 scope, in preference to multicasting a request to SAs. A UA MAY 1772 multicast the request if no DA is available in the scope it is 1773 configured to use. 1775 11.2. Administrative and User Selectable Scopes 1777 All requests and services are scoped. The two exceptions are 1778 SrvRqsts for "service:directory-agent" and "service:service-agent". 1779 These MAY have a zero-length when used to enable the 1780 user to make scope selections. In this case UAs obtain their scope 1781 list from DAAdverts (or if DAs are not available, from SAAdverts.) 1783 Otherwise, if SAs and UAs are to use any scope other than the default 1784 (i.e., "DEFAULT"), the UAs and SAs are configured with lists of 1785 scopes to use by system administrators, perhaps automatically by way 1786 of DHCP option 78 or 79. Such administrative scoping allows services 1787 to be provisioned, so that users will only see services they are 1788 intended to see. 1790 User configurable scopes allow a user to discover any service, but 1791 require them to do their own selection of scope. This is similar 1792 to the way AppleTalk [12] and LanManager [18] networking allow user 1793 selection of AppleTalk Zone or Windows Workgroups. 1795 Note that the two configuration choices are not compatible. One 1796 model allows administrators control over service provision. The 1797 other delegates this to users (who may not be prepared to do any 1798 configuration of their system). 1800 12. Directory Agents 1802 DAs cache service location and attribute information. They exist to 1803 enhance the performance and scalability of SLP. Multiple DAs provide 1804 further scalability and robustness of operation, since they can each 1805 store service information for the same SAs, in case one of the DAs 1806 fails. 1808 A DA provides a centralized store for service information. This is 1809 useful in a network with several subnets or with many SLP Agents. 1810 The DA address can be dynamically configured with UAs and SAs using 1811 DHCP, or by using static configuration. 1813 SAs configured to use DAs with DHCP or static configuration MUST 1814 unicast a SrvRqst to the DA, when the SA is initialized. The SrvRqst 1815 omits the scope list and sets the service type of the request to 1816 "service:directory-agent". The DA will return a DAAdvert with its 1817 attributes, SLP SPI list, and other parameters which are essential 1818 for proper SA to DA communication. 1820 Passive detection of DAs by SAs enables services to be advertised 1821 consistently among DAs of the same scope. Advertisements expire if 1822 not renewed, leaving only transient stale registrations in DAs, even 1823 in the case of a failure of a SA. 1825 A single DA can support many UAs. UAs send the same requests to DAs 1826 that they would send to SAs and expect the same results. DAs reduce 1827 the load on SAs, making simpler implementations of SAs possible. 1829 UAs MUST be prepared for the possibility that the service information 1830 they obtain from DAs is stale. 1832 12.1. Directory Agent Rules 1834 When DAs are present, each SA MUST register its services with DAs 1835 that support one or more of its scope(s). 1837 UAs MUST unicast requests directly to a DA (when scoping rules 1838 allow), hence avoiding using the multicast convergence algorithm, to 1839 obtain service information. This decreases network utilization and 1840 increases the speed at which UAs can obtain service information. 1842 DAs MUST flush service advertisements once their lifetime expires or 1843 their URL Authentication Block "Timestamp" of expiration is past. 1845 DAAdverts MUST include DA Stateless Boot Timestamp, in the same 1846 format as the Authentication Block (see Section 9.2). The Timestamp 1847 in the Authentication Block indicates the time at which all previous 1848 registrations were lost (i.e., the last stateless reboot). The 1849 Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the 1850 DA is going down. DAs MUST NOT use equal or lesser Boot Timestamps 1851 to previous ones, if they go down and restart without service 1852 registration state. This would mislead SAs to not reregister with 1853 the DA. 1855 DAs which receive a multicast SrvRqst for the service type 1856 "service:directory-agent" MUST silently discard it if the 1857 is (a) not omitted and (b) does not include a scope 1858 they are configured to use. Otherwise the DA MUST respond with a 1859 DAAdvert. 1861 DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are 1862 OPTIONAL only for SAs, not DAs.) 1864 12.2. Directory Agent Discovery 1866 UAs can discover DAs using static configuration, DHCP options 78 and 1867 79, or by multicasting (or broadcasting) Service Requests using the 1868 convergence algorithm in Section 6.3. 1870 See Section 6 regarding unsolicited DAAdverts. Section 12.2.2 1871 describes how SAs may reduce the number of times they must reregister 1872 with DAs in response to unsolicited DAAdverts. 1874 DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An 1875 unsolicited DAAdvert has an XID of 0. SAs MUST listen for DAAdverts, 1876 passively, as described in Section 8.5. UAs SHOULD do this. 1878 A URL with the scheme "service:directory-agent" indicates 1879 the DA's location as defined in Section 8.5. For example: 1880 "service:directory-agent://foobawooba.org". 1882 The following sections suggest timing algorithms which enhance the 1883 scalability of SLP. 1885 12.2.1. Active DA Discovery 1887 After a UA or SA restarts, its initial DA discovery request SHOULD 1888 be delayed for some random time uniformly distributed from 0 to 1889 CONFIG_START_WAIT seconds. 1891 The UA or SA sends the DA Discovery request using a SrvRqst, as 1892 described in Section 8.1. DA Discovery requests MUST include a 1893 Previous Responder List. SrvRqsts for Active DA Discovery SHOULD NOT 1894 be sent more than once per CONFIG_DA_FIND seconds. 1896 After discovering a new DA, a SA MUST wait a random time between 0 1897 and CONFIG_REG_ACTIVE seconds before registering their services. 1899 12.2.2. Passive DA Advertising 1901 A DA MUST multicast (or broadcast) an unsolicited DAAdvert every 1902 CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to 1903 prevent DAAdverts from using more than 1% of the available bandwidth. 1905 All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine 1906 its DA stateless Boot Timestamp. If it is set to 0, the DA is going 1907 down and no further messages should be sent to it. 1909 If a SA detects a DA it has never encountered (with a nonzero 1910 timestamp,) the SA must register with it. SAs MUST examine the 1911 DAAdvert's timestamp to determine if the DA has had a stateless 1912 reboot since the SA last registered with it. If so it registers 1913 with the DA. SAs MUST wait a random interval between 0 and 1914 CONFIG_REG_PASSIVE before beginning DA registration. 1916 12.3. Reliable Unicast to DAs 1918 If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY 1919 seconds, the message should be retried. If a DA fails to respond 1920 after CONFIG_DA_MAX seconds, the SA should consider the DA to have 1921 gone down. The UA should use a different DA. If no such DA responds, 1922 DA discovery should be used to find a new DA. If no DA is available, 1923 multicast is used. 1925 12.4. DA Scope Configuration 1927 By default, DAs are configured with the "DEFAULT" scope. 1928 Administrators may add other configured scopes, in order to support 1929 UAs and SAs in non default scopes. The default configuration MUST 1930 NOT be removed from the DA unless: 1932 - There are other DAs which support the "DEFAULT" scope, or 1934 - All UAs and SAs have been configured with non-default scopes. 1936 Non-default scopes can be phased-in as the SLP deployment grows. 1937 Default scopes should be phased out only when the non-default scopes 1938 are universally configured. 1940 If a DA and SA are coresident on a host (quite possibly implemented 1941 by the same process), configuration of the host is considerably 1942 simplified if the SA supports only scopes also supported by the DA. 1943 That is, the SA SHOULD NOT advertise services in any scopes which are 1944 not supported by the coresident DA. This means that incoming requests 1945 can be answered by a single data store; the SA and DA registrations 1946 do not need to be kept separately. 1948 12.5. DAs and Authentication Blocks 1950 DAs are not configured to sign service registrations or attribute 1951 lists. They simply cache services registered by Service Agents. DAs 1952 MUST NOT accept registrations including authentication blocks for SLP 1953 SPIs which it is not configured with, see Section 8.5. 1955 A DA protects registrations which are made with authentication 1956 blocks using SLP SPIs it is configured to use. If a service S 1957 is registered, a subsequent registration (which will replace the 1958 adertisement) or a deregistration (which will remove it) MUST 1959 include an Authentication Block with the corresponding SLP SPI, see 1960 Section 8.3 and Section 10.6. 1962 Example: 1964 A DA is configured to be able to verify Authentication Blocks with 1965 SLP SPIs "X,Y", that is X and Y. 1967 An SA registers a service with an Authentication Block with SPI "Z". 1968 The DA stores the registration, but discards the Authentication 1969 Block. If a UA requests a service with an SLP SPI string "Z", the DA 1970 will respond with an AUTHENTICATION_UNKNOWN error. 1972 An SA registers a service S with Authentication Blocks including SLP 1973 SPIs "X" and "Y". If a UA requests a service with an SLP SPI string 1974 "X" the DA will be able to return S (if the service type, language, 1975 scope and predicate of the SrvRqst match S) The DA will also return 1976 the Authentication Block with SLP SPI set to "X". If the DA receives 1977 a subsequent SrvDeReg for S (which will remove the advertisement) 1978 or a subsequent SrvReg for S (which will replace it), the message 1979 must include two URL Authentication Blocks, one each for SPIs "X" 1980 and "Y". If either of these were absent, the DA would return an 1981 AUTHENTICATION_ABSENT error. 1983 13. Protocol Timing Defaults 1985 Interval name Section Default Value Meaning 1986 ------------------- ------- ------------- ------------------------ 1987 CONFIG_MC_RETRY 6.3 each second, Retry multicast query 1988 backing off until no new values 1989 gradually arrive. 1990 CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a 1991 complete multicast query 1992 response (all values.) 1993 CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA 1994 discovery on reboot. 1995 CONFIG_DA_RETRY 12.3 2 seconds Retransmit DA discovery, 1996 try it 3 times. 1997 CONFIG_DA_MAX 12.3 6 seconds Give up on requests sent 1998 to a DA. 1999 CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs 2000 passively detect new DAs. 2001 CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait 2002 before repeating Active 2003 DA discovery. 2004 CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services 2005 on passive DA discovery. 2006 CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services 2007 on active DA discovery. 2008 CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle 2009 connections. 2011 14. Optional Configuration 2013 Broadcast Only 2014 Any SLP agent SHOULD be configurable to use broadcast 2015 only. See Sections 6.1 and 12.2. 2017 Predefined DA 2018 A UA or SA SHOULD be configurable to use a predefined DA. 2020 No DA Discovery 2021 The UA or SA SHOULD be configurable to ONLY use 2022 predefined and DHCP-configured DAs and perform no active 2023 or passive DA discovery. 2025 Multicast TTL 2026 The default multicast TTL is 32. Agents SHOULD be 2027 configurable to use other values. A lower value will 2028 focus the multicast convergence algorithm on smaller 2029 subnetworks, decreasing the number of responses and 2030 increases the performance of service location. This 2031 may result in UAs obtaining different results for the 2032 identical requests depending on where they are connected 2033 to the network. 2035 Timing Values 2036 Time values other than the default MAY be configurable. 2037 See Section 13. 2039 Scopes 2040 A UA MAY be configurable to support User Selectable 2041 scopes by omitting all predefined scopes. See 2042 Section 11.2. A UA or SA MUST be configurable to use 2043 specific scopes by default. Additionally, a UA or SA 2044 MUST be configurable to use specific scopes for requests 2045 for and registrations of specific service types. The 2046 scope or scopes of a DA MUST be configurable. The 2047 default value for a DA is to have the scope "DEFAULT" if 2048 not otherwise configured. 2050 DHCP Configuration 2051 DHCP options 78 and 79 may be used to configure SLP. If 2052 DA locations are configured using DHCP, these SHOULD 2053 be used in preference to DAs discovered actively or 2054 passively. One or more of the scopes configured using 2055 DHCP MUST be used in requests. The entire configured 2056 MUST be used in registration and DA 2057 configuration messages. 2059 Service Template 2060 UAs and SAs MAY be configured by using Service Templates. 2061 Besides simplifying the specification of attribute 2062 values, this also allows them to enforce the inclusion 2063 of 'required' attributes in SrvRqst, SrvReg and SrvDeReg 2064 messages. DAs MAY be configured with templates to 2065 allow them to WARN UAs and SAs in these cases. See 2066 Section 10.4. 2068 SLP SPI for service discovery 2069 Agents SHOULD be configurable to support SLP SPIs using 2070 the following parameters: BSD=2 (DSA with SHA-1) and 2071 a public key identified by the SLP SPI String. In 2072 the future, when a Public Key Infrastructure exists, 2073 SLP Agents may be able to obtain public keys and 2074 cryptographic parameters corresponding to the names used 2075 in SLP SLP Strings. 2077 Note that if the SLP SPI string chosen is identical 2078 to a scope string, it is effectively the same as a 2079 Protected Scope in SLPv1. Namely, every SA advertising 2080 in that scope would be configured with the same Private 2081 Key. Every DA and UA of that scope would be configured 2082 with the appropriate Public Key to verify signatures 2083 produced by those SAs. This is a convenient way to 2084 configure SLP deployments in the absense of a Public Key 2085 Infrastructure. Currently, it would be too difficult to 2086 manage the keying of UAs and DAs if each SA had its own 2087 key. 2089 SLP SPI for Directory Agent discovery 2090 Agents SHOULD be configurable to support SLP SPIs as 2091 above, to be used when discovering DAs. This SPI SHOULD 2092 be sent in SrvRqsts to discover DAs and be used to verify 2093 multicast DAAdvert messages. 2095 SA and DA Private Key 2096 SAs and DAs which can generate digital signatures require 2097 a Private Key and a corresponding SLP SPI indentifier 2098 to include in the Authentication Block. The SLP SPI 2099 identifies the Public Key to use to verify the digital 2100 signature in the Authentication Block. 2102 15. IANA Considerations 2104 Further Block Structured Descriptor (BSD) values may be standardized 2105 in the future by submitting a document which describes: 2107 - The data format of the Structured Authenticator block. 2109 - Which cryptographic algorithm to use (including a reference 2110 to a technical specification of the algorithm.) 2112 - The format of any keying material required for 2113 preconfiguring UAs, DAs and SAs. Also include any 2114 considerations regarding key distribution. 2116 - Security considerations to alert others to the strengths and 2117 weaknesses of the approach. 2119 The IANA will assign Cryptographic BSD numbers (from the range 0x0003 2120 to 0x7FFF) on a first come, first served basis. These numbers are 2121 assigned when an RFC (of any status) is issued defining the SLP BSD 2122 and its use. 2124 New function-IDs, in the range 12-255, may be standardized by the 2125 method of IETF Consensus [17]. Similarly, new extensions with types 2126 in the range 3-65535 may be standardized by the method of IETF 2127 Consensus. Specification and Expert Review is required for the 2128 assignment of new error numbers in the range of 15-65535. 2130 Protocol elements used with Service Location Protocol may also 2131 require IANA registration actions. SLP is used in conjunction with 2132 "service:" URLs and service templates [13]. These are standardized 2133 by the method of a Designated Expert and a mailing list (see [13].) 2135 16. Internationalization Considerations 2137 SLP messages support the use of multiple languages by providing a 2138 Language Tag field in the common message header (see Section 8). 2140 Services MAY be registered in multiple languages. This provides 2141 attributes so that users with different language skills may select 2142 services interactively. 2144 A service which is registered in multiple languages may be queried in 2145 multiple languages. The language of the SrvRqst or AttrRqst is used 2146 to satisfy the request. If the requested language is not supported, 2147 a LANGUAGE_NOT_SUPPORTED error is returned. SrvRply and AttrRply 2148 messages are always in the same language of the request. 2150 A DA or SA MAY be configured with translations of Service Templates 2151 [13] for the same service type. This will allow the DA or SA to 2152 translate a request (say in Italian) to the language of the service 2153 advertisement (say in English) and then translate the reply back to 2154 Italian. Similarly, a UA MAY use templates to translate outgoing 2155 requests and incoming replies. 2157 The dialect field in the Language Tag MAY be used: Requests which 2158 can be fulfilled by matching a language and dialect will be preferred 2159 to those which match only the language portion. Otherwise, dialects 2160 have no effect on matching requests. 2162 17. Year 2000 Considerations 2164 SLPv2 uses a Timestamp field in some messages. This value is a 2165 32-bit unsigned fixed-point number of *minutes* relative to 0h on 1 2166 January 1900. This timestamp will wrap back to 0 in the year 10,066. 2168 18. Security Considerations 2170 SLP provides for authentication of service URLs and service 2171 attributes. This provides UAs and DAs with knowledge of the 2172 integrity of service URLs and attributes included in SLP messages. 2173 The only systems which can generate digital signatures are those 2174 which have been configured by administrators in advance. Agents 2175 which verify signed data may assume it is 'trustworthy' inasmuch as 2176 administrators have ensured the cryptographic keying of SAs and DAs 2177 reflects 'trustworthiness.' 2179 Service Location does not provide confidentiality. Because the 2180 objective of this protocol is to advertise services to a community 2181 of users, confidentiality might not generally be needed when this 2182 protocol is used in non-sensitive environments. Specialized schemes 2183 might be able to provide confidentiality, if needed in the future. 2184 Sites requiring confidentiality should implement the IP Encapsulating 2185 Security Payload (ESP) [3] to provide confidentiality for Service 2186 Location messages. 2188 If Agents are not configgured to generate Authentication Blocks and 2189 Agents are not configured to verify them, an adversary might easily 2190 use this protocol to advertise services on servers controlled by the 2191 adversary and thereby gain access to users' private information. 2192 Further, an adversary using this protocol will find it much easier 2193 to engage in selective denial of service attacks. Sites that are in 2194 potentially hostile environments (e.g., are directly connected to 2195 the Internet) should consider the advantages of distributing keys 2196 associated with SLP SPIs prior to deploying the sensitive directory 2197 agents or service agents. 2199 SLP is useful as a bootstrap protocol. It may be used in 2200 environments in which no preconfiguration is possible. In such 2201 situations, a certain amount of "blind faith" is required: Without 2202 any prior configuration it is impossible to use any of the security 2203 mechanisms described above. SLP will make use of the mechanisms 2204 provided by the Security Area of the IETF for key distribution as 2205 they become available. At this point it would only be possible to 2206 gain the benefits associated with the use of Authentication Blocks if 2207 cryptographic information and SLP SPIs can be preconfigured with the 2208 end systems before they use SLP. 2210 SLPv2 enables a number of security policies with the mechanisms it 2211 includes. A SLPv2 UA could, for instance, reject any SLP message 2212 which did not carry an authentication block which it could verify. 2213 This is not the only policy which is possible to implement. 2215 A. Appendix: SLP Protocol Extensions 2217 A.1. Required Attribute Missing Option 2219 0 1 2 3 2220 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 2221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2222 | Extension Type = 0x0001 | Extension Length | 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Template IDVer Length | Template IDVer String \ 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 |Required Attr Length| Required Attr \ 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2229 Required attributes and the format of the IDVer string are defined 2230 by [13]. 2232 If a SA or DA receives a SrvRqst or a SrvReg which fails to include 2233 a Required Attribute for the requested Service Type (according 2234 to the service template), it MAY return the Required Attribute 2235 Extension in addition to the reply corresponding to the message. The 2236 sender SHOULD reissue the message with a search filter including 2237 the attributes listed in the returned Required Attribute Extension. 2238 Similarly, the Required Attribute Extension may be returned in 2239 response to a SrvDereg message that contains a required attribute 2240 tag. 2242 The Template IDVer String is the name and version number string of 2243 the service template which defines the given attribute as required. 2244 It SHOULD be included, but can be omitted if a given SA or DA has 2245 been individually configured to have 'required attributes.' 2247 The Required Attribute MUST NOT include wild cards. 2249 Acknowledgments 2251 This document incorporates ideas from work on several discovery 2252 protocols, including RDP by Perkins and Harjono, and PDS by 2253 Michael Day. John Veizades was working group chair for much of 2254 the development of Service Location Protocol, instrumental in its 2255 standardization, and the lead author of SLPv1 [20]. 2257 References 2259 [1] Port numbers, July 1997. 2260 ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers. 2262 [2] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2263 DAM 4 to ISO/IEC 9594-2, December 1996. 2265 [3] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2266 DAM 2 to ISO/IEC 9594-6, December 1996. 2268 [4] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2269 DAM 1 to ISO/IEC 9594-7, December 1996. 2271 [5] ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment 2272 DAM 1 to ISO/IEC 9594-8, December 1996. 2274 [6] Unicode Technical Report #8. The Unicode Standard, version 2.1. 2275 Technical report, The Unicode Consortium, 1998. 2277 [7] H. Alvestrand. Tags for the Identification of Languages. RFC 2278 1766, March 1995. 2280 [8] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource 2281 Identifiers (URI): Generic Syntax. RFC 2396, August 1998. 2283 [9] S. Bradner. Key Words for Use in RFCs to Indicate Requirement 2284 Levels. RFC 2119, March 1997. 2286 [10] CCITT. The Directory Authentication Framework. Recommendation 2287 X.509, 1988. 2289 [11] D. Crocker and P. Overell. Augmented BNF for Syntax 2290 Specifications: ABNF. RFC 2234, November 1997. 2292 [12] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. 2293 Addison-Wesley, 1990. 2295 [13] E. Guttman, C. Perkins, and J. Kempf. Service Templates and 2296 service: Schemes. draft-ietf-svrloc-service-scheme-12.txt, 2297 October 1998. (work in progress). 2299 [14] T. Howes. The String Representation of LDAP Search Filters. 2300 RFC 2254, December 1997. 2302 [15] D. Meyer. Administratively Scoped IP Multicast. RFC 2365, July 2303 1998. 2305 [16] S. Kille. A String Representation of Distinguished Names. RFC 2306 1779, March 1995. 2308 [17] Thomas Narten and Harald Tveit Alvestrand. Guidelines 2309 for Writing an IANA Considerations Section in RFCs. 2311 draft-iesg-iana-considerations-04.txt, May 1998. (work in 2312 progress). 2314 [18] Microsoft Networks. SMB File Sharing Protocol Extensions 3.0 2315 Document Version 1.09, November 1989. 2317 [19] National Institute of Standards and Technology. Digital 2318 signature standard. Technical Report NIST FIPS PUB 186, U.S. 2319 Department of Commerce, May 1994. 2321 [20] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 2322 Location Protocol. RFC 2165, July 1997. 2324 [21] F. Yergeau. UTF-8, a transformation format of ISO 10646. RFC 2325 2279, January 1998. 2327 B. Full Copyright Statement 2329 Copyright (C) The Internet Society (1997). All Rights Reserved. 2331 This document and translations of it may be copied and furnished to 2332 others, and derivative works that comment on or otherwise explain it 2333 or assist in its implementation may be prepared, copied, published 2334 and distributed, in whole or in part, without restriction of any 2335 kind, provided that the above copyright notice and this paragraph 2336 are included on all such copies and derivative works. However, 2337 this document itself may not be modified in any way, such as by 2338 removing the copyright notice or references to the Internet Society 2339 or other Internet organizations, except as needed for the purpose 2340 of developing Internet standards in which case the procedures 2341 for copyrights defined in the Internet Standards process must be 2342 followed, or as required to translate it into languages other than 2343 English. 2345 The limited permissions granted above are perpetual and will not be 2346 revoked by the Internet Society or its successors or assigns. 2348 This document and the information contained herein is provided on an 2349 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2350 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2351 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2352 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2353 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 2355 Authors' Addresses 2357 Erik Guttman Charles Perkins 2358 Sun Microsystems Sun Microsystems 2359 Bahnstr. 2 901 San Antonio Road 2360 74915 Waibstadt Palo Alto, CA 94040 2361 Germany USA 2363 Phone: +49 7263 911 701 +1 650 786 6464 2364 Email: Erik.Guttman@sun.com cperkins@sun.com 2366 John Veizades Michael Day 2367 @Home Network Madison River Technologies, Inc. 2368 385 Ravendale Dr. 840 North 1415 East 2369 Mountain View, CA 94043 Orem, Utah 84097 2370 USA USA 2372 Phone: +1 650 569 5243 +1 801 802 0706 2373 Email: veizades@home.net Michael.Day@madisonriv.com