idnits 2.17.1 draft-ietf-svrloc-protocol-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 6 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 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 ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 288: '... MUST This word, or the adj...' RFC 2119 keyword, line 292: '... MUST NOT This phrase means tha...' RFC 2119 keyword, line 295: '... SHOULD This word, or the adj...' RFC 2119 keyword, line 302: '... MAY This word, or the adj...' RFC 2119 keyword, line 304: '...hich does not include this option MUST...' (67 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1303 has weird spacing: '...t "some strin...' == Line 2931 has weird spacing: '...ing off unti...' == Line 3017 has weird spacing: '... Bangla in ...' -- 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 1533 (ref. '2') (Obsoleted by RFC 2132) ** 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 1866 (ref. '5') (Obsoleted by RFC 2854) ** Obsolete normative reference: RFC 1738 (ref. '6') (Obsoleted by RFC 4248, RFC 4266) ** Obsolete normative reference: RFC 1521 (ref. '7') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) -- Unexpected draft version: The latest known version of draft-bradner-key-words is -02, but you're referring to -03. -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 1541 (ref. '12') (Obsoleted by RFC 2131) -- Possible downref: Non-RFC (?) normative reference: ref. '13' == Outdated reference: A later version (-14) exists of draft-ietf-svrloc-service-scheme-00 -- Possible downref: Non-RFC (?) normative reference: ref. '15' -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** Obsolete normative reference: RFC 2030 (ref. '17') (Obsoleted by RFC 4330) ** Obsolete normative reference: RFC 1970 (ref. '20') (Obsoleted by RFC 2461) -- Possible downref: Non-RFC (?) normative reference: ref. '21' == Outdated reference: A later version (-07) exists of draft-ietf-dhc-slp-00 ** Downref: Normative reference to an Informational RFC: RFC 1321 (ref. '23') -- Possible downref: Non-RFC (?) normative reference: ref. '24' -- Possible downref: Non-RFC (?) normative reference: ref. '25' -- Possible downref: Non-RFC (?) normative reference: ref. '26' Summary: 20 errors (**), 0 flaws (~~), 8 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force John Veizades 2 INTERNET DRAFT @Home Network 3 13 March 1997 Erik Guttman 4 Charles Perkins 5 Sun Microsystems 6 Scott Kaplan 8 Service Location Protocol 9 draft-ietf-svrloc-protocol-16.txt 11 Status of This Memo 13 This draft document is a product of the Service Location Working 14 Group of the Internet Engineering Task Force (IETF); it will be 15 submitted to the RFC editor as a standards document. Please respond 16 with comments to the srvloc@tgv.com mailing list. 18 Distribution of this memo is unlimited. 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at 27 any time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as ``work in progress.'' 30 To learn the current status of any Internet-Draft, please check 31 the ``1id-abstracts.txt'' listing contained in the Internet-Drafts 32 Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (North 33 Europe), ftp.nis.garr.it (South Europe), munnari.oz.au (Pacific Rim), 34 ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The Service Location Protocol provides a scalable framework for 39 the discovery and selection of network services. Using this 40 protocol, computers using the Internet no longer need so much static 41 configuration of network services for network based applications. 42 This is especially important as computers become more portable, and 43 users less tolerant or able to fulfill the demands of network system 44 administration. 46 Contents 48 Status of This Memo i 50 Abstract i 52 1. Introduction 1 54 2. Terminology 1 55 2.1. Notation Conventions . . . . . . . . . . . . . . . . . . 3 56 2.2. Service Information and Predicate Representation . . . . 3 57 2.3. Specification Language . . . . . . . . . . . . . . . . . 4 59 3. Protocol Overview 4 60 3.1. Protocol Transactions . . . . . . . . . . . . . . . . . . 5 61 3.2. Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 3.2.1. The ``service:'' URL scheme . . . . . . . . . . 7 63 3.3. Standard Attribute Definitions . . . . . . . . . . . . . 7 64 3.4. Naming Authority . . . . . . . . . . . . . . . . . . . . 8 65 3.5. Interpretation of Service Location Replies . . . . . . . 8 66 3.6. Use of TCP, UDP and Multicast in Service Location . . . . 9 67 3.6.1. Multicast vs. Broadcast . . . . . . . . . . . . 9 68 3.6.2. Service-Specific Multicast Address . . . . . . . 10 69 3.7. Service Location Scaling, and Multicast Operating Modes . 11 71 4. Service Location General Message Format 12 72 4.1. Use of Transaction IDs (XIDs) . . . . . . . . . . . . . . 14 73 4.2. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.3. Authentication Blocks . . . . . . . . . . . . . . . . . . 15 75 4.4. URL Entry Lifetime . . . . . . . . . . . . . . . . . . . 18 77 5. Service Request Message Format 18 78 5.1. Service Request Usage . . . . . . . . . . . . . . . . . . 20 79 5.2. Directory Agent Discovery Request . . . . . . . . . . . . 21 80 5.3. Explanation of Terms of Predicate Grammar . . . . . . . . 22 81 5.4. Service Request Predicate Grammar . . . . . . . . . . . . 24 82 5.5. String Matching for Requests . . . . . . . . . . . . . . 26 84 6. Service Reply Message Format 27 86 7. Service Type Request Message Format 28 88 8. Service Type Reply Message Format 30 90 9. Service Registration Message Format 31 92 10. Service Acknowledgement Message Format 34 94 11. Service Deregister Message Format 36 96 12. Attribute Request Message Format 37 98 13. Attribute Reply Message Format 39 100 14. Directory Agent Advertisement Message Format 41 102 15. Directory Agents 42 103 15.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 42 104 15.2. Finding Directory Agents . . . . . . . . . . . . . . . . 42 106 16. Scope Discovery and Use 44 107 16.1. Protected Scopes . . . . . . . . . . . . . . . . . . . . 45 109 17. Language and Character Encoding Issues 46 110 17.1. Character Encoding and String Issues . . . . . . . . . . 47 111 17.1.1. Substitution of Character Escape Sequences . . . 48 112 17.2. Language-Independent Strings . . . . . . . . . . . . . . 48 114 18. Service Location Transactions 49 115 18.1. Service Location Connections . . . . . . . . . . . . . . 49 116 18.2. No Synchronous Assumption . . . . . . . . . . . . . . . . 50 117 18.3. Idempotency . . . . . . . . . . . . . . . . . . . . . . . 50 119 19. Security Considerations 50 121 20. String Formats used with Service Location Messages 52 122 20.1. Previous Responders' Address Specification . . . . . . . 52 123 20.2. Formal Definition of the ``service:'' Scheme . . . . . . 52 124 20.2.1. Service Type String . . . . . . . . . . . . . . . 53 125 20.3. Attribute Information . . . . . . . . . . . . . . . . . . 53 126 20.4. Address Specification in Service Location . . . . . . . . 54 127 20.5. Attribute Value encoding rules . . . . . . . . . . . . . 55 129 21. Protocol Requirements 55 130 21.1. User Agent Requirements . . . . . . . . . . . . . . . . . 56 131 21.2. Service Agent Requirements . . . . . . . . . . . . . . . 57 132 21.3. Directory Agent Requirements . . . . . . . . . . . . . . 59 134 22. Configurable Parameters and Default Values 60 135 22.1. Service Agent: Use Predefined Directory Agent(s) . . . . 62 136 22.2. Time Out Intervals . . . . . . . . . . . . . . . . . . . 62 138 23. Non-configurable Parameters 63 139 24. Acknowledgments 63 141 A. Appendix: Technical contents of ISO 639:1988 (E/F): "Code for 142 the representation of names of languages" 65 144 B. SLP Certificates 66 146 C. Example of deploying SLP security using MD5 and RSA 68 148 D. Example of use of SLP Certificates by mobile nodes 68 150 E. Appendix: For Further Reading 69 152 1. Introduction 154 Traditionally, users find services by using the name of a network 155 host (a human readable text string) which is an alias for a network 156 address. The Service Location Protocol eliminates the need for 157 a user to know the name of a network host supporting a service. 158 Rather, the user names the service and supplies a set of attributes 159 which describe the service. The Service Location Protocol allows the 160 user to bind this description to the network address of the service. 162 Service Location provides a dynamic configuration mechanism for 163 applications in local area networks. It is not a global resolution 164 system for the entire Internet; rather it is intended to serve 165 enterprise networks with shared services. Applications are modeled 166 as clients that need to find servers attached to the enterprise 167 network at a possibly distant location. For cases where there are 168 many different clients and/or services available, the protocol 169 is adapted to make use of nearby Directory Agents that offer a 170 centralized repository for advertised services. 172 2. Terminology 174 User Agent (UA) 175 A process working on the user's behalf to acquire 176 service attributes and configuration. The User Agent 177 retrieves service information from the Service Agents or 178 Directory Agents. 180 Service Agent (SA) 181 A process working on the behalf of one or more services 182 to advertise service attributes and configuration. 184 Service Information 185 A collection of attributes and configuration information 186 associated with a single service. The Service Agents 187 advertise service information for a collection of 188 service instances. 190 Service The service is a process or system providing a facility 191 to the network. The service itself is accessed using 192 a communication mechanism external to the the Service 193 Location Protocol. 195 Directory Agent (DA) 196 A process which collects information from Service Agents 197 to provide a single repository of service information 198 in order to centralize it for efficient access by User 199 Agents. There can only be one DA present per given 200 host. 202 Service Type 203 Each type of service has a unique Service Type string. 204 The Service Type defines a template, called a "service 205 scheme", including expected attributes, values and 206 protocol behavior. 208 Naming Authority 209 The agency or group which catalogues given Service Types 210 and Attributes. The default Naming Authority is IANA, 211 the Internet Assigned Numbers Authority. 213 Keyword 214 A string describing a characteristic of a service. 216 Attribute 217 A (class, value-list) pair of strings describing a 218 characteristic of a service. The value string may be 219 interpreted as a boolean, integer or opaque value if it 220 takes specific forms (see section 20.5). 222 Predicate 223 A boolean expression of attributes, relations and 224 logical operators. The predicate is used to find 225 services which satisfy particular requirements. See 226 section 5.3. 228 Alphanumeric 229 A character within the range 'a' to 'z', 'A' to 'Z', or 230 '0' to '9'. 232 Scope A collection of services that make up a logical group. 233 See sections 3.7 and 16. 235 Site Network 236 All the hosts accessible within the Agent's multicast 237 radius, which defaults to a value appropriate for 238 reaching all hosts within a site (see section 22). If 239 the site does not support multicast, the agent's site 240 network is restricted to a single subnet. 242 URL A Universal Resource Locator - see [6]. 244 Address Specification 245 This is the network layer protocol dependent mechanism 246 for specifying an Agent. For Internet systems this is 247 part of a URL. 249 2.1. Notation Conventions 251 CAPS Strings which appear in all capital letters are protocol 252 literal. All string comparison is case insensitive, 253 however, (see section 5.5). Some strings are quoted in 254 this document to indicate they should be used literally. 255 Single characters inside apostrophes are included 256 literally. 258 <> Values set off in this manner are fully described in 259 section 20. In general, all definitions of items in 260 messages are described in section 20 or immediately 261 following their first use. 263 | | 264 \ \ Message layouts with this notation indicate a variable 265 | | length field. 267 2.2. Service Information and Predicate Representation 269 Service information is represented in a text format. The goal is 270 that the format be human readable and transmissible via email. The 271 location of network services is encoded as a Universal Resource 272 Locator (URL) which is human readable. Only the datagram headers are 273 encoded in a form which is not human readable. Strings used in the 274 Service Location Protocol are NOT null-terminated. 276 Predicates are expressed in a simple boolean notation using keywords, 277 attributes, and logical connectives, as described in Section 5.4. 279 The logical connectives and subexpressions are presented in 280 prefix-order, so that the connective comes first and the expressions 281 it operates on follow afterwards. 283 2.3. Specification Language 285 In this document, several words are used to signify the requirements 286 of the specification [8]. These words are often capitalized. 288 MUST This word, or the adjective "required", means that 289 the definition is an absolute requirement of the 290 specification. 292 MUST NOT This phrase means that the definition is an absolute 293 prohibition of the specification. 295 SHOULD This word, or the adjective "recommended", means 296 that, in some circumstances, valid reasons may exist 297 to ignore this item, but the full implications must 298 be understood and carefully weighed before choosing 299 a different course. Unexpected results may result 300 otherwise. 302 MAY This word, or the adjective "optional", means that this 303 item is one of an allowed set of alternatives. An 304 implementation which does not include this option MUST 305 be prepared to interoperate with another implementation 306 which does include the option. 308 silently discard 309 The implementation discards the datagram without 310 further processing, and without indicating an error 311 to the sender. The implementation SHOULD provide the 312 capability of logging the error, including the contents 313 of the discarded datagram, and SHOULD record the event 314 in a statistics counter. 316 3. Protocol Overview 318 The basic operation in Service Location is that a client attempts 319 to discover the location of a Service. In smaller installations, 320 each service will be configured to respond individually to each 321 client. In larger installations, services will register their 322 services with one or more Directory Agents, and clients will 323 contact the Directory Agent to fulfill requests for Service Location 324 information. Clients may discover the whereabouts of a Directory 325 Agent by preconfiguration, DHCP [2, 12], or by issuing queries to the 326 Directory Agent Discovery multicast address. 328 3.1. Protocol Transactions 330 The diagram below illustrates the relationships described below: 332 +---------------+ we want this info: +-----------+ 333 | Application | - - - - - - - - - - - -> | Service | 334 +---------------+ +-----------+ 335 /|\ | | 336 | +-------------+ | 337 | | | 338 \|/ \|/ \|/ 339 +---------------+ +-----------+ +----------------+ 340 | User Agent |<-------->| Service | | Service | 341 +---------------+ | Agent | | Agent which | 342 | +-----------+ | does not reply | 343 | | | to UA requests | 344 | \|/ +----------------+ 345 | +-------------+ | 346 +------------------>| Directory |<----------+ 347 | Agent | 348 +-------------+ ___________ 349 /|\ / Many other\ 350 +------------>| SA's | 351 \___________/ 353 The following describes the operations a User Agent would employ 354 to find services on the site's network. The User Agent needs no 355 configuration to begin network interaction. The User Agent can 356 acquire information to construct predicates which describe the 357 services that match the user's needs. The User Agent may build on 358 the information received in earlier network requests to find the 359 Service Agents advertising service information. 361 A User Agent will operate two ways: If the User Agent has already 362 obtained the location of a Directory Agent, the User Agent will 363 unicast a request to it in order to resolve a particular request. 364 The Directory Agent will unicast a reply to the User Agent. The 365 User Agent will retry a request to a Directory Agent until it gets 366 a reply, so if the Directory Agent cannot service the request (say 367 it has no information) it must return an response with zero values, 368 possibly with an error code set. 370 If the User Agent does not have knowledge of a Directory Agent or if 371 there are no Directory Agents available on the site network, a second 372 mode of discovery may be used. The User Agent multicasts a request 373 to the service-specific multicast address, to which the service it 374 wishes to locate will respond. All the Service Agents which are 375 listening to this multicast address will respond, provided they can 376 satisfy the User Agent's request. A similar mechanism is used for 377 Directory Agent discovery; see section 5.2. Service Agents which 378 have no information for the User Agent MUST NOT respond. 380 When a User Agent wishes to obtain an enumeration of ALL services 381 which satisfy the query, a retransmission/convergence algorithm is 382 used. The User Agent resends the request, together with a list of 383 previous responders. Only those Service Agents which are not on 384 the list respond. Once there are no new responses to the request 385 the accumulation of responses is deemed complete. Depending on the 386 length of the request, around 60 previous responders may be listed 387 in a single datagram. If there are more responders than this, the 388 scaling mechanisms described in section 3.7 should be used. 390 While the multicast/convergence model may be important for 391 discovering services (such as Directory Agents) it is the exception 392 rather than the rule. Once a User Agent knows of the location of a 393 Directory Agent, it will use a unicast request/response transaction. 395 The Service Agent SHOULD listen for multicast requests on the 396 service-specific multicast address, and MUST register with an 397 available Directory Agent. This Directory Agent will resolve 398 requests from User Agents which are unicasted using TCP or UDP. This 399 means that a Directory Agent must first be discovered, using DHCP, 400 the DA Discovery Multicast address, the multicast mechanism described 401 above, or manual configuration. See section 5.2. 403 A Service Agent which does not respond to multicast requests will not 404 be useful in the absence of Directory Agents. Some Service Agents 405 may not include this functionality, if an especially lightweight 406 implementation is required. 408 If the service is to become unavailable, it should be deregistered 409 with the Directory Agent. The Directory Agent responds with an 410 acknowledgment to either a registration or deregistration. Service 411 Registrations include a lifetime, and will eventually expire. 412 Service Registrations need to be refreshed by the Service Agent 413 before their Lifetime runs out. If need be, Service Agents can 414 advertise signed URLs to prove that they are authorized to provide 415 the service. 417 3.2. Schemes 419 The Service Location Protocol, designed as a way for clients to 420 access resources on the network, is a natural application for 421 Universal Resource Locators (URLs). It is intended that by re-using 422 URL specification and technology from the World Wide Web, clients and 423 servers will be more flexible and able to be written using already 424 existing code. Moreover, it is hoped that browsers will be written 425 to take advantage of the similarity in locator format, so that a 426 client can dynamically formulate requests for services that are 427 resolved differently depending upon the circumstances. 429 3.2.1. The ``service:'' URL scheme 431 The service URL scheme is used by Service Location. It is used to 432 specify a Service Location. Many Service Types will be named by 433 including a scheme name after the ``service:'' scheme name. Service 434 Types are used by SAs to register and deregister Services with DAs. 435 It is also used by SAs and DAs to return Service Replies to UAs. The 436 formal definition of the ``service:'' URL scheme is in section 20.2. 437 The format of the information which follows the ``service:'' scheme 438 should as closely as possible follow the URL structure and semantics 439 as formalized by the IETF standardization process. 441 Well known Service Types are registered with the IANA and templates 442 are available as RFCs. Private Service Types may also be supported. 444 3.3. Standard Attribute Definitions 446 Service Types used with the Service Location Protocol must describe 447 the following: 449 Service Type string of the service 450 Attributes and Keywords 451 Attribute Descriptions and interpretations 453 Service Types not registered with IANA will use their own Naming 454 Authority string. The registration process for new Service Types is 455 defined in [14]. 457 Services which advertise a particular Service Type must support the 458 complete set of standardized attributes. They may support additional 459 attributes, beyond the standardized set. Unrecognized attributes 460 MUST be ignored by User Agents. 462 Service Type names which begin with "x-" are guaranteed not to 463 conflict with any officially registered Service Type names. It 464 is suggested that this prefix be used for experimental or private 465 Service Type names. Similarly, attribute names which begin with "x-" 466 are guaranteed not to be used for any officially registered attribute 467 names. 469 A service of a given Service Type should accept the networking 470 protocol which is implied in its definition. If a Service Type 471 can accept multiple protocols, configuration information SHOULD 472 be included in the Service Type attribute information. This 473 configuration information will enable an application to use the 474 results of a Service Request and Attribute Request to directly 475 connect to a service. 477 See section 20.2.1 for the format of a Service Type String as used in 478 the Service Location Protocol. 480 3.4. Naming Authority 482 The Naming Authority of a service defines the meaning of the 483 Service Types and attributes registered with and provided by Service 484 Location. The Naming Authority itself is a string which uniquely 485 identifies an organization. If no string is provided IANA is the 486 default. IANA stands for the Internet Assigned Numbers Authority. 488 Naming Authorities may define Service Types which are experimental, 489 proprietary or for private use. The procedure to use is to create 490 a 'unique' Naming Authority string and then specify the Standard 491 Attribute Definitions as described above. This Naming Authority will 492 accompany registration and queries, as described in sections 5 and 9. 494 3.5. Interpretation of Service Location Replies 496 Replies should be considered to be valid at the time of delivery. 497 The service may, however, fail or change between the time of the 498 reply and the moment an application seeks to make use of the service. 499 The application making use of Service Location MUST be prepared for 500 the possibility that the service information provided is either stale 501 or incomplete. In the case where the service information provided 502 does not allow a User Agent to connect to a service as desired, the 503 Service Request and/or Attribute Request may be resubmitted. 505 Service specific configuration information (such as which protocol 506 to use) should be included as attribute information in Service 507 Registrations. These configuration attributes will be used by 508 applications which interpret the Service Location Reply. 510 3.6. Use of TCP, UDP and Multicast in Service Location 512 The Service Location Protocol requires the implementation of UDP 513 (connectionless) and TCP (connection oriented) transport protocols. 514 The latter is used for bulk transfer, only when necessary. 515 Connections are always initiated by an agent request or registration, 516 not by a replying Directory Agent. Service Agents and User Agents 517 use ephemeral ports for transmitting information to the service 518 location port, which is 427. 520 The Service Location discovery mechanisms typically multicast 521 messages to as many enterprise networks as needed to establish 522 service availability. The protocol will operate in a broadcast 523 environment with limitations detailed in section 3.6.1. 525 3.6.1. Multicast vs. Broadcast 527 The Service Location Protocol was designed for use in networks 528 where DHCP is available, or multicast is supported at the network 529 layer. To support this protocol when only network layer broadcast is 530 supported, the following procedures may be followed. 532 3.6.1.1. Single Subnet 534 If a network is not connected to any other networks simple network 535 layer broadcasts will work in place of multicast. 537 Service Agents SHOULD and Directory Agents MUST listen for broadcast 538 Service Location request messages to the Service Location port. This 539 allows UAs which lack multicast capabilities to still make use of 540 Service Location on a single subnet. 542 3.6.1.2. Multiple Subnets 544 The Directory Agent provides a central clearing house of information 545 for User Agents. If the network is designed so that a Directory 546 Agent address is statically configured with each User Agent 547 and Service Agent, the Directory Agent will act as a bridge for 548 information that resides on different subnets. The Directory Agent 549 address can be dynamically configured with Agents using DHCP. The 550 address can also be determined by static configuration. 552 As dynamic discovery is not feasible in a broadcast environment with 553 multiple subnets and manual configuration is difficult, deploying 554 DAs to serve enterprises with multiple subnets will require use of 555 multicast discovery with multiple hops (i.e., TTL > 1 in the IP 556 header). 558 3.6.2. Service-Specific Multicast Address 560 This mechanism is used so that the number of datagrams any one 561 service agent receives is minimized. The Service Location General 562 Multicast Address MAY be used to query for any service, though one 563 SHOULD use the service-specific multicast address if it exists. 565 If the site network does not support multicast then the query 566 SHOULD be broadcast to the Service Location port. If, on the other 567 hand, the underlying hardware will not support the number of needed 568 multicast addresses the Service Location General Multicast Address 569 MAY be used. Service Agents MUST listen on this multicast address 570 as well as the service-specific multicast addresses for the service 571 types they advertise. 573 Service-Specific Multicast Addresses are computed by calculating a 574 string hash on the Service Type string. The Service Type string MUST 575 first be converted to an ASCII string from whatever character set it 576 is represented in, so the hash will have well-defined results. 578 The string hash function is modified from a code fragment attributed 579 to Chris Torek: 581 /* 582 * SLPhash returns a hash value in the range 0-1023 for a 583 * string of single-byte characters, of specified length. 584 */ 585 unsigned long SLPhash (const char *pc, unsigned int length) { 586 unsigned long h = 0; 587 while (length-- != 0) { 588 h *= 33; 589 h += *pc++; 590 } 591 return (0x3FF & h); /* round to a range of 0-1023 */ 592 } 594 This value is added to the base range of Service Specific Discovery 595 Addresses, to be assigned by IANA. These will be 1024 contiguous 596 multicast addresses. 598 3.7. Service Location Scaling, and Multicast Operating Modes 600 In a very small network, with few nodes, no DA is required. A user 601 agent can detect services by multicasting requests. Service Agents 602 will then reply to them. Further, Service Agents which respond to 603 user requests must be used to make service information available. 604 This does not scale to environments with many hosts and services. 606 When scaling Service Location systems to intermediate sized networks, 607 a central repository (Directory Agent) may be added to reduce the 608 number of Service Location messages transmitted in the network 609 infrastructure. Since the central repository can respond to 610 all Service and Attribute Requests, fewer Service and Attribute 611 Replies will be needed; for the same reason, there is no need to 612 differentiate between Directory Agents. 614 A site may also grow to such a size that it is not feasible to 615 maintain only one central repository of service information. In this 616 case more Directory Agents are needed. The services (and service 617 agents) advertised by the several Directory Agents are collected 618 together into logical groupings called "Scopes". 620 All Service Registrations that have a scope must be registered with 621 all DAs (within the appropriate multicast radius) of that scope which 622 have been or are subsequently discovered. Service Registrations 623 which have no scope are only registered with unscoped DAs. User 624 Agents make requests of DAs whose scope they are configured to use. 626 Service Agents MUST register with unscoped DAs even if they are 627 configured to specifically register with DAs which have a specific 628 scope or set of scopes. User Agents MAY query DAs without scopes, 629 even if they are configured to use DAs with a certain scope. This 630 is because any DA with no scope will have all the available service 631 information. 633 Scoped user agents SHOULD always use a DA which supports their 634 configured scope when possible instead of an unscoped DA. This will 635 prevent the unscoped DAs from becoming overused and thus a scaling 636 problem. 638 It is possible to specially configure Service Agents to register 639 only with a specific set of DAs (see Section 22.1). In that case, 640 services may not be available to User Agents via all Directory 641 Agents, but some network administrators may deem this appropriate. 643 There are thus 3 distinct operating modes. The first requires no 644 administrative intervention. The second requires only that a DA be 645 run. The last requires that all DAs be configured to have scope and 646 that a coherent strategy of assigning scopes to services be followed. 647 Users must be instructed which scopes are appropriate for them to 648 use. This administrative effort will allow users and applications to 649 subsequently dynamically discover services without assistance. 651 The first mode (no DAs) is intended for a LAN. The second mode 652 (using a DA or DAs, but not using scopes) scales well to a group 653 of interconnected LANs with a limited number of hosts. The third 654 mode (with DAs and scopes) allows the SLP protocol to be used in an 655 internetworked campus environment. 657 If scoped DAs are used, they will not accept unscoped registrations 658 or requests. UAs which issue unscoped requests will discover only 659 unscoped services. They SHOULD use a scope in their requests if 660 possible and SHOULD use a DA with their scope in preference to an 661 unscoped DA. In a large campus environment it would be a bad idea to 662 have ANY unscoped DAs: They attract ALL registrations and will thus 663 present a scaling problem eventually. 665 A subsequent protocol document will describe mechanisms for 666 supporting a service discovery protocol for the global Internet. 668 4. Service Location General Message Format 670 The following header is used in all of the message descriptions below 671 and is abbreviated by using "Service Location header =" followed by 672 the function being used. 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Version | Function | Length | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 |O|M|U|A|F| rsvd| Dialect | Language Code | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Char Encoding | XID | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Version This protocol document defines version 1 of the Service 685 Location protocol. 687 Function Service Location datagrams can be identified as to their 688 operation by the function field. The following are the 689 defined operations: 691 Message Type Abbreviation Function Value 693 Service Request SrvReq 1 694 Service Reply SrvRply 2 695 Service Registration SrvReg 3 696 Service Deregister SrvDereg 4 697 Service Acknowledge SrvAck 5 698 Attribute Request AttrRqst 6 699 Attribute Reply AttrRply 7 700 DA Advertisement DAAdvert 8 701 Service Type Request SrvTypeRqst 9 702 Service Type Reply SrvTypeRply 10 704 Length The number of bytes in the message, including the Service 705 Location Header. 707 O The 'Overflow' bit. See Section 18 for the use of this 708 field. 710 M The 'Monolingual' bit. Requests with this bit set 711 indicate the User Agent will only accept responses in 712 the language (see section 17) that is indicated by the 713 Service or Attribute Request. 715 U The 'URL Authentication Present' bit. See sections 4.2, 716 4.3, 9, and 11 for the use of this field. 718 A The 'Attribute Authentication Present' bit. See 719 sections 4.2, 4.3, and 13 for the use of this field. 721 F If the 'F' bit is set in a Service Acknowledgement, the 722 directory agent has registered the service as a new 723 entry, not as an updated entry. 725 rsvd MUST be zero. 727 Dialect Dialect tags will be used by future versions of the 728 Service Location Protocol to indicate a variant of 729 vocabulary used. This field is reserved and MUST be 730 set to 0 for compatibility with future versions of the 731 Service Location Protocol. 733 Language Code 734 Strings within the remainder of the message which follows 735 are to be interpreted in the language encoded (see 736 section 17 and appendix A) in this field. 738 Character Encoding 739 The characters making up strings within the remainder of 740 the message may be encoded in any standardized encoding 741 (see section 17.1). 743 Transaction Identifier (XID) 744 The XID (transaction ID) field allows the requester to 745 match replies to individual requests (see section 4.1). 747 Note that, whenever there is an Attribute Authentication 748 block, there will also be a URL Authentication block. 749 Thus, it is an error to have the 'A' bit set without also 750 having the 'U' bit set. 752 4.1. Use of Transaction IDs (XIDs) 754 Retransmission is used to ensure reliable transactions in the 755 Service Location Protocol. If a User Agent or Service Agent sends 756 a message and fails to receive an expected response, the message 757 will be sent again. Retransmission of the same Service Location 758 datagram should not contain an updated XID. It is quite possible the 759 original request reached the DA or SA, but reply failed to reach the 760 requester. Using the same XID allows the DA or SA to cache its reply 761 to the original request and then send it again, should a duplicate 762 request arrive. This cached information should only be held very 763 briefly (CONFIG_INTERVAL_0.) Any registration or deregistration at 764 a Directory Agent, or change of service information at a SA should 765 flush this cache so that the information returned to the client is 766 always valid. 768 The requester creates the XID from an initial random seed and 769 increments it by one for each request it makes. The XIDs will 770 eventually wrap back to zero and continue incrementing from there. 772 Directory Agents use XID values in their DA Advertisements to 773 indicate their state (see section 15.2). 775 4.2. URL Entries 777 When URLs are registered, they have lifetimes and lengths, and may 778 be authenticated. These values are associated with the URL for 779 the duration of the registration. The association is known as a 780 "URL-entry", and has the following format: 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Lifetime | Length of URL | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | | 788 \ URL \ 789 | | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | (if present) URL Authentication Block ..... 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 Lifetime The length of time that the registration is valid, in 795 the absence of later registrations or deregistration. 797 Length of URL 798 The length of the URL, measured in bytes and < 32768. 800 URL Authentication Block 801 (if present) A timestamped authenticator (section 4.3) 803 The URL conforms to RFC 1738 [6]. If the 'U' bit is set in the 804 message header, the URL is followed by an URL Authentication 805 Block. If the scheme used in the URL does not have a standardized 806 representation, the minimal requirement is: 808 service::// 810 "service" is the URL scheme of all Service Location Information 811 included in service registrations and service replies. Each URL 812 entry contains the service: scheme name. It may also 813 include an except in the case of a reply to a Service 814 Type request (see section 7). 816 4.3. Authentication Blocks 818 Authentication blocks are used to authenticate service registrations 819 and deregistrations. URLs are registered along with an URL 820 Authentication block to retain the authentication information in the 821 URL entry for subsequent use by User Agents who receive a Service 822 Reply containing the URL entry. Service attributes are registered 823 along with an Attribute Authentication block. Both authentication 824 blocks have the format illustrated below. 826 If a service registration is accompanied by authentication which can 827 be validated by the DA, the DA MUST validate any subsequent service 828 deregistrations, so that unauthorized entities cannot invalidate 829 such registered services. Likewise, if a service registration 830 is accompanied by an Attribute Authentication block which can be 831 validated by the DA, the DA MUST validate any subsequent attribute 832 registrations, so that unauthorized entities cannot invalidate such 833 registered attributes. 835 To avoid replay attacks which use previously validated 836 deregistrations, the deregistration or attribute registration 837 message must contain a timestamp for use by the DA. To avoid replay 838 attacks which use previously validated registrations to nullify a 839 valid deregistration, registrations must also contain a timestamp. 841 An authentication block has the following format: 843 0 1 2 3 844 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 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | | 847 + Timestamp + 848 | | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Block Structure Descriptor | Length | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Structured Authenticator ... 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 Timestamp A 64-bit value formatted as specified by the Network 856 Time Protocol (NTP) [17]. 858 Block Structure Descriptor (BSD) 859 A value describing the structure of the Authenticator. 860 The only value currently defined is 1, for 861 Object-Identifier. 863 Length The length of the Authenticator 865 Structured Authenticator 866 An algorithm specification, and the authentication data 867 produced by the algorithm. 869 The algorithms to use for encryption, decryption and message 870 digest calculation are identified within the authenticator itself. 871 When producing a URL Authentication block, the authentication 872 data produced by the algorithm identified within the Structured 873 Authenticator is a message digest D calculated over the following 874 ordered stream of data: 876 CHARACTER ENCODING OF URL (2 bytes in network byte order) 877 LIFETIME (2 bytes in network byte order) 878 LENGTH OF URL (2 bytes in network byte order) 879 URL (n bytes) 880 TIMESTAMP (8 bytes in SNTP format [17]) 882 When producing a URL Authentication block, the authentication 883 data produced by the algorithm identified within the Structured 884 Authenticator is a message digest D calculated over the following 885 ordered stream of data: 887 ATTRIBUTE CHARACTER ENCODING (2 bytes in network byte order) 888 LENGTH OF ATTRIBUTES (2 bytes in network byte order) 889 ATTRIBUTES (n bytes) 890 TIMESTAMP (8 bytes in SNTP format [17]) 892 In either case, D is then encrypted using the key of the protected 893 scope to produce N bytes of authenticator info. The length field of 894 the authenticator block is set to N. The N bytes of the encrypted 895 message digest D follow. 897 To verify an authenticator, the UA or DA computes the message digest 898 D from the same data as the SA did. The UA or DA then decrypts the N 899 bytes of authenticator data to obtain D'. If D is the same as D' the 900 URL has been authenticated. 902 There is currently only one value defined for the Block Structure 903 Descriptor (BSD): 905 1 The Structured Authenticator uses AlgorithmIdentifiers [10] 906 in ASN.1 [9] notation to identify the algorithm and 907 encrypted data format. 909 BSD values 0 and 2-255 are reserved for future standardized structure 910 descriptors. Other values may be defined in a site-dependent 911 fashion, and are not intended be used to denote well-known structure 912 descriptor formats. 914 Every Service Location Protocol entity (User Agent, Service Agent, 915 or Directory Agent) which is to be configured for use with protected 916 scopes MUST implement "md5WithRSAEncryption" [4] and be able to 917 associate it with BSD value == 1 to verify the authentication. 919 4.4. URL Entry Lifetime 921 The Lifetime field is set to the number of seconds the reply can be 922 cached by any agent. A value of 0 means the information must not 923 be cached. User Agents MAY cache service information, but if they 924 do, they must provide a way for applications to flush this cached 925 information and issue the request directly onto the network. 927 Services should be registered with DAs with a Lifetime, the suggested 928 value being CONFIG_INTERVAL_1. The service must be reregistered 929 before this interval elapses, or the service advertisement will 930 no longer be available. Thus, services which vanish and fail to 931 deregister eventually become automatically deregistered. 933 5. Service Request Message Format 935 The Service Request is used to obtain URLs from a Directory Agent or 936 Service Agents. 938 The format of the Service Request is as follows: 940 0 1 2 3 941 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 942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 | Service Location header (function = SrvReq) | 944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 945 |length of prev resp list string|| 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | | 948 \ \ 949 | | 950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 951 | length of predicate string | Service Request | 952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 | | 954 \ Service Request , contd. \ 955 | | 956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 958 If a UA issues a request which will result in a reply which is 959 too large, the SA or DA will return an abbreviated response (in a 960 datagram the size of the site's MTU) which has the 'Overflow' bit 961 flag set. The UA must then issue the request again using TCP. 963 The is described in sections 7 964 and 20.1. 966 After a User Agent restarts (say, after rebooting of a system, 967 loading of the network kernel), Service Requests should be delayed 968 for some random time uniformly distributed within a one second 969 interval centered about a configured delay value (by default, 970 CONFIG_INTERVAL_4). 972 The Service Request allows the User Agent to specify the Service Type 973 of the service and a Predicate in a specific language. The general 974 form of a Service Request is shown below: 976 [.]/[]/[]/ 978 The punctuation is necessary even where the fields are omitted. 980 - The refers to the Service Type. For each type of 981 service available, there is a unique Service type name string. 982 See section 20.2.1. 984 - The is the Naming Authority. This string determines the 985 semantic interpretation of the attribute information in the 986 part of the Service Request. 988 - The is a string used to restrict the range of the query. 989 Scope is determined administratively, at a given site. It is 990 not necessarily related to network topology (see Section 16). 991 Leaving this field out means that the request can be satisfied 992 only by unscoped service advertisements. 994 - The string is the Where Clause of the request. It 995 contains a query which allows the selection of those service 996 instances which the User Agent is interested in. The query 997 includes attributes, boolean operators and relations. (See 998 section 5.3.) 1000 In the case of a multicast service request, a list of previous 1001 responders is sent. This list will prevent those in the list from 1002 responding, to be sure that responses from other sources are not 1003 drowned out. The request is multicast repeatedly (with a recommended 1004 wait interval of CONFIG_INTERVAL_2) until there are no new responses, 1005 or a certain time (CONFIG_INTERVAL_3) has elapsed. Different timing 1006 values are applied to a Service Request used for Directory Agent 1007 Discovery, see Section 5.2. 1009 In order for a request to succeed in matching registered information, 1010 the following conditions must be met: 1012 1. The result must have the same Service Type as the request. 1014 2. It must have the same Naming Authority. 1016 3. It must have the same scope. (If the scope of the request 1017 was omitted, the request will only match services which were 1018 registered with no scope. Note that a scoped request WILL match 1019 all unscoped Services). 1021 4. The conditions specified in the Where Clause must match the 1022 attributes and keywords registered for the service. 1024 5.1. Service Request Usage 1026 The User Agent may form Service Requests using preconfigured 1027 knowledge of a Service Type's attributes. It may also issue 1028 Attribute Requests to obtain the attribute values for a Service Type 1029 before issuing Service Requests (see Section 13). Having obtained 1030 the attributes which describe a particular kind of service from an 1031 Attribute Request, or using configured knowledge of a service's 1032 attributes, the User Agent can build a predicate that describes the 1033 service needs of the user. 1035 Service Requests may be sent directly to a Directory Agent. Suppose 1036 a printer supporting the lpr protocol is needed on the 12th floor 1037 which has UNRESTRICTED_ACCESS and prints 12 pages per minute. 1038 Suppose further that a Attribute Request indicates that there is a 1039 printer on the 12th floor, a printer that prints 12 pages per minute, 1040 and a printer that offers UNRESTRICTED_ACCESS. To check whether they 1041 are same printer, issue the following request: 1043 lpr//(& (PAGES PER MINUTE==12) 1044 (UNRESTRICTED_ACCESS) 1045 (LOCATION==12th FLOOR))/ 1047 Suppose there is no such printer. The Directory Agent responds 1048 with a Service Reply with 0 in the number of responses and no reply 1049 values. 1051 The User Agent then tries a less restrictive query to find a printer, 1052 using the 12th floor as "where" criteria. 1054 lpr//(LOCATION==12th FLOOR)/ 1056 In this case, there is now only one reply: 1058 Returned URL: service:lpr://igore.wco.ftp.com:515/draft 1060 The Address Specification for the printer is: igore.wco.ftp.com:515, 1061 containing the name of the host managing the requested printer. 1062 Files would be printed by spooling to that port on that host. The 1063 word 'draft' refers to the name of the print queue the lpr server 1064 supports. 1066 In the absence of a Directory Agent, the request above could be 1067 multicast. In this case it would be sent to the Service Specific 1068 Multicast Address for "service:printer" and not to the Directory 1069 Agent. Service Agents that can satisfy the predicate will reply. 1070 Service Agents which cannot support the character set of the request 1071 MUST return CHARSET_NOT_UNDERSTOOD in the SrvRply. In all other 1072 circumstances, Service Agents which cannot satisfy the reply do not 1073 send any reply at all. 1075 The only way a User Agent can be sure there are no services which 1076 match the query is by retrying the request (CONFIG_INTERVAL_8). If 1077 no response comes, the User Agent gives up and assumes there are no 1078 such printers. 1080 Another form of query is a simpler 'join' query. Its syntax has no 1081 parentheses or logical operators. Each term is conjoined (AND-ed 1082 together.) Rewriting the initial query provides an example: 1084 lpr//PAGES PER MINUTE==12, 1085 UNRESTRICTED_ACCESS, 1086 LOCATION==12th FLOOR/ 1088 5.2. Directory Agent Discovery Request 1090 Normally a Service Request returns a Service Reply. The sole 1091 exception to this is a Service Request for the Service Type 1092 "directory-agent". This Service Request is answered with a DA 1093 Advertisement. 1095 Without configured knowledge of a Directory Agent (DA), a User Agent 1096 or Service Agent uses a Service Request to discover a DA. (See 1097 section 15.1 for mechanisms by which a client may be configured to 1098 have knowledge of a DA.) Such a Service Request used for Directory 1099 Agent Discovery includes a predicate of the form: 1101 directory-agent/// 1103 This query is always sent to the Directory Agent Discovery multicast 1104 address. The Service Type of a Directory Agent is "directory-agent", 1105 hence it is the Service Type used in the request. No scope is 1106 included in the request, so all Directory Agents will reply. This is 1107 the only request which omits a scope which all Directory Agents MUST 1108 respond to. Normally, a Directory Agent with a scope ONLY responds 1109 to requests with that scope. No Naming Authority is included, so 1110 "IANA" is assumed. We want to reach all the available directory 1111 agents. If the scope were supplied, only DAs supporting that scope 1112 would reply. 1114 DA Advertisement Replies may arrive from different sources, similar 1115 in form to: 1117 URL returned: service:directory-agent://slp-resolver.catch22.com 1118 Scope returned: ACCOUNTING 1120 URL returned: service:directory-agent://204.182.15.66 1121 Scope returned: JANITORIAL SERVICES 1123 The DA Advertisement format is defined in Section 14. 1125 If the goal is merely to discover any Directory Agent, the first 1126 reply will do. If the goal, however, is to discover all reachable 1127 DAs, the request must be retransmitted after an interval (the 1128 recommended time is CONFIG_INTERVAL_5). This retransmitted request 1129 will include a list of DAs which have already responded. See 1130 sections 7 and 20.1. Directory Agents which receive the request will 1131 only respond if they are not on this list. After there are no new 1132 replies, all DAs are presumed to have been discovered. 1134 If a DA fails to respond after CONFIG_INTERVAL_6 seconds, the UA or 1135 Service Agent should use a different DA. DA addresses may be cached 1136 from previous discovery attempts, preconfigured, or by use of DHCP 1137 (see section 15.2). If no such DA responds, DA discovery should be 1138 used to find a new DA. Only after CONFIG_INTERVAL_7 seconds should 1139 it be assumed that no DA exists and multicast based Service Requests 1140 should be used. 1142 5.3. Explanation of Terms of Predicate Grammar 1144 A predicate has a simple structure, which depends on parentheses, 1145 commas and slashes to delimit the elements. Examples of proper usage 1146 are given throughout this document. The terms used in the grammar 1147 are as follows: 1149 predicate: 1151 Placed in a Service Request, this is interpreted by a Service 1152 Agent or Directory Agent to determine what information to 1153 return. 1155 scope: 1157 If this is absent in a Service Request, the request will match 1158 only services registered without a scope. If it is present, 1159 only services registered under that scope or are unscoped will 1160 match the request. 1162 where-clause: 1164 This determines which services the request matches. An empty 1165 where-clause will match all services. The request will be 1166 limited to services which have the specified Service Type, so 1167 the where-clause is not the sole factor in picking out which 1168 services match the request. 1170 where-list: 1172 The where-list is a logical expression. It can be a single 1173 expression, a disjunction or a conjunction. A single 1174 expression must apply for the where-clause to match. A 1175 disjunction matches if any expression in the OR list matches. 1176 A conjunction matches only if all elements in the AND list 1177 match. 1179 Note that there is no logical negation operator: This is 1180 because there is no notion of returning "everything except" 1181 what matches a given criteria. 1183 A where-list can be nested and complex. For example, the 1184 following requires that three subexpressions must all be true: 1186 (& (| ) 1187 1188 (& ) 1189 ) 1191 Notice that white space, tabs or carriage returns can be added 1192 anywhere outside query-items. Each list has 2 or more items in 1193 it, and lists can be nested. Services which fulfill the entire 1194 logical expression match the where-clause. 1196 '(' '|' ')' and '(' '&' ')' are 1197 degenerate expressions but they should be tolerated. They are 1198 equivalent to . 1200 query-item: 1202 A query item has the form: 1204 '(' ')' 1206 or 1208 '(' ')' 1210 Examples of this would be: 1212 (SOME ATTRIBUTE == SOME VALUE) 1213 (RESERVED) 1214 (QUEUE LENGTH <= 234) 1216 query-join: 1218 The query-join is a comma delimited list of conditions which 1219 the service must satisfy in order to match the query. The 1220 items are considered to be logically conjoined. Thus the 1221 query-join: 1223 ATTR1=VALUE1, KEYWORD1, KEYWORD2, ATTR2>=34 1225 is equivalent to the where-list: 1227 (& (ATTR1=VALUE1) (KEYWORD1) (KEYWORD2) (ATTR2>=34)) 1229 The query-join cannot be mixed with a where-list. It is 1230 provided as a convenient mechanism to provide a statement of 1231 necessary conditions without building a logical expression. 1233 5.4. Service Request Predicate Grammar 1235 Service Requests can precisely describe the services they need by 1236 including a Predicate the body of the Request. This Predicate must 1237 be constructed according to the grammar below. 1239 ::= ['.']'/''/''/' 1241 ::= string representing type of service. Only 1242 alphanumeric characters, '+', and '-' are allowed. 1244 ::= string representing the Naming Authority. 1245 Only alphanumeric characters, '+', 1246 and '-' are allowed. If this field is 1247 omitted then "IANA" is assumed. 1249 ::= string representing the directory agent scope. 1250 '/', ',' (comma) and ':' are not allowed in 1251 this string. The scopes "LOCAL" and "REMOTE" 1252 are reserved. 1254 ::= class name of an attribute of a given Service 1255 Type. This tag cannot include the following 1256 characters: '(', ')', ',', '=', '!', '>', 1257 '<', '/', '*', except where escaped (see 17.1.) 1259 ::= a class name of an attribute which will have 1260 no values. This string has the same limits 1261 as the , except that white space 1262 internal to the keyword is illegal. 1264 ::= | 1265 | 1266 1268 ::= 1269 That is NOTHING, or white space. 1271 ::= '(' '&' ')' | 1272 '(' '|' ')' | 1273 '(' ')' 1274 '(' ')' 1276 ::= | 1277 1278 ::= | 1279 | 1280 ',' | 1281 ',' 1283 ::= 1285 ::= "!=" | "==" | '<' | "<=" | '>' | ">=" 1287 ::= any string (see Section 20.5 for the ways 1288 in which attr-vals are interpreted.) 1289 Value strings may not contain '/', ',' 1290 '=', '<', '>', or '*' except where escaped (see 17.1.). 1292 '(' and ')' may be used in attribute values 1293 for the purpose of encoding a binary values. 1294 Binary encodings (See 20.5) may 1295 include the above reserved characters. 1297 5.5. String Matching for Requests 1299 All strings are case insensitive, with respect to string matching on 1300 queries. All preceding or trailing blanks should not be considered 1301 for a match, but blanks internal to a string are relevant. 1302 For example, " Some String " matches "SOME STRING", 1303 but not "some string". 1305 String matching may only be performed over the same character sets. 1306 If a request cannot be satisfied due to a lack of support for the 1307 character set of the request a CHARSET_NOT_UNDERSTOOD error is 1308 returned. 1310 String comparisons (using comparison operators such as '<' or 1311 '>=') are done using lexical ordering in the character set of the 1312 registration, not using any language specific rules. The ordering 1313 is strictly by the character value, i.e. "0" < "A" is true when the 1314 character set is US-ASCII, since "0" has the value of 48 and "A" has 1315 the value 65. 1317 The special character '*' may precede or follow a string in order to 1318 allow substring matching. If the '*' precedes a string, it matches 1319 any attribute value which ends with the string. If the string ends 1320 with a '*', it matches any attribute value which begins with the 1321 string. Finally, if a string begins and ends with a '*', the string 1322 will match any attribute value which contains the string. 1324 Examples: 1326 "bob*" matches "bob", "bobcat", and "bob and sue" 1327 "*bob" matches "bob", "bigbob", and "sue and bob" 1328 "*bob*" matches "bob", "bobcat", "bigbob", and "a bob I know" 1330 String matching is done after escape sequences have been substituted. 1331 See sections 17, 5.3, 17.1. 1333 6. Service Reply Message Format 1335 The format of the Service Reply Message is: 1337 0 1 2 3 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Service Location header (function = SrvRply) | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Error Code | URL Entry count | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1344 | ... 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | . | 1347 \ . \ 1348 | . | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | ... 1351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1353 Each Service Reply message is composed of a list of URL Entries. 1355 The Error Code may have one of the following values: 1357 0 Success 1359 LANGUAGE_NOT_SUPPORTED 1360 A SA or DA returns this when a request is received 1361 from a UA which is in a language for which there is no 1362 registered Service Information and the request arrived 1363 with the Monolingual bit set. See Section 17. 1365 PROTOCOL_PARSE_ERROR 1366 A SA or DA returns this error when a SrvRply is received 1367 which cannot be parsed or the declared string lengths 1368 overrun the message. 1370 SCOPE_NOT_SUPPORTED 1371 A DA will return this error if it receives a request 1372 which has a scope not supported by the DA. An SA will 1373 not return this error; it will simply not reply to the 1374 multicast request. 1376 CHARSET_NOT_UNDERSTOOD 1377 If the DA or SA receives a request or registration in a 1378 character set which it does not support, it will return 1379 this error. 1381 Each in the list has the form defined in Section 4.2. 1382 The URL entries in the reply have no delimiters between them, other 1383 than the length fields. The URL length fields indicate where the 1384 URL strings end. If the presence of an URL Authenticator block is 1385 signalled by the 'U' bit, the length of the authenticator block 1386 is determined by information within the block as discussed in 1387 section 4.3. A User Agent MAY use the authentication block to 1388 determine whether the Service Agent advertising the URL is, in fact, 1389 authorized to offer the indicated service. If, in a list of URL 1390 entries, some of the URLs indicate services which are in protected 1391 scopes (see section 16.1) while other URLs in the list indicate 1392 services which are not in protected scopes, the latter must still 1393 have Authentication Blocks, but the length of the authentcitor is 1394 shown as zero, and no authentication need be done. 1396 7. Service Type Request Message Format 1398 The Service Type Request is used to determine all the types of 1399 services supported on a network. 1401 The request should be sent directly to a DA (though it may also be 1402 sent to the Service Location General Multicast Address), in order 1403 to find out all services available on the site network (which are 1404 advertised by Directory Agents and Service Agents.) If no DA is 1405 available, a User Agent MAY issue more than one request to insure 1406 that all replies have been received. In each subsequent request, a 1407 User Agent includes those Service Types that it is aware of. When no 1408 new replies arrive within CONFIG_INTERVAL_3 from a request, the User 1409 Agent can presume that it has acquired a complete set of available 1410 Service Types. 1412 The format of a Service Type Request is: 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Service Location header (function = SrvTypeRqst) | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | length of prev resp string || 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | | 1422 \ \ 1423 | | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1425 | length of naming authority | | 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | | 1428 \ , continued \ 1429 | | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1431 | length of Scope String | | 1432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1433 | | 1434 \ , continued \ 1435 | | 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1438 Note that the is a comma delimited 1439 list. (See section 20.1.) The 'length of prev responder list' field 1440 indicates the length of the comma delimited list string. A previous 1441 responder list with 3 elements takes this form: 1443 ,, 1445 The Naming Authority, if included, will limit the replies to Service 1446 Type Requests to Service Types which have the specified Naming 1447 Authority. If this field is omitted (i.e., the length field is 1448 zero), the default Naming Authority ("IANA") is assumed. If the 1449 length field is -1, service types from all naming authorities are 1450 requested. 1452 The Scope String Field, if included, will limit replies to Service 1453 Types which have the specified scope or are unscoped. If this field 1454 is omitted, all Service Types (from the specified Naming Authority) 1455 are returned. 1457 8. Service Type Reply Message Format 1459 The Service Type Reply has the following format: 1461 0 1 2 3 1462 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 1463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1464 | Service Location header (function = SrvTypeRply) | 1465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1466 | Error Code | number of service types | 1467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1468 | | 1469 \ \ 1470 | | 1471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1472 | . . . | 1473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1474 | | 1475 \ \ 1476 | | 1477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1479 The format of a Service Type Item is as follows: 1481 0 1 2 3 1482 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 1483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1484 | length of Service Type String | | 1485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1486 | | 1487 \ , continued \ 1488 | | 1489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1491 The Error Code may have one of the following values: 1493 0 Success 1495 PROTOCOL_PARSE_ERROR 1496 A SA or DA returns this error when a SrvTypeRqst is 1497 received which cannot be parsed. 1499 SCOPE_NOT_SUPPORTED 1500 A DA which is configured to have a scope will return this 1501 error if it receives a SrvTypeRqst which is set to have a 1502 scope which it does not support. An SA will not return 1503 this error, it will simply silently discard the multicast 1504 request. 1506 CHARSET_NOT_UNDERSTOOD 1507 If the DA receives a SrvTypeRqst in a character set which 1508 it does not support, it MUST use this error. 1510 The service type's name is provided in the . If 1511 the service type has a naming authority other than "IANA" it should 1512 be returned following the service type string and a "." character. 1513 See section 20.2.1 for the formal definition of this field. User 1514 Agents calculate Service Specific Multicast addresses based on a hash 1515 of the Service Type (see Section 3.6.2). This multicast address may 1516 then be used for issuing Service and Attribute Requests directly to 1517 SAs. 1519 The following are examples of Service Type Strings which might be 1520 found in Service Type Replies: 1522 service:lpr:// 1523 service:http:// 1524 service:nfs:// 1526 9. Service Registration Message Format 1528 After a Service Agent has found a Directory Agent, it begins to 1529 register its advertised services one at a time. A Service Agent 1530 must wait for some random time uniformly distributed within the 1531 range specified by CONFIG_INTERVAL_11 before registering again. 1532 Registration is done using the Service Registration message 1533 specifying all attributes for a service. If the service registration 1534 in a protected scope 16.1, then the service MUST include both a URL 1535 Authentication block and an Attribute Authentication block (see 1536 section 4.3). In that case, the service agent MUST set both the 'U' 1537 bit and the 'A' bit (see section 4). 1539 A Directory Agent must acknowledge each service registration request. 1540 If authentication blocks are included, the Directory Agent MUST 1541 verify the authentication before registering the service. This 1542 requires obtaining key information, either by preconfiguration, 1543 maintenance of a security association with the service agent, or 1544 acquiring the appropriate certificate. 1546 The format of a Service Registration is: 1548 0 1 2 3 1549 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 1550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1551 | Service Location header (function = SrvReg) | 1552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1553 | | 1554 \ \ 1555 | | 1556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1557 | Length of Attr List String | | 1558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1559 | | 1560 \ , Continued. \ 1561 | | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | (if present) Attribute Authentication Block ... 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1566 The is defined at the end of Section 4.2. The 1567 is defined in Section 20.3. The Attribute Authentication 1568 Block, which is only present if the 'A' bit is set in the message 1569 header, is defined in section 4.3. 1571 Service registration may use a connectionless protocol (e.g. UDP), 1572 or a connection oriented protocol (e.g. TCP). If the registration 1573 operation may contain more information than can be sent in one 1574 datagram, the Service Agent MUST use a connection oriented protocol 1575 to register itself with the DA. When a Service Agent registers the 1576 same attribute class more than once for a service instance, the 1577 Directory Agent overwrites the all the values associated with that 1578 attribute class for that service instance. Separate registrations 1579 must be made for each language that the service is to be advertised 1580 in. 1582 If a SA attempts to register a service with a DA and the registration 1583 is larger than the site path MTU, then the DA will reply with a 1584 SrvAck, with the error set to INVALID_REGISTRATION and the 'Overflow' 1585 byte set. 1587 An example of Service Registration information is: 1589 Lifetime (seconds): 16-bit unsigned integer 1590 URL (at least): service::// 1591 Attributes (if any): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2) 1593 In order to offer continuously advertised services, Service Agents 1594 should start the reregistration process before the Lifetime they used 1595 in the registration expires. 1597 An example of a service registration (valid for 3 hours) is as 1598 follows: 1600 Lifetime: 10800 1601 URL: service:lpr://igore.wco.ftp.com:515/draft 1602 Attributes: (SCOPE=DEVELOPMENT), 1603 (PAPER COLOR=WHITE), 1604 (PAPER SIZE=LETTER), 1605 UNRESTRICTED_ACCESS, 1606 (LANGUAGE=POSTSCRIPT, HPGCL), 1607 (LOCATION=12 FLOOR) 1609 The same registration could be done again, as shown below, in German; 1610 however, note that "lpr", "service", and "SCOPE" are reserved terms 1611 and will remain in the language they were originally registered 1612 (English). 1614 Lifetime: 10800 1615 URL: service:lpr://igore.wco.ftp.com:515/draft 1616 Attributes: (SCOPE=ENTWICKLUNG), 1617 (PAPIERFARBE=WEISS), 1618 (PAPIERFORMAT=BRIEF), 1619 UNBEGRENTZTER_ZUGANG, 1620 (DRUECKERSPRACHE=POSTSCRIPT,HPGCL), 1621 (STANDORT=11 ETAGE) 1623 Scoped registrations must contain the SCOPE attribute. Unscoped 1624 registrations must be registered with all unscoped Directory Agents. 1626 Registrations of a previously registered service are considered 1627 an update. If such an attribute registration is performed in a 1628 protected scope (see section 16.1), a new Attribute Authentication 1629 block must also be included, and the 'A' bit set in the registration 1630 message header. 1632 The new registration's attributes replace the previous 1633 registration's, but do not effect attributes which were 1634 included previously and are not present in the update. 1636 For example, suppose service:x://a.org has been registered 1637 with attributes A=1, B=2, C=3. If a new registration comes for 1638 service:x://a.org with attributes C=30, D=40, then the attributes for 1639 the service after the update are A=1, B=2, C=30, D=40. 1641 In the example above, the SCOPE is set to DEVELOPMENT (in English) 1642 and ENTWICKLUNG (in German). Recall that all strings in a message 1643 must be in one language, which is specified in the header. The 1644 string SCOPE is *not* translated, as it is one of the reserved 1645 strings in the Service Location Protocol (see section 17.2.) 1647 The Directory Agent may return a server error in the acknowledgment. 1648 This error is carried in the Error Codes field of the service 1649 location message header. A Directory Agent MUST decline to register 1650 a service if it is specified with an unsupported scope. In this case 1651 a SCOPE_NOT_SUPPORTED error is returned in the SrvAck. A Directory 1652 Agent MUST NOT accept Service Registrations which have an unsupported 1653 scope unless it is an unscoped Directory Agent, in which case it MUST 1654 accept all Service Registrations. 1656 An unscoped Service Registration will match all requests. A request 1657 which specifies a certain scope will therefore return services which 1658 have that scope and services which are unscoped. It is strongly 1659 suggested that one should use scopes in all registrations or none. 1660 See Sections 16 and 3.7 for details. 1662 When the URL entry accompanying a registration also contains an 1663 authentication block (section 4.3), the DA MUST perform the indicated 1664 authentication, and subsequently indicate the results in the Service 1665 Acknowledgement message. 1667 10. Service Acknowledgement Message Format 1669 A Service Acknowledgement is sent as the result of a DA receiving 1670 and processing a Service Registration or Service Deregistration. An 1671 acknowledgment indicating success must have the error code set to 1672 zero. Once a DA acknowledges a service registration it makes the 1673 information available to clients. 1675 0 1 2 3 1676 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 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 | Service Location header (function = SrvAck) | 1679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1680 | Error Code | 1681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1683 The Error Code may have one of the following values: 1685 0 Success 1686 PROTOCOL_PARSE_ERROR 1687 A DA returns this error when the SrvReg or SrvDereg is 1688 received which cannot be parsed or the declared string 1689 lengths overrun the message. 1691 INVALID_REGISTRATION 1692 A DA returns this error when a SrvReg or SrvDeReg is 1693 invalid. For instance, an invalid URL, unknown or 1694 malformed attributes, or deregistering an unregistered 1695 service all cause this error to be reported. 1697 SCOPE_NOT_SUPPORTED 1698 A DA which is configured to have a scope will return this 1699 error if it receives a SrvReq which is set to have a 1700 scope which it does not support. 1702 CHARSET_NOT_UNDERSTOOD 1703 If the DA receives a SrvReg or SrvDereg in a character 1704 set which it does not support, it will return this error. 1706 AUTHENTICATION_ABSENT 1707 If DA has been configured to require an authentication 1708 for any service registered in the requested scope, and 1709 there are no authentication blocks in the registration, 1710 the DA will return this error. 1712 AUTHENTICATION_FAILED 1713 If the registration contains an authentication block 1714 which fails to match the correct result as calculated 1715 (see section 4.3) over the URL or attribute data to be 1716 authenticated, the DA will return this error. 1718 If the Directory Agent accpets a Service Registration, and already 1719 has an existing entry, it updates the existing entry with the new 1720 lifetime information and possibly new attributes and new attribute 1721 values. Otherwise, if the registration is acceptable (including all 1722 necessary authentication checks) the Directory Agent creates a new 1723 entry, and sets the 'F' bit in the Service Acknowledgement returned 1724 to the Service Agent. 1726 11. Service Deregister Message Format 1728 When a service is no longer available for use, the Service Agent must 1729 deregister itself from Directory Agents that it has been registered 1730 with. A service uses the following PDU to deregister itself. 1732 0 1 2 3 1733 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 1734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1735 | Service Location header (function = SrvDereg) | 1736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1737 | length of URL | URL | 1738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1739 | | 1740 \ URL of Service to Deregister, contd. \ 1741 | | 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | (if present) authentication block ..... 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | length of string | | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | | 1748 \ , continued \ 1749 | | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1752 The Service Agent should retry this operation if there is no response 1753 from the Directory Agent. The Directory Agent acknowledges this 1754 operation with a Service Acknowledgment message. Once the Service 1755 Agent receives an acknowledgment indicating success, it can assume 1756 that the service is no longer advertised by the Directory Agent. The 1757 Error Code in the Acknowledgment of the Service Deregistration may 1758 have the same values as described in section 10. 1760 The Service Deregister Information sent to the directory agent has 1761 the following form: 1763 service::// 1764 Attribute tags (if any): ATTR1,KEYWORD,ATTR2 1766 This will deregister the specified attributes from the service 1767 information from the directory agent. If no attribute tags are 1768 included, the entire service information is deregistered in every 1769 language and every scope it was registered in. To deregister the 1770 printer from the preceding example, use: 1772 service:lpr://igore.wco.ftp.com:515/draft 1774 If the service was originally registered with a URL entry containing 1775 a URL authentication block, then the Service Deregistration message 1776 header MUST have the 'U' bit set, and the URL entry is then followed 1777 by the authentication block, with the authenticator calculated over 1778 the URL data, the timestamp, and the length of the authenticator as 1779 explained in section 4.3. In this calculation, the lifetime of the 1780 URL data is considered to be zero, no matter what the current value 1781 for the remaining lifetime of the registered URL. 1783 12. Attribute Request Message Format 1785 The Attribute Request is used to obtain attribute information. The 1786 UA supplies a request and the appropriate attribute information is 1787 returned. 1789 If the UA supplies only a Service Type, then the reply includes 1790 all attributes and all values for that Service Type. The reply 1791 includes only those attributes for which services exist and are 1792 advertised by the DA or SA which received the Attribute Request. 1793 Since different instances of a given service can, and very likely 1794 will, have different values for the attributes defined by the Service 1795 Type, the User Agent must form a union of all attributes returned by 1796 all service Agents. The Attribute information will be used to form 1797 Service Requests. 1799 If the UA supplies a URL, the reply will contain service information 1800 corresponding to that URL. 1802 Attribute Requests include a 'select clause'. This may be used to 1803 limit the amount of information returned. If the select clause is 1804 empty, all information is returned. Otherwise, the UA supplies 1805 a comma delimited list of attribute tags and keywords. If the 1806 attribute or keyword is defined for a service, it will be returned 1807 in the Attribute Reply, along with all registered values for that 1808 attribute. If the attribute selected has not been registered for 1809 that URL or Service Type, the attribute or keyword information is 1810 simply not returned. 1812 The Attribute Request message has the following form: 1814 0 1 2 3 1815 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 1816 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1817 | Service Location header (function = AttrRqst) | 1818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1819 |length of prev resp list string|| 1820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1821 | | 1822 \ , continued \ 1823 | | 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | length of URL | URL | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | | 1828 \ URL, continued \ 1829 | | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | length of | | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | | 1834 \ , continued \ 1835 | | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | length of | | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | | 1840 \ , continued \ 1841 | | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 The functions exactly as introduced 1845 in Section 7. See also Section 20.1. 1847 The URL can take two forms: Either it is simply a Service 1848 Type, such as "service:http:", or it can be a URL, such as 1849 "service:lpr://igore.wco.ftp.com:515/draft". In the former case, all 1850 attributes and the full range of values for each attribute for the 1851 Service Type is returned. In the latter case, only the attributes 1852 for the service whose URL is defined are returned. 1854 The Scope String is provided so that Attribute Requests for Service 1855 Types can be made so that only the Attribute information pertaining 1856 to a specific scope will be returned. This field is ignored in the 1857 case when a full URL is sent in the Attribute Request. The rules for 1858 encoding of the Scope String are given in Section 5.4. 1860 The select list takes the form: 1862 ::= | 1863 ',' 1865 ::= | | '*' 1867 ::= the partial class name of an attribute 1868 If followed by an '*', it matches all class names 1869 which begin with the partial tag. If preceded by a 1870 '*' it matches all class names which end with 1871 partial tag. If both preceded and followed by '*' 1872 it matches all class names which contain the 1873 partial tag. 1875 For definitions of and see 5.4. 1877 An example of a select-list following the printer example is: 1879 PAGES PER MINUTE, UNRESTRICTED_ACCESS, LOCATION 1881 If sent to a Directory Agent, the number of previous responders is 1882 zero and there are no Previous Responder Address Specification. 1883 These fields are only used for repeated multicasting, exactly as for 1884 the Service Request. 1886 13. Attribute Reply Message Format 1888 An Attribute Reply Message takes the form: 1890 0 1 2 3 1891 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 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | Service Location header (function = AttrRply) | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | Error Code | length of string | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | | 1898 \ \ 1899 | | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 The Error Code may have the following values: 1904 0 Success 1905 LANGUAGE_NOT_SUPPORTED 1906 A SA or DA returns this when a request is received 1907 from a UA which is in a language for which there is no 1908 registered Service Information and the request arrived 1909 with the Monolingual bit set. See Section 17. 1911 PROTOCOL_PARSE_ERROR 1912 A DA or SA returns this error when a AttrRqst is received 1913 which cannot be parsed or the declared string lengths 1914 overrun the message. 1916 SCOPE_NOT_SUPPORTED 1917 A DA which is configured to have a scope will return this 1918 error if it receives an AttrRqst which is set to have 1919 a scope which it does not support. SAs will silently 1920 discard multicast AttrRqst messages for scopes they do 1921 not support. 1923 CHARSET_NOT_UNDERSTOOD 1924 If the DA receives an AttrRqst in a character set which 1925 it does not support, it will return this error. SAs will 1926 silently discard multicast AttrRqst messages which arrive 1927 using character sets they do not support. 1929 The (attribute list) has the same form as the attribute 1930 list in a Service Registration, see Section 20.3 for a formal 1931 definition of this field. 1933 An Attribute Request for "lpr" might elicit the following reply 1934 (UNRESTRICTED_ACCESS is a keyword): 1936 (PAPER COLOR=WHITE,BLUE), 1937 (PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED), 1938 UNRESTRICTED_ACCESS, 1939 (PAGES PER MINUTE=1,3,12), 1940 (LOCATION=12th, NEAR ARUNA'S OFFICE), 1941 (QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD) 1943 If the message header has the 'A' bit set, the Attribute Reply will 1944 have an Attribute Authentication block set. In this case, the 1945 Attribute Authenticator must be returned with the entire list of 1946 attributes, exactly as it was registered by an SA in a protected 1947 scope. In this case, the URL was registered in a protected scope 1948 and the UA included a URL but not a select clause. If the AttrRqst 1949 specifies that only certain attributes are to be returned, the DA 1950 does not (typically cannot) compute a new Authenticator so it simply 1951 returns the attributes without an authenticator block. 1953 A UA which wishes to obtain authenticated attributes for a service in 1954 a protected scope MUST therefore must include a particular URL and no 1955 select list with the AttrRqst. 1957 14. Directory Agent Advertisement Message Format 1959 Directory Agent Advertisement Messages have the following format: 1961 0 1 2 3 1962 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 1963 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1964 | Service Location header (function = DAAdvert) | 1965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1966 | Error Code | Length of URL | 1967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1968 | | 1969 \ URL \ 1970 | | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Length of | | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | | 1975 \ , continued \ 1976 | | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 The Error Code is set when a DA Advertisement is returned as the 1980 result of a Service Request. It will always be set to 0 in the case 1981 of an unsolicited DA Advertisement. The Error Code may take the 1982 values specified in Section 6. 1984 The URL corresponds to the Directory Agent's location. The 1985 is a comma delimited list of scopes which the DA 1986 supports, in the following format: 1988 ::= | ',' 1989 ::= String representing a scope 1991 See Section 5.4 for the lexical rules regarding . 1993 DA Advertisements sent in reply to a Directory Agent Discovery 1994 Request has the same format as the unsolicited DA Advertisement, for 1995 example: 1997 URL: service:directory-agent://SLP-RESOLVER.CATCH22.COM 1998 SCOPE List: ADMIN 2000 The Directory Agent can be reached at the Address Specification 2001 returned, and supports the SCOPE called "ADMIN". 2003 15. Directory Agents 2005 15.1. Introduction 2007 A Directory Agent acts on behalf of many Service Agents. It acquires 2008 information from them and acts as a single point of contact to supply 2009 that information to User Agents. 2011 The queries that a User Agent multicasts to Service Agents (in an 2012 environment without a Directory Agent) are the same as queries that 2013 the User Agent might unicast to a Directory Agent. A User Agent may 2014 cache information about the presence of alternate Directory Agents to 2015 use in case a selected Directory Agent fails. 2017 Aside from enhancing the scalability of the protocol (see 2018 section 3.7), running multiple DAs provides robustness of operation. 2019 The DAs may have replicated service information which remain 2020 accessible even when one of the DAs fail. Directory Agents, in the 2021 future, may use mechanisms outside of this protocol to coordinate 2022 the maintenance of a distributed database of Service Location 2023 information, and thus scale to enterprise networks or larger 2024 administrative domains. 2026 Each Service Agent must register with all DAs they are configured to 2027 use. UAs may choose among DAs they are configured to use. 2029 Locally, Directory Agent consistency is guaranteed using mechanisms 2030 in the protocol. There isn't any Directory to Directory Agent 2031 protocol yet. Rather, passive detection of DAs by SAs ensures that 2032 eventually service information will be registered consistently 2033 between DAs. Invalid data will age out of the Directory Agents 2034 leaving only transient stale registrations even in the case of a 2035 failure of a Service Agent. 2037 15.2. Finding Directory Agents 2039 A User or Service Agent may be statically configured to use a 2040 particular DA. This is discouraged unless the application resides on 2041 a network where any form of multicast or broadcast is impossible. 2043 Alternatively, a host which uses DHCP [2, 12] may use it to obtain a 2044 Directory Agent's address. DHCP options 78 and 79 have been assigned 2045 for this purpose [22]. 2047 The third way to discover DAs is dynamically. This is done by 2048 sending out a Directory Agent Discovery request (see Section 5.2). 2050 Lastly, the agent may be informed passively as follows: 2052 When a Directory Agent first comes on-line it sends an unsolicited DA 2053 Advertisement to the Service Location general multicast address. If 2054 a DA supports a particular scope or set of scopes these are placed in 2055 the reply. The class for this attribute is 'SCOPE'. 2057 Every CONFIG_INTERVAL_9 a Directory Agent will send an unsolicited 2058 DA Advertisement. This will ensure that eventually it will be 2059 discovered by all applications which are concerned. 2061 When a Directory Agent first comes up it begins with 0 as its XID, 2062 and increments this by one each time it sends an unsolicited DA 2063 Advertisement. When the counter wraps, it should go from 0xFFFF to 2064 0x0100, not 0. 2066 If the Directory Agent has stored all of the service information in 2067 a nonvolatile store, it should initially set the XID to 0x100, as it 2068 is not coming up 'stateless.' If it stores service registrations in 2069 memory only, it will restart without any state. It should indicate 2070 this by resetting its XID to 0. 2072 All Service Agents which receive the unsolicited DA Advertisement 2073 should examine its XID. If the Directory Agent has never before 2074 been heard from or if the XID is less than it was previously and 2075 less than 256, the Service Agent should assume the DA does not have 2076 its service registration, even if it once did. If this is the case 2077 and the DA has the proper scope, the SA should register all service 2078 information with the Directory Agent, after waiting a random interval 2079 CONFIG_INTERVAL_10. 2081 When a Service Agent or User Agent first comes on-line it must issue 2082 a Directory Agent Discovery Request unless it is using static or DHCP 2083 configuration, as described in 5.2. 2085 A Service Agent registers information with ALL newly discovered 2086 Directory Agents when either of the above two events take place. 2087 When scopes are being used, a Service Agent SHOULD choose a set of 2088 scopes to be advertised in and need only register with Directory 2089 Agents that support the scopes in which they wish to be registered. 2090 Services MUST be registered with DAs that support their scope and 2091 those which have no scope, unless specifically configured not to do 2092 so (see section 22.1.) 2093 Once a User Agent becomes aware of a Directory Agent it will unicast 2094 its queries there. In the event that more than one Directory Agent 2095 is detected, it will select one to communicate with. When scopes 2096 are supported, the User Agent will direct its queries to different 2097 Directory Agents depending on which scopes are appropriate domains 2098 for the query to be answered in. 2100 The protocol will cause all DAs (of the same scope) to eventually 2101 obtain consistent information. Thus one DA should be as good as any 2102 other for obtaining service information. There may be temporary 2103 inconsistencies between DAs. 2105 16. Scope Discovery and Use 2107 The scope mechanism in the Service Location Protocol enhances its 2108 scalability. The primary use of scopes is to provide the capability 2109 to organize a site network along administrative lines. A set of 2110 services can be assigned to a given department of an organization, 2111 to a certain building or geographical area or for a certain purpose. 2112 The users of the system can be presented with these organizational 2113 elements as a top level selection, before services within this domain 2114 are sought. 2116 A site network that has grown beyond a size that can be reasonably 2117 serviced by a few DAs can use the scope mechanism. DAs have the 2118 attribute class "SCOPE". The values for this attribute are a list 2119 of strings that represent the administrative areas for which this 2120 Directory Agent is configured. The semantics and language of the 2121 strings used to describe the scope are almost entirely the choice of 2122 the administrative entity of the particular domain in which these 2123 scopes exist. The values of SCOPE should be configurable, so the 2124 system administrator can set its value. The scopes "LOCAL" and 2125 "REMOTE" are reserved and SHOULD NOT be used. Use of these reserved 2126 values is to be defined in a future protocol document. 2128 Services with the attribute SCOPE should only be registered with DAs 2129 which support the same scope or DAs which have no scope. 2131 Directory Agents advertise their available scopes. A Service Agent 2132 may then choose a scope in which to register, and SHOULD register 2133 with all Directory Agents in that scope, as well as all DAs which 2134 have no scope. Failure to be comprehensive in registration according 2135 to this rule will mean that the service advertisement may not be 2136 available to all User Agents. 2138 A Directory Agent which has a scope will return advertisements 2139 in response to Directory Agent Discovery requests with the scope 2140 information included. Note that the "service:directory-agent" scheme 2141 is registered with the IANA naming authority (which is automatically 2142 selected by leaving the Naming Authority field empty.) 2144 The query: 2146 directory-agent/MATH DEPT// 2148 Could receive the following DA Advertisement: 2150 Returned URL: service:directory-agent://diragent.blah.edu 2151 Returned SCOPE: MATH DEPT 2153 The same Directory Agent if it had no scope value would reply: 2155 Returned URL: service:directory-agent://diragent.void.com 2156 Returned SCOPE: 2158 If a Directory Agent supported more than one scope it would reply as: 2160 Returned URL: service:directory-agent://srv.domain.org 2161 Returned SCOPE: MATH DEPT,ENGLISH DEPT,CS DEPT 2163 A DA which has no scope will reply to any Directory Agent Discovery 2164 Request. 2166 Being a member of a scope means that an agent SHOULD use those 2167 Directory Agents that support its scope. User Agents send all 2168 requests to DAs which support the indicated scope. Services are 2169 registered with the DA(s) in their scope. For a UA to find a service 2170 that is registered in a particular scope it must send requests to a 2171 DA which supports the indicated scope. There is no limitation on 2172 scope membership built into the protocol; that is to say, a User 2173 Agent or Service Agent may be a member of more than one scope. 2174 Membership is open to all, unless some external authorization 2175 mechanism is added to limit access. 2177 16.1. Protected Scopes 2179 Scope membership MAY also define the security access and 2180 authorization for services in the scope; such scopes are called 2181 protected scopes. If a User Agent wishes to be sure that Service 2182 Agents are authorized to provide the service they advertise, then 2183 the User Agent should request services from a protected scope which 2184 has been configured to have the necessary authentication mechanism 2185 and keys distributed to the Service Agents within the scope. A 2186 directory agent distributing URLs for services in a protected scope 2187 will reject any registrations or deregistrations for service agents 2188 which cannot provide cryptographically strong authentication to prove 2189 their authorization to provide the services. 2191 For instance, if a campus registrar wishes to find a working printer 2192 to produce student grade information for mailing, the registrar would 2193 require the printing user agent to transmit the printable output 2194 only to those printing Service Agents which have been registered in 2195 the appropriate protected scope. Notice that each service agent 2196 is, under normal circumstances, validated two times: once when 2197 registering with the directory agent, and once when the user agent 2198 validates the URL received with the Service Reply. This protects 2199 against the possibilities of malicious Directory Agents as well as 2200 malicious Service Agents. 2202 Note that services in protected scopes provide separate 2203 authentication for their URL entry, and for their attributes. This 2204 follows naturally from the needs of the protocol operation. User 2205 Agents which specify a service type and attributes needed for service 2206 in that service type will not receive attribute information from the 2207 directory agent; they will only receive the appropriate URL entries. 2208 Only the information returned needs to be authenticated. 2210 User agents which receive attribute information for a particular 2211 URL (see section 12), on the other hand, need to authenticate the 2212 attributes when they are returned (see section 13). In this case, 2213 there may be much more data to authenticate, but this operation 2214 is also performed much less often, usually only while the user is 2215 browsing the available network resources. 2217 17. Language and Character Encoding Issues 2219 All Service Registrations declare the language in which the strings 2220 in the service attributes are written by specifying the appropriate 2221 code in the message header. For each language the Service advertises 2222 a separate registration takes place. Each of these registrations 2223 uses the same URL to indicate that they refer to the same service. 2225 If a Service is fully deregistered (the URL is given in the Service 2226 Deregister request, without any attribute information) then the 2227 Service needs to be deregistered only once. This will effectively 2228 deregister the service in all languages it has been registered in. 2230 If, on the other hand, attribute information is included in the 2231 Service Deregistration request, a separate Service Deregistration 2232 of selected attributes must be undertaken in each language in which 2233 service information has been provided to the DA by a Service Agent. 2235 Service Registrations in different languages are mutually 2236 unintelligible. They share no information except for their service 2237 type and URL with which they were registered. No attempt is made 2238 to match queries with "language independence." Instead, queries are 2239 handled using string matching against registrations in the same 2240 language as the query. 2242 Service Types which are standardized will have definitions for 2243 all attributes and value strings. Official translations to other 2244 languages of the attribute tags and values may be created and 2245 submitted as part of the standard; this is not feasible for all 2246 languages. For those languages which are not defined as part of the 2247 Service Type, a best effort translation of the standard definitions 2248 of the Service type's attribute strings MAY be used. 2250 All Service Requests specify a requested language in the message 2251 header. The Directory Agent or Service Agent will respond in the 2252 same language as the request, if it has a registration in the same 2253 language as the request. If this language is not supported, and the 2254 Monolingual bit is not specified, a reply can be sent in the default 2255 language (which is English.) If the 'monolingual bit' flag in the 2256 header is set and the requested language is not supported, a SrvRply 2257 is returned with the error field set to LANGUAGE_NOT_SUPPORTED. 2259 If a query is in a supported language on a SA or DA, but has a 2260 different dialect than the available service information, the query 2261 MUST be serviced on a best-effort basis. If possible, the query 2262 should be matched against the same dialect. If that is not possible, 2263 it MAY be matched against any dialect of the same language. 2265 17.1. Character Encoding and String Issues 2267 Values for character encoding can be found in IANA's database 2268 http://www.isi.edu/in-notes/iana/assignments/character-sets 2269 and have the values referred by the MIBEnum value. 2271 The encoding will determine the interpretation of all character data 2272 which follows the Service Location Protocol header. There is no way 2273 to mix ASCII and UNICODE, for example. All responses must be in the 2274 character set of the request, or use US-ASCII. If a request is sent 2275 to a DA or SA or a registration is sent to a DA, which is unable to 2276 manipulate or store the character set of the incoming message, the 2277 request will fail. The SA or DA returns a CHARSET_NOT_UNDERSTOOD 2278 error in a SrvAck message in this case. Requests using US-ASCII will 2279 never fail for this reason, since all SAs and DAs must be able to 2280 accept this character set. 2282 Certain characters are illegal in certain contexts of the protocol. 2283 Since the protocol is largely character string based, in some 2284 contexts characters are used as protocol delimiters. In these cases 2285 the delimiting characters must not be used as 'data text.' 2287 17.1.1. Substitution of Character Escape Sequences 2289 The Service Location Protocol has an 'escape mechanism' which 2290 is consistent with HTTP 2.0 [5] and SGML [16]. If the character 2291 sequence "&#" is followed by one or more digits, followed by 2292 a semicolon ';' the entire sequence is interpreted as a single 2293 character. The digits are interpreted as a decimal value in the 2294 character set of the request, as specified by the header. Thus, in 2295 US-ASCII , would be interpreted as a comma. Substitution of 2296 these escape strings must be done in all and strings 2297 present in SrvReq and AttrRqst messages. Only numerical character 2298 references are accepted, not 'Entity References,' as defined in HTML. 2299 These escape values should only be used to provide a mechanism for 2300 including reserved characters in attribute tag and value strings. 2302 The interpretation of these escape values is different than in 2303 HTML in one respect: In HTML the escape values are considered to 2304 be in the ISO Latin-1 character set. In Service Location they 2305 are interpreted in the character set defined in the header of the 2306 message. 2308 This escape mechanism allows characters like commas to be included in 2309 attribute tags and values, which would otherwise be illegal as the 2310 comma is a protocol delimiter. 2312 Attribute tags and values of different languages are considered to be 2313 mutually unintelligible. A query in one language SHOULD use service 2314 information registered in that language. 2316 17.2. Language-Independent Strings 2318 Some strings, such as Service Type names, have standard definitions. 2319 These strings should be considered as tokens and not as words in a 2320 language to be translated. 2322 Reserved String Section xDefinition 2323 --------------- ------- -------------------------------------- 2324 SCOPE 3, 15 Used to limit the matching of requests. 2325 SERVICE 6, 9 The URL scheme of all Service Location 2326 information registered with a DA or 2327 returned from a Service Request. 2329 20.2.1 Used in all service registrations 2330 and replies. 2331 domain names 20.4 A fully qualified domain name, used 2332 in registrations and replies. 2333 IANA 3.3 The default naming authority. 2334 LOCAL 16 Reserved. 2335 REMOTE 16 Reserved. 2336 TRUE 20.5 Boolean true. 2337 FALSE 20.5 Boolean false. 2339 18. Service Location Transactions 2341 18.1. Service Location Connections 2343 When a Service Location Request or Attribute Request results in a 2344 UDP reply from a Service or Directory Agent that will overflow a 2345 datagram, the User Agent can open a connection to the Agent and 2346 reissue the request over the connection. The reply will be returned 2347 with the overflow bit set (see section 4). The reply will contain as 2348 much data as will fit into a single datagram. If no MTU information 2349 is available for the route, assume that the MTU is 1400; this value 2350 is configurable (see section 22). 2352 When a request results in overflowed data that cannot be correctly 2353 parsed (say, because of duplicate or dropped IP datagrams), a 2354 User Agent that wishes to reliably obtain the overflowed data must 2355 establish a TCP connection with the Directory Agent or Service Agent 2356 with the data. When the request is sent again with a new XID, the 2357 reply is returned over the connection. 2359 When registration data exceeds one datagram in length, the Service 2360 Registration should be made by establishing a connection with a 2361 Directory Agent and sending the registration over the connection 2362 stream. 2364 Directory Agents and Service Agents must respond to connection 2365 requests; services whose registration data can overflow a datagram 2366 must be able to use TCP to send the registration. User Agents 2367 should be able to make Service and Attribute Requests using TCP. If 2368 they fail to implement this, they must be able to interpret partial 2369 replies and/or reissue requests with more selective criteria to 2370 reduce the size of the replies. 2372 A connection initiated by an Agent may be used for a single 2373 transaction. It may also be used for multiple transactions. Since 2374 there are length fields in the message headers, the Agents may send 2375 multiple requests along a connection and read the return stream for 2376 acknowledgments and replies. 2378 The initiating agent is responsible for closing the TCP connection. 2379 The DA should wait at least CONFIG_INTERVAL_12 before closing an idle 2380 connection. DAs and SAs SHOULD eventually close idle connections 2381 to ensure robust operation, even when the agent which opened a 2382 connection neglects to close it. 2384 18.2. No Synchronous Assumption 2386 There is no requirement that one transaction complete before a 2387 given host begins another. An agent may have multiple outstanding 2388 transactions, initiated either using UDP or TCP. 2390 18.3. Idempotency 2392 All Service Location actions are idempotent. Of course registration 2393 and deregistration will change the state of a DA, but repeating these 2394 actions with the same XID will have exactly the same effect each 2395 time. Repeating a registration with a new XID has the effect of 2396 extending the lifetime of the registration. 2398 19. Security Considerations 2400 The Service Location Protocol provides for authentication of Service 2401 Agents as part of the scope mechanism, and consequently, integrity 2402 of the data received as part of such registrations. Service 2403 Location does not provide confidentiality. Because the objective 2404 of this protocol is to advertise services to a community of users, 2405 confidentiality might not generally be needed when this protocol is 2406 used in non-sensitive environments. Specialized schemes might be 2407 able to provide confidentiality, if needed in the future. Sites 2408 requiring confidentiality should implement the IP Encapsulating 2409 Security Payload (ESP) [3] to provide confidentiality for Service 2410 Location messages. 2412 Using unprotected scopes, an adversary might easily use this protocol 2413 to advertise services on servers controlled by the adversary and 2414 thereby gain access to users' private information. Further, an 2415 adversary using this protocol will find it much easier to engage in 2416 selective denial of service attacks. Sites that are in potentially 2417 hostile environments (e.g. are directly connected to the Internet) 2418 should consider the advantages of distributing keys associated with 2419 protected scopes prior to deploying the sensitive directory agents or 2420 service agents. 2422 Service Location is useful as a bootstrap protocol. It may be used 2423 in environments in which no preconfiguration is possible. In such 2424 situations, a certain amount of "blind faith" is required: Without 2425 any prior configuration it is impossible to use any of the security 2426 mechanisms described above. Service Location will make use of 2427 the mechanisms provided by the Security Area of the IETF for key 2428 distribution as they become available. At this point it would only 2429 be possible to gain the benefits associated with the use of protected 2430 scopes if some cryptographic information can be preconfigured with 2431 the end systems before they use Service Location. For User Agents, 2432 this could be as simple as supplying the public key of a Certificate 2433 Authority. See Appendix B. 2435 20. String Formats used with Service Location Messages 2437 The following section supplies formal definitions for fields and 2438 protocol elements introduced in the sections indicated. 2440 Protocol Element Defined in Used in 2441 ----------------------------------- ------------ ------------ 2442 20.1 SrvReq 2443 Service Request 5.4 SrvReq 2444 URL 20.2 SrvReg, 2445 SrvDereg, 2446 SrvRply 2447 20.3 SrvReg, 2448 SrvRply, 2449 AttrRply 2450 9 SrvReg 2451 11 SrvDereg 2452 20.2.1 AttrRqst 2454 20.1. Previous Responders' Address Specification 2456 The previous responders' Address Specification is specified as 2458 ::= 2459 | 2460 , 2462 i.e., a list separated by commas with no intervening white space. 2463 The Address Specification is the address of the Directory Agent 2464 or Service Agent which supplied the previous response. The 2465 format for Address Specifications in Service Location is defined 2466 in section 20.4. The comma delimiter is required between each 2467 . The use of dotted decimal IP address notation should 2468 only be used in environments which have no Domain Name Service. 2470 Example: 2472 RESOLVO.NEATO.ORG,128.127.203.63 2474 20.2. Formal Definition of the ``service:'' Scheme 2476 A URL with a ``service:'' scheme is used in the SrvReg, SrvDereg, 2477 SrvRply and AttrRqst messages in Service Location. URLs are defined 2478 in RFC 1738 [6]. A URL with the ``service:'' scheme must contain at 2479 least: 2481 ::= service::// 2483 where: 2485 service the URL scheme for Service Location, to return 2486 Replies. 2488 a string; Service Types may be standardized 2489 by developing a specification for the "service 2490 type"-specific part and registering it with IANA. 2491 See sections 20.2.1 and 3.3. 2493 the service access point of the service. It is the 2494 network address or domain name where the service can 2495 be accessed. See section 20.4. 2497 The ``service:'' scheme may be followed by any legal URL. The 2498 'minimal' service URL provides a service type and an access point for 2499 a particular service. The protocol used to access the service at 2500 the given service access may be implicit in the Service 2501 Type name. If this is not the case, the Service Type MUST be defined 2502 in such a way that attribute information will include all necessary 2503 configuration and protocol information. A User Agent MUST therefore 2504 be able to use either a ``service:'' URL alone or a ``service:'' 2505 URL in conjunction with service attributes to make use of a service. 2507 20.2.1. Service Type String 2509 The Service Type is a string describing the type of service. These 2510 strings may only be comprised of alphanumeric characters, '+', and 2511 '-'. Upper case is considered equivalent to lower case in Service 2512 Type names. 2514 If the Service Type name is followed by a '.' and a string (which 2515 has the same limitations) the 'suffix' is considered to be the Naming 2516 Authority of the service. If the Naming Authority is omitted, IANA 2517 is assumed to be the Naming Authority. 2519 Service Types developed for in-house or experimental use may have any 2520 name and attribute semantics provided that they do not conflict with 2521 the standardized Service Types. 2523 20.3. Attribute Information 2525 The is returned in the Attribute Reply if the Attribute 2526 Request does not result in an empty result. 2528 ::= | , 2529 ::= (=) | 2530 ::= | , 2532 An must be scanned prior to evaluation for all 2533 occurrences of the string "&#" followed by one or more digit followed 2534 by ';'. See Section 17.1.1. 2536 A keyword has only an , and no values. 2538 A comma cannot appear in an , as the comma is used as the 2539 multiple value delimiter. Examples of an are: 2541 (SCOPE=ADMINISTRATION) 2542 (COLOR=RED, WHITE, BLUE) 2543 (DELAY=10 MINS),BUSY,(LATEST BUILD=10-5-95),(PRIORITY=L,M,H) 2545 The third example has three attributes in the list. Color can take 2546 on the values red, white and blue. There are several other examples 2547 of replies throughout the document. 2549 20.4. Address Specification in Service Location 2551 The address specification used in Service Location is: 2553 ::= [:@][:] 2555 ::= Fully qualified domain name | 2556 dotted decimal IP address notation 2558 When no Domain Name Server is available, SAs and DAs must use dotted 2559 decimal conventions for IP addresses. Otherwise, it is preferable to 2560 use a fully qualified domain name wherever possible as renumbering of 2561 host addresses will make IP addresses invalid over time. 2563 Generally, just the host domain name (or address) is returned. 2564 When there is a non-standard port for the protocol, that should 2565 be returned as well. Some applications may make use of the 2566 :@ syntax, but its use is not encouraged in this 2567 context until mechanisms are established to maintain confidentiality. 2569 Address specification in Service Location is consistent with standard 2570 URL format [6]. 2572 20.5. Attribute Value encoding rules 2574 Attribute values, and attribute tags are CASE INSENSITIVE for 2575 purposes of lexical comparison. 2577 Attribute values are strings containing any characters with the 2578 exception of '(', ')', '=', '>', '<', '/', '*', and ',' (the comma) 2579 except in the case described below where opaque values are encoded. 2580 These characters may be included using the character value escape 2581 mechanism described in section 17.1.1. 2583 While an attribute can take any value, there are three types 2584 of values which differentiate themselves from general strings: 2585 Booleans, Integers and Opaque values. 2587 - Boolean values are either "TRUE" or "FALSE". This is the case 2588 regardless of the language (i.e. in French or Telugu, Boolean 2589 TRUE is "TRUE", as well as in English.) Boolean attributes can 2590 take only one value. 2592 - Integer values are expressed as a sequence of numbers. The 2593 range of allowable values for integers is "-2147483648" to 2594 "2147483647". No other form of numeric representation is 2595 interpreted as such except integers. For example, hexadecimal 2596 numbers such as "0x342" are not interpreted as integers, but as 2597 strings. 2599 - Opaque values (i.e. binary values) are expressed in radix-64 2600 notation. The syntax is: 2602 ::= (:) 2603 ::= number of bytes of the original data 2604 ::= radix-64 encoding of the original data 2606 is a 16-bit binary number. Radix-64 encodes every 3 bytes 2607 of binary data into 4 bytes of ASCII data which is in the range 2608 of characters which are fully printable and transferable by mail. 2609 For a formal definition of the Radix-64 format see RFC 1521 [7], 2610 MIME Part One, Section 5.2 Base64 Content Transfer Encoding, page 2611 21. 2613 21. Protocol Requirements 2615 In this section are listed various protocol requirements for User 2616 Agents, Service Agents, and Directory Agents. 2618 21.1. User Agent Requirements 2620 A User Agent MAY: 2622 - Provide a way for the application to configure the default DA, so 2623 that it can be used without needing to find it each initially. 2625 - Be able to request the address of a DA from DHCP, if configured 2626 to do so. 2628 - Ignore any unauthenticated Service Reply. 2630 - Be able to issue requests in any language or character set 2631 provided that it can switch to the default language and character 2632 set if the request can not be serviced by DAs and SAs at the 2633 site. 2635 - Require an authentication block in any URL entry returned as 2636 part of a Service Request, before making use of the advertised 2637 service. 2639 A User Agent SHOULD: 2641 - Try to contact DHCP to obtain the address of a DA. 2643 - Use a scope in all requests, if possible. 2645 - Issue requests to scoped DAs if the UA has been configured with a 2646 scope. 2648 - Listen on the Service Location General Multicast address for 2649 unsolicited DA Advertisements. This will increase the set of 2650 Directory Agents available to it for making requests. See 2651 Section 15.2. 2653 - Be able to be configured to require an authentication block in 2654 any received URL entry advertised as belonging to a protected 2655 scope, before making use of the service. 2657 If the UA does not listen for DA Advertisements, new DAs will not 2658 be passively detected. A UA which does not have a configured DA 2659 and has not yet discovered one and is not listening for unsolicited 2660 DA Advertisements will remain ignorant of DAs. It may then do a DA 2661 discovery before each query performed or it may simply use multicast 2662 queries to Service Agents. 2664 A User Agent MUST: 2666 - Be able to unicast requests and receive replies from a DA. 2667 Transactions should be made reliable by using retransmission 2668 of the request if the reply does not arrive within a timeout 2669 interval. 2671 - Be able to detect DAs using a Directory Agent Discovery request 2672 issued when the UA starts up. 2674 - Be able to send requests to a multicast address. Service 2675 Specific Multicast addresses are computed based on a hash of the 2676 Service Type. See Section 3.6.2. 2678 - Be able to handle numerous replies after a multicast request. 2679 The implementation may be configurable so it will either return 2680 the first reply, all replies until a timeout or keep trying till 2681 the results converge. 2683 - Ignore any unauthenticated Service Reply or Attribute Reply when 2684 an appropriate IPSec Security Association for that Reply exists. 2686 - Whenever it obtains its IP address from DHCP in the first place, 2687 also attempt to obtain scope information, and the address of a 2688 DA, from DHCP. 2690 - Use the IP Authentication Header or IP Encapsulating Payload in 2691 all Service Location messages, whenever an appropriate IPSec 2692 Security Association exists. 2694 - Be able to issue requests using the US-ASCII character set. 2696 - If configured to use a protected scope, be able to use 2697 "md5WithRSAEncryption" [4] to verify the signed data. 2699 21.2. Service Agent Requirements 2701 A Service Agent MAY be able to: 2703 - Get the address of a local Directory Agent by way of DHCP. 2705 - Accept requests in non-US-ASCII character encodings. This is 2706 encouraged, especially for UNICODE [1] and UTF-8 [25] encodings. 2708 - Register services with a DA in non-US-ASCII character encodings. 2709 This is encouraged, especially for UNICODE [1] and UTF-8 [25] 2710 encodings. 2712 A Service Agent SHOULD be able to: 2714 - Listen to the service-specific multicast address of the service 2715 it is advertising. The incoming requests should be filtered: 2716 If the Address Specification of the SA is in the Previous 2717 Responders Address Specification list, the SA SHOULD NOT respond. 2718 Otherwise, a response to the multicast query SHOULD be unicast to 2719 the UA which sent the request. 2721 - Listen for and respond to broadcast requests and TCP connection 2722 requests, to the Service Location port. 2724 - Be configurable to calculate authentication blocks and thereby 2725 be enabled to register in protected scopes. This requires that 2726 the service agent be configured to possess the necessary keys to 2727 calculate the authenticator. 2729 A Service Agent MUST be able to: 2731 - Listen to the Service Location General Multicast address for 2732 queries (e.g., Service Type Requests). If the query can be 2733 replied to by the Service Agent, the Service Agent MUST do 2734 so. It MUST check first to make sure it is not on the list of 2735 'previous responders.' 2737 - Listen to the Service Location General Multicast address for 2738 unsolicited DA Advertisements. If one is detected, and the DA 2739 has the right scope, (or has no scope), all services which are 2740 currently being advertised MUST be registered with the DA (unless 2741 configured to only use a single DA (see section 22.1), or the 2742 DA has already been detected, subject to certain rules (see 2743 section 15.2)). 2745 - Whenever it obtains its IP address from DHCP in the first place, 2746 also attempt to obtain scope information, and the address of a 2747 DA, from DHCP. 2749 - Unicast registrations and deregistrations to a DA. Transactions 2750 should be made reliable by using retransmission of the request if 2751 the reply does not arrive within a timeout interval. 2753 - Be able to detect DAs using a Directory Agent Discovery request 2754 issued when the SA starts up (unless configured to only use a 2755 single DA, see section 22.1.) 2757 - Use the IP Authentication Header or IP Encapsulating Payload in 2758 all Service Location messages, whenever an appropriate IPSec 2759 Security Association exists. 2761 - Be able to register service information with a DA using US-ASCII 2762 character encoding. It must also be able to reply to requests 2763 from UAs which use US-ASCII character encoding. 2765 - Reregister with a DA before the Lifetime of registered service 2766 information elapses. 2768 - If configured to use a protected scope, be able to use 2769 "md5WithRSAEncryption" [4] to produce the signed data. 2771 21.3. Directory Agent Requirements 2773 A Directory Agent MAY: 2775 - Accept registrations and requests in non-US-ASCII character 2776 encodings. This is encouraged, especially for UNICODE [1] and 2777 UTF-8 [25] encodings. 2779 A Directory Agent SHOULD: 2781 - Be able to configure certain scopes as protected scopes, so that 2782 registrations within those scopes require the calculation of 2783 cryptographically strong authenticators. This requires that the 2784 DA be able to possess the keys needed for the authentication, 2785 or that the DA be able to acquire a certificate generated by a 2786 trusted Certificate Authority [24], before completing Service 2787 Registrations for protected scopes. 2789 A Directory Agent MUST be able to: 2791 - Send an unsolicited DA Advertisements to the Service Location 2792 General Multicast address on startup and repeat it periodically. 2793 This reply has an XID which is incremented by one each time. If 2794 the DA starts with state, it initializes the XID to 0x0100. If 2795 it starts up stateless, it initializes the XID to 0x0000. 2797 - Ignore any unauthenticated Service Registration or Service 2798 Deregistration from an entity with which it maintains a security 2799 association. 2801 - Listen on the Directory Agent Discovery Multicast Address for 2802 Directory Agent Discovery requests. Filter these requests if the 2803 Previous Responder Address Specification list includes the DA's 2804 Address Specification. 2806 - Listen for broadcast requests to the Service Location port. 2808 - Listen on the TCP and UDP Service Location Ports for unicast 2809 requests, registrations and deregistrations and service them. 2811 - Provide a way in which scope information can be used to configure 2812 the Directory Agent. 2814 - Expire registrations when the service registration's lifetime 2815 expires. 2817 - When a Directory Agent has been configured with a scope, it MUST 2818 refuse all requests and registrations which do not have this 2819 scope. The DA replies with a SCOPE_NOT_SUPPORTED error. There 2820 is one exception: All DAs MUST respond to DA discovery requests 2821 which have no scope. 2823 - When a Directory Agent has been configured without a scope, it 2824 MUST accept ALL registrations and requests. 2826 - Ignore any unauthenticated Service Location messages when an 2827 appropriate IPSec Security Association exists for that request. 2829 - Use the IP Authentication and IP Encapsulating Security Payload 2830 in Service Location messages whenever an appropriate IPSec 2831 Security Association exists. 2833 - Accept requests and registrations in US-ASCII. 2835 - If configured with a protected scope, be able to authenticate (at 2836 least by using "md5WithRSAEncryption" [4]) Service Registrations 2837 advertising services purporting to belong to such configured 2838 protected scopes. 2840 22. Configurable Parameters and Default Values 2842 There are several configuration parameters for Service Location. 2843 Default values are chosen to allow protocol operation without the 2844 need for selection of these configuration parameters, but other 2845 values may be selected by the site administrator. The configurable 2846 parameters will allow an implementation of Service Location to be 2847 more useful in a variety of scenarios. 2849 Multicast vs. Broadcast 2850 All Service Location entities must use multicast by 2851 default. The ability to use broadcast messages must be 2852 configurable for UAs and SAs. Broadcast messages are to 2853 be used in environments where not all Service Location 2854 entities have hardware or software which supports 2855 multicast. 2857 Multicast Radius 2858 Multicast requests should be sent to all subnets in a 2859 site. The default multicast radius for a site is 32. 2860 This value must be configurable. The value for the 2861 site's multicast TTL may be obtained from DHCP using an 2862 option which is currently unassigned. 2864 Directory Agent Address 2865 The Directory Agent address discovery mechanism must be 2866 configurable. There are three possibilities for this 2867 configuration: A default address, no default address 2868 and the use of DHCP to locate a DA as described in 2869 section 15.2. The default value should be use of DHCP, 2870 with "no default address" used if DHCP does not respond. 2871 In this case the UA or SA must do a Directory Agent 2872 Discovery query. 2874 Directory Agent Scope Assignment 2875 The scope or scopes of a DA must be configurable. The 2876 default value for a DA is to have no scope if not 2877 otherwise configured. 2879 Path MTU 2880 The default path MTU is assumed to be 1400. This value 2881 may be too large for the infrastructure of some sites. 2882 For this reason this value MUST be configurable for all 2883 SAs and DAs. 2885 Keys for Protected Scopes 2887 If the local administration designates certain scopes 2888 as "protected scopes", the agents making use of those 2889 scopes have to be able to acquire keys to authenticate 2890 data sent by services along with their advertised 2891 URLs for services within the protected scope. For 2892 instance, service agents would use a private key to 2893 produce authentication data. By default, service agents 2894 use "md5WithRSAEncryption" [4] to produce the signed 2895 data, to be be included with service registrations 2896 and deregistrations (see appendix B, 4.3). This 2897 authentication data could be verified by user agents and 2898 directory agents that possess the corresponding public 2899 key. 2901 22.1. Service Agent: Use Predefined Directory Agent(s) 2903 A Service Agent's default configuration is to do passive and active 2904 DA discovery and to register with all DAs which are properly scoped. 2906 A Service Agent SHOULD be configurable to allow a special mode of 2907 operation: They will use only preconfigured DAs. This means they 2908 will *NOT* actively or passively detect DAs. 2910 If a Service Agent is configured this way, knowledge of the DA must 2911 come through another channel, either static configuration or by the 2912 use of DHCP. 2914 The availability of the Service information will not be consistent 2915 between DAs. The mechanisms which achieve eventual consistency 2916 between DAs are ignored by the SA, so their service information will 2917 not be distributed. This leaves the SA open to failure if the DA 2918 they are configured to use fails. 2920 22.2. Time Out Intervals 2922 These values should be configurable in case the site deploying 2923 Service Location has special requirements (such as very slow links.) 2925 Interval name Section Default Value Meaning 2926 ----------------- ------- ------------- ----------------------- 2927 CONFIG_INTERVAL_0 4.1 1 minute Cache replies by XID. 2928 CONFIG_INTERVAL_1 4.4 10800 seconds registration Lifetime, 2929 (ie. 3 hours)after which ad expires 2930 CONFIG_INTERVAL_2 5 each second, Retry multicast query 2931 backing off until no new values 2932 gradually arrive. 2933 CONFIG_INTERVAL_3 5 15 seconds Max time to wait for a 2934 complete multicast query 2935 response (all values.) 2936 CONFIG_INTERVAL_4 9 3 seconds Wait to register on 2937 reboot. 2938 CONFIG_INTERVAL_5 5.2 3 seconds Retransmit DA discovery, 2939 try it 3 times. 2940 CONFIG_INTERVAL_6 5.2 5 seconds Give up on requests sent 2941 to a DA. 2942 CONFIG_INTERVAL_7 5.2 15 seconds Give up on DA discovery 2943 CONFIG_INTERVAL_8 5.1 15 seconds Give up on requests 2944 sent to SAs. 2945 CONFIG_INTERVAL_9 15.2 3 hours DA Heartbeat, so that SAs 2946 passively detect new DAs. 2947 CONFIG_INTERVAL_10 15.2 1-3 seconds Wait to register services 2948 on passive DA discovery. 2949 CONFIG_INTERVAL_11 9 1-3 seconds Wait to register services 2950 on active DA discovery. 2951 CONFIG_INTERVAL_12 18.1 5 minutes DAs and SAs close idle 2952 connections. 2954 A note on CONFIG_INTERVAL_9: While it might seem advantageous to 2955 have frequent heartbeats, this poses a significant risk of generating 2956 a lot of overhead traffic. This value should be kept high to prevent 2957 routine protocol operations from using any significant bandwidth. 2959 23. Non-configurable Parameters 2961 IP Port number for unicast requests to Directory Agents: 2963 UDP and TCP Port Number: 427 2965 Multicast Addresses 2967 Service Location General Multicast Address: 224.0.1.22 2968 Directory Agent Discovery Multicast Address: 224.0.1.35 2970 A range of 1024 contiguous multicast addresses for use as Service 2971 Specific Discovery Multicast Addresses will be assigned by IANA. 2973 Error Codes: 2975 No Error 0 2976 LANGUAGE_NOT_SUPPORTED 1 2977 PROTOCOL_PARSE_ERROR 2 2978 INVALID_REGISTRATION 3 2979 SCOPE_NOT_SUPPORTED 4 2980 CHARSET_NOT_UNDERSTOOD 5 2981 AUTHENTICATION_ABSENT 6 2982 AUTHENTICATION_FAILED 7 2984 24. Acknowledgments 2986 This protocol owes some of the original ideas to other service 2987 location protocols found in many other networking protocols. Leo 2988 McLaughlin and Mike Ritter (Metricom) provided much input into early 2989 version of this document. Thanks also to Steve Deering (Xerox) for 2990 providing his insight into distributed multicast protocols. Harry 2991 Harjono and Charlie Perkins supplied the basis for the URL based 2992 wire protocol in their Resource Discovery Protocol. Thanks also to 2993 Peerlogic, Inc. for supporting this work. 2995 A. Appendix: Technical contents of ISO 639:1988 (E/F): "Code for the 2996 representation of names of languages" 2998 Two-letter lower-case symbols are used. The Registration Authority 2999 for ISO 639 [15] is Infoterm, Osterreiches Normungsinstitut (ON), 3000 Postfach 130, A-1021 Vienna, Austria. Contains additions from ISO 3001 639/RA Newsletter No.1/1989 3003 aa Afar ga Irish mg Malagasy 3004 ab Abkhazian gd Scots Gaelic mi Maori 3005 af Afrikaans gl Galician mk Macedonian 3006 am Amharic gn Guarani ml Malayalam 3007 ar Arabic gu Gujarati mn Mongolian 3008 as Assamese mo Moldavian 3009 ay Aymara ha Hausa mr Marathi 3010 az Azerbaijani he Hebrew ms Malay 3011 hi Hindi mt Maltese 3012 ba Bashkir hr Croatian my Burmese 3013 be Byelorussian hu Hungarian 3014 bg Bulgarian hy Armenian na Nauru 3015 bh Bihari ne Nepali 3016 bi Bislama ia Interlingua nl Dutch 3017 bn Bengali; Bangla in Indonesian no Norwegian 3018 bo Tibetan ie Interlingue 3019 br Breton ik Inupiak oc Occitan 3020 is Icelandic om (Afan) Oromo 3021 ca Catalan it Italian or Oriya 3022 co Corsican ja Japanese 3023 cs Czech jw Javanese pa Punjabi 3024 cy Welsh pl Polish 3025 ka Georgian ps Pashto, Pushto 3026 da Danish kk Kazakh pt Portuguese 3027 de German kl Greenlandic 3028 dz Bhutani km Cambodian qu Quechua 3029 rw Kinyarwanda 3030 el Greek kn Kannada rm Rhaeto-Romance 3031 en English ko Korean rn Kirundi 3032 eo Esperanto ks Kashmiri ro Romanian 3033 es Spanish ku Kurdish ru Russian 3034 et Estonian ky Kirghiz 3035 eu Basque 3036 la Latin 3037 fa Persian ln Lingala 3038 fi Finnish lo Laothian 3039 fj Fiji lt Lithuanian 3040 fo Faeroese lv Latvian, Lettish 3041 fr French 3042 fy Frisian 3043 sa Sanskrit ta Tamil ug Uigar 3044 sd Sindhi te Telugu uk Ukrainian 3045 sg Sangro tg Tajik ur Urdu 3046 sh Serbo-Croatian th Thai uz Uzbek 3047 si Singhalese ti Tigrinya 3048 sk Slovak tk Turkmen vi Vietnamese 3049 sl Slovenian tl Tagalog vo Volapuk 3050 sm Samoan tn Setswana 3051 sn Shona to Tonga wo Wolof 3052 so Somali tr Turkish 3053 sq Albanian ts Tsonga xh Xhosa 3054 sr Serbian tt Tatar 3055 ss Siswati tw Twi yi Yiddish 3056 st Sesotho yo Yoruba 3057 su Sundanese 3058 sv Swedish za Zhuang 3059 sw Swahili zh Chinese 3060 zu Zulu 3062 B. SLP Certificates 3064 Certificates may be used in SLP in order to distribute the public 3065 keys of trusted protected scopes. Assuming public keys, this 3066 appendix discusses the use of such certificates in the Service 3067 Location Protocol. 3069 Possession of the private key of a protected scope is equivalent 3070 to being a trusted SA. The trustworthiness of the protected scope 3071 depends upon all of these private keys being held by trusted 3072 hosts, and used only for legitimate service registrations and 3073 deregistrations. 3075 With access to the proper Certificate Authority (CA), DAs and UAs 3076 do not need (in advance) hold public keys which correspond to these 3077 protected scopes. They do require the public key of the CA. The CA 3078 produces certificates using its unique private key. This private key 3079 is not shared with any other system, and must remain secure. The 3080 certificates declare that a given protected scope has a given public 3081 key, as well as the expiration date of the certificate. 3083 The ASCII (mail-safe) string format for the certificate is the 3084 following list of tag and value pairs: 3086 "certificate-alg=" 1*ASN1CHAR CRLF 3087 "scope-charset=" 1*DIGIT CRLF 3088 "scope=" 1*RADIX-64-CHAR CRLF 3089 "timestamp=" 16HEXDIGIT CRLF 3090 "public-key=" 1*RADIX-64-CHAR CRLF 3091 "cert-digest=" 1*RADIX-64-CHAR CRLF 3093 ASN1CHAR = DIGIT | '.' 3094 HEXDIGIT = DIGIT | 'a'..'f' | 'A'..'F' 3095 RADIX-64-CHAR = DIGIT | 'a'..'z' | 'A'..'Z' | '+' | '/' | '=' 3097 The radix-64 notation is described in RFC 1521 [7]. Spaces are 3098 ignored in the computation of the binary value corresponding to a 3099 Radix-64 string. If the value for scope, public-key or cert-digest 3100 is greater than 72 characters, the Radix-64 notation may be broken 3101 up on to separate lines. The continuation lines must be preceded 3102 by one or more spaces. Only the tags listed above may start in the 3103 first column of the certificate string. This removes ambiguity in 3104 parsing the Radix-64 values (since the tags consist of legal Radix-64 3105 values.) 3107 The certificate-alg is the ASN.1 string for the Object Identifier 3108 value of the algorithm used to produce the "cert-digest". The 3109 scope-charset is a decimal representation of the MIBEnum value for 3110 the character set in which the scope is represented. 3112 The radix-64 encoding of the scope string will allow the ASCII 3113 rendering of a scope string any character set. 3115 The 8 byte NTP format timestamp is represented as 16 hex digits. 3116 This timestamp is the time at which the certificate will expire. 3118 The format for the public key will depend on the type of cryptosystem 3119 used, which is identified by the certificate-alg. When the CA 3120 generated the certificate holding the public key being obtained, 3121 it used the message digest algorithm identified by certificate-alg 3122 to calculate a digest D on the string encoding of the certificate, 3123 excepting the cert-digest. The CA then encrypted this value using 3124 the CA's private key to produce the cert-digest, which is included in 3125 the certificate. 3127 The CA generates the certificate off-line. The mechanism to 3128 distibute certificates is not specified in the Service Location 3129 Protocol, but may be in the future. The CA specifies the algorithms 3130 to use for message digest and public key decryption. The DA or SA 3131 need only obtain the certificate, have a preconfigured public key for 3132 the CA and support the algorithm specified in the certificate-alg in 3133 order to obtain certified new public keys for protected scopes. 3135 The DA or UA may confirm the certificate by calculating the message 3136 digest D, using the message digest algorithm identified by the 3137 certificate-alg. The input to the message digest algorithm is the 3138 string encoding of the certificate, excepting the cert-digest. 3139 The cert-digest is decrypted using the CA's public key to produce 3140 D'. If D is the same as D', the certificate is legitimate. The 3141 public-key for the protected scope may be used until the expiration 3142 date indicated by the certificate timestamp. 3144 The certificate may be distributed along untrusted channels, such as 3145 email or through file transfer, as it must be verified anyhow. The 3146 CA's public key must be delivered using a trusted channel. 3148 C. Example of deploying SLP security using MD5 and RSA 3150 In our site, we have a protected scope "CONTROLLED". We generate a 3151 private key - public key pair for the scope, using RSA. The private 3152 key is maintained on a secret key ring by all SAs in the protected 3153 scope. The public key is available to all DAs which support the 3154 protected scope and to all UAs which will use it. 3156 In order to register or deregister a URL, the data required to be 3157 authenticated (as described in section 4.3) is digestified using 3158 MD5 [23] to create a digital signature, then encrypted by RSA with 3159 the protected scope's private key. The output of RSA is used in the 3160 authenticator data field of the authenticator block. 3162 The DA or UA discovers the appropriate method for verifying the 3163 authentication by looking inside the authentication block. Suppose 3164 that the "md5WithRSAEncryption" [4] algorithm has to be used 3165 to verify the signed data. The DA or UA calculates the message 3166 digest of the URL Entry by using md5, exactly as the SA did. The 3167 authenticator block is decrypted using the public key for the 3168 "CONTROLLED" scope, which is stored in the public key ring of the UA 3169 or DA under the name "CONTROLLED". If the digest calculated by the 3170 UA or DA matches that of the SA, the URL Entry has been validated. 3172 D. Example of use of SLP Certificates by mobile nodes 3174 Say a mobile node needs to make use of protected scopes. The mobile 3175 node is first preconfigured by adding a single public key to its 3176 public key ring: We will call it the CA-Key. This key will be used 3177 to obtain SLP certificates in the format described in Appendix B. 3178 The corresponding private key will be used by the CA to create the 3179 certificates in the necessary format. 3181 The CA might be operated by a system administrator using a computer 3182 which is not connected to any networks. The certificate's duration 3183 will depend on the policy of the site. The duration, scope, and 3184 public key for the protected scope, are used as input to 'md5sum'. 3185 This sum is then encrypted with RSA using the CA's private key. The 3186 radix 64 encoding of this is added to the mail-safe string based 3187 certificate encoding defined in Appendix B. 3189 The certificate, say for the protected scope "CONTROLLED" could be 3190 made available to the mobile node. For example, it might be on a 3191 web page. The mobile node could then process the certificate in 3192 order to obtain the public key for the CONTROLLED scope. There is 3193 still no reason to *trust* this key is really the one to use (as in 3194 Appendix C). To trust it, calculate the md5 checksum of the ascii 3195 encoded certificate, excluding the cert-digest. Next, decrypt the 3196 cert-digest using the CA's public key and RSA. If the cert-digest 3197 matches the output of MD5, the certificate may be trusted (until it 3198 expires). 3200 The mobile node requires only one key (CA-key) in order to obtain 3201 others dynamically and make use of protected scopes. Notice that we 3202 do not define any method for access control by arbitrary UAs to SAs 3203 in protected scopes. This could be done fairly easily by limiting 3204 access to the public key certificates. 3206 E. Appendix: For Further Reading 3208 Three related resource discovery protocols are NBP and ZIP 3209 which are part of the AppleTalk protocol family [13], the Legato 3210 Resource Administration Platform [26], and the Xerox Clearinghouse 3211 system [21]. Domain names and representation of addresses are 3212 used extensively in the Service Location Protocol. The references 3213 for these are RFCs 1034 and 1035 [18, 19]. Example of a discovery 3214 protocol for routers include Router Discovery [11] and Neighbor 3215 Discovery [20]. 3217 References 3219 [1] Unicode Technical Report #4. The unicode standard, version 1.1 3220 (volumes 1 and 2). Technical Report (ISBN 0-201-56788-1) and 3221 (ISBN 0-201-60845-6), Unicode Consortium, 1994. 3223 [2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor 3224 Extensions. RFC 1533, October 1993. 3226 [3] R. Atkinson. IP Encapsulating Security Payload. RFC 1827, 3227 August 1995. 3229 [4] D. Balenson. Privacy Enhancement for Internet Electronic 3230 Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, 3231 February 1993. 3233 [5] T. Berners-Lee and D. Connolly. Hypertext Markup Language - 3234 2.0. RFC 1866, November 1995. 3236 [6] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource 3237 Locators (URL). RFC 1738, December 1994. 3239 [7] N. Borenstein and N. Freed. MIME (Multipurpose Internet Mail 3240 Extensions) Part One: Mechanisms for Specifying and Describing 3241 the Format of Internet Message Bodies. RFC 1521, September 3242 1993. 3244 [8] Scott Bradner. Key words for use in RFCs to Indicate 3245 Requirement Levels, January 1997. draft-bradner-key-words-03.txt 3246 (work in progress). 3248 [9] CCITT. Specification of the Abstract Syntax Notation One 3249 (ASN.1). Recommendation X.208, 1988. 3251 [10] CCITT. The Directory Authentication Framework. Recommendation 3252 X.509, 1988. 3254 [11] Stephen E. Deering, editor. ICMP Router Discovery Messages. 3255 RFC 1256, September 1991. 3257 [12] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541, 3258 October 1993. 3260 [13] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk. 3261 Addison-Wesley, 1990. 3263 [14] E. Guttman. The service: URL scheme, November 1996. 3264 draft-ietf-svrloc-service-scheme-00.txt (work in progress). 3266 [15] Geneva ISO. Code for the representation of names of languages. 3267 ISO 639:1988 (E/F), 1988. 3269 [16] ISO 8879, Geneva. Information Processing -- Text and Office 3270 Systems - Standard Generalized Markup Language (SGML). 3271 , 1986. 3273 [17] D. Mills. Simple Network Time Protocol (SNTP) Version 4 for 3274 IPv4, IPv6 and OSI. RFC 2030, October 1996. 3276 [18] P. Mockapetris. Domain Names - Concepts and Facilities. RFC 3277 1034, November 1987. 3279 [19] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND 3280 SPECIFICATION. RFC 1035, November 1987. 3282 [20] T. Narten, E. Nordmark, and W. Simpson. Neighbor Discovery for 3283 IP version 6 (IPv6). RFC 1970, August 1996. 3285 [21] D. Oppen and Y. Dalal. The clearinghouse: A decentralized 3286 agent for locating named objects in a distributed environment. 3287 Technical Report Tech. Rep. OPD-78103, Xerox Office Products 3288 Division, 1981. 3290 [22] C. Perkins. DHCP Options for Service Location Protocol, August 3291 1996. draft-ietf-dhc-slp-00.txt (work in progress). 3293 [23] Ronald L. Rivest. The MD5 Message-Digest Algorithm. RFC 1321, 3294 April 1992. 3296 [24] Bruce Schneier. Applied Cryptography: Protocols, Algorithms, 3297 and Source Code in C. John Wiley, New York, NY, USA, 1994. 3299 [25] X/Open Preliminary Specification. File System Safe UCS 3300 Transformation Format (FSS_UTF). Technical Report Document 3301 Number: P316, X/Open Company Ltd., 1994. 3303 [26] Legato Systems. The Legato Resource Administration Platform. 3304 Legato Systems, 1991. 3306 Authors' Addresses 3308 Questions about this memo can be directed to: 3310 John Veizades Erik Guttman 3311 @Home Network Sun Microsystems 3312 385 Ravendale Dr. Gaisbergstr. 6 3313 Mountain View, CA 94043 69115 Heidelberg Germany 3315 Phone: +1 415 944 7332 Phone: +1 415 336 6697 3316 Fax: +1 415 944 8500 3318 Email: veizades@home.com Email: Erik.Guttman@eng.sun.com 3320 Charles E. Perkins Scott Kaplan 3321 Sun Microsystems 3322 2550 Garcia Avenue 346 Fair Oaks St. 3323 Mountain View, CA 94043 San Francisco, CA 94110 3325 Phone: +1 415 336 7153 Phone: +1 415 285 4526 3326 Fax: +1 415 336 0670 3328 EMail: cperkins@Corp.sun.com Email: scott@catch22.com