idnits 2.17.1 draft-ietf-svrloc-protocol-v2-01.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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. == There is 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There is 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There is 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 2860 has weird spacing: '...seconds reg...' -- 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: 'RFC2165' on line 901 ** Obsolete normative reference: RFC 1766 (ref. '2') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1827 (ref. '3') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Historic RFC: RFC 1423 (ref. '4') ** Obsolete normative reference: RFC 1738 (ref. '5') (Obsoleted by RFC 4248, RFC 4266) -- Possible downref: Non-RFC (?) normative reference: ref. '8' ** Obsolete normative reference: RFC 2234 (ref. '9') (Obsoleted by RFC 4234) == Outdated reference: A later version (-02) exists of draft-ietf-svrloc-sysman-00 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-14) exists of draft-ietf-svrloc-service-scheme-05 ** Obsolete normative reference: RFC 1960 (ref. '13') (Obsoleted by RFC 2254) ** Obsolete normative reference: RFC 1778 (ref. '14') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2030 (ref. '15') (Obsoleted by RFC 4330) == Outdated reference: A later version (-11) exists of draft-ietf-svrloc-discovery-05 -- Possible downref: Normative reference to a draft: ref. '16' == Outdated reference: A later version (-07) exists of draft-ietf-dhc-slp-02 ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '18') ** Obsolete normative reference: RFC 1777 (ref. '20') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 2044 (ref. '21') (Obsoleted by RFC 2279) Summary: 21 errors (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Erik Guttman 3 INTERNET DRAFT Charles Perkins 4 30 October 1997 Sun Microsystems 5 John Veizades 6 @Home Network 7 Michael Day 8 Intel 10 Service Location Protocol 11 draft-ietf-svrloc-protocol-v2-01.txt 13 Status of This Memo 15 This document is a submission by the Service Location Working Group 16 of the Internet Engineering Task Force (IETF). Comments should be 17 submitted to the srvloc@corp.home.net mailing list. 19 Distribution of this memo is unlimited. 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at 28 any time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check 32 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 33 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 34 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 35 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 37 Abstract 39 The Service Location Protocol provides a scalable framework for 40 the discovery and selection of network services. Using this 41 protocol, computers using the Internet need little or no static 42 configuration of network services for network based applications. 43 This is especially important as computers become more portable, and 44 users less tolerant or able to fulfill the demands of network system 45 administration. 47 Contents 49 Status of This Memo i 51 Abstract i 53 1. Introduction 1 55 2. Terminology 2 56 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 57 2.2. Service Information and Predicate Representation . . . . 4 59 3. Protocol Overview 4 60 3.1. Protocol Operations . . . . . . . . . . . . . . . . . . . 5 61 3.2. Minimal SLP Implementation Requirements . . . . . . . . . 6 62 3.2.1. Minimal UA Requirements . . . . . . . . . . . . . 7 63 3.2.2. Minimal SA Requirements . . . . . . . . . . . . . 7 64 3.2.3. Peer-to-Peer Usage of SLP . . . . . . . . . . . . 8 65 3.3. Interactive Service Selection . . . . . . . . . . . . . . 8 66 3.4. Using SLP Directory Agents In Larger Environments . . . . 9 67 3.4.1. Directory Agents . . . . . . . . . . . . . . . . 9 68 3.4.2. Scopes . . . . . . . . . . . . . . . . . . . . . 10 69 3.4.3. Scaling Configuration Options . . . . . . . . . . 10 70 3.5. Introduction to Directory Agents . . . . . . . . . . . . 11 71 3.6. URLs used in the Service Location Protocol . . . . . . . 11 72 3.6.1. The ``service:'' URL scheme . . . . . . . . . . 12 73 3.7. Standard Attribute Definitions . . . . . . . . . . . . . 12 74 3.8. Naming Authority . . . . . . . . . . . . . . . . . . . . 13 75 3.9. Interpretation of Service Location Replies . . . . . . . 13 76 3.10. Transmission of SLP messages . . . . . . . . . . . . . . 13 77 3.10.1. Use of TCP . . . . . . . . . . . . . . . . . . . 14 78 3.10.2. Use of Multicast Addresses . . . . . . . . . . . 15 79 3.10.3. Multicast vs. Broadcast . . . . . . . . . . . . 15 81 4. Service Location General Message Format 16 82 4.1. Service Location Extension Options . . . . . . . . . . . 18 83 4.2. Retransmission and Transaction IDs (XIDs) . . . . . . . . 19 84 4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 20 85 4.4. Authentication Blocks . . . . . . . . . . . . . . . . . . 20 86 4.5. URL Entry Lifetime . . . . . . . . . . . . . . . . . . . 23 88 5. Service Location Protocol Requests 23 90 6. Service Request Message Format 24 91 6.1. Service Request Usage . . . . . . . . . . . . . . . . . . 25 92 6.2. Directory Agent Discovery Request . . . . . . . . . . . . 26 93 6.3. Explanation of Terms of Predicate Grammar . . . . . . . . 27 94 6.4. Service Request Predicates . . . . . . . . . . . . . . . 28 95 6.5. String Matching for Requests . . . . . . . . . . . . . . 29 97 7. Service Reply Message Format 30 99 8. Service Type Request Message Format 31 101 9. Service Type Reply Message Format 32 103 10. Attribute Request Message Format 33 105 11. Attribute Reply Message Format 34 107 12. Directory Agent Advertisement Message Format 35 109 13. Service Registration Message Format 37 111 14. Service Acknowledgement Message Format 39 113 15. Service Deregister Message Format 41 115 16. Directory Agents 42 116 16.1. Finding Directory Agents . . . . . . . . . . . . . . . . 42 118 17. Scope Discovery and Use 43 119 17.1. Rules Governing Scopes . . . . . . . . . . . . . . . . . 44 120 17.1.1. Scope Strings in SLP Messages . . . . . . . . . . 45 121 17.1.2. Registration . . . . . . . . . . . . . . . . . . 46 122 17.1.3. Query Handling . . . . . . . . . . . . . . . . . 46 123 17.2. Protected Scopes . . . . . . . . . . . . . . . . . . . . 47 124 17.2.1. Protected Scope Rules . . . . . . . . . . . . . . 48 126 18. Language Internationalization Issues 49 127 18.1. Language Tags and Dialects . . . . . . . . . . . . . . . 49 128 18.2. Scope Strings are not Language Specific . . . . . . . . . 49 129 18.3. Declaring the language of registrations . . . . . . . . . 49 130 18.4. Translation of Attribute Strings . . . . . . . . . . . . 50 131 18.5. Declaring the language of a Request . . . . . . . . . . . 50 133 19. Substitution of Character Escape Sequences 51 134 19.1. Language-Independent Strings . . . . . . . . . . . . . . 51 136 20. String Formats used with Service Location Messages 53 137 20.1. Previous Responders' Address Specification . . . . . . . 53 138 20.1.1. Service Type String . . . . . . . . . . . . . . . 54 139 20.1.2. String List . . . . . . . . . . . . . . . . . . . 54 140 20.1.3. Select List . . . . . . . . . . . . . . . . . . . 54 141 20.2. Attribute Information . . . . . . . . . . . . . . . . . . 55 142 20.3. Address Specification in Service Location . . . . . . . . 55 143 20.4. Attribute Value encoding rules . . . . . . . . . . . . . 56 145 21. Protocol Timing Rules 57 146 21.1. Active DA Discovery . . . . . . . . . . . . . . . . . . . 57 147 21.2. Passive DA Advertising . . . . . . . . . . . . . . . . . 57 148 21.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . . 58 149 21.4. Multicast/Convergence . . . . . . . . . . . . . . . . . . 58 151 22. Configurable Parameters and Default Values 58 152 22.1. Time Out Intervals . . . . . . . . . . . . . . . . . . . 59 153 22.2. Service Agent: Use Predefined Directory Agent(s) . . . . 61 155 23. Security Considerations 61 157 24. Protocol Requirements 62 158 24.1. Directory Agent Requirements . . . . . . . . . . . . . . 62 159 24.2. Service Agent Requirements . . . . . . . . . . . . . . . 63 160 24.3. User Agent Requirements . . . . . . . . . . . . . . . . . 63 161 24.4. Common Requirements for all SLP Agents . . . . . . . . . 63 163 25. Non-configurable Parameters 64 165 26. Acknowledgments 64 167 A. Version 2 Notes 65 169 B. SLP Certificates 70 171 C. Example of deploying SLP security using MD5 and RSA 72 173 D. Scaling and Deployment of the Service Location Protocol 72 175 E. Using SLP For Network and Systems Management 74 177 F. Full Copyright Statement 76 179 1. Introduction 181 Traditionally, users find services by using the name of a network 182 host (a human readable text string) which is an alias for a network 183 address. The Service Location Protocol eliminates the need for 184 a user to know the name of a network host supporting a service. 185 Rather, the user names the service and supplies a set of attributes 186 which describe the service. The Service Location Protocol allows the 187 user to bind this description to the network address of the service. 189 Service Location provides a dynamic configuration mechanism for 190 applications in local area networks. It has been designed to serve 191 enterprise networks with shared services. In its in its current 192 form, it may not scale for wide-area service discovery throughout the 193 global Internet. Applications are modeled as clients that need to 194 find servers attached to the enterprise network at a possibly distant 195 location. For cases where there are many different clients and/or 196 services available, the protocol is adapted to make use of nearby 197 Directory Agents that offer a centralized repository for advertised 198 services. 200 2. Terminology 202 User Agent (UA) 203 A process working on the user's behalf to establish 204 contact with a useful service. The UA retrieves service 205 information from the Service Agents or Directory Agents. 207 Service Agent (SA) 208 A process working on the behalf of one or more services 209 to advertise service information. 211 Service Information 212 A collection of attributes and configuration information 213 associated with a single service. The SAs advertise 214 service information for a collection of service 215 instances. 217 Directory Agent (DA) 218 A process which collects information from SAs to provide 219 a single repository of service information in order to 220 centralize it for efficient access by UAs. There can 221 only be one DA present per given host. 223 Service Type 224 Each type of service has a unique Service Type string. 225 The Service Type defines a template, called a "service 226 scheme", including expected attributes, values and 227 protocol behavior. 229 IANA IANA stands for the Internet Assigned Numbers Authority. 231 Naming Authority 232 The agency or group which catalogues given Service Types 233 and Attributes. The default Naming Authority is IANA. 235 Keyword 236 A string describing a characteristic of a service. 238 Attribute 239 A (class, value-list) pair of strings describing a 240 characteristic of a service. The value string may be 241 interpreted as a boolean, integer or opaque value if it 242 takes specific forms (see section 20.4). 244 Predicate 245 A boolean expression of attributes, relations and 246 logical operators. The predicate is used to find 247 services which satisfy particular requirements. See 248 section 6.3. 250 Alphanumeric 251 A character within the range 'a' to 'z', 'A' to 'Z', or 252 '0' to '9'. 254 Scope A collection or set of services that make up a logical 255 group. See section 17 and appendix D. 257 Site Network 258 All the hosts accessible within the Agent's multicast 259 radius, which defaults to a value appropriate for 260 reaching all hosts within a site (see section 22). If 261 the site does not support multicast, the agent's site 262 network is restricted to a single subnet. 264 URL A Universal Resource Locator - see [5]. 266 Address Specification 267 This is the network layer protocol dependent mechanism 268 for specifying an Agent. This is part of a URL. 270 SLPv1 The version of Service Location Protocol specified in 271 RFC 2165 [19]. 273 2.1. Notation Conventions 275 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 276 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", 277 "MAY", and "OPTIONAL" in this document are to be 278 interpreted as described in RFC 2119 [7]. 280 Quoted Strings 281 Some strings are quoted in this document to indicate 282 they should be used literally. Single characters inside 283 apostrophes are included literally. 285 <> Values set off in this manner are fully described in 286 section 20. In general, all definitions of items in 287 messages are described in section 20 or immediately 288 following their first use. 290 silently discard 291 The implementation discards the datagram without further 292 processing, and without indicating an error to the 293 sender. The implementation SHOULD provide the capability 294 of logging the error, including the contents of the 295 discarded datagram, and SHOULD record the event in a 296 statistics counter. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | A | B \ 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 \ C \ 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 A is a 2 byte field. B is of *arbitrary length*, where the length 307 in bytes is typically indicated by A. C is of arbitrary length. A 308 string field in a SLP message is 'omitted' by setting the length of 309 the string to 0 and transmitting no character bytes. 311 Syntax for string based protocols will follow the conventions defined 312 for ABNF [9]. Terms in angular brackets are defined formally in 313 Section 20 or where they are introduced. 315 2.2. Service Information and Predicate Representation 317 Service information is represented in a text format. The goal is 318 that the format be human readable and transmissible via email. The 319 location of network services is encoded as a Universal Resource 320 Locator (URL) which is human readable. Strings used in the Service 321 Location Protocol are NOT null-terminated. 323 3. Protocol Overview 325 The Service Location Protocol (SLP) provides a flexible and scalable 326 framework for providing hosts with access to information about the 327 existence, location, and configuration of networked services. 329 SLP is a request-reply protocol; in a typical operation a User Agent 330 (UA) issues a request for service information and awaits one or more 331 replies containing the requested information. Depending on the 332 environment, replies will be sent to the UA by a Service Agent (SA), 333 a Directory Agent (DA), or by both. 335 For smaller environments, SLP allows a simple peer-to-peer deployment 336 consisting only of UAs and SAs. For larger environments, SLP allows 337 the consolidation of service configuration data at one or more 338 Directory Agents (DAs). 340 DAs, in addition to consolidating service information, allow 341 information to be organized according to administrative, usage, or 342 type domains using "scopes." Section 3.4 contains information on 343 deploying SLP in larger environments using DAs and scopes. 345 SLP PDUs are normally transmitted in datagrams using UPD/IP. Requests 346 may be unicast, multicast, or broadcast. When a UA multicasts or 347 broadcasts a request, it will often recieve more than one reply. 348 Replies must be unicast. In cases where a SLP PDU is too large to 349 fit within a datagram, the UA, SA, or DA may unicast that PDU using 350 TCP. 352 SLP allows a host to "bootstrap" itself, beginning with no knowledge 353 of any services or SLP agents beyond its own UA. To bootstrap itself, 354 the host must multicast or broadcast its first request. 356 Hosts may also be preconfigured--statically or by using DHCP 357 options--to issue requests to specific SAs or DAs, hence avoiding 358 multicast or broadcast requests. 360 Certain conditions will influence the best strategy for deploying SLP 361 in specific environments. Centralizing service information using 362 DAs simplifies the process by which UAs obtain service information. 363 However, it may not be practical to centralize service-related 364 information that changes frequently. Also, specific environments may 365 have special policies regarding broadcasting or multicasting. 367 This document specifies a range of usage models for SLP, beginning 368 with a lightweight and simple minimal implementation for smaller or 369 constrained environments. SLP can be scaled upward from the minimal 370 implementation by deploying more richly featured UAs and SAs, and by 371 adding DAs. 373 3.1. Protocol Operations 375 The diagram below shows the objects that engage in the SLP and their 376 relationships with each other. 378 +--------------------+ we want this info: +-----------+ 379 | Application |- - - - - - - - - - - - ->>| Service | 380 +--------------------+ +-----------+ 381 ^ | 382 /|\ | 383 | | 384 | | 385 \|/ \|/ 386 v v 387 +----------------+ +------------+ 388 | User Agent(UA) | -------------------------->| Service | 389 +----------------+ | Agent (SA) | 390 ^ +------------+ 391 /|\ ^ 392 | /|\ 393 | | 394 | +-------------+ | 395 +------------------>| Directory |<----------+ 396 | Agent (DA) | 397 +-------------+ 398 ^ ___________ 399 /|\ / Many other\ 400 +------------>| SA's | 401 \___________/ 403 In the diagram above, the service contains information the 404 application requires in order to use the service. (If the 405 application knew this information, it could ask the service for it 406 directly; but it doesn't and it can't.) 408 The service publishes its location and configuration by providing 409 that information to the SA. When there is a DA present, the SA also 410 passes the service's configuration and location on to the DA. 412 The application obtains the service's location and configuration by 413 causing the UA to issue a service request to the SA. The UA awaits 414 the service reply from the SA; when it arrives the UA makes the 415 service information available to the application. The SLP includes 416 a predicate grammar that allows the application to form service 417 requests of varying specificity. 419 When one or more DAs are present, unless there is a very good reason 420 not to (see, for example, Appendix E) the UA will issue the service 421 request to a DA rather than to a SA. Information on using DAs is 422 contained in section 3.4. 424 3.2. Minimal SLP Implementation Requirements 426 This section lists the required characteristics of UAs and SAs, 427 which, together, comprise the absolute minimum functionality of a 428 compliant SLP implementation. 430 Sections 3.3 and 3.4 discuss increasing degrees of greater SLP 431 functionality, and how a more functional and scalable implementation 432 of SLP can be deployed. 434 An implementation of SLP MUST, at a minimum, include a User Agent 435 (UA) or a Service Agent (SA). A host supporting SLP MAY host one 436 or more processes using UA and SA functions concurrently. An 437 implementation MAY support both UA and SA funtionality. In order to 438 deploy SLP, both UAs and SAs must be present on the network. 440 3.2.1. Minimal UA Requirements 442 A minimal UA implementation has the the following requirements: 444 - The UA must be able to send Service Requests (see Section 6) and 445 receive Service Replies (see Sections 7). 447 - The UA must be able to send Service Requests and receive DA 448 Advertisements, to discover DAs. The UA will do this initially 449 and periodically. (See Section 21.1). 451 - The UA must be able to handle replies which overflow a single 452 datagram (see Section 3.10.1). 454 - The UA must support a number of configurable parameters (see 455 Section 22). The UA will work fine without any additional 456 configuration, however. 458 - If the UA is configured to use a protected scope, it must 459 reject unauthenticated Service or Attribute Replies (see 460 Section 17.2.1). 462 For a complete list of UA characteristics see Section 24.3. 464 3.2.2. Minimal SA Requirements 466 A minimal SA implementation has the following requirements: 468 - The SA MUST perform both active and passive DA discovery (see 469 Section 21.1 and 21.2) unless it is specifically configured not 470 to perform DA Discovery (see Section 22.2). 472 - SAs must forward service registrations and deregistrations (see 473 Section 13 and 15). 475 - SAs must reply to Service Requests (see Section 6). 477 - SAs must reply to UDP requests which overflow so that a UA can 478 retransmit using TCP (see Section 3.10.1). 480 - SAs must be configurable with a number of parameters (see 481 Section 22). 483 - If the SA is configured to work with protected scopes, it MUST 484 generate and include signatures in all Service Reply, Service 485 Register, and Service Deregister messages it sends. (See 486 Section 17.2.1). 488 For a complete list of SA characteristics, see Section 24.2. 490 3.2.3. Peer-to-Peer Usage of SLP 492 A peer-to-peer usage of SLP is possible by having stations host both 493 UA and SA functionality. Each station is therefore a peer, and peers 494 make requests and provide responses directly to each other. This 495 usage allows a lightweight implementation of SLP that works well in 496 small environments or on smaller broadcast networks. 498 DAs are not required under a peer-to-peer usage of SLP. Instead of 499 discovering centralized service information by issuing requests to 500 DAs, SLP peers can discover services by multicasting or broadcasting 501 service requests to other peers. Multicasting and broadcasting 502 require usage of the convergence algorithm described in Section 21.4. 504 3.3. Interactive Service Selection 506 By supporting the Service Type Request and the Attribute Request SLP 507 can enable interactive service discovery and Internationalization. 509 With interactive service selection, the user can discover all types 510 of services present on a network. He or she can select a service 511 type and discover all the attributes supported on the network by that 512 type of service. The user can then form a query for specific service 513 attributes; if such a query fails, the user can form a less specific 514 attribute query, and so on. 516 Internationalization requires service attributes to be stored in 517 multiple languages, thus making it possible for users from different 518 communities to share resources in a more natural manner. However, 519 internationalization of SLP service attributes requires support for 520 the Attribute Request. 522 For interactivity and internationalization, UAs SHOULD send Service 523 Type Requests and Attribute Requests by unicasting them over UDP (and 524 TCP in case of overflow); and by multicasting or broadcasting (if 525 configured to do so) them over UDP. 527 SAs SHOULD respond to respond to Service Type Requests and Attribute 528 Requests by unicasting the appropriate responses over UDP (and TCP in 529 the case of overflow). 531 If the SA supports Service Type Requests or Attribute Requests, 532 when it receives an incorrect Service Type or Attribute Request, 533 it MUST return an error code to the requester. Error codes are in 534 Section 25. 536 3.4. Using SLP Directory Agents In Larger Environments 538 Through the deployment of DAs and the usage of scopes, SLP can scale 539 up to larger environments. 541 3.4.1. Directory Agents 543 DAs are consolidated stores of service location, configuration, and 544 attribute information. They exist to enhance the performance and 545 upward scalability of SLP. When DAs are present, SAs MUST register 546 all of their service information with the DAs. 548 When DAs are present, UAs SHOULD unicast requests directly to a DA 549 (when scoping rules allow), hence avoiding using the multicast and 550 convergence algorithm to obtain service information. This decreases 551 network utilization and increases the speed at which UAs can obtain 552 service information. 554 A single DA can support many UAs. Moreover, many DAs can coreside on 555 a network, which makes load balancing and redundancy possible. DAs 556 reduce the load on SAs, which makes simpler implementations of SAs 557 possible. 559 UAs can discover DAs using static configuration, DHCP options, 560 or by multicasting (or broadcasting) Service Requests using the 561 convergence algorithm in Section 21.4. n a large scale case, the 562 configuration of UAs might be through SRV records in the DNS or TXT 563 records pointing to a DA URL (see [16]) 565 When DAs are deployed, are subject to the requirements listed in 566 Section 24.1. 568 3.4.2. Scopes 570 Scopes exist to make SLP easier to use and to administer in larger 571 environments, and require the presence of DAs. Scopes are a logical 572 mechanism that allows the grouping of services into different sets. 573 Services can be grouped according to organizational structure, 574 physical location, type, and so on. Some scopes can be protected 575 (subject to authentication of service information). 577 Scoped DAs accept registrations and requests that are within their 578 scope. For protected scopes, this means that the registrations and 579 requests are signed using the scope's Public Key. DAs that are not 580 scoped accept registrations and requests from any agent. 582 SAs and UAs must use scopes when they exist. UAs use scopes to focus 583 their requests to specific groups of services. SAs use scopes to 584 advertise (register) their service information as part of a specific 585 group. 587 Unscoped services are discoverable and usable by anyone. 589 In the special case of DA Discovery, requests may be sent to DAs with 590 scoping turned off (see Section 6.2). 592 UAs may issue requests to SAs with scoping turned off (see 593 Section 17.1.3). In this case, SAs will ignore scoping when replying 594 to the request. 596 All SLP agents can discover scopes by observing DA Advertisements, by 597 using DHCP options, or by static configuration. 599 Scoping rules are detailed in Section 17.1. 601 3.4.3. Scaling Configuration Options 603 By using specific configuration settings, SLP agents can work better 604 in larger environments. 606 The most effective mechanisms SLP offers for scaling up are DAs and 607 scopes. When DAs and scopes are present on the network, further 608 gains can be had by doing the following: 610 - Configuring UAs and SAs to have a predefined scope. These agents 611 can then perform DA discovery and make requests using their 612 scope. This will limit the number of replies. 614 - Turning off DA discovery and using DHCP options to gain DA and 615 scoping information. This will limit the amount of bandwidth 616 consumed by DA discovery. 618 - Adjusting the TTL for multicast requests downward to limit 619 the scope of multicast requests. This focuses the multicast 620 convergence algorithm on smaller subnetworks, which decreases 621 the number of responses and increases the performance of service 622 location. 624 3.5. Introduction to Directory Agents 626 A DA acts on behalf of many SAs. It acquires information from them 627 and acts as a soft state cache. It is a single point of contact to 628 supply that information to UAs. 630 The queries that a UA multicasts to SAs (in an environment without a 631 DA) are the same as queries that the UA might unicast to a DA. A UA 632 may cache information about the presence of alternate DAs to use in 633 case a selected DA fails. 635 Aside from enhancing the scalability of the protocol (see Section D), 636 running multiple DAs provides robustness of operation. The DAs may 637 have replicated service information which remain accessible even when 638 one of the DAs fail. DAs, in the future, may use mechanisms outside 639 of this protocol to coordinate the maintenance of a distributed 640 database of Service Location information, and thus scale to larger 641 administrative domains. 643 Each SA MUST register with all DAs they are configured to use. 644 UAs may choose among DAs they are configured to use. UAs and 645 SAs determine which DAs to use based on scope rules described in 646 Section 17.1. 648 Locally, DA consistency is guaranteed using mechanisms in the 649 protocol. There isn't any DA to DA protocol yet. Rather, passive 650 detection of DAs by SAs ensures that eventually service information 651 will be registered consistently between equivalent DAs. Invalid 652 data will age out of the DA caches leaving only transient stale 653 registrations even in the case of a failure of a SA. 655 3.6. URLs used in the Service Location Protocol 657 The Service Location Protocol uses URLs to indicate the location of 658 services. URLs are used in a variety of Service Location Messages: 659 SAs send them to register and deregister service advertisements, 660 UAs obtain them in Service Replies and may send them in Attribute 661 Requests. Any URL which conforms to standard URL syntax conventions 662 (see RFC 1738 [5]) may be used in these messages. 664 Service: URLs are useful for transmitting a service's location to a 665 client application. Other standard URL schemes may also be used for 666 this purpose. 668 3.6.1. The ``service:'' URL scheme 670 The service URL scheme is used specifically to communicate a Service 671 Location. Many Service Types will be named by including a standard 672 network service name after the ``service:'' scheme name. 674 The format of the information which follows the ``service:'' scheme 675 should as closely as possible follow the URL structure and semantics 676 as formalized by the IETF standardization process. See [12]. 678 Well known Service Types are registered with the IANA and templates 679 are available as RFCs. Private Service Types may also be supported. 681 3.7. Standard Attribute Definitions 683 Service Types used with the Service Location Protocol must describe 684 the following: 686 Service Type string of the service 687 Attributes and Keywords 688 Attribute Descriptions and interpretations 690 Service Types not specified by documents maintained with IANA 691 will use their own Naming Authority string. The procedure for 692 standardizing new Service Types is defined in [12]. 694 Services which advertise a particular Service Type must support the 695 complete set of standardized attributes. They may support additional 696 attributes, beyond the standardized set. Unrecognized attributes 697 MUST be ignored by UAs. 699 Service Type names which begin with "x-" are guaranteed not to 700 conflict with any officially registered Service Type names. It 701 is suggested that this prefix be used for experimental or private 702 Service Type names. Similarly, attribute names which begin with "x-" 703 are guaranteed not to be used for any officially registered attribute 704 names. 706 A service of a given Service Type should accept the networking 707 protocol if one is implied in its definition. If a Service Type 708 can accept multiple protocols, configuration information SHOULD 709 be included in the Service Type attribute information. This 710 configuration information will enable an application to use the 711 results of a Service Request and Attribute Request to directly 712 connect to a service. The format of a Service Type string is 713 described in Section 20.1.1. 715 3.8. Naming Authority 717 The Naming Authority of a service defines the meaning of the 718 Service Types and attributes registered with and provided by Service 719 Location. The Naming Authority itself is a string which uniquely 720 identifies an organization. If no string is provided IANA is the 721 default. 723 Naming Authorities may define Service Types which are experimental, 724 proprietary or for private use. The procedure to use is to create 725 a 'unique' Naming Authority string and then specify the Standard 726 Attribute Definitions as described above. This Naming Authority 727 will accompany registration and queries, as described in Sections 6 728 and 13. 730 Service Types SHOULD be registered with IANA to allow for 731 Internet-wide interoperability. 733 3.9. Interpretation of Service Location Replies 735 Replies should be considered to be valid at the time of delivery. 736 The service may, however, fail or change between the time of the 737 reply and the moment an application seeks to make use of the service. 738 The application making use of Service Location MUST be prepared for 739 the possibility that the service information provided is either stale 740 or incomplete. In the case where the service information provided 741 does not allow a UA to connect to a service as desired, the Service 742 Request and/or Attribute Request may be resubmitted. 744 Service specific configuration information (such as which protocol 745 to use) should be included as attribute information in Service 746 Registrations. 748 3.10. Transmission of SLP messages 750 UAs MUST be able to issue requests to DAs using UDP and SAs using 751 multicast/convergence. UAs will use TCP in the case of overflow as 752 described below. UAs MAY be able to issue UDP requests to SAs, but 753 this is not normally necessary. 755 SAs MUST be able to respond to UDP, TCP and multicast requests. 757 DAs MUST be able to respond to UDP and TCP requests, as well as 758 multicast DA Discovery SrvRqsts. 760 See Section 21 for timing and retransmission rules on how these 761 messages are exchanged. 763 3.10.1. Use of TCP 765 The Service Location Protocol requires the implementation of UDP 766 (connectionless) and TCP (connection oriented) transport protocols. 767 The latter is used for bulk transfer only when necessary. The only 768 two reasons to use TCP are: 770 First, a registration or deregistration may be too large to fit into 771 a datagram. If no MTU information is available for the route, assume 772 that the MTU is 1400 which is enough to accommodate a IPv6 header and 773 UDP header in an ethernet frame. This value is configurable (see 774 Section 22). In this case a connection must be set up from a SA to a 775 DA. UAs may establish a TCP connection with a DA (not an SA) to send 776 requests which do not fit in a datagram to DAs. 778 Second, if the reply to a UA's request overflows a datagram, the 779 DA or SA truncates the reply to fit in one datagram and sets the 780 'overflow' bit in the SLP header. A UA which receives such a reply 781 MAY open a TCP connection with the DA or SA and retransmit the 782 request. It MAY also attempt to make use of the truncated reply or 783 reformulate a more restrictive request which will result in a smaller 784 reply. 786 DAs and SAs MUST respond to connection requests; SAs whose 787 registration data can overflow a datagram must be able to use TCP to 788 send the registration. 790 A TCP connection initiated by an Agent may be used for a single 791 transaction. It may also be used for multiple transactions. Since 792 there are length fields in the message headers, the Agents may send 793 multiple requests along a connection and read the return stream for 794 acknowledgments and replies. 796 The initiating agent is responsible for closing the TCP connection. 797 The DA should wait at least CONFIG_CLOSE_CONN seconds before closing 798 an idle connection. DAs and SAs SHOULD eventually close idle 799 connections to ensure robust operation, even when the agent which 800 opened a connection neglects to close it. 802 SAs and UAs use ephemeral ports for transmitting information to the 803 service location port, which is 427. 805 3.10.2. Use of Multicast Addresses 807 SrvTypeRqst messages are sent to the Service Location General 808 Multicast Address. SrvRqst messages used for DA Discovery are sent 809 to the Directory Agent Discovery Multicast Address. 811 SAs must join multicast groups depending on which services they 812 advertise (called Service-Specific multicast addresses). They also 813 must join the Service Location General Multicast Address. 815 UAs send multicast SrvRqst or AttrRqst messages to the Service- 816 Specific multicast group corresponding to the service type of the 817 request. 819 Service-Specific Multicast addresses are computed by calculating a 820 string hash on the service type string. The service type string is 821 defined in Section 20.1.1. This string will always fall inside the 822 ASCII range of the UTF8 [21] encoding due to its definition. 824 The multicast group they join is determined by the string hash 825 function given below: 827 #define RANGE_SIZE 0x7f 828 /* 829 * SLPhash returns a hash value in the range 0-RANGE_SIZE for 830 * a string of single-byte characters, of specified length. 831 */ 832 unsigned long SLPhash (const char *pc, unsigned int length) { 833 unsigned long h = 0; 834 while (length-- != 0) { 835 h *= 33; 836 h += *pc++; 837 } 838 return (RANGE_SIZE & h); /* round to fit in range of addresses */ 839 } 841 This value is added to the base range of Service Specific Discovery 842 Addresses, to be assigned by IANA. These will be 128 contiguous 843 multicast addresses from the administrative local multicast range. 845 3.10.3. Multicast vs. Broadcast 847 The Service Location Protocol was designed for use in networks 848 where DHCP is available, or multicast is supported at the network 849 layer. To support this protocol when only network layer broadcast is 850 supported, the following procedures may be followed. 852 3.10.3.1. Single Subnet 854 In isolated networks, broadcasts will work in place of multicast. 856 SAs SHOULD and DAs MUST listen for broadcast Service Location request 857 messages to the Service Location port. This allows UAs which lack 858 multicast capabilities to still make use of Service Location on a 859 single subnet. 861 3.10.3.2. Multiple Subnets 863 In larger enterprises, a DA can be used to provide a central clearing 864 house of information for UAs. The DA address can be dynamically 865 configured with Agents using DHCP. The address can also be determined 866 by static configuration. Using multicast DA discovery in enterprises 867 with multiple subnets will require use of multicast discovery with 868 multiple hops (i.e., TTL > 1 in the IP header). Note that the 869 setting of the TTL in multicast packets sometimes must be interpreted 870 according to conventional scoping agreements rather than strictly as 871 the number of hops. 873 4. Service Location General Message Format 875 The following header is used in all of the message descriptions below 876 and is abbreviated by using "Service Location header =" followed by 877 the function being used. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Version | Function | Length | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 |O|M|U|A|F|R|S| reserved | Language Tag Length | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Next option, offset | XID | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 \ Language Tag (ASCII string) \ 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 891 The header for SLP v2 has changed from SLP v1 in the following ways. 892 Dialect is no longer needed, as it is included in the Language Tag. 893 The Language Code field is now interpreted as the length of the 894 Language Tag which follows the header. Finally, since all characters 895 will be encoded in UTF-8, the Char Encoding field of SLP v1 is no 896 longer necessary. This field is now used as an offset to the Next 897 Option. 899 Version This protocol document defines version 2 of the Service 900 Location protocol. A SLP implementation MAY support 901 version 1 [RFC2165]. If a SLP message indicates it 902 is sent using version 1 and this is not supported, a 903 PROTOCOL_V1_REJECTED error is returned. 905 Function Service Location datagrams can be identified as to their 906 operation by the function field. The following are the 907 defined operations: 909 Message Type Abbreviation Function Value 911 Service Request SrvRqst 1 912 Service Reply SrvRply 2 913 Service Registration SrvReg 3 914 Service Deregister SrvDeReg 4 915 Service Acknowledge SrvAck 5 916 Attribute Request AttrRqst 6 917 Attribute Reply AttrRply 7 918 DA Advertisement DAAdvert 8 919 Service Type Request SrvTypeRqst 9 920 Service Type Reply SrvTypeRply 10 922 Length The number of bytes in the message, including the Service 923 Location Header. 925 O The 'Overflow' bit. See Section 3.10 for the use of this 926 field. 928 M The 'Monolingual' bit. Requests with this bit set 929 indicate the User Agent will only accept responses in 930 the language (see Section 18) that is indicated by the 931 Service or Attribute Request. 933 U The 'URL Authentication Present' bit. See Sections 4.3, 934 4.4, 13, and 15 for the use of this field. 936 A The 'Attribute Authentication Present' bit. See 937 Sections 4.3, 4.4, and 11 for the use of this field. 939 F If the 'Fresh bit' is set by the SA when it makes 940 a Service Registration if it is to be considered 941 'fresh'. If this bit is not present, the registration is 942 considered to be an update. 944 R The 'Multicast request' bit. This is set by the UA when 945 it multicasts or broadcasts a request. 947 S The 'Specific Scoping' bit. This is set by Service 948 Location Protocol entities wishing to exclude services 949 not assigned to any scope, or by services unwilling 950 to provide service to user agents not specifying the 951 particular scope. 953 reserved MUST be zero. 955 Language Tag Length 956 Strings within the remainder of the message which follows 957 are to be interpreted in the language specified (see 958 Section 18) in the bytes following the header. The 959 Language Tag is defined by RFC 1766 [2]. 961 Next Option Offset 962 Options are added after the regular payload in the SLP 963 packet. If no options are present, then this field is 964 set to 0. 966 Transaction Identifier (XID) 967 The XID (transaction ID) field allows the requester to 968 match replies to individual requests (see Section 4.2). 970 Note that, whenever there is an Attribute Authentication block, there 971 will also be a URL Authentication block. Thus, it is an error to 972 have the 'A' bit set without also having the 'U' bit set. 974 4.1. Service Location Extension Options 976 A service location extension option must be specified by a standards 977 track document. The option may be defined to accompany any or 978 all Service Location Messages. A conforming SLP implementation 979 MUST be able to ignore Service Location Extension Options it does 980 not recognize. It may be the case that future Options will be 981 defined and standardized which will become requirements of SLP 982 implementations. These documents will have to proceed as Standards 983 Track specifications. Otherwise, support of all extension options is 984 elective. 986 The format of a Service Location Extension Option is: 988 0 1 2 3 989 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 990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 991 | Option Extension ID | Offset to next Option | 992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 993 \ Extension Contents \ 994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 The Option Extension ID is defined by a Standards document which also 997 defines the contents of the extension. The offset to next option 998 is 0 if there is no option following or is set to the length of the 999 Extension contents. 1001 4.2. Retransmission and Transaction IDs (XIDs) 1003 Retransmission is used by UAs and SAs to ensure reliable exchange of 1004 unicast messages with DAs. If a UA or SA sends a message to a DA 1005 fails to receive a response, the message will be sent again. The 1006 message is retried up to 3 times 1008 Multicast requests are retransmitted, but according to different 1009 rules. See Section 21 for the details of the algorithm. 1011 Replies received using the multicast convergence algorithm are 1012 accumulated until convergence has been detected. 1014 A list of previous responders is sent. This list will prevent those 1015 in the list from responding, to be sure that responses from other 1016 sources are not drowned out. 1018 Retransmission of the same message should not contain an updated XID. 1019 It is quite possible the original request reached the DA or SA, but 1020 reply failed to reach the requester. Using the same XID allows the 1021 DA or SA to cache its reply to the original request and then send it 1022 again, should a duplicate request arrive. This cached information 1023 should only be held very briefly (CONFIG_KEEP_RPLY is recommended.) 1024 Any registration or deregistration at a DA, or change of service 1025 information at a SA should flush this cache so that the information 1026 returned to the client is always valid. 1028 The requester creates the XID from an initial random seed and 1029 increments it by one for each request it makes. The XIDs will 1030 eventually wrap and continue incrementing from there. Requests are 1031 never sent with an XID of 0. 1033 An unsolicited DAAdvert has an XID of 0. 1035 Requests all include XIDs which will match the XIDs of the replies. 1036 The replies may be returned in any order. A UA or SA may have 1037 multiple outstanding requests. 1039 4.3. URL Entries 1041 When URLs are registered, they have lifetimes and lengths, and may 1042 be authenticated. These values are associated with the URL for 1043 the duration of the registration. The association is known as a 1044 "URL-entry", and has the following format: 1046 0 1 2 3 1047 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 1048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1049 | Reserved | Lifetime |# of URL auths | 1050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1051 | URL length | URL (variable length) \ 1052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1053 | URL Auth. blocks (if any) \ 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 |# of Attr auths| Attr Auth. blocks (if any) \ 1056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 Reserved MUST be zero. This field is reserved for longer 1059 lifetimes used by a wide area service location 1060 protocol. 1062 Lifetime The length of time that the registration is valid, in 1063 the absence of later registrations or deregistration. 1065 Length of URL 1066 The length of the URL, measured in bytes and < 32768. 1068 URL Authentication Block 1069 (if present) A timestamped authentication block 1070 (Section 4.4) 1072 If the 'U' bit is set in the message header, the URL is followed by 1073 an URL Authentication Block. If the scheme used in the URL does not 1074 have a standardized representation, the minimal requirement is: 1076 service::// 1078 "service" is the URL scheme used for denoting a service access point, 1079 (see [12] for the formal definition.) Other URLs besides service: 1080 scheme URLs may be transmitted in Service Location Messages. 1082 4.4. Authentication Blocks 1084 Authentication blocks are used to authenticate service registrations 1085 and deregistrations. URLs are registered along with an URL 1086 Authentication block to retain the authentication information in 1087 the URL entry for subsequent use by UAs who receive a Service Reply 1088 containing the URL entry. Service attributes are registered along 1089 with an Attribute Authentication block. Both authentication blocks 1090 have the format illustrated below. 1092 If a service registration is accompanied by authentication which can 1093 be validated by the DA, the DA MUST validate any subsequent service 1094 deregistrations, so that unauthorized entities cannot invalidate 1095 such registered services. Likewise, if a service registration 1096 is accompanied by an Attribute Authentication block which can be 1097 validated by the DA, the DA MUST validate any subsequent attribute 1098 registrations, so that unauthorized entities cannot invalidate such 1099 registered attributes. 1101 To avoid replay attacks which use previously validated 1102 deregistrations, the deregistration or attribute registration 1103 message must contain a timestamp for use by the DA. To avoid replay 1104 attacks which use previously validated registrations to nullify a 1105 valid deregistration, registrations must also contain a timestamp. 1107 A single Authentication Block is returned with an AttrRply and 1108 SrvRply. A SrvReg may include multiple authentication blocks if 1109 more the service is to be registered in more than one protected 1110 scope, or if more than one cryptographic algorithm is supported by 1111 the Service Location Protocol deployment. A DAAdvert will include 1112 one Authentication Block per protected scope that the DA supports. 1113 Unsolicited DAAdverts (see Section 12) will always be made in using 1114 the default cryptographic algorithm (see below). DAAdverts sent as a 1115 reply to a SrvRqst will include only one Authenticator Block. 1117 An authentication block has the following format: 1119 0 1 2 3 1120 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 1121 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1122 | Protected Scope String Length | Protected Scope String \ 1123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1124 | | 1125 + Timestamp + 1126 | | 1127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1128 | Block Structure Descriptor | Length | 1129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1130 \ Structured Authentication Block ... \ 1131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 Timestamp A 64-bit value formatted as specified by the Network 1134 Time Protocol (NTP) [15]. 1136 Block Structure Descriptor (BSD) 1137 A value describing the structure of the Authentication 1138 Block. The only value currently defined is 1, for 1139 Object-Identifier. 1141 Length The length of the Authentication Block 1143 Structured Authentication Block 1144 An algorithm specification, and the authentication data 1145 produced by the algorithm. 1147 The Structured Authentication Block contains a digital signature 1148 of the information being authenticated. It contains sufficient 1149 information to determine the algorithm to be used and the keys to be 1150 selected to verify the digital signature. 1152 The digital signature is computed over the following ordered stream 1153 of data: 1155 LIFETIME (2 bytes in network byte order) 1156 LENGTH OF URL (2 bytes in network byte order) 1157 URL (n bytes) 1158 TIMESTAMP (8 bytes in SNTP format [15]) 1159 LENGTH OF SCOPE STRING (2 bytes) 1160 SCOPE STRING (n bytes) 1162 When producing a URL Authentication block, the authentication 1163 data produced by the algorithm identified within the Structured 1164 Authentication Block calculated over the following ordered stream of 1165 data: 1167 LENGTH OF ATTRIBUTES (2 bytes in network byte order) 1168 ATTRIBUTES (n bytes) 1169 TIMESTAMP (8 bytes in SNTP format [15]) 1170 LENGTH OF SCOPE STRING (2 bytes) 1171 SCOPE STRING (n bytes) 1173 Every Service Location Protocol entity (UA, SA, or DA) which 1174 is configured for use with protected scopes MUST implement 1175 "md5WithRSAEncryption" [4] and be able to associate it with BSD value 1176 == 1. A conforming SLP implementation MAY implement other digital 1177 signature systems. 1179 In the case where BSD == 1 and OID == "md5WithRSAEncryption" is 1180 selected, the Structured Authentication Block will start with the 1181 ASN.1 Distinguished Encoding (DER) [8] for "md5WithRSAEncryption", 1182 which has the as its value the bytes (MSB first in hex): 1184 "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00" 1186 This is then immediately followed by an ASN.1 Distinguished Encoding 1187 (as a "Bitstring") of the RSA encryption (using the Scope's private 1188 key) of a bitstring consisting of the OID for "MD5" concatenated by 1189 the MD5 [18] message digest computed over the fields above. The 1190 exact construction of the MD5 OID and digest can be found in RFC 1191 1423 [4]. 1193 4.5. URL Entry Lifetime 1195 The Lifetime field is set to the number of seconds the reply can be 1196 cached by any agent. A value of 0 means the information must not be 1197 cached. UAs MAY cache service information, but if they do, they must 1198 provide a way for applications to flush this cached information and 1199 issue the request directly onto the network. 1201 Services should be registered with DAs with a Lifetime, the suggested 1202 value being CONFIG_LIFETIME. The service must be reregistered before 1203 this interval elapses, or the service advertisement will no longer 1204 be available. Thus, services which vanish and fail to deregister 1205 eventually become automatically deregistered. 1207 5. Service Location Protocol Requests 1209 SLP includes SrvRqst, AttrRqst and SrvTypeRqst messages. All UAs 1210 MUST be able to issue SrvRqst messages and SHOULD be able to issue 1211 AttrRqst and SrvTypeRqst messages. SAs issue only SrvRqst messages, 1212 and only for the purpose of DA discovery. 1214 SAs MUST be able to respond to SrvRqsts and SHOULD be able to respond 1215 to AttrRqsts and SrvTypeRqsts. 1217 UAs MUST use scoped DAs in preference to unscoped DAs and any DA 1218 in preference to multicasting to SAs. See Section 17.1 for rules 1219 concerning the use of scopes. 1221 Multicast and broadcast requests MUST set the 'R' bit in the header. 1222 This will ease implementation of combined DA and SA services by 1223 making it apparent whether an arriving datagram was unicast or 1224 multicast. Multicast (or broadcast) service requests MUST be ignored 1225 by DAs. 1227 Replies to SLP requests include a 2 byte error code. If the error 1228 code indicates failure the rest of the message SHOULD be omitted. 1229 The error codes which may be returned are: 1231 0 Success 1233 LANGUAGE_NOT_SUPPORTED 1234 A SA or DA returns this when a request is received 1235 from a UA which is in a language for which there is no 1236 registered Service Information which can satisfy it, or 1237 the request arrived with the Monolingual bit set and no 1238 registration is available in the specified language. See 1239 Section 18. Note: SrvTypeRqst messages do not contain a 1240 Language Tag, so they never elicit this error. 1242 PROTOCOL_PARSE_ERROR 1243 A SA or DA returns this error when a SrvRply is received 1244 which cannot be parsed or the declared string lengths 1245 overrun the message. 1247 SCOPE_NOT_SUPPORTED 1248 A DA will return this error if it receives a request 1249 which has a scope not supported by the DA. An SA will 1250 not return this error; it will simply not reply to the 1251 multicast request. 1253 6. Service Request Message Format 1255 The Service Request is used by UAs to obtain URLs from a DA or SAs. 1257 The format of the Service Request is as follows: 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Service Location header (function = SrvRqst) | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 |length of prev resp list string| Previous Responders Addr Spec \ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | length of | String \ 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | length of predicate string | Service Request \ 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 The is described in Sections 8 1272 and 20.1. 1274 See Section 17.1 for the interpretation of the scope-list field. 1276 The predicate allows the UA to request the Service Type and specific 1277 required attributes of a services in a specific language. The 1278 minimal form of a Service Request Predicate is shown below: 1280 "(service-type=" ["."] ")" 1282 Service Requests MAY include a scope term and a 'where clause'. The 1283 syntax of the query language is described in Section 6.4. The form 1284 of a Service Request is: 1286 "(&(service-type=" ["."] ")" ")" 1288 where: 1290 - The refers to the Service Type. For each type 1291 of service available, there is a unique Service type name 1292 string. This term MUST be part of every Service Request. See 1293 Section 20.1.1. 1295 - The is the Naming Authority. This term is OPTIONAL. See 1296 Section 20.1.1. 1298 - The string contains a set of query terms which will 1299 indicate those service instances which the User Agent is 1300 interested in. This clause includes attributes, boolean 1301 operators and relations. (See Section 6.3.) 1303 In order for a request to succeed in matching registered information, 1304 the following conditions must be met: 1306 1. The result must have the same Service Type as the request. 1308 2. It must have the same Naming Authority. 1310 3. It must satisfy the scoping rules for requests (see 1311 Section 17.1). 1313 4. The conditions specified in the Where Clause must match the 1314 attributes and keywords registered with the service. 1316 6.1. Service Request Usage 1318 The UA forms SrvRqsts using standard or conventionally known Service 1319 Type attributes. It MAY also issue AttrRqsts to obtain the attribute 1320 values for a Service Type before issuing SrvRqsts (see Section 11). 1321 Having obtained the attributes which describe a particular kind 1322 of service from an AttrRqsts, or using configured knowledge of a 1323 service's attributes, the UA can build a predicate that describes the 1324 service needs of the user. 1326 Suppose a printer supporting the lpr protocol is needed on the 12th 1327 floor which has UNRESTRICTED_ACCESS and prints 12 pages per minute. 1328 Suppose further that a Attribute Request indicates that there is a 1329 printer on the 12th floor, a printer that prints 12 pages per minute, 1330 and a printer that offers UNRESTRICTED_ACCESS. To check whether they 1331 are same printer, issue the following request: 1333 (& (SERVICE-TYPE=LPR)(PAGES PER MINUTE=12) 1334 (UNRESTRICTED_ACCESS=*) 1335 (LOCATION=12th FLOOR)) 1337 Suppose there is no such printer. The DA responds with a SrvRply 1338 with 0 in the number of responses and no reply values. A SA silently 1339 discards the request. 1341 The UA might then try a less restrictive query to find a printer, 1342 using only the 12th floor as "where" criteria. 1344 (&(SERVICE-TYPE=LPR)(LOCATION=12th FLOOR)) 1346 In this case, there might be the reply: 1348 Returned URL: service:lpr://igore.wco.ftp.com:515/draft 1350 The Address Specification for the printer is: igore.wco.ftp.com:515, 1351 containing the name of the host managing the requested printer. 1352 Files would be printed by spooling to that port on that host. The 1353 word 'draft' refers to the name of the print queue the lpr server 1354 supports. 1356 6.2. Directory Agent Discovery Request 1358 Normally a SrvRqst returns a Service Reply. The sole exception to 1359 this is a SrvRqst for the Service Type "directory-agent". This 1360 SrvRqst is answered with a DAAdvert. 1362 UAs and SAs which lack preconfigured or DHCP configured knowledge of 1363 a DA MUST multicast a Service Request to the DA Discovery Multicast 1364 Address. For the details of the multicast convergence algorithm see 1365 Section 21. The predicate included in this request is: 1367 (service-type=directory-agent) 1369 The in the DA discovery request may include only the 1370 string "*" in their . In this case, all DAs respond. 1372 If it includes any scope strings, only those DAs which support the 1373 indicated scope reply, or those which support unscoped requests. A 1374 DA discovery request which has the 'S' bit set in the message header 1375 will not get responses from unscoped DAs. 1377 Normally, a DA will not respond to multicast requests, nor will 1378 it respond to requests which are improperly scoped. This request 1379 is a special case, if a properly scoped DA Discovery request is 1380 received from the DA Discovery multicast group a DA MUST respond. If 1381 the request specifies a scope, the DA MUST NOT respond unless the 1382 scope request matches its scope. If a DA has no scope, it will only 1383 respond if there is no scope term or the request does not have the 1384 'S' bit set. 1386 DA Advertisement Replies may arrive from different sources, similar 1387 in form to: 1389 URL returned: service:directory-agent://slp-resolver.big.org 1390 Scope returned: NONE (ie. the length field is set to 0 for the 1391 scope string.) 1393 URL returned: service:directory-agent://204.182.15.66 1394 Scope returned: JANITORIAL SERVICES,ADMIN 1396 URL returned: service:directory-agent://204.182.15.66 1397 Scope returned: Legal Department ('S' bit set) 1399 The first DA supports only unscoped advertisements. The second 1400 supports advertisements which are unscoped, or are in the JANITORIAL 1401 SERVICES or ADMIN scope. The DA in the last example supports 1402 only the LEGAL DEPARTMENT scope, and explicitly NOT unscoped 1403 advertisements. 1405 The DA Advertisement format is defined in Section 12. 1407 If the goal is merely to discover any DA, the first DA Advert which 1408 is received will do. If the goal, however, is to discover all 1409 reachable DAs, the multicast convergence algorithm must be used, see 1410 Section 21. 1412 6.3. Explanation of Terms of Predicate Grammar 1414 A predicate has a simple structure, which depends on parentheses, 1415 commas and slashes to delimit the elements. Examples of proper usage 1416 are given throughout this document. 1418 The predicate uses the same syntax as a LDAP search filter [13]. 1419 This means that a SLP service request could be handled by a LDAP 1420 server. The reverse is not true: SLP uses a greatly simplified 1421 attribute typing system. Thus a SA or DA cannot interpret an 1422 arbitrary LDAP query. There are some restrictions and assumptions 1423 which are necessary in order to interpret SrvRqst predicates in the 1424 context of SLP. 1426 - A query for keywords uses a 'present' filter type. Thus, to 1427 query for services including the keyword 'X', the filter would be 1428 "X=*". 1430 - Degenerate queries such as "(&" ")" and "(|" 1431 ")" must be tolerated. They are equivalent to . 1433 - LDAPv2 defines several data types [14]. The only data types 1434 which are supported in SLP are String (equivalent to a Case 1435 Ignore String), Opaque (equivalent to a Case Exact String, since 1436 the binary values is encoded as a radix64 value). Integer and 1437 Boolean values are identically represented in SLP and LDAPv2. 1439 6.4. Service Request Predicates 1441 The Service Request Predicate follows the grammar of the LDAPv2 1442 string search filter [13]. 1444 The Predicate MUST contain a simple term which defines a service type 1445 for the query. It MAY contain a simple term which defines the scope 1446 for the query (see Section 17.1.) 1448 Restrictions which are not implied by the grammar are: 1450 - LDAPv2 string text filters [13] and string based attribute 1451 encodings [14] are all ASCII based. For UTF8 character encoding, 1452 which SLP supports, either the LDAPv3 filters (and UTF8) must 1453 be used or the production in RFC 1778, Section 2, must be 1454 expanded to include the entire range of allowed alphanumerics 1455 excluding those in the

(protected) rule. 1457 - filters, ``=~'', are interpreted as filters 1458 ``=''. For strings the filter MAY be implemented 1459 so that it returns true for the service with the 'greatest 1460 possible' match of the string sequence. For example: (x=~ABCD) 1461 applied to services S1 with x=AAAA, S2 with x=ABBBBB and S3 with 1462 x=ABCCCC would return S3 since it matches the longest sequence of 1463 characters in the request. 1465 - terms are always interpreted as string values and may 1466 only be used with filters, with the two exceptions 1468 - filters applied to ``*'' as the value will return true 1469 only for the item whose value is the MAXIMUM for the attribute. 1470 This only applies to an Integer attribute. Otherwise, it returns 1471 a PROTOCOL_PARSE_ERROR. 1473 - filters applied to ``*'' as the value will return 1474 true only for the item(s) whose value is the MINIMUM for 1475 the attribute. This only applies to an Integer attribute. 1476 Otherwise, it returns a PROTOTOL_PARSE_ERROR. 1478 The following are examples of query predicates in Service Requests. 1479 When the 'S' is present, it means that the 'S' bit is set in 1480 the message header. See Section 17.1 for how details on how the 1481 works. 1483 "(service-type=http)" = none 1484 This is a minimal request string. It matches all 1485 http services. 1487 "(service-type=lpr)" ="SALES" 1488 This request is for all lpr services either 1489 universally available or available in the SALES 1490 scope. 1492 "(service-type=lpr)" ="SALES", 'S' 1493 This request is for all lpr services which have 1494 been explicitly configured to reside within in 1495 the SALES scope. 1497 "(&(service-type=pop3)(user=wump))" ="ADMIN" 1498 This is a request for all pop3 services available 1499 in the ADMIN scope (or are unscoped) and which 1500 serve mail to the user 'wump'. 1502 "(&(service-type=backup)(qlength<=*))" ="BLDG 32", 'S' 1504 This returns the backup service which has 1505 the shortest queue-length. (This assumes that 1506 the queue length is an integer based attribute). 1507 It will return this only for services registered 1508 with the BLDG 32 scope (not unscoped services.) 1510 6.5. String Matching for Requests 1512 All strings are case insensitive, with respect to string matching 1513 on queries. All preceding or trailing blanks which are not escaped 1514 should not be considered for a match. White space (SPACE, CR, LF, 1515 TAB) internal to a string value is folded to a single SPACE character 1516 for the sake of string comparisons. 1518 For example, " Some String " matches "SOME STRING". 1520 String comparisons (using comparison operators such as '<' or 1521 '>=') are done using lexical ordering in the character set of the 1522 registration, not using any language specific rules. The ordering 1523 is strictly by the character value, i.e. "0" < "A" is true when the 1524 character set is US-ASCII, since "0" has the value of 48 and "A" has 1525 the value 65. 1527 The special character '*' may precede, follow or be internal to a 1528 string value in order to indicate substring matching. The query 1529 including this character matches any character sequence which 1530 conforms to the letters which are not wildcarded. 1532 Examples: 1534 "bob*" matches "bob", "bobcat", and "bob and sue" 1535 "*bob" matches "bob", "bigbob", and "sue and bob" 1536 "*bob*" matches "bob", "bobcat", "bigbob", and "a bob I know" 1537 "b*b" matches "bob" and "big dreams no grub" 1539 String matching is done after escape sequences have been substituted. 1540 See Sections 18, 6.3, 19. 1542 7. Service Reply Message Format 1544 The format of the Service Reply Message is: 1546 0 1 2 3 1547 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 1548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1549 | Service Location header (function = SrvRply) | 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Error Code | URL Entry count | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | \ 1554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1555 | ... \ 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 \ . . . \ 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | ... \ 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1562 Each Service Reply message is is sent in response to a Service 1563 Request message. The XID field in the Service Reply is copied from 1564 the XID field in the Service Request message. 1566 A successful Service Reply message is composed of a list of URL 1567 Entries, and an error code indicating the successful status of the 1568 request. If an error is encountered during the processing of the 1569 Service Request, the Error Code is set appropriately, according to 1570 the available errors in 25. If the error code indicates failure the 1571 rest of the message SHOULD be omitted. In addition to the errors 1572 listed in section 5, the EXPECTED_ATTRIBUTE_MISSING error may be 1573 returned. A DA or SA with access to the scheme definition for a 1574 service: URL [12] MAY return this error (along with the matching 1575 URLs) if the Service Request query does NOT contain a value for an 1576 "expected" attribute (i.e., an attribute marked with the 'X' flag in 1577 the scheme template). A SA will not return this error upon receiving 1578 a multicast request; it will silently discard the multicast request 1579 instead. 1581 Each in the list has the form defined in Section 4.3. 1582 If the presence of an URL Authentication block is signaled by the 1583 'U' bit, the length of the authentication block is determined by 1584 information within the block as discussed in Section 4.4. The URL 1585 Authentication block will include the authentication block calculated 1586 using the algorithm specified in the SrvRqst if possible. If not, 1587 the Authentication block calculated using the default algorithm is 1588 supplied. 1590 A UA MAY use the authentication block to determine whether the SA 1591 advertising the URL is, in fact, authorized to offer the indicated 1592 service. 1594 If, in a list of URL entries, some of the URLs indicate services 1595 which are in protected scopes (see Section 17.2) while other URLs in 1596 the list indicate services which are not in protected scopes, the 1597 latter must still have Authentication Blocks, but the length of the 1598 authentication block is shown as zero, and no authentication need be 1599 done. 1601 8. Service Type Request Message Format 1603 The Service Type Request is used to determine all the types of 1604 services supported on a network. 1606 The format of a Service Type Request is: 1608 0 1 2 3 1609 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 1610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 | Service Location header (function = SrvTypeRqst) | 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | length of prev resp string |\ 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | length of naming authority | \ 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | length of | String \ 1618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1620 The is a comma delimited list. See 1621 Section 20.1. 1623 The Naming Authority, if included, will limit the replies to Service 1624 Type Requests to Service Types which have the specified Naming 1625 Authority. If this field is omitted (i.e., the length field is 1626 zero), the default Naming Authority ("IANA") is assumed. If the 1627 length field is -1, service types from all naming authorities are 1628 requested. 1630 See Section 17.1 for the interpretation of the scope-list field. 1632 9. Service Type Reply Message Format 1634 The Service Type Reply has the following format: 1636 0 1 2 3 1637 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 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Service Location header (function = SrvTypeRply) | 1640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1641 | Error Code | number of service types | 1642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 | length of Service Type String | \ 1644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1645 \ . . . \ 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | length of Service Type String | \ 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1650 The service type's name is provided in the . If 1651 the service type has a naming authority other than "IANA" it MUST be 1652 returned following the service type string and a "." character. See 1653 Section 20.1.1 for the formal definition of this field. 1655 The following are examples of Service Type Strings which might be 1656 found in Service Type Replies: 1658 service:lpr: 1659 service:http: 1660 nfs: 1662 10. Attribute Request Message Format 1664 The Attribute Request is used to obtain attribute information. The 1665 UA supplies a request and the appropriate attribute information is 1666 returned. 1668 If the UA supplies only a Service Type, then the reply includes 1669 all attributes and all values for that Service Type. The reply 1670 includes only those attributes for which services exist and are 1671 advertised by the DA or SA which received the Attribute Request. 1672 Since different instances of a given service can, and very likely 1673 will, have different values for the attributes defined by the Service 1674 Type, the UA must form a union of all attributes returned by all 1675 service Agents. The Attribute information will be used to form 1676 Service Requests. 1678 If the UA supplies a URL, the reply will contain service information 1679 corresponding to that URL. 1681 Attribute Requests MAY include a 'select clause'. This limits the 1682 amount of information returned. If the select clause is empty, 1683 all information is returned. Otherwise, the UA supplies a comma 1684 delimited list of attribute tags and keywords. If the attribute 1685 or keyword is defined for a service, it will be returned in the 1686 Attribute Reply, along with all registered values for that attribute. 1687 If the attribute selected has not been registered for that URL or 1688 Service Type, the attribute or keyword information is simply not 1689 returned. 1691 The Attribute Request message has the following form: 1693 0 1 2 3 1694 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 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Service Location header (function = AttrRqst) | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 |length of prev resp list string|\ 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | length of URL | URL \ 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | length of | string \ 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 |length of string | string \ 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 The functions exactly as introduced 1708 in Section 8. See also Section 20.1. 1710 The URL field can take two forms: Either it is simply a Service 1711 Type (see Section 20.1.1), such as "service:http:" or "nfs:". All 1712 attributes and the full range of values for each attribute of all 1713 services of the given Service Type is returned. 1715 The URL field may also be a full URL, such as 1716 "service:lpr://igore.wco.ftp.com:515/draft" or "ftp://max.net/znoo". 1717 In this, only the attributes for the service of the specified URL is 1718 defined are returned. 1720 See Section 17.1 for the interpretation of the scope-list field. 1722 The select list takes the form of a , see 20. The 1723 items on the list are attribute tags or keywords, which can be either 1724 complete tags or include '*' characters for wildcard string matching. 1726 An example of a select-list following the printer example is: 1728 "PAGES PER MINUTE,UNRESTRICTED_ACCESS,LOCATION" 1730 11. Attribute Reply Message Format 1732 An Attribute Reply Message takes the form: 1734 0 1 2 3 1735 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 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | Service Location header (function = AttrRply) | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | Error Code | length of string \ 1740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1741 \ \ 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 \ Attribute Authentication Block (if any) \ 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1746 The (attribute list) has the same form as the attribute 1747 list in a Service Registration, see Section 20.2 for a formal 1748 definition of this field. 1750 If the AttrRqst included a Service Type in the URL field, all 1751 attribute results must be coallated. For example, a SA receives 1752 an AttrRqst and there are three services of the specified type 1753 (in the requested scope, etc.). The first service supports the 1754 attribute "(A=1,2)", the second service, "(A=3,4)" and the third, 1755 "(A=5,6)". The SA returns the attribute "A" in the AttrRply as 1756 "(A=5,2,3,1,4,6)". (Note that the SA does not need to sort the 1757 return values in any way.) 1759 An Attribute Request for "lpr:" might elicit the following reply 1760 (UNRESTRICTED_ACCESS is a keyword): 1762 (PAPER COLOR=WHITE,BLUE), 1763 (PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED), 1764 UNRESTRICTED_ACCESS, 1765 (PAGES PER MINUTE=1,3,12), 1766 (LOCATION=12th, NEAR ARUNA'S OFFICE), 1767 (QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD) 1769 If the message header has the 'A' bit set, the Attribute Reply will 1770 have an Attribute Authentication block set. In this case, the 1771 Attribute Authentication Block must be returned with the entire list 1772 of attributes, exactly as it was registered by an SA in a protected 1773 scope. In this case, the URL was registered in a protected scope 1774 and the UA included a URL but not a select clause. If the AttrRqst 1775 specifies that only certain attributes are to be returned, the DA 1776 does not (typically cannot) compute a new Authentication so it simply 1777 returns the attributes without an authentication block. 1779 The SA or DA returns the Attribute Authentication block. A UA 1780 which wishes to obtain authenticated attributes for a service in a 1781 protected scope MUST therefore must include a particular URL and no 1782 select list with the AttrRqst. 1784 12. Directory Agent Advertisement Message Format 1786 DA Advertisement Messages have the following format: 1788 0 1 2 3 1789 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 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Service Location header (function = DAAdvert) | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | Error Code | DAAdvert Sequence Number | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | Length of URL | URL \ 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Length of | \ 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | Number of Auth Blocks | authentication block 1 ... \ 1800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1801 \ autentication block 1 (continued) ... \ 1802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1803 \ ... \ 1804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 \ autentication block N (continued) ... \ 1806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 The Error Code is set when a DA Advertisement is returned as the 1809 result of a Service Request, as specified in Section 5. The Error 1810 Code will always be set to 0 in the case of an unsolicited DA 1811 Advertisement. 1813 The DAAdvert Sequence Number is 0 when the DA comes up initially 1814 and increases by one each time the DAAdvert is sent unsolicited. 1815 DAs which store service advertisements in a nonvolatile store will 1816 set their initial sequence number to 256. The sequence number will 1817 be used by SAs to determine if they must reregister services when 1818 a DA is discovered. See Section 16.1 which describes unsolicited 1819 DAAdverts and how SAs respond to them. 1821 The URL corresponds to the DA's location. 1823 There MUST be at least one authentication block for each protected 1824 scope. There MAY be more than one authentication block for each 1825 protected scope if more than one authentication algorithm (identified 1826 by the BSD field) is used. 1828 See Section 17.1 for the definition of the . 1830 If the 'U' bit in the SLP header is set, an authentication block 1831 is included to allow the SA and UA to ascertain whether the DA 1832 Advertisement is valid. See 4.4. See Section 6.4 for the lexical 1833 rules regarding . 1835 DA Advertisements sent in reply to a Directory Agent Discovery 1836 Request has the same format as the unsolicited DA Advertisement, for 1837 example: 1839 URL: service:directory-agent://SLP-RESOLVER.CATCH22.COM 1840 SCOPE List: ADMIN 1842 The DA can be reached at the Address Specification returned, and 1843 supports the SCOPE called "ADMIN". 1845 13. Service Registration Message Format 1847 After a SA has found a DA, due to either active DA Discovery (see 1848 Section 21.1) or passive DA Discovery (see Section 21.2) it begins 1849 to register its advertised services one at a time. A SA must wait 1850 for some random time uniformly distributed within the range specified 1851 by CONFIG_REG_ACTIVE seconds before registering again. Registration 1852 is done using the Service Registration message specifying all 1853 attributes for a service. If the service registration in a protected 1854 scope 17.2, then the service MUST include both a URL Authentication 1855 block and an Attribute Authentication block (see Section 4.4). In 1856 that case, the service agent MUST set both the 'U' bit and the 'A' 1857 bit (see Section 4). 1859 A DA must acknowledge each service registration request. If 1860 authentication blocks are included, the DA MUST verify the 1861 authentication before registering the service. This requires 1862 obtaining key information, either by preconfiguration, maintenance 1863 of a security association with the service agent, or acquiring the 1864 appropriate certificate. 1866 The format of a Service Registration is: 1868 0 1 2 3 1869 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 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1871 | Service Location header (function = SrvReg) | 1872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 \ \ 1874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1875 | Length of | String \ 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Length of Attr List String | \ 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 \ (if present) Attribute Authentication Block ... \ 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1882 The is defined at the end of Section 4.3. The 1883 is defined in Section 20.2. The Attribute Authentication 1884 Block, which is only present if the 'A' bit is set in the message 1885 header, is defined in Section 4.4. 1887 The is defined in Section 17.1. 1889 Service registration may use a connectionless protocol (e.g. UDP), 1890 or a connection oriented protocol (e.g. TCP). If the registration 1891 operation may contain more information than can be sent in one 1892 datagram, the SA MUST use a connection oriented protocol to register 1893 itself with the DA. 1895 When a SA registers the same attribute class more than once for a 1896 service instance, the DA overwrites the all the values associated 1897 with that attribute class for that service instance. Separate 1898 registrations must be made for each language that the service is to 1899 be advertised in. 1901 If a SA attempts to register a service with a DA and the registration 1902 is larger than the site path MTU, then the DA will reply with a 1903 SrvAck, with the error set to INVALID_REGISTRATION and the 'Overflow' 1904 byte set. 1906 An example of Service Registration information is: 1908 Lifetime (seconds): 16-bit unsigned integer 1909 URL (at least): service::// 1910 scope-list: omitted (ie. no items, 0 bytes) 1911 Attributes (if any): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2) 1913 In order to offer continuously advertised services, SAs should start 1914 the reregistration process before the Lifetime they used in the 1915 registration expires. 1917 An example of a service registration (valid for 3 hours) is as 1918 follows: 1920 Lifetime: 10800 1921 URL: service:lpr://igore.wco.ftp.com:515/draft 1922 scope-list: DEVELOPMENT 1923 Attributes: (PAPER COLOR=WHITE), 1924 (PAPER SIZE=LETTER), 1925 UNRESTRICTED_ACCESS, 1926 (LANGUAGE=POSTSCRIPT, HPGCL), 1927 (LOCATION=12 FLOOR) 1929 The same registration could be done again, as shown below, in German; 1930 however, note that "lpr" and "service" are reserved terms and will 1931 remain in the language they were originally registered (English). 1933 Lifetime: 10800 1934 URL: service:lpr://igore.wco.ftp.com:515/draft 1935 scope-list: ENTWICKLUNG 1936 Attributes: (PAPIERFARBE=WEISS), 1937 (PAPIERFORMAT=BRIEF), 1938 UNBEGRENTZTER_ZUGANG, 1939 (DRUECKERSPRACHE=POSTSCRIPT,HPGCL), 1940 (STANDORT=11 ETAGE) 1942 Scoped registrations must contain the SCOPE attribute. Unscoped 1943 registrations must be registered with all unscoped DAs. 1945 Registrations of a previously registered service are considered 1946 an update. If such an attribute registration is performed in a 1947 protected scope (see Section 17.2), a new Attribute Authentication 1948 block must also be included, and the 'A' bit set in the registration 1949 message header. 1951 The new registration's attributes replace the previous 1952 registration's, but do not effect attributes which were 1953 included previously and are not present in the update. 1955 For example, suppose service:x://a.org has been registered 1956 with attributes A=1, B=2, C=3. If a new registration comes for 1957 service:x://a.org with attributes C=30, D=40, then the attributes for 1958 the service after the update are A=1, B=2, C=30, D=40. 1960 In the example above, the SCOPE is set to DEVELOPMENT (in English) 1961 and ENTWICKLUNG (in German). Recall that all strings in a message 1962 must be in one language, which is specified in the header. The 1963 string SCOPE is *not* translated, as it is one of the reserved 1964 strings in the Service Location Protocol (see Section 19.1.) 1966 The DA may return a server error in the acknowledgment. This error 1967 is carried in the Error Codes field of the service location message 1968 header. The SrvReg may result in the error codes described in 1969 Section 14. 1971 There are various rules concerning scopes: Which DAs a SA MUST 1972 register with and which DAs accept which registrations. See 1973 Section 17.1. 1975 When the URL entry accompanying a registration also contains an 1976 authentication block (Section 4.4), the DA MUST perform the indicated 1977 authentication, and subsequently indicate the results in the Service 1978 Acknowledgement message. 1980 14. Service Acknowledgement Message Format 1982 A Service Acknowledgement is sent as the result of a DA receiving 1983 and processing a Service Registration or Service Deregistration. An 1984 acknowledgment indicating success must have the error code set to 1985 zero. Once a DA acknowledges a service registration it makes the 1986 information available to clients. 1988 0 1 2 3 1989 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 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Service Location header (function = SrvAck) | 1992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1993 | Error Code | 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1996 The Error Code may have one of the following values: 1998 0 Success 2000 PROTOCOL_PARSE_ERROR 2001 A DA returns this error when the SrvReg or SrvDeReg is 2002 received which cannot be parsed or the declared string 2003 lengths overrun the message. 2005 INVALID_REGISTRATION 2006 A DA returns this error when a SrvReg or SrvDeReg is 2007 invalid. For instance, an invalid URL, unknown or 2008 malformed attributes, or deregistering an unregistered 2009 service all cause this error to be reported. 2011 SCOPE_NOT_SUPPORTED 2012 A DA which is configured to have a scope will return this 2013 error if it receives a SrvRqst which is set to have a 2014 scope which it does not support. 2016 AUTHENTICATION_ABSENT 2017 If DA has been configured to require an authentication 2018 for any service registered in the requested scope, and 2019 there are no authentication blocks in the registration, 2020 the DA will return this error. 2022 AUTHENTICATION_FAILED 2023 If the registration contains an authentication block 2024 which fails to match the correct result as calculated 2025 (see Section 4.4) over the URL or attribute data to be 2026 authenticated, the DA will return this error. 2028 INTERNAL_ERROR 2029 A DA will return this if it cannot satisfy a request due 2030 to an internal failure. This might occur, for example, 2031 if the DA could not allocate sufficient resources. The 2032 SA MUST assume its request was not satisfied. 2034 If the DA accepts a Service Registration, and already has an 2035 existing entry, it updates the existing entry with the new lifetime 2036 information and possibly new attributes and new attribute values. 2037 Otherwise, if the registration is acceptable (including all necessary 2038 authentication checks) the DA creates a new entry, and sets the 'F' 2039 bit in the Service Acknowledgement returned to the SA. 2041 15. Service Deregister Message Format 2043 When a service is no longer available for use, the SA must deregister 2044 itself from DAs that it has been registered with. A service uses the 2045 following PDU to deregister itself from all scopes the service was 2046 registered in. 2048 0 1 2 3 2049 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 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2051 | Service Location header (function = SrvDeReg) | 2052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2053 | length of URL | URL \ 2054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2055 \ (if present) authentication block ..... \ 2056 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2057 | length of string | \ 2058 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2060 The SA should retry this operation if there is no response from the 2061 DA. The DA acknowledges this operation with a Service Acknowledgment 2062 message. Once the Service Agent receives an acknowledgment 2063 indicating success, it can assume that the service is no longer 2064 advertised by the DA. The Error Code in the Acknowledgment of the 2065 Service Deregistration may have the same values as described in 2066 Section 14. 2068 The Service Deregister Information sent to the directory agent has 2069 the following form: 2071 service::// 2072 Attribute tags (if any): ATTR1,KEYWORD,ATTR2 2074 This will deregister the specified attributes from the service 2075 information from the directory agent. If the Language Tag is omitted 2076 or no attribute tags are included, the entire service information is 2077 deregistered in every language and every scope it was registered in. 2078 To deregister the printer from the preceding example, use: 2080 service:lpr://igore.wco.ftp.com:515/draft 2082 If the service was originally registered with a URL entry containing 2083 a URL authentication block, then the Service Deregistration 2084 message header MUST have the 'U' bit set, and the URL entry is then 2085 followed by the authentication block, with the authentication block 2086 calculated over the URL data, the timestamp, and the length of the 2087 authentication as explained in Section 4.4. In this calculation, the 2088 lifetime of the URL data is considered to be zero, no matter what the 2089 current value for the remaining lifetime of the registered URL. 2091 16. Directory Agents 2093 16.1. Finding Directory Agents 2095 A UA or SA may be statically configured to use a particular DA. This 2096 is discouraged unless the application resides on a network where any 2097 form of multicast or broadcast is impossible. 2099 Alternatively, a host which uses DHCP [11, 1] may use it to obtain 2100 a DA's address. DHCP options 78 and 79 have been assigned for this 2101 purpose [17]. SLP Agents SHOULD be configurable using DHCP. 2103 The third way to discover DAs is dynamically. This is done by 2104 sending out a Directory Agent Discovery request (see Section 6.2). 2106 Lastly, the agent may be informed passively as follows: 2108 When a DA first comes on-line, and periodically, it sends an 2109 unsolicited DA Advertisement to the Service Location general 2110 multicast address. See Section 21 for details. If a DA supports a 2111 particular scope or set of scopes these are placed in its DAAdvert. 2113 When a SA or UA first comes on-line it must issue a Directory Agent 2114 Discovery Request unless it is using static or DHCP configuration, as 2115 described in 6.2. 2117 A SA registers information with ALL newly discovered DAs when either 2118 of the above two events take place. 2120 Once a UA becomes aware of a DA it will unicast its queries there. 2121 In the event that more than one DA is detected, it will select one to 2122 communicate with. 2124 The protocol will cause all DAs (of the same scope) to eventually 2125 obtain consistent information. Thus one DA should be as good as any 2126 other for obtaining service information. There may be temporary 2127 inconsistencies between DAs. 2129 17. Scope Discovery and Use 2131 The scope mechanism in the Service Location Protocol enhances its 2132 scalability. The primary use of scopes is to provide the capability 2133 to organize a site network along administrative lines. A set of 2134 services can be assigned to a given department of an organization, 2135 to a certain building or geographical area or for a certain purpose. 2136 The users in a department can be configured to request services from 2137 a particular scope. A scope is not an attribute of the service 2138 instance, because it is completely independent of the characteristics 2139 of the service instance. 2141 Services in a scope effectively offer their service only to users 2142 that indicate that particular scope in their user requests. Just 2143 as sets can be non-disjoint, services can belong to several scopes. 2144 Users, on the other hand, are not viewed as belonging to particular 2145 scopes, but instead as having access to services in one or more 2146 scopes. This access can be acquired in several ways, as further 2147 detailed below. 2149 Services that do not belong to any scope effectively offer their 2150 service to any user agent. Since a user agent selects its desired 2151 service by specifying the desired attributes of that service, any 2152 service satisfying those attributes will satisfy the needs of the 2153 user agent. Thus, a user agent typically does not care about which 2154 service agent provides the needed service. Cases in which this is 2155 not true require the user agent to specify that only services from 2156 the specific scope are desired, but such cases always arise from 2157 administrative considerations, and not from the specific values 2158 assigned to service attributes. The 'S' bit is supplied by user 2159 agents requiring the exclusion of services not assigned to the 2160 specific requested scope or scopes. 2162 A site network that has grown beyond a size that can be reasonably 2163 serviced by a few DAs can use the scope mechanism. DAs may be 2164 configured with a scope list, representing the administrative 2165 categories which they serve. The semantics and language of the 2166 strings used to describe the scope are almost entirely the choice of 2167 the administrative entity of the particular domain in which these 2168 scopes exist. The values of SCOPE should be configurable, so the 2169 system administration Block can set its value. The scopes "LOCAL" 2170 and "REMOTE" are reserved and SHOULD NOT be used. Use of these 2171 reserved values is to be defined in a future protocol document. 2173 DAs advertise their available scopes, together with a 2174 "service:directory-agent:" URL indicating its location. 2175 These advertisements are sent periodically starting as soon as the 2176 DA first becomes available. The UA and SA may also solicit these DA 2177 advertisements when they first come on line. Thus, UAs and SAs are 2178 consistently informed of available scopes provided by scoped DAs. 2180 UAs may select or be configured with one or more scopes to use. This 2181 selection may be automated through the use of DHCP or it may be done 2182 by the individual client application or service programmatically. 2183 UAs send all requests to DAs which support the scope or scopes they 2184 select. A SA is configured with a scope (or scopes) in which to 2185 register. It MUST register with all DAs in that scope that it can 2186 discover. Failure to be comprehensive in registration according 2187 to this rule may mean that the service advertisement may not be 2188 available to all UAs. 2190 17.1. Rules Governing Scopes 2192 For the sake of illustration, imagine that a service is a candy M&M, 2193 and that scopes divide the candy up into sets all containing the same 2194 color. Users want candy, but some users are more particular than 2195 others, and some users are constrained by their administration to 2196 only eat candy of a particular color. 2198 Rules for User Agents, for various combinations of settings of the 2199 'S' bit, and contents of the : 2201 <'S'=on, scope-list=""> I want colorless M&Ms. 2203 <'S'=on, scope-list="green"> I want green M&Ms. 2205 <'S'=off, scope-list="green"> I want green M&Ms, or else 2206 colorless M&Ms. 2208 <'S'=off, scope-list=""> I want colorless M&Ms. 2210 Rules for Service Agents, for various combinations of settings of the 2211 'S' bit, and contents of the : 2213 <'S'=on, scope-list=""> I am a colorless M&M. 2215 <'S'=on, scope-list="green"> I am a green M&M, and always appear 2216 colorful. 2218 <'S'=off, scope-list="green"> I am a green M&M, but I'm happy to 2219 appear colorless. 2221 <'S'=off, scope-list=""> I am a colorless M&M. 2223 Rules for Directory Agents, for various combinations of settings of 2224 the 'S' bit, and contents of the : 2226 <'S'=on, scope-list=""> I am a jar for colorless M&Ms. 2228 <'S'=on, scope-list="green"> I am a jar for green M&Ms only. 2230 <'S'=off, scope-list="green"> I am a jar for green M&Ms, but I'm 2231 happy to accept colorless. 2233 <'S'=off, scope-list=""> I am a jar for colorless M&Ms. 2235 The intention motivating this algorithm for satisfying scoped service 2236 requests is to allow a smooth transition between administration of 2237 unscoped service domains into scoped service domains. Notice that if 2238 a DA is installed and configured to offer scoped service, that user 2239 agents sending requests to that DA will typically be able to find 2240 the existing unscoped services until the services are configured for 2241 scope membership. This should enable system administrators to become 2242 more familiar with the scope model without the need for "flag days" 2243 or discontinuous changeovers of services. 2245 If it is intended that all user agents be configured to request 2246 services from particular scopes, then while the user agents receive 2247 the necessary scope configuration information they will work as 2248 before in the unscoped administration until the time finally arrives 2249 when all user agents are configured with scopes. After that time, 2250 all service agents can be configured to register their services with 2251 the 'S' bit set, and the user agents will all continue to work as 2252 before. 2254 17.1.1. Scope Strings in SLP Messages 2256 Scope strings are found in several service location messages. The 2257 takes the form of a (see Section 20) of 2258 scope names. The only characters which are reserved in scope strings 2259 are commas ',', asterisk '*' and the backslash character '\'. 2261 If this scope list is omitted, the message is said to be 'not 2262 scoped'. 2264 will explicitly exclude unscoped requests, as will be explained 2265 below. The scope list may include '*' when multicasting requests to 2266 SAs, which specifies that scopes will be ignored for the purposes 2267 of handling the request. The list may also include any other valid 2268 scope string. 2270 17.1.2. Registration 2272 Services which are registered with a non-null scope list are 2273 considered 'scoped'. A service registration which has no scope 2274 string is considered unscoped. That means it will be registered with 2275 all DAs which do not explicitly refuse unscoped registrations. A DA 2276 does this by setting the 'S' bit in its DAAdvert. 2278 A DA may be configured to be unscoped or scoped. An unscoped DA 2279 accepts only unscoped registrations. SAs MUST register all unscoped 2280 services with an unscoped DA. By default, a scoped DA will accept 2281 unscoped registrations. A DA MUST be configurable to deny unscoped 2282 registrations. 2284 Scopes determine which requests a DA will accept. A DA MUST decline 2285 to register a service if it is specified with an unsupported scope. 2286 In this case a SCOPE_NOT_SUPPORTED error is returned in the SrvAck. 2287 SAs MUST register scoped services with every DA they are aware of, 2288 that supports the service's scopes. 2290 DAs return a SrvAck in response to a SrvReg or SrvDeReg as defined in 2291 Section 13 and 15. 2293 SA registration with DAs occurs with built in delays, depending 2294 on whether the DA was discovered actively (see Section 21.1) or 2295 passively (see Section 21.2). 2297 17.1.3. Query Handling 2299 In every case, the rules specified in Section 17.1 apply. 2301 UAs MUST use scoped DAs in preference to unscoped DAs, and unscoped 2302 DAs in preference to multicasting requests to SAs. UAs MUST use 2303 scoped requests when making requests of scoped DAs. UAs SHOULD use 2304 requests with no scope when multicasting requests to SAs. UAs MUST 2305 use requests with no scope when sending a request to an unscoped DA. 2307 17.1.3.1. DA Query Handling 2309 An unscoped DA accepts only unscoped requests. It will send the 2310 corresponding reply with a SCOPE_NOT_SUPPORTED error if a scoped 2311 service registration is received. 2313 A scoped DA MUST accept only requests which have the scope of the DA 2314 or where the request is unscoped (ie. the is omitted). 2315 The DA will respond with information which matches the request in 2316 the scope of the request AND unscoped service information. If the 2317 request has the 'S' bit set in the message header, the DA will 2318 respond only with scoped service information. 2320 If a scoped DA receives a request which does not include a supported 2321 scope in its , or includes the string "*" the DA replies 2322 with a SCOPE_NOT_SUPPORTED error in the reply corresponding to the 2323 request. This rule does not apply DA Discovery requests, which are 2324 described in Section 6.2. 2326 DAs will return a reply with 0 results if they support the request 2327 (ie. do not return an error) and they have no matches to the 2328 request. 2330 17.1.3.2. SA Query Handling 2332 SAs apply the same rules for matching requests except that if there 2333 is no match they will drop the request if there are no matches. They 2334 will never reply with a SCOPE_NOT_SUPPORTED error. 2336 SAs which receive a request where the is set to the 2337 string "*" does not apply scope matching rules to the request. 2338 This may mean that a SrvRply or AttrRply will not include digital 2339 signatures for services which registered in a protected scope. In 2340 order to receive these digital signatures in the reply, the UA MUST 2341 specify the protected scope explicitely in the Service Request. 2342 See 17.2. 2344 17.2. Protected Scopes 2346 Scope membership MAY also define the security access and 2347 authorization for services in the scope; such scopes are called 2348 protected scopes. If a UA wishes to be sure that SAs are authorized 2349 to provide the service they advertise, then the UA should request 2350 services from a protected scope which has been configured to have the 2351 necessary authentication mechanism and keys distributed to the SAs 2352 within the scope. A directory agent distributing URLs for services 2353 in a protected scope will reject any registrations or deregistrations 2354 for service agents which cannot provide cryptographically strong 2355 authentication to prove their authorization to provide the services. 2357 For instance, if a campus registrar wishes to find a working printer 2358 to produce student grade information for mailing, the registrar would 2359 require the printing user agent to transmit the printable output only 2360 to those printing SAs which have been registered in the appropriate 2361 protected scope. Notice that each service agent is, under normal 2362 circumstances, validated two times: once when registering with 2363 the directory agent, and once when the user agent validates the 2364 URL received with the Service Reply. This protects against the 2365 possibilities of malicious DAs as well as malicious SAs. 2367 Note that services in protected scopes provide separate 2368 authentication for their URL entry, and for their attributes. This 2369 is so that the URLs in SrvRply message can be authenticated (see 2370 Section 7). This is the common case. In interactive mode, a user 2371 may wish to obtain the set of all attributes a service supports using 2372 an AttrRqst. The AttrRply for this request, made in a protected 2373 scope, will include a digital signature over the attributes (see 2374 Section 11). 2376 17.2.1. Protected Scope Rules 2378 Protected Scopes make use of structured Authenticator Blocks. These 2379 are described in Section 4.4. 2381 DAs and SAs are configured for use in a protected scope by 2382 configuring them with the Public and Private keys of the protected 2383 scope. UAs are configured for use in a protected scope by 2384 configuring them with the Public key of the protected scope. See 2385 Section22. 2387 - SAs which have been configured with a protected scope MUST 2388 include Authentication Blocks with all SrvReg and SrvDeReg 2389 messages sent to DAs. 2391 - SAs which have been configured with a protected scope MUST 2392 include URL Authentication Blocks in SrvRply messages and 2393 Attribute Authentication Blocks in AttrRply messages if the 2394 corresponding SrvRqst or AttrRqst included the protected scope 2395 explicitely in the in the request. 2397 - SAs must reject DAAdverts they receive for a protected scope 2398 which do not contain an Authenticator Block which the SA can 2399 verify. 2401 - DAs which have been configured with a protected scope must 2402 verify the signatures of SrvReg and SrvDeReg messages from 2403 SAs. The DA returns a SrvAck reply. If the signature fails, 2404 the DA returns an AUTHENTICATION_FAILED error. If the BSD of 2405 the Authentication Block is not supported by the DA, the DA 2406 returns an AUTHENTICATION_ALGO_UNKNOWN error. If the SA fails 2407 to include an authenticator where it should, the DA returns an 2408 AUTHENTICATION_ABSENT error. 2410 - DAs which have been configured with a Public Key for a protected 2411 scope MUST include URL Authentication Blocks in SrvRply messages 2412 and Attribute Authentication Blocks in AttrRply messages. They 2413 must also include Authentication Blocks in their DAAdvert 2414 messages (see Section 12.) 2416 - If the UA is configured with a protected scope, and if the UA 2417 receives a SrvRply, AttrRply or DAAdvert from that protected 2418 scope, the UA MUST verify the reply or advertisement before 2419 accepting it. 2421 18. Language Internationalization Issues 2423 18.1. Language Tags and Dialects 2425 Service location messages often include a Language Tag in the header. 2426 A SrvDeReg message MAY omit a Language Tag if the service is to be 2427 deregistered in ALL languages it has been registered in. If the 2428 Language Tag is omitted, the Language Tag length in the header is set 2429 to 0. 2431 If the Language Tag used includes a dialect, the dialect is to be 2432 used the following way: Requests which can be fulfilled by matching 2433 a language and dialect will be preferred to those which match only 2434 the language portion. Otherwise, dialects have no effect on matching 2435 requests. 2437 18.2. Scope Strings are not Language Specific 2439 A scope string, which is used to configure DAs and which are used 2440 by both UAs and SAs for various operations (see Section 17.1) is 2441 NOT language specific. Thus, the language declared in a SrvRqst 2442 used for DA discovery has no effect on whether the request predicate 2443 matches the scopes of the DA or not. The DAAdvert does not include a 2444 Language Tag as the scope strings are not language specific. 2446 18.3. Declaring the language of registrations 2448 All Service Registrations declare the language in which the strings 2449 in the service attributes are written by specifying a Language Tag 2450 in the message header. For each language the Service advertises a 2451 separate registration takes place. Each of these registrations uses 2452 the same URL to indicate that they refer to the same service. 2454 A Service is fully deregistered if the URL is given in the Service 2455 Deregister message without any attribute information or Language Tag 2456 sent in the message. 2458 If, on the other hand, attribute information is included in the 2459 Service Deregistration request, a separate Service Deregistration 2460 of selected attributes must be undertaken in each language in which 2461 service information has been provided to the DA by a SA. 2463 Service Registrations in different languages are mutually 2464 unintelligible. They share no information except for their service 2465 type and URL with which they were registered. No attempt is made 2466 to match queries with "language independence." Instead, queries are 2467 handled using string matching against registrations in the same 2468 language as the query. 2470 18.4. Translation of Attribute Strings 2472 Service Types which are standardized will have definitions for 2473 all attributes and value strings. Official translations to other 2474 languages of the attribute tags and values may be created and 2475 submitted as part of the standard; this is not feasible for all 2476 languages. For those languages which are not defined as part of the 2477 Service Type, a best effort translation of the standard definitions 2478 of the Service type's attribute strings MAY be used. 2480 18.5. Declaring the language of a Request 2482 Service and Attribute requests specify a requested language in the 2483 message header. The DA or SA will respond in the same language as 2484 the request, if it has a registration in the same language as the 2485 request. 2487 If this language is not supported, and the Monolingual bit is not 2488 specified, a reply MAY be sent in the default language (which is 2489 English) on a best effort basis. 2491 In the case where there are services registered in the type 2492 requested in a SrvRqst (or AttrRqst), but not in a language 2493 which the service information supplies, the following two rules 2494 apply: If the 'monolingual bit' flag in the header is set, a 2495 SrvRply (or AttrRply) is returned with the error field set to 2496 LANGUAGE_NOT_SUPPORTED. A SrvRqst may include a predicate (or an 2497 AttrRqst may contain a tag list) in an unsupported language. If any 2498 of the attribute strings are not language literal (see Section 19.1), 2499 the SrvRply (or AttrRply) is returned with the error field set to 2500 LANGUAGE_NOT_SUPPORTED. 2502 If a query is in a supported language on a SA or DA, but has a 2503 different dialect than the available service information, the query 2504 MUST be serviced on a best-effort basis. If possible, the query 2505 should be matched against the same dialect. If that is not possible, 2506 it MAY be matched against any dialect of the same language. 2508 When there are several replies returned in one message and the reply 2509 includes attributes which were registered with separate dialects, the 2510 dialect portion of the Language Tag in the reply is dropped. This 2511 could occurs primarily with an attribute reply. 2513 19. Substitution of Character Escape Sequences 2515 Certain characters are illegal in certain contexts of the protocol. 2516 Since the protocol is largely character string based, in some 2517 contexts characters are used as protocol delimiters. In these cases 2518 the delimiting characters must not be used as 'data text.' 2520 Characters which are reserved as part of the encoding of attribute 2521 tags or values MUST be escaped if they are included in Attribute 2522 Lists or Predicates. Any character in these strings MAY be escaped. 2524 The escape mechanism uses the reserved backslash character '\' (ASCII 2525 0x5c). This character is followed by two hexadecimal digits of the 2526 escaped character. Note that some characters are multibyte, using 2527 UTF8 encoding. 2529 Examples: 2531 Character to encode Unicode UTF8 SLP Escaped value 2532 ------------------- ------- --------- ----------------- 2533 ',' 0x0029 0x0029 \29 2534 e accent aigue 0x0039 0xc3a9 \c3\a9 2535 not equals glyph 0x2260 0xe289a0 \e2\89\a0 2537 Characters in URLs which are reserved according to the URL syntax 2538 specification must be escaped using the URL escape character 2539 convention. In this case a 'percent' is followed by the hex encoding 2540 of the escaped character exactly as defined above for the 'slash' 2541 character. The current URL syntax specification limits all encoded 2542 characters to a subset of the ASCII character set. The update to 2543 this defines a way to transmit UTF8 encoded characters outside of the 2544 ASCII range. 2546 19.1. Language-Independent Strings 2548 Some strings, such as Service Type names, have standard definitions. 2549 These reserved strings should be considered as tokens and not as 2550 words in a language to be translated. They are case-independent. 2552 Reserved String Section xDefinition 2553 --------------- ------- -------------------------------------- 2554 SCOPE 3, 16 Used to limit the matching of requests. 2555 SERVICE 7, 13 The URL scheme of all Service Location 2556 information registered with a DA or 2557 returned from a Service Request. 2558 20.1.1 Used in all service registrations 2559 and replies. 2560 domain names 20.3 A fully qualified domain name, used 2561 in registrations and replies. 2562 IANA 3.7 The default naming authority. 2563 LOCAL 17 Reserved. 2564 REMOTE 17 Reserved. 2565 TRUE 20.4 Boolean true. 2566 FALSE 20.4 Boolean false. 2567 SERVICE-TYPE 6 Standard term in predicates. 2569 20. String Formats used with Service Location Messages 2571 The following section supplies formal definitions for fields and 2572 protocol elements introduced in the sections indicated. 2574 Protocol Element Defined in Used in 2575 ----------------------------------- ------------ ------------ 2576 20.1 SrvRqst 2577 Service Request 6.4 SrvRqst 2578 URL [12] SrvReg, 2579 SrvDeReg, 2580 SrvRply 2581 20.2 SrvReg, 2582 SrvRply, 2583 AttrRply 2584 13 SrvReg 2585 15 SrvDeReg 2586 20.1.1 AttrRqst 2587 DAAdvert, 2588 SrvTypeRply 2589 attr vals 2590 AttrRqst, 2591 SrvDeReg 2593 20.1. Previous Responders' Address Specification 2595 The previous responders' Address Specification is specified as a 2596 of terms. 2598 The Address Specification is the address of the DA or SA 2599 which supplied the previous response. The format for Address 2600 Specifications in Service Location is defined in Section 20.3. The 2601 use of dotted decimal IP address notation should only be used in 2602 environments which have no Domain Name Service. 2604 Example: 2606 RESOLVO.NEATO.ORG,128.127.203.63 2608 SAs or DAs which are listed in a Previous Responders list in a 2609 multicast Service Location request will silently discard the request. 2611 Depending on the length of the request, around 60 previous responders 2612 may be listed in a single datagram. If there are more responders 2613 than this, the scaling mechanisms described in Section D should be 2614 used. 2616 20.1.1. Service Type String 2618 The Service Type is a string describing the type of service. These 2619 strings may only be comprised of alphanumeric characters, '+', and 2620 '-'. Upper case is considered equivalent to lower case in Service 2621 Type names. 2623 The Service Type of a service: scheme URL is encoded as the string 2624 up to and including the last ":". This includes the Naming Authority 2625 string. 2627 URL Service Type String 2628 ----------------------------------- ------------------ 2629 service:lpr://biglaser.dog.com service:lpr: 2630 service:wp:http://dir.cat.org service:wp: 2631 service:game.cs312://morb.lug.edu service:game.cs312: 2632 ftp://ftpserv.mouse.gov ftp: 2634 20.1.2. String List 2636 String lists transmitted by the service location protocol are items 2637 with a ',' delimiter. 2639 str-list = str-item / str-item ',' str-list 2641 The definition of depends on the string list. For a 2642 DAAdvert, the is a scope attribute value (see 2643 in Section 20.2). The other important case is described in 2644 Section 20.1, which may be included with SrvRqst, AttrRqst and 2645 SrvTypeRqst messages. 2647 20.1.3. Select List 2649 Select Lists are String List used in AttrRqst and SrvDeReg messages. 2650 The is a with the following syntax: 2652 tag-filter = simple-tag / substring 2653 simple-tag = 1*filt-char 2654 substring = [initial] any [final] 2655 initial = 1*filt-char 2656 any = '*' *(filt-char '*') 2657 final = 1*filt-char 2658 filt-char = Any character excluding and See 2659 Section 20.2. 2661 20.2. Attribute Information 2663 The is returned in the Attribute Reply if the Attribute 2664 Request does not result in an empty result. 2666 attr-list = attribute / attribute ',' attr-list 2667 attribute = '(' attr-tag '=' attr-val-list ')' / attr-tag 2668 attr-val-list = attr-val / attr-val ',' attr-val-list 2669 attr-tag = 1*safe-tag 2670 attr-val = intval / strval / boolval / opaque 2671 intval = [-]1*DIGIT 2672 strval = 1*safe-val 2673 boolval = "TRUE" / "FALSE" 2674 opaque = "(" 1*DIGIT ":" 1*r64chars ")" 2675 safe-val = Any character except reserved. 2676 safe-tag = Any character except reserved, star and bad-tag. 2677 reserved = '(' / ')' / ',' / '\' / '!' / '<' / '=' / '>' / 'tilde' 2678 bad-tag = CR / LF / HT 2679 star = '*' 2680 r64chars = DIGIT / ALPHA / '=' / '/' / '-' 2682 An must be scanned prior to evaluation for all 2683 occurrences of the escape character '\'. Reserved characters in 2684 attributes placed in attribute lists must be escaped. All escaped 2685 characters must be restored to their value before used for string 2686 matching. See Section 19. 2688 A keyword has only an , and no values. 2690 (OPERATOR=Joe Javaman) 2691 (COLOR=RED\, WHITE\, BLUE) 2692 (DELAY=10 MINS), BUSY, (LATEST BUILD=10-5-95), (PRIORITY=L,M,H) 2694 The third example has three attributes in the list. Color takes 2695 the value "RED, WHITE, BLUE" (the commas in the value string are 2696 escaped). Priority, on the other hand, takes the three values "L", 2697 "M", and "H". There are several other examples of attribute lists 2698 throughout the document. 2700 20.3. Address Specification in Service Location 2702 The address specification used in Service Location is: 2704 ::= [ ':' '@' ] [ ':' ] 2706 ::= Fully qualified domain name / 2707 dotted decimal IP address notation 2709 When no Domain Name Server is available, SAs and DAs must use dotted 2710 decimal conventions for IP addresses. Otherwise, it is preferable to 2711 use a fully qualified domain name wherever possible as renumbering of 2712 host addresses will make IP addresses invalid over time. 2714 Generally, just the host domain name (or address) is returned. 2715 When there is a non-standard port for the protocol, that should be 2716 returned as well. Passwords SHOULD NOT be sent with SLP messages 2717 (as cleartext) unless an IPSec ESP is used for delivery of the SLP 2718 message. 2720 Address specification in Service Location is consistent with standard 2721 URL format [5]. 2723 20.4. Attribute Value encoding rules 2725 Attribute values, and attribute tags are CASE INSENSITIVE for 2726 purposes of lexical comparison. 2728 The syntax of attribute values is described in Section 20.2. 2730 While an attribute can take any value, there are three types 2731 of values which differentiate themselves from general strings: 2732 Booleans, Integers and Opaque values. 2734 - Boolean values are either "TRUE" or "FALSE". This is the case 2735 regardless of the language strings are encoded in. Boolean 2736 attributes can take only one value. 2738 - Integer values are expressed as a sequence of DIGITs. The 2739 range of allowable values for integers is "-2147483648" to 2740 "2147483647". No other form of numeric representation is 2741 interpreted as such except integers. For example, hexadecimal 2742 numbers such as "0x342" are not interpreted as integers, but as 2743 strings. 2745 - Opaque values (i.e. binary values) are expressed in radix-64 2746 notation. The syntax is: 2748 ::= "(" ":" ")" 2749 ::= 1*DIGIT 2750 ::= radix-64 encoding of the original data 2752 is a 16-bit binary number expressed as a decimal string. 2753 For example, if the opaque value is 34 bytes long before encoding 2754 the field would be the string "34". 2756 Radix-64 encodes every 3 bytes of binary data into 4 bytes of 2757 ASCII data which is in the range of characters which are fully 2758 printable and transferable by mail. For a formal definition of 2759 the Radix-64 format see RFC 2045 [6], Section 6.8. 2761 The Opaque value encoding includes otherwise reserved 2762 characters in attribute values: '(', ')'. It may include 2763 another reserved character: '='. These characters 2764 are escaped in SrvRqst predicates. For example 2765 "(&(service-type=thing)(att=\(3:AAAA\)))" is a query for 2766 a service of type "thing" which has an attribute "att" with a 2767 value of a 3 zero bytes. 2769 21. Protocol Timing Rules 2771 There are four protocol actions which require timing rules. Active 2772 DA Discovery, Passive DA Advertising, reliable unicast requests to a 2773 DA and multicast/convergence. 2775 21.1. Active DA Discovery 2777 After a UA or SA restarts (say, after rebooting of a system or 2778 loading of the network kernel), their initial DA discovery request 2779 should be delayed for some random time uniformly distributed from 0 2780 to CONFIG_START_WAIT seconds. 2782 The UA or SA sends the DA Discovery request using a SrvRqst, as 2783 described in Section 6.2 and receives a DAAdvert as a reply, as 2784 described in Section 12. 2786 DA Discovery requests should be sent according to CONFIG_DA_RETRY. 2787 The second and third transmission of the DA Discovery request MUST 2788 include a previous responders list of all DAs which have responded. 2789 See Section 20.1. 2791 SAs which discover DAs actively must wait CONFIG_REG_ACTIVE seconds 2792 before registering their services. 2794 21.2. Passive DA Advertising 2796 Upon startup, then every CONFIG_DA_BEAT seconds a DA will multicast 2797 (or broadcast) an unsolicited DAAdvert. This will ensure that 2798 eventually it will be discovered by all applications which are 2799 concerned. 2801 All SAs which receive the unsolicited DAAdvert should examine its 2802 Sequence Number. If the DA has never before been heard from or if 2803 the Sequence Number is less than it was previously and less than 256, 2804 the SA should assume the DA does not have its service registration, 2805 even if it once did. If this is the case and the DA has the proper 2806 scope, the SA should register all service information with the DA, 2807 after waiting a random interval CONFIG_REG_PASSIVE. 2809 While it might seem advantageous to have frequent heartbeats, this 2810 generates traffic throughout the network in proportion to the number 2811 of DAs. Thus, CONFIG_DA_BEAT should be specified with a value in 2812 seconds long enough to prevent routine protocol operations from using 2813 any significant bandwidth. 2815 21.3. Reliable Unicast to DAs 2817 If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY 2818 seconds, the message should be retried. If a DA fails to respond 2819 after CONFIG_DA_MAX seconds, the UA or SA should use a different DA. 2821 DA addresses may be cached from previous discovery attempts, 2822 preconfigured, or by use of DHCP (see Section 16.1). 2824 If no such DA responds, DA discovery should be used to find a new DA. 2825 Care should be taken not to do Active DA Discovery more than once per 2826 CONFIG_DA_FIND seconds. 2828 21.4. Multicast/Convergence 2830 This algorithm is used by UAs to send requests to SAs using the 2831 Service Location General Multicast Address. The algorithm is used by 2832 both UAs and SAs to send DA Discovery requests to DAs using the DA 2833 Discovery Multicast Address. 2835 Requests to SAs are multicast repeatedly (with a recommended wait 2836 interval of CONFIG_MC_RETRY) until there are no new responses, or 2837 CONFIG_MC_MAX seconds have elapsed. DA discovery requests use 2838 different timing for repeated requests, CONFIG_DA_RETRY. 2840 Repeated requests include a previous responder list, see 2841 Section 20.1. 2843 22. Configurable Parameters and Default Values 2845 There are several configuration parameters for Service Location. 2846 Default values are chosen to allow protocol operation without the 2847 need for selection of these configuration parameters, but other 2848 values may be selected by the site administrator. The configurable 2849 parameters will allow an implementation of Service Location to be 2850 more useful in a variety of scenarios. 2852 22.1. Time Out Intervals 2854 These values should be configurable in case the site deploying 2855 Service Location has special requirements (such as very slow links.) 2857 Interval name Section Default Value Meaning 2858 ======================================================================== 2859 CONFIG_KEEP_RPLY 4.2 1 minute Cache replies by XID. 2860 CONFIG_LIFETIME 4.5 10800 seconds registration Lifetime, 2861 (3 hours) after which ad expires 2862 CONFIG_MC_RETRY 4.2 each second, Retry multicast query 2863 backing off until no new values 2864 gradually arrive. 2865 CONFIG_MC_MAX 6 15 seconds Max time to wait for a 2866 complete multicast query 2867 response (all values.) 2868 CONFIG_START_WAIT 13 3 seconds Wait to perform DA 2869 discovery on reboot. 2870 CONFIG_DA_RETRY 6.2 2 seconds Retransmit DA discovery, 2871 try it 3 times. 2872 CONFIG_DA_MAX 6.2 6 seconds Give up on requests sent 2873 to a DA. 2874 CONFIG_DA_BEAT 16.1 3 hours DA Heartbeat, so that SAs 2875 passively detect new DAs. 2876 CONFIG_DA_FIND 6.2 900 seconds Minimum interval to wait 2877 before repeating Active 2878 DA discovery. 2879 CONFIG_REG_PASSIVE 16.1 1-3 seconds Wait to register services 2880 on passive DA discovery. 2881 CONFIG_REG_ACTIVE 13 1-3 seconds Wait to register services 2882 on active DA discovery. 2883 CONFIG_CLOSE_CONN 3.10 5 minutes DAs and SAs close idle 2884 connections. 2886 Multicast vs. Broadcast 2887 All Service Location entities must use multicast by 2888 default. The ability to use broadcast messages must 2889 be configurable for UAs and SAs. Broadcast messages 2890 are to be used in environments where not all Service 2891 Location entities have hardware or software which 2892 supports multicast. 2894 Multicast Radius 2895 Multicast requests should be sent to all subnets in a 2896 site. The default multicast radius for a site is 32. 2897 This value MUST be configurable. 2899 Directory Agent Address 2900 The DA address discovery mechanism must be 2901 configurable. There are three possibilities for this 2902 configuration: A default address, no default address 2903 and the use of DHCP to locate a DA as described in 2904 Section 16.1. The default value should be use of 2905 DHCP, with "no default address" used if DHCP does 2906 not respond. In this case the UA or SA must do a 2907 Directory Agent Discovery query. 2909 Directory Agent Scope Assignment 2910 The scope or scopes of a DA must be configurable. 2911 The default value for a DA is to have no scope if not 2912 otherwise configured. 2914 Path MTU The default path MTU is assumed to be 1400. This 2915 value MUST be configurable for all SAs and DAs. 2917 Keys for Protected Scopes 2918 If the local administration designates certain 2919 scopes as "protected scopes", the agents making 2920 use of those scopes MUST able to acquire keys to 2921 authenticate data sent by services along with their 2922 advertised URLs for services within the protected 2923 scope. SAs and DAs require private keys for the 2924 scope, where all entities require public keys for 2925 the scope. See Section 17.2.1 which defines how 2926 these keys are used. By default, service agents use 2927 "md5WithRSAEncryption" [4] to produce the signed 2928 data, to be be included with service registrations 2929 and deregistrations (see appendix B, 4.4). This 2930 authentication data could be verified by user agents 2931 and directory agents that possess the corresponding 2932 public key. 2934 22.2. Service Agent: Use Predefined Directory Agent(s) 2936 A SA's default configuration is to do passive and active DA discovery 2937 and to register with all DAs which are properly scoped. 2939 A SA SHOULD be configurable to allow a special mode of operation: 2940 They will use only preconfigured DAs. This means they will *NOT* 2941 actively or passively detect DAs. 2943 If a SA is configured this way, knowledge of the DA must come through 2944 another channel, either static configuration or by the use of DHCP. 2946 The availability of the Service information will not be consistent 2947 between DAs. The mechanisms which achieve eventual consistency 2948 between DAs are ignored by the SA, so their service information will 2949 not be distributed. This leaves the SA open to failure if the DA 2950 they are configured to use fails. 2952 23. Security Considerations 2954 The Service Location Protocol provides for authentication of Service 2955 Information registered by SAs and DA Advertisements. This allows 2956 UAs to obtain information about services with confidence that is 2957 reasonably complete and accurate. 2959 Service Location does not provide confidentiality. Because the 2960 objective of this protocol is to advertise services to a community 2961 of users, confidentiality might not generally be needed when this 2962 protocol is used in non-sensitive environments. Specialized schemes 2963 might be able to provide confidentiality, if needed in the future. 2964 Sites requiring confidentiality should implement the IP Encapsulating 2965 Security Payload (ESP) [3] to provide confidentiality for Service 2966 Location messages. 2968 Using unprotected scopes, an adversary might easily use this protocol 2969 to advertise services on servers controlled by the adversary and 2970 thereby gain access to users' private information. Further, an 2971 adversary using this protocol will find it much easier to engage in 2972 selective denial of service attacks. Sites that are in potentially 2973 hostile environments (e.g. are directly connected to the Internet) 2974 SHOULD use protected scopes. 2976 Service Location is useful as a bootstrap protocol. It may be used 2977 in environments in which no preconfiguration is possible. In such 2978 situations, a certain amount of "blind faith" is required: Without 2979 any prior configuration it is impossible to use any of the security 2980 mechanisms described above. Service Location will make use of 2981 the mechanisms provided by the Security Area of the IETF for key 2982 distribution as they become available. At this point it would only 2983 be possible to gain the benefits associated with the use of protected 2984 scopes if some cryptographic information can be preconfigured with 2985 the end systems before they use Service Location. For UAs, this 2986 could be as simple as supplying the public key of a Certificate 2987 Authority. See Appendix B. 2989 24. Protocol Requirements 2991 In this section are listed various protocol requirements for UAs, 2992 SAs, and DAs. 2994 24.1. Directory Agent Requirements 2996 Protocol Feature Section Requirement Level 2997 ======================================================================== 2998 Announce using multicast on startup. 21.2 MUST 2999 Announce using multicast, regularly. 21.2 MUST 3000 Reply to unicast requests from UAs. 17.1.3.1 MUST 3001 Reply to multicast DADiscovery requests. 6.2 MUST 3002 Support TCP when overflow occurs. 3.10.1 MUST 3003 Accept de/registration from SAs. 17.1.2 MUST 3004 Age out expired service registrations. 4.5 MUST 3005 Reply to message using DA scoping rules. 17.1.3.1 MUST 3006 Obey language rules for de/reg, requests. 18 MUST 3007 Announce and verify using pro. scopes. 17.2.1 MUST 3008 Be able to ignore unrecognized options. 4.1 MUST 3010 24.2. Service Agent Requirements 3012 Protocol Feature Section Requirement Level 3013 ======================================================================== 3014 Perform Active DA discovery on start up. 21.1 MUST 3015 Perform Passive DA discovery always. 21.2 MUST 3016 Forward Registrations discovered DAs. 17.1.2 MUST 3017 Forward Deregistrations to DAs if needed. 17.1.2 MUST 3018 Age out expired service registrations. 4.5 MUST 3019 Obey pro. scope rules: in all messages. 17.2.1 MUST 3020 Obey scope rules: forwarding to DAs. 17.1 MUST 3021 Obey scope rules: responding to UAs. 17.1 MUST 3022 Obey language rules on reply or register. 18 MUST 3023 Support TCP for overflowed SLP messages. 3.10.1 MUST 3024 Respond to multicast & unicast SrvRqst. 3.10 MUST 3025 Also respond to AttrRqst and SrvTypeRqst. 3.10 SHOULD 3026 Be able to ignore unrecognized options. 4.1 MUST 3028 24.3. User Agent Requirements 3030 Protocol Feature Section Requirement Level 3031 ======================================================================== 3032 Perform Active DA discovery on start up. 21.1 MUST 3033 Perform Passive DA discovery always. 21.2 SHOULD 3034 Obey rules: preferring DAs to SAs, etc. 5 MUST 3035 Obey scope rules: where to send requests. 17.1 MUST 3036 Obey pro. scope rules: reject bad info. 17.2.1 MUST 3037 Support TCP for overflowed SLP messages. 3.10.1 MUST 3038 Be able to ignore unrecognized options. 4.1 MUST 3039 Send SrvRqst to SAs using multicast. 21.4 MUST 3040 Send SrvRqst to DAs using unicast. 21.3 MUST 3041 Send SrvTypeRqst and AttrRqst messages. 5 SHOULD 3042 Send requests to SAs using unicast. 5 MAY 3044 24.4. Common Requirements for all SLP Agents 3046 Protocol Feature Section Requirement Level 3047 ======================================================================== 3048 Static Configurability. 22 MUST 3049 DHCP Configurability. 16.1 SHOULD 3050 Support protected scope configuration. 22 SHOULD 3051 For protected scopes, support md5/RSA. RFC 1423[4] MUST 3052 Support UTF-8 character encoding. 4 MUST 3054 25. Non-configurable Parameters 3056 IP Port number for unicast requests to DAs: 3058 UDP and TCP Port Number: 427 3060 Multicast Addresses 3062 Service Location General Multicast Address: 224.0.1.22 3063 Directory Agent Discovery Multicast Address: 224.0.1.35 3065 A range of 1024 contiguous multicast addresses for use as Service 3066 Specific Discovery Multicast Addresses will be assigned by IANA. 3068 Error Codes: 3070 No Error 0 3071 LANGUAGE_NOT_SUPPORTED 1 3072 PROTOCOL_PARSE_ERROR 2 3073 INVALID_REGISTRATION 3 3074 SCOPE_NOT_SUPPORTED 4 3075 AUTHENTICATION_ABSENT 6 3076 AUTHENTICATION_FAILED 7 3077 AUTHENTICATION_ALGO_UNKNOWN 8 3078 PROTOCOL_V1_REJECTED 9 3079 EXPECTED_ATTRIBUTE_MISSING 64 3080 INTERNAL_ERROR 128 3082 26. Acknowledgments 3084 Early work on this protocol was done by Leo McLaughlin, Mike Ritter 3085 and Scott Kaplan. Charlie Perkins and Harry Harjono's Resource 3086 Discovery Protocol was merged with the Service Location Protocol. 3087 Jeff Schiller assisted in shaping the security architecture specified 3088 in this document. This protocol has benefited from the techniques, 3089 focus and minimal requirements of the Ping Discovery Service (PDS) 3090 from Intel in its recent revision. 3092 A. Version 2 Notes 3094 This document revises the Service Location Protocol as specified in 3095 RFC 2165. There are some open issues which are resolved here. Some 3096 of these are protocol corrections (which result in a change in the on 3097 the protocol as it is exchanged over the wire.) Some of the changes 3098 to the document are merely clarifications and document restructuring. 3100 Changes since draft-ietf-svrloc-protocol-v2-00.txt: 3102 - URL length was 1 byte, now it is 2. 3104 - Deregistration without language tag or attr tags fully 3105 deregisters a service. 3107 - We clarified the monolingual bit, so that it is clear that 3108 LANGUAGE_NOT_SUPPORTED is returned only when there are services 3109 available, but not in an available language. 3111 - We added a new error: INTERNAL_ERROR, for the case where a DA or 3112 SA cannot respond. 3114 - We restored the header to as close a form to the v1 version as 3115 possible and noted why it could not be the same. 3117 - We clarified the 'S' bit. 3119 - Michael Day added as an editor/author. 3121 - PDS added to the acknowledgement section. 3123 - ISOC copyright header added. 3125 - We added 'service-type' to the list of reserved, non-translatable 3126 strings. 3128 - We fixed the bibliography. 3130 - We added a section on minimal UA and SA requirements. 3132 - We rewrote the introduction and added an appendix on SLP and 3133 management. 3135 - We updated the requirements tables at the end. 3137 Changes between RFC 2165 and version-00 of this document: 3139 Clarifications: 3141 SrvTypeRqst definition 3142 SrvTypeRqst does not include a list of previously received 3143 service types as was erroneously indicated. 3145 Opaque value syntax 3146 The ``(`` and ``)'' characters enclosing an opaque value are 3147 to be taken literally. The length of the opaque value is to 3148 be encoded as a decimal number. 3150 Scopes 3151 Are NOT language specific strings. All scope rules have 3152 been coalesced into a single section. The rules for when to 3153 use unscoped requests and registrations have been clarified 3154 as well as the consequences of receiving them and the 3155 behavior of unscoped DAs. 3157 Requirements 3158 The requirements section has been redone in a simpler matrix 3159 style, with references to the protocol section, reflecting 3160 *all* protocol requirements. 3162 Wild Card values in search filters 3163 Wild card values are only intended to be used for string 3164 MATCHING not string COMPARISONS. 3166 Service Type Reply strings 3167 The definition of the reply strings needs to be clarified 3168 and allow for arbitrary URL schemes. 3170 Security considerations 3171 The security section has been updated to reflect the changes 3172 made to the certificate format section and the ability to 3173 sign DAAdverts. 3175 AttrRqst select-list length 3176 The length of the select-list is the length of the 3177 select-list string, which is the common convention in SLP. 3179 Modifications: 3181 Crypto Algorithm field in Service requests 3182 The UA requires a way to specify which crypto algorithm 3183 it can use, if it is not the default, so the DA or SA can 3184 determine what to use. 3186 Version Number 3187 Since the wire protocol has changed, the version number of 3188 the protocol takes the version number 2. 3190 Character Encoding 3191 Character encodings are all be in UTF8 [21]. This conforms 3192 to current IESG recommendations and simplifies the protocol. 3194 Service Request Predicates 3195 Service Request Predicate grammar have been replaced by the 3196 request grammar used by LDAP string search filters. Some 3197 conventions are necessary to ensure proper structure of 3198 requests. The simple 'list format' queries is no longer 3199 supported. 3201 Character escapes in string encoding 3202 To be consistent with the LDAP string search filters syntax 3203 and to simplify the encoding rules in SLP, all character 3204 escapes in SLP string based messages reserve the backslash 3205 character as an escape for reserved characters. Character 3206 escapes in URLs conform to standard URL syntax conventions. 3208 Fresh Bit Handling 3209 The Fresh bit is transmitted by SAs to DAs to indicate 3210 freshness, not returned by DAs to SAs in the acknowledgement 3211 of registration. This allowed for a race condition. 3213 URL handling 3214 SLPv1 only supports service: URLs. It now supports 3215 arbitrary URLs provided that they follow standard URL 3216 syntax. This support modifies SrvRply, AttrRqst, SrvReg, 3217 DAAdvert and SrvDeReg. 3219 Further Modifications: 3221 DAAdvert format 3222 The DAAdvert message contains new information: It indicates 3223 whether it was sent as the result of a service request or 3224 at the DA's own initiative. It can also carry a digital 3225 signature of the DAAdvert. The DA may also mark some of 3226 the scopes it advertises in as 'protected' and provide a 3227 pointer to the protected scope's certificate. DAAdverts no 3228 longer override the XID in the header, but instead carry a 3229 'DAAdvert sequence number'. 3231 Request Flagging 3232 The header indicates whether a request was multicast or 3233 unicast. This aids interpretation of the request by SAs 3234 and DAs implemented on platforms which receive all datagram 3235 requests from the same socket and cannot distinguish between 3236 the 'destination' address of the datagram they received. 3238 String Interpretation 3239 Strings are interpreted in line with other string based 3240 query protocols: Interior white space is folded to a single 3241 white space rather than interpreted literally for string 3242 matching. 3244 Language Tagging 3245 The reserved Dialect field is used for inclusion of RFC 1766 3246 language tags (or whatever obsoletes them.) This is in 3247 accord with the new guidelines for internationalization. 3249 SLP Certificate format 3250 The certificate format needs an additional field indicating 3251 the name of the CA. There also needs to be text which 3252 encourages the use of standard certificate formats if 3253 possible (X.509, etc.) 3255 Requirements 3256 The requirement that SAs handle SrvTypeRqst and AttrRqst 3257 has been relaxed from a SHOULD to a MAY. The requirement 3258 that a UA be able to issue a SrvTypeRqst and AttrRqst has 3259 been relaxed from a MUST to a SHOULD. The requirement that 3260 UAs be able to use multicast/convergence has been relaxed 3261 from a MUST to a SHOULD (provided that DHCP is used for DA 3262 discovery!) This allows conformant implementations to be 3263 much more lightweight. 3265 Service Location Extension Options 3266 These options allow for the protocol to be enhanced without 3267 requiring the main protocol specification standardization to 3268 be derailed. 3270 Open Issues: 3272 Service Specific Multicast Addresses 3273 Use of Service Specific Discovery Multicast Addresses as 3274 defined in RFC 2165 is deprecated until a multicast address 3275 range allocation mechanism is defined using Administratively 3276 Scoped Multicast Addresses. We need to assign the range of 3277 service specific multicast addresses for use by UAs and SAs. 3279 Lifetime may be too short 3280 It may be that timeouts for soft state are too short. We 3281 may want to make the URL entry's Lifetime field be longer 3282 than 2 bytes worth of seconds. 3284 Allow the tag list in SrvDeReg to include wildcards 3285 This would allow for deletions of attributes with patterns, 3286 such as all entries with a common prefix. This facilitates 3287 efficient name deletion based on a hierarchical structure. 3289 Include a MIN, MAX and BEST operator for queries 3290 MIN and MAX would be used for integer query terms - to allow 3291 the service with the smallest or largest value for a given 3292 attribute to be returned. BEST would be a string match 3293 which would return the service(s) for which the longest 3294 substring match could be found. 3296 Allow increasing ring multicast discovery 3297 This would allow the 'nearest' services to be discovered. 3299 Use multicast based de/registration of services 3300 This would eliminate a scaling issue in the protocol but 3301 would require the use of MTCP-like techniques so that 3302 SAs could moderate their refresh intervals so that SLP 3303 registration take only a fixed amount of network bandwidth. 3305 LDAP search filters 3306 Should LDAPv2 filters [13, 20, 14] be used, since they rely 3307 on Draft Standard protocols? Or, should SLP use the new 3308 LDAPv3 filters (which have not yet gone to PS)? The latter 3309 handle internationalization far better! 3311 B. SLP Certificates 3313 Certificates may be used in SLP in order to distribute the public 3314 keys of trusted protected scopes. This section defines a very 3315 simple format for certificates which provides only the most basic 3316 functionality required for deploying protected scopes. If a public 3317 key infrastructure has already been deployed, for instance using 3318 X.509 certificates, these SHOULD be used instead. Implementation of 3319 SLP Certificates is entirely OPTIONAL. 3321 Possession of the private key of a protected scope is equivalent 3322 to being a trusted SA. The trustworthiness of the protected scope 3323 depends upon all of these private keys being held by trusted 3324 hosts, and used only for legitimate service registrations and 3325 deregistrations. 3327 With access to the proper Certificate Authority (CA), DAs and UAs 3328 do not need (in advance) hold public keys which correspond to these 3329 protected scopes. They do require the public key of the CA. The CA 3330 produces certificates using its unique private key. This private key 3331 is not shared with any other system, and must remain secure. The 3332 certificates declare that a given protected scope has a given public 3333 key, as well as the expiration date of the certificate. 3335 The ASCII (mail-safe) string format for the certificate is the 3336 following list of tag and value pairs: 3338 "certificate-auth=" 1*ALPHANUMERIC CRLF 3339 "certificate-alg=" 1*ASN1CHAR CRLF 3340 "scope-charset=" 1*DIGIT CRLF 3341 "scope=" 1*RADIX-64-CHAR CRLF 3342 "timestamp=" 16HEXDIGIT CRLF 3343 "public-key=" 1*RADIX-64-CHAR CRLF 3344 "cert-digest=" 1*RADIX-64-CHAR CRLF 3346 ASN1CHAR = DIGIT | '.' 3347 HEXDIGIT = DIGIT | 'a'..'f' | 'A'..'F' 3348 RADIX-64-CHAR = DIGIT | 'a'..'z' | 'A'..'Z' | '+' | '/' | '=' 3350 The radix-64 notation is described in RFC 2045 [6]. Spaces are 3351 ignored in the computation of the binary value corresponding to a 3352 Radix-64 string. If the value for scope, public-key or cert-digest 3353 is greater than 72 characters, the Radix-64 notation may be broken 3354 up on to separate lines. The continuation lines must be preceded 3355 by one or more spaces. Only the tags listed above may start in the 3356 first column of the certificate string. This removes ambiguity in 3357 parsing the Radix-64 values (since the tags consist of legal Radix-64 3358 values.) 3359 The certificate-auth identifies the authority who created the 3360 certificate. This enables a very unsophisticated mechanism for 3361 enabling the use of multiple certificate authorities: An end 3362 system may be configured with public keys for multiple certificate 3363 authorities. In each case the public key will be identified by 3364 a 'certificate-auth' string as part of the configuration. When 3365 certificates are obtained, they may use the 'certificate-auth' field 3366 to determine which public key to use to verify the certificate's 3367 validity. 3369 The certificate-alg is the ASN.1 string for the Object Identifier 3370 value of the algorithm used to produce the "cert-digest". The 3371 scope-charset is a decimal representation of the MIBEnum value for 3372 the character set in which the scope is represented. 3374 The radix-64 encoding of the scope string will allow the ASCII 3375 rendering of a scope string any character set. 3377 The 8 byte NTP format timestamp is represented as 16 hex digits. 3378 This timestamp is the time at which the certificate will expire. 3380 The format for the public key will depend on the type of cryptosystem 3381 used, which is identified by the certificate-alg. When the CA 3382 generated the certificate holding the public key being obtained, 3383 it used the message digest algorithm identified by certificate-alg 3384 to calculate a digest D on the string encoding of the certificate, 3385 excepting the cert-digest. The CA then encrypted this value using 3386 the CA's private key to produce the cert-digest, which is included in 3387 the certificate. 3389 The CA generates the certificate off-line. The mechanism to 3390 distribute certificates is not specified in the Service Location 3391 Protocol, but may be in the future. The CA specifies the algorithms 3392 to use for message digest and public key decryption. The DA or SA 3393 need only obtain the certificate, have a preconfigured public key for 3394 the CA and support the algorithm specified in the certificate-alg in 3395 order to obtain certified new public keys for protected scopes. 3397 The DA or UA may confirm the certificate by calculating the message 3398 digest D, using the message digest algorithm identified by the 3399 certificate-alg. The input to the message digest algorithm is the 3400 string encoding of the certificate, excepting the cert-digest. 3401 The cert-digest is decrypted using the CA's public key to produce 3402 D'. If D is the same as D', the certificate is legitimate. The 3403 public-key for the protected scope may be used until the expiration 3404 date indicated by the certificate timestamp. 3406 The certificate may be distributed along untrusted channels, such as 3407 email or through file transfer, as it must be verified anyhow. The 3408 CA's public key must be delivered using a trusted channel. 3410 C. Example of deploying SLP security using MD5 and RSA 3412 In our site, we have a protected scope "CONTROLLED". We generate a 3413 private key - public key pair for the scope, using RSA. The private 3414 key is maintained on a secret key ring by all SAs in the protected 3415 scope. The public key is available to all DAs which support the 3416 protected scope and to all UAs which will use it. 3418 In order to register or deregister a URL, the data required to be 3419 authenticated (as described in Section 4.4) is digestified using 3420 MD5 [18] to create a digital signature, then encrypted by RSA with 3421 the protected scope's private key. The output of RSA is used in the 3422 authentication data field of the authentication block. 3424 The DA or UA discovers the appropriate method for verifying the 3425 authentication by looking inside the authentication block. Suppose 3426 that the "md5WithRSAEncryption" [4] algorithm has to be used 3427 to verify the signed data. The DA or UA calculates the message 3428 digest of the URL Entry by using md5, exactly as the SA did. The 3429 authentication block is decrypted using the public key for the 3430 "CONTROLLED" scope, which is stored in the public key ring of the UA 3431 or DA under the name "CONTROLLED". If the digest calculated by the 3432 UA or DA matches that of the SA, the URL Entry has been validated. 3434 D. Scaling and Deployment of the Service Location Protocol 3436 The Service Location Protocol is meant to be deployable in a variety 3437 of network configurations. The protocol is ideal for 'plug and play' 3438 networks, which have the minimum of services offered. It also will 3439 scale to sites, with many routed networks, even over wide-area low 3440 bandwidth links. 3442 The key to SLP's scalability is how it is configured in the default 3443 case and how it can be configured for use in larger deployments. 3445 The default configuration for SLP requires it to discover DAs and if 3446 possible, to use them. This ensures that even in a larger deployment 3447 SLP will not use multicast or broadcast more than necessary. Thus 3448 SLP will not require much network bandwidth for its operation. 3450 If there are no DAs, as would be the case in the simplest 3451 configuration, UAs will multicast (or broadcast) their requests to 3452 SAs. This allows a network of client applications and services to be 3453 set up with no configuration; no DNS, no DHCP, and so on. This is a 3454 useful feature for extremely small networks, such as in a conference 3455 room. 3457 DAs are provided for scalability. The protocol works identically 3458 whether DAs are present or not (UAs issue the same requests to either 3459 SAs or DAs, and get the same replies.) The only difference is 3460 efficiency and scalability. 3462 The scoping feature of SLP provides further scalability. Services 3463 which are scoped will be attracted to the subset of DAs which support 3464 their scope. UAs will go to the DAs which supply service information 3465 in the scope they are configured to use, or the scope which the user 3466 selects if the UA is not configured with a scope. 3468 In some cases multicast cannot be used to discover DAs. In others, 3469 administration Blocks may decide that they would prefer to control 3470 the way DAs are used. Here, DHCP may be used to configure UAs and 3471 SAs with the location of DAs. This is particularly useful for 3472 configuring hosts which are networked via slow wide-area links. It 3473 would be a waste of scarce network bandwidth to use a multicast 3474 routing protocol to distribute DA advertisements over such a link. 3476 There is no guarantee that a DA of a particular scope will contain 3477 the same service information as another DA in the same scope. This 3478 consistency is only achieved when all SAs which advertise services 3479 in that scope are aware of the same set of DAs. This may not be 3480 possible, if multicast routing does not pervade the entire site or if 3481 DHCP does not uniformly configure SAs with the same scope to use the 3482 same DAs. 3484 Indeed, it may not even be desirable to allow such pervasive use 3485 of multicast nor even be required for useful 'best effort' service 3486 provision for there to be a consistent view of services from all DAs 3487 of the same scope. This is a decision which network administrators 3488 of SLP in large sites need to consider. The more consistency 3489 they wish to achieve between DAs, the more complicated their DHCP 3490 configuration will be, or the more SLP based multicast traffic they 3491 will have in their networks. 3493 E. Using SLP For Network and Systems Management 3495 When deploying SLP for purposes of network or systems management, 3496 there are some important points to consider. These include ease of 3497 administration, having a low impact on the network, and providing SLP 3498 support for the entire range of systems on the network. (Note that 3499 using SLP to discover managed systems will only find managed systems 3500 that support SLP.) 3502 Network and systems management applications need to continue working 3503 when other network components are broken. Further, management 3504 applications frequently need to obtain information that has a 3505 very short lifetime. These considerations motivate some of the 3506 recommendations that are listed below. 3508 The Service Location Protocol can provide a number of applications 3509 for network and systems management. For example: 3511 - A manager can use SLP to discover managed systems without 3512 performing brute-force scanning of the network. 3514 - A manager can select manageable systems based on specific 3515 attributes, such as support for a specific management protocol, 3516 agent, instrumentation group, and software distribution format. 3518 - A managed system can use SLP to find its manager(s), to which the 3519 managed system can then send traps and issue trouble tickets. 3521 - A managed system can use SLP to publish basic information about 3522 itself, such as its operating system vendor, type and version; 3523 its MAC address(es); operator information; management agent(s) 3524 hosted by that system, and so on. 3526 - A manager can periodically search for new hosts using SLP. 3528 A good strategy to follow when using SLP for manageability includes 3529 the following points: 3531 - Peer-to-peer implementation. Each managed system, along with 3532 each management application, implements UA and SA functionality. 3533 The system advertises its management services. These service 3534 types are defined elsewhere, for example [10]. 3536 - Bootstrap capability. Each managed system, along with each 3537 management application can begin functioning with no knowledge 3538 of exisiting manageability services beyond a knowledge of its 3539 own UA. For example, a management application can, with no 3540 foreknowledge, use SLP to build a list of manageable stations and 3541 their basic capabilities. 3543 This bootstrap capability requires the use of multicast or 3544 broadcast with convergence. Multicasting and broadcasting should 3545 be avoided when possible. However, bootstrap capability is a 3546 key aspect of systems management. (What happens when the DA is 3547 broken and needs to be managed?) Therefore, managers and managed 3548 stations should use DAs for discovery when they exist, but must 3549 also have the ability to perform multicast or broadcast with 3550 convergence. 3552 - DAs for support of mobile and occasionally connected stations, as 3553 well as for scalability. DAs provide a good way to support the 3554 discovery of mobile and occasionally connected systems because 3555 they can act as SLP proxies for such systems, which may be 3556 connected via a slow link. In addition, DAs provide scalability 3557 to SLP. 3559 F. Full Copyright Statement 3561 Copyright (C) The Internet Society (1997). All Rights Reserved. 3563 This document and translations of it may be copied and furnished to 3564 others, and derivative works that comment on or otherwise explain it 3565 or assist in its implmentation may be prepared, copied, published 3566 and distributed, in whole or in part, without restriction of any 3567 kind, provided that the above copyright notice and this paragraph 3568 are included on all such copies and derivative works. However, 3569 this document itself may not be modified in any way, such as by 3570 removing the copyright notice or references to the Internet Society 3571 or other Internet organizations, except as needed for the purpose 3572 of developing Internet standards in which case the procedures 3573 for copyrights defined in the Internet Standards process must be 3574 followed, or as required to translate it into languages other than 3575 English. 3577 The limited permissions granted above are perpetual and will not be 3578 revoked by the Internet Society or its successors or assigns. 3580 This document and the information contained herein is provided on an 3581 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3582 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3583 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3584 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3585 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 3587 References 3589 [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 3590 Extensions. RFC 2132, March 1997. 3592 [2] H. Alvestrand. Tags for the Identification of Languages. RFC 3593 1766, March 1995. 3595 [3] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 3596 August 1995. 3598 [4] D. Balenson. Privacy Enhancement for Internet Electronic 3599 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 3600 February 1993. 3602 [5] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 3603 Locators (URL). RFC 1738, December 1994. 3605 [6] N. Borenstein and N. Freed. Multipurpose Internet Mail 3606 Extensions (MIME) Part One: Format of Internet Message Bodies. 3607 RFC 2045, November 1996. 3609 [7] S. Bradner. Key words for use in RFCs to Indicate Requirement 3610 Levels. RFC 2119, March 1997. 3612 [8] CCITT. Specification of the Abstract Syntax Notation One 3613 (ASN.1). Recommendation X.208, 1988. 3615 [9] D. Crocker and P. Overell. Augmented BNF for Syntax 3616 Specifications: ABNF. RFC 2234, November 1997. 3618 [10] M. Day. Manageability service: Schemes. November 1997. 3619 draft-ietf-svrloc-sysman-00.txt (work in progress). 3621 [11] R. Droms. Dynamic Host Configuration Protocol. RFC 2131, March 3622 1997. 3624 [12] E. Guttman, C. Perkins, and J. Kempf. Service Templates and 3625 service: Schemes. draft-ietf-svrloc-service-scheme-05.txt, 3626 November 1997. (work in progress). 3628 [13] T. Howes. A String Representation of LDAP Search Filters. RFC 3629 1960, June 1996. 3631 [14] T. Howes, S. Kille, W. Yeong, and C. Robbins. The String 3632 Representation of Standard Attribute Syntaxes. RFC 1778, March 3633 1995. 3635 [15] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for 3636 IPv4, IPv6 and OSI. RFC 2030, October 1996. 3638 [16] R. Moats and M. Hamilton. Finding Stuff (How to discover 3639 services). draft-ietf-svrloc-discovery-05.txt, October 1997. 3640 (work in progress). 3642 [17] C. Perkins. DHCP Options for Service Location Protocol, May 3643 1997. draft-ietf-dhc-slp-02.txt (work in progress). 3645 [18] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 3646 April 1992. 3648 [19] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan. Service 3649 Location Protocol. RFC 2165, July 1997. 3651 [20] W. Yeong, T. Howes, and S. Kille. Lightweight Directory Access 3652 Protocol. RFC 1777, March 1995. 3654 [21] F. Yergeau. UTF-8, a transformation format of unicode and ISO 3655 10646. RFC 2044, October 1996. 3657 Authors' Addresses 3659 Questions about this memo can be directed to: 3661 Erik Guttman Charles Perkins 3662 Sun Microsystems Sun Microsystems 3663 Bahnstr. 2 901 San Antonio Road 3664 74915 Waibstadt Palo Alto, CA 94040 3665 Germany USA 3667 Phone: +49 7263 911701 +1 650 786 6464 3668 Fax: +1 650 786 6445 3669 Email: Erik.Guttman@sun.com cperkins@sun.com 3671 John Veizades Michael Day 3672 @Home Network Intel 3673 385 Ravendale Dr. 3674 Mountain View, CA 94043 3675 USA 3677 Phone: +1 650 569 5243 +1 801 763 2341 3678 Fax: 3679 Email: veizades@home.net Michael_Day@ccm.ut.intel.com