Internet Engineering Task Force Erik Guttman INTERNET DRAFT James Kempf Category: Standards Track Obsoletes: 2608 August 4, 2002 Service Location Protocol, Version 2 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Comments on this document should be sent to the SLP discussion list, srvloc-discuss@lists.sourceforge.net. Internet-Drafts are draft documents of the Internet Engineering Task valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." See http://www.ietf.org/ietf/1id-abstracts.txt. Find shadow directories at http://www.ietf.org/shadow.html. Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet need little or no static configuration of network services for network based applications. This is especially important as computers become more portable, and users less tolerant or able to fulfill the demands of network system administration. This document updates SLPv2, adding clarifications and removing features which were neither widely implemented or deemed useful. Acknowledgements Authors of previous versions of SLP listed alphabetically are Mike Day, Erik Guttman, Scott Kaplan, Charles Perkins and John Veizades. Contributors to this version include (in alphabetical order) Kevin Arnold, Erik Guttman, Evan Hughes, Terry Lambert, Jim Mayer, Ira McDonald, Mikael Pahmp, Matt Peterson and Weibin Zhao. 1. Introduction The Service Location Protocol (SLP) provides a flexible and scalable framework for provisioning network nodes with information on the Guttman & Kempf Expires: 3 February 2003 [Page 1] Internet Draft SLPv2 Revision August 2002 existence, location, and configuration of networked services. Users have had to manually configure the location of services by typing in their domain names or IP addresses. SLP eliminates this requirement: the user supplies the desired type of service and a set of attributes that describe the service. Based on that description, SLP returns all required information to communicate with the service. SLP is a dynamic configuration mechanism for applications in networks under a common administration. Client applications using SLP may find available services offered by hosts attached on any network within an enterprise. This document obsoletes SLPv2 [RFC2608], correcting protocol errors and removing some requirements. A separate SLPv2 applicability statement [SLPv2AS] describes both the protocol's domain of applicability as well as the interoperability of this specification with prior versions of the protocol. 2. Terminology and Conventions used in this Document Attribute An Attribute consists of a tag and a list of typed values. An Attribute without a value list, called a "keyword" attribute, may also appear. Attributes are used to describe instances of a service type. Directory Agent (DA) A network element that collects and caches service advertisements. There can only be one DA present per host. Directory Agent (DA) Service Type The Directory Agent Service Type is the service type "service:directory-agent". It is used to discover DAs. Naming Authority The agency or group that catalogues Service Types and Attributes. The default Naming Authority is IANA. Except for the default Naming Authority, requires not describing string, a Naming Authority is described by a short string. Network Element A software process capable of network communication. Scope A named collection of service advertisements, making up a logical administrative group. Service Advertisement The set consisting of a Service Type, a Service URL, a list of Scopes, a Language Tag, a List of Attributes and a lifetime, indicating how long the advertisement is valid. This set serves to Guttman & Kempf Expires: 3 February 2003 [Page 2] Internet Draft SLPv2 Revision August 2002 describe the service and provide information on its location, availability, and language locale. Service Agent (SA) A network element working on the behalf of services to advertise them. Service Agent (SA) Service Type The Service Agent Service Type is the service type "service:service-agent". It is used to discover and advertise SAs. Service Template A structured description of a service, including the Service Type, Service URL, and Attributes. See [RFC2609]. Service Type A short string describing the service. Each type of service has a unique Service Type string. The default service type for a 'generic' URI is its scheme name. For example, the service type string for "http://www.srvloc.org" is "http". Service URL A Service URL serves two functions in SLP. First, it is a handle to refer to a service advertisement, for purposes of registration, deregistration or requesting associated attributes. Second, the Service URL may indicate the location of a service. A service URL may be of the service: scheme [RFC2609] or any other scheme conforming to the URI standard [RFC2396]. User Agent (UA) A network element working on the user's behalf to establish contact with some service. The UA retrieves service information from the Service Agents (SAs) or DAs. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In packet diagrams, an explicit length field may be followed by a variable length field. Variable length fields are terminated by a backslash ('\'). Fields are not aligned to 4 byte boundaries. 3. Protocol Overview In SLP, service discovery support for a client application is provided by a UA. Service advertising support for a service is provided by an SA. A third network element, the DA, provides scalability to the protocol. To discover a service using SLP, the UA MUST issue a Service Request (SrvRqst) on behalf of a client application. The SrvRqst specifies Guttman & Kempf Expires: 3 February 2003 [Page 3] Internet Draft SLPv2 Revision August 2002 the characteristics of a service required by the client. The UA MUST receive one or more Service Reply (SrvRply) specifying the location of all services in the network that match the conditions supplied in the SrvRqst, if the request was successful. The SLP framework allows a UA to directly issue requests to SAs. Such requests SHOULD be multicast. A SA MUST unicast a reply to the UA, containing a Service URL and other information, if the SA advertises a service matching the request. +------------+ ----Multicast SrvRqst----> +---------------+ | User Agent | | Service Agent | +------------+ <----Unicast SrvRply------ +---------------+ In larger networks, one or more DAs are used. A DA functions as a cache. If DAs are in use, SAs MUST send Service Registration (SrvReg) messages, containing all the services they advertise to DAs. SAs MUST receive Service Acknowledgements (SrvAck) messages in reply. Advertisements registered with DAs MUST be refreshed or they will expire, since each advertisement has a finite lifetime. If DAs are in use, UAs MUST unicast requests to a DA instead of multicasting. Deploying DAs thereby helps reduce the amount of multicast datagrams in a network. +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+ | User | | Directory | |Service | | Agent | | Agent | | Agent | +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+ There are three possible ways for UAs and SAs to discover DAs. In each case, the agent obtains a DA Advertisement (DAAdvert): 1) Issue a multicast SrvRqst for the DA Service Type when they start up, and receive a unicast advertisement in reply, 2) Listen for unsolicited advertisements that are sent periodically by Directory Agents, 3) Obtain Directory Agent addresses via DHCP or static configuration, issue a unicast SrvRqst for the Directory Agent Service Type, and receive a unicast DAAdvert in reply. +---------------+ --Multicast SrvRqst-> +-----------+ | User or | <--Unicast DAAdvert-- | Directory | | Service Agent | | Agent | +---------------+ <-Multicast DAAdvert- +-----------+ Service advertisements are grouped into named sets called 'scopes'. Scope names are expressed as strings. A scope can indicate a location, administrative grouping, proximity in a network topology or some other category. The mapping between service advertisements and Guttman & Kempf Expires: 3 February 2003 [Page 4] Internet Draft SLPv2 Revision August 2002 scopes is at the discretion of the network administrator. SAs and DAs MUST be configured with scopes. A UA MAY be assigned scopes, in which case the UA is only able to discover that particular grouping of services. This allows a network administrator to assign services to particular groups of users. Alternatively, the UA MAY be configured with no scope at all. In that case, the UA MUST discover all available scopes and a client application may issue requests for any service available on the network. In the following figure, the UA is configured with scopes X and Y. If a service is sought in scope X, the request MUST be multicast because no DA supports scope X. If a service is sought in scope Y, the request MUST be unicast to the DA. If the request is made in both scopes, the request MUST be both unicast and multicast. +---------+ Multicast +-----------+ Unicast +-----------+ | Service | <--SrvRqst-- | User | --SrvRqst-> | Directory | | Agent | | Agent | | Agent | | Scope=X | Unicast | Scope=X,Y | Unicast | Scope=Y | +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+ 3.1 SLP Message Types Table 1 contains a brief summary of all SLP, along with the requirement level for the SLP agents. SAs MUST accept multicast and unicast SrvRqsts. SAs SHOULD accept Attribute Requests (AttrRqsts), see Appendix B. SAs MAY accept Service Type Requests (SrvTypeRqsts). SAs MUST listen for unsolicited multicast DA Advertisements. DAs MUST support all required and optional SLP message types in the table. In the absence of multicast routing support in a network, broadcast MAY be used. +----------------------+----+----+-----+-----+-------------------------+ | Message |CODE| UA | SA | DA | Purpose | +----------------------+----+----+-----+-----+-------------------------+ | Service Register | 3 | | MUST| MUST| Register a service (url,| | (SrvReg) | | NA | send| recv| attrs, etc.) with a DA. | +----------------------+----+----+-----+-----+-------------------------+ | Service Deregister | 4 | | MAY | MUST| Deregisters a service | | (SrvDereg) | | NA | send| recv| from a DA. | +----------------------+----+----+-----+-----+-------------------------+ | Service Acknowledge | 5 | | MUST| MUST| Contains a DA's response| | (SrvAck) | | NA | recv| send| to SrvReg and SrvDereg. | +----------------------+----+----+-----+-----+-------------------------+ | Service Request | 1 |MUST| MUST| MUST| Requests services that | | (SrvRqst) | |send|s & r| recv| match query criteria. | +----------------------+----+----+-----+-----+-------------------------+ | Service Reply | 2 |MUST| MUST| MUST| Returns services that | | (SrvRply) | |recv| send| send| match query criteria. | Guttman & Kempf Expires: 3 February 2003 [Page 5] Internet Draft SLPv2 Revision August 2002 +----------------------+----+----+-----+-----+-------------------------+ | DA Advertisement | 8 |MUST| MUST| MUST| Contains location, DA | | (DAAdvert) | |recv| recv| send| attributes and more. | +----------------------+----+----+-----+-----+-------------------------+ | SA Advertisement | 11 |MAY | MUST| | Contains location, SA | | (SAAdvert) | |recv| send| NA | attributes and more. | +----------------------+----+----+-----+-----+-------------------------+ | Service Type Request | 9 |MAY | MAY | MUST| Requests available | | (SrvTypeRqst) | |send| recv| recv| service types. | +----------------------+----+----+-----+-----+-------------------------+ | Service Type Reply | 10 |MAY | MAY | MUST| Contains all available | | (SrvTypeRply) | |recv| send| send| service types. | +----------------------+----+----+-----+-----+-------------------------+ | Attribute Request | 6 |MAY |SHOULD MUST| Requests attributes for | | (AttrRqst) | |send| recv| recv| a particular service. | +----------------------+----+----+-----+-----+-------------------------+ | Attribute Reply | 7 |MAY |SHOULD MUST| Contains all attributes | | (AttrRply) | |recv| send| send| of a particular service.| +----------------------+----+----+-----+-----+-------------------------+ Table 1 - Summary of Required and Optional SLP Message Types and Requirement Level 4. Protocol Elements All integer fields in SLP messages MUST be in network byte order. 4.1 Error Codes If the Error Code in a SLP reply message is nonzero, the rest of the message MAY be truncated. No data is necessarily transmitted or should be expected after the header and the error code, except if some optional extensions are sent to clarify the error. Errors MUST be return for unicast requests. Multicast requests that result in an error MUST BE silently discarded. A reply MUST NOT be sent if a multicast request results in an error. The following is a list of SLP error codes. Error codes marked with a '*' can be returned in response to any request message, all others are returned only for specific messages. Error codes returned for specific messages are described in the sections where the messages are specified. OK * 0 The request was successful. LANGUAGE_NOT_SUPPORTED 1 The request could not be processed due to the Language Lag. Resending the request SHOULD NOT fail if the default Language Tag 'en' is used. Guttman & Kempf Expires: 3 February 2003 [Page 6] Internet Draft SLPv2 Revision August 2002 PARSE_ERROR * 2 The message fails to obey SLP syntax. The error may be due to misalignment in the binary format of the message, a missing header Language Tag, a syntax error in the header Language Tag, or a syntax error in a message-specific string such as a service query or scope string. INVALID_REGISTRATION 3 A problem occurred with the parameters of a SrvReg or SrvDereg message, other than with the syntax of string parameters. SCOPE_NOT_SUPPORTED * 4 The scope-list lacks a supported scope. VER_NOT_SUPPORTED * 9 The SLP version number is not supported. INTERNAL_ERROR * 10 The DA or SA failed for some reason. DA_BUSY_NOW * 11 The DA is currently busy processing other requests. The UA or SA SHOULD retry, using exponential back off. OPTION_NOT_UNDERSTOOD *12 The DA or SA received an unknown SLP option from the mandatory range. INVALID_UPDATE 13 A SrvReg was received without the FRESH bit set. MSG_NOT_SUPPORTED 14 The SA received an unsupported request. REFRESH_REJECTED 15 The SA sent a SrvReg with too low a lifetime. The SA SHOULD consult the DA's minimum refresh interval attribute (Section 9.4) for the minimum advertisement lifetime. 4.2 SLP Message Header 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Code | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length, contd.|O|F|R| Reserved |Next Ext Offset| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Extension Offset, contd.| XID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Language Tag Length | Language Tag \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ All SLP messages begin with this header. Guttman & Kempf Expires: 3 February 2003 [Page 7] Internet Draft SLPv2 Revision August 2002 - Version: This field MUST be set to 2. Else, a VER_NOT_SUPPORTED error results. - Code: Identifies the messsage type, see Table 1. Any value outside those defined in Table 1 or standards track protocols extending SLP MUST be treated as a PARSE_ERROR result. - Length: Three byte unsigned integer containing the number of bytes in the SLP message including the header. - Flags: O Field is (0x80). "OVERFLOW" MUST be set to 1 when a message length exceeds the path MTU and the message contents doesn't fit into a datagram. See Section 5.1.3. Otherwise, MUST be 0. F Field is (0x40). "FRESH" MUST be set to 1 on every SrvReg. Otherwise, MUST be 0. R Field is (0x20). "REQUEST MCAST" MUST be set when multicasting or broadcasting requests. Otherwise, MUST be 0. Reserved This bits MUST be set to zero on transmission and ignored on reception. See Section 4.5. - Next Extension Offset: MUST be set to 0 unless the message has any extensions. If the message has extensions, MUST contain the offset from the beginning of the message, in bytes, to the first extension header. Extensions SHOULD come after the message body. See Section 7.1. - XID: The Transaction Identifier MUST be set to a unique value for each unique request. See Section 9 for the special case of unsolicited DAAdverts. - Lang Tag Length: Two byte unsigned integer giving the length in bytes of the Language Tag field. MUST NOT be zero. - Language Tag: MUST contain a variable length field, RFC 3066 [RFC3066] language local string. This specifies the language locale for all human readable strings in the message. See Section 14. A PARSE_ERROR results if the header is syntactically incorrect. Guttman & Kempf Expires: 3 February 2003 [Page 8] Internet Draft SLPv2 Revision August 2002 4.3 Strings Strings in SLP messages MUST be encoded using UTF-8 [RFC2279]. Strings MUST not be null terminated and MUST always be preceded by a two byte unsigned length field indicating the number of bytes that follow. Optional strings MAY be omitted. In this case, the Length field is set to zero and the string MUST be absent. The specifications for the syntax of string-based protocol elements in this document conform to ABNF [RFC2234]. 4.3.1 General String Comparisons String comparisons MUST NOT be case sensitive. For example "STRING1" is equal to "String1" and is also equal to "string1". This corresponds to the LDAPv3 string matching rule caseIgnoreMatch. [RFC2252] WARNING! SPECIAL CASE: caseIgnoreMatch specifies that leading and trailing spaces in strings are elided before string comparison is performed. This feature is not supported in SLPv2. White spaces in strings MUST NOT be elided for the purposes of string comparison. For example, "string1 " is not equal " string1" nor is it equal to "string1". In practice this means that (a) UTF-8 based strings are converted to Unicode, (b) comparisons are done on the basis of numerical magnitude ordering except that (c) case folding occurs according to specific code page rules. 'a' (0x0041) and 'A' (0x0061) are equivalent, as are "u umlaut" (0x00db) and "U umlaut" (0x00fb), both offset by 0x20. Note that on other code pages the offset is different - as Cyrillic "e accent aigue" (0x4400) and "E accent aigue" (0x4450) are offset by 0x50! 4.3.2 Lists A List is a comma delimited set of strings, which can be of zero length. Since the list is comma delimited, the comma is a reserved character in string list items. A comma must be escaped to be considered as a data item. For example "a\2Cb,c\2Cd" is a string list with two items "a\2Cb" and "c\2Cd". These items include escaped commas; un-escaped they are "a,b" and "c,d" respectively. 4.3.3 Previous Responder List The Previous Responder List (PR List) is a List of dotted decimal notation IPv4 addresses. When SLP messages are unicast, PR lists MUST be ignored. When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they SHOULD contain a PR List (see Section 4.3.1) indicating all Guttman & Kempf Expires: 3 February 2003 [Page 9] Internet Draft SLPv2 Revision August 2002 responders from which the sender has received replies. Each responder's IP address (in dotted decimal form) SHOULD be added to form the new List before the request is multicast again. Any DA or SA that sees its address in the PR List SHOULD NOT respond to the request. PR Lists MUST NOT be used with unicast requests. A multicast request message with a PR List SHOULD be retransmitted until either: a) no further responses are elicited, b) the PR List and the request will not fit into a single datagram, or: c) CONFIG_MC_MAX seconds have elapsed. A syntax error in a PR List results in a PARSE_ERROR, and the response is suppressed because PR Lists are only be used with multicast requests. 4.3.4 Service Type The Service Type is a string parameter in SrvRqst and SrvReg messages. The syntax of the Service Type is: service-type = generic-uri-scheme / service-scheme generic-uri-scheme = ALPHA *( alpha / digit / '+' / '-' / '.' ) service-scheme = "service:" type ['.' na ] [':' type ] type = 1*(alpha / digit / '+' / '-' ) na = 1*(alpha / digit / '+' / '-' ) ; The naming authority field SHOULD have the ; form described in [vendorext] Service Types MUST match with case insensitive string comparison. WARNING! SPECIAL CASE: If the "service:" scheme [RFC2609] is used, special matching rules apply. A service type string which begins with "service:" is followed by either one or two "type" fields. The first type field after the "service:" scheme MAY have a naming authority string associated with it. If so, the type is considered unique. Example: "service:a" does not match "service:a.93439". This naming authority field allows for vendor extension and is NOT RECOMMENDED. [vendorext] The default Naming Authority is IANA. A Service Type that is registered with IANA MUST NOT contain a Naming Authority string. A service type string beginning with "service:" followed by one type field will match service type strings of that form, whether they have one or two type fields which follow. Example: "service:a" matches "service:a" and "service:a:b". And: "service:a.1234" matches "service:a.1234:b" but it does not match "service:a:b". Guttman & Kempf Expires: 3 February 2003 [Page 10] Internet Draft SLPv2 Revision August 2002 A syntax error in a Service Type name MUST result in the return of a PARSE ERROR to the sending agent, if the request was unicast. 4.3.5 Scope List With two exceptions, all requests, service advertisement registrations, and service advertisement deregistrations MUST contain a Scope List. SLP messages that fail to contain a Scope list or that contain a Scope List having no Scopes for which the receiving agent is configured MUST BE either dropped, if the request was multicast, or result in a SCOPE_NOT_SUPPORTED error in reply, if the request was unicast. The two exceptions are SrvRqsts for the DA Service Type and for the SA Service Type. These MAY be transmitted without a Scope List if the transmitting agent is interested in obtaining a list of all configured Scopes supported by the replying DA or SA. Scope Lists in SLPv2 are a comma delimited list of scope strings. Scope strings have reserved characters which must be expressed as escape values if they are to be included in the scope name. reserved = '(' / ')' / ',' / '\' / '!' / '<' / '=' / '>' / '~' /CTL / ';' / '*' / '+' escape-val = '\' HEXDIG HEXDIG For example the scope name "ou=sales,o=examplecorp" would have to be represented "ou\3Dsales\2Co\3Dexamplecorp" to escape the "=" and "," characters in the name. If a syntax error in a Scope List or Scope name is encountered, the receiving agent MUST return a PARSE ERROR if the request was unicast. The default value for the Scope List is the Scope name "DEFAULT". Scope configuration rules are described in Section 8.0. 4.3.6 Attribute List A service advertisement is often accompanied by Attributes. A UA formulates a service query containing Attributes in order to select particular service advertisements. A Service Type MAY specify allowable Attributes through a defined service template [RFC2609]. The allowable Attributes for such a service are defined in the service template. Services that are advertised according to a standard template SHOULD register all service Attributes required by the standard template. If no service template is available for a Service Type, then any Attributes are allowed. Support for service templates is optional. An Attribute List is a string encoding of the Attributes for a Guttman & Kempf Expires: 3 February 2003 [Page 11] Internet Draft SLPv2 Revision August 2002 service advertisement. The following grammar defines the Attribute list syntax: attr-list = attribute / attribute ',' attr-list attribute = '(' attr-tag '=' val-list ')' / attr-tag val-list = attr-val / attr-val ',' val-list attr-tag = 1*safe-tag / nonstd-tag nonstd-tag = "x-" enum '-' 1*safe-tag enum = 1*DIGIT ; The field corresponds to an Enterprise ; Number registered with IANA. [IANA] Using this ; prefix avoids collisions in interpretation of ; nonstandard attribute name. attr-val = intval / strval / boolval / opaque intval = [-]1*DIGIT strval = 1*safe-val boolval = "true" / "false" opaque = "\FF" 1*escape-val safe-val = ; Any character except reserved. safe-tag = ; Any character except reserved, '*' and bad-tag. reserved = '(' / ')' / ',' / '\' / '!' / '<' / '=' / '>' / '~' / CTL escape-val = '\' HEXDIG HEXDIG bad-tag = CR / LF / HTAB / '_' An Attribute List MUST be scanned prior to evaluation for all occurrences of the escape character '\'. Reserved characters MUST be escaped while other characters MAY be escaped. All escaped characters MUST be restored to their value before attempting string matching. Escaped Opaque values are converted into bytes, not into characters. The following list contains more detail on the various types of Attributes: Boolean A Boolean Attribute MUST have a value list that is one of the Boolean constants "true" or "false". A Boolean value list MUST only have a single value and MUST only be compared with '='. As with all strings, the Boolean constants are case insensitive. Integer An Integer Attribute MUST have a value list consisting of Integer constants. Integer constants MUST be strings that take the form [-] 1*DIGIT and fall in the range "-2147483648" to "2147483647", that is, the range of 32 bit signed integers. Integer values MUST be compared using integer comparison. Opaque An Opaque Attribute MUST have a value list consisting of opaque values. Opaque values are sequences of bytes. These MUST be distinguished Guttman & Kempf Expires: 3 February 2003 [Page 12] Internet Draft SLPv2 Revision August 2002 from strings since they begin with the sequence "\FF". Unescaping this sequence results in an illegal UTF-8 encoding, indicating that what follows is a sequence of escaped bytes and not a UTF-8 string. For example, a '0' byte is encoded "\FF\00" and "\ff\00\00\30\39" is a bigendian representation of 12345. Opaque values MUST only be compared with '='. String All other string values are String type. String values MUST be matched using strict lexical ordering. Example of string values with escaped characters: "Hello\0a" (Hello with a newline) and "\48\65\6c\6c\6f\0a" (the same string, entirely escaped). To include reserved characters as string data they must be escaped. Example "a,b" is "a\40b". Illegal UTF-8 characters MUST NOT be included in Strings, ie. "a\ff" is illegal. Keyword A Keyword Attribute has only a tag. A Keyword Attribute MUST be designated by attr-tag in the Attribute List, and it MUST have no values. Syntax errors in the Attribute List MUST result in a PARSE ERROR, which is returned if the request was unicast. When values are advertised by a SA or are registered in a DA, they MUST take on implicit typing rules for matching incoming requests, according to the types described above. Stored value types in Attribute Lists MUST be consistent, i.e., x=4,true,sue,\ff\00\00 is in error. Inconsistent stored value types in a SrvReg MUST result in a PARSE ERROR returned to the SA. A DA MUST consolidate multiple instances of the same Attribute within an Attribute List before storing and an SA MUST consolidate multiple instances before sending the Attribute in an AttrRply. For example, if the Attribute List received by a DA is: "(x=5,6,7),(y=a,b,c),(x=6,7,8)" one Attribute, "x", is stored having value list "5,6,7,8". Embedded blanks in Attribute tags and value lists MUST be processed as part of the tags or values in which they appear, embedded blanks MUST NOT be ignored. For example, in the Attribute List "(attra = -345)", the Attribute tag is "attra " and the value is the String " -345". The value is not an Integer due to the embedded blank. Guttman & Kempf Expires: 3 February 2003 [Page 13] Internet Draft SLPv2 Revision August 2002 4.3.7 Search Filter A SrvRqst message MAY include a LDAPv3 Search Filter [RFC2254], with certain restrictions. RFC 2254 describes the syntax of LDAPv3 Search Filters. A DA MUST accept any LDAPv3 query, excluding those with extensible matching rules. A SA MAY accept only simple queries; otherwise, it MUST accept service queries as a DA would. A UA SHOULD send only simple queries. The syntax for a simple query is: simple-query = conjoin / term conjoin = "(&" term-list ')' term-list = term term-list / term term = '(' tag querytype item ')' / '(' tag "=*)" ; The "=*" term tests if the Attribute is ; present. tag = 1*tag-safe querytype = '=' / "~=" / ">=" / "<=" ; These correspond to equal, approx, ; greater than or equal, less than or ; equal. item = value / substring ; Only substring matching is supported. value = 1*val-safe substring = [ value ] any [ value ] any = '*' *(value "*") tag-unsafe = val-unsafe / CR / LF / HTAB / '_' tag-safe = ; All UTF-8 characters are included except ; those in tag-unsafe. Tag-unsafe must be ; escaped. val-unsafe = '(' / ')' / ',' / '´ / '!' / '<' / '=' / '>' / '~' / CTL val-safe = ; All UTF-8 characters are included ; except those in val-unsafe. Val-unsafe ; must be escaped. escaped = '´ HEXDIG HEXDIG Attribute tags and String values MUST be case-folded before performing string matching, as per Section 4.3.1. Matching rules for other types are as described in 4.3.6. If a Service Template [RFC2609] is available, the Service Template SHOULD be used to guide matching of types. If no Service Template is available, for ordered string matching, values MUST be matched using an implicit type system. If the Attribute in the query has been registered with multiple values, the query MUST be compared to each value and the results MUST Guttman & Kempf Expires: 3 February 2003 [Page 14] Internet Draft SLPv2 Revision August 2002 be combined with logical 'OR', i.e., "(x=\ff\00)" matches an advertisement of (x=\ff\33,\ff\00); "(Y<=0)" matches (y=0,-1). Keywords (i.e., Attributes without values) MUST be matched with a "presence" query, as in "(keyword=*)". WARNING! SPECIAL CASE: Ordering comparisons with strings and integers is subtle. Integer comparison is only used if both values are integers. Since implicit type matching is done, this can lead to unexpected results. Values of ['-']1*DIGIT MUST be treated as integers, so a service advertisement with Attribute List "(x=12),(y=-55)" would match the query "(&(x>=6)(y<=-44))". Note that integers MUST NOT match strings, for example, the search query "(x=34*)" matches an Attribute List "(x=34foo)", but not "(x=3432)" since the first value is a String while the second value is an Integer. Embedded blanks MUST NOT be ignored. For example, the query "(&(x= -345)(y=7))" matches the service advertisement with Attribute List "(x= -345)" but not the service advertisement with Attribute List "(x=-345)". See Section Examples: Given an attribute list "(a=12),(b=10,100),(c=100foo)", the query "(a<=16)" is a match. The query "(a<=100 )" is not a match, since "100 " is a string, so the value "12" must be treated as a string and "100 " is less than "12" by string ordering. The filter "(b<=20)" matches, because y can be 10, but "(b<= 1000)" does not match: " 1000" begins with a string and space (0x20) is less than "1", the first character of "10" and "100" values of b. The filter "(c<=2)" matches because c is a string, starting with "1". A syntax error in a service query results in a PARSE_ERROR. 4.3.8 Attribute Tag List This is a List of Attribute tags, defined as attr-tag the grammar of Section 4.3.4 above. In addition, an member of the list may contain a wild-card according to the following grammar: wild-card = ['*'] attr-tag ['*'] 4.4 URL Entry 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Lifetime | URL Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |URL len, contd.| URL (variable length) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-0 | +-+-+-+-+-+-+-+-+ Guttman & Kempf Expires: 3 February 2003 [Page 15] Internet Draft SLPv2 Revision August 2002 SLP stores URLs in protocol elements called URL Entries, which associate a URL with a lifetime. Lifetime An unsigned two byte integer giving the lifetime during which the URL is valid (that is, may be cached), in seconds. URL Length, URL String The Length MUST NOT be zero, the URL MUST NOT be omitted. 4.5 Reserved and Backward Compatibility Fields marked as Reserved in protocol messages MUST be set to zero on transmission and ignored on reception. Fields marked Backward Compatibility (or BC with a number) MUST be treated similarly, except where compatibility with previous specifications of SLP is being provided. [SLPv2AS] provides more details on backward compatibility. 5. Required Features This section lists requirements for any conforming implementation of SLP. All requirements are identified by a letter (U, S or D, for UA, SA or DA requirement) and a number, throughout this specification. A minimal implementation may consist of either a UA or SA or both. A DA is not required for SLP to function, but if it is present, the UA and SA MUST interact with it as defined below. A UA MUST be able to [U1] issue SrvRqst messages and [U2] interpret SrvRply messages. These messages are transported via either [U3] unicast requests to DAs if one is available (in the desired Scope) using UDP or [U4] multicast requests if no DA is available (in the desired Scope). A UA MUST [U5] perform DA discovery initially, then either periodically or passively if no DA is known, interpreting DAAdvert messages. A UA MUST also [U6] be configurable with a Scope list and DA locations. A SA MUST be able to [S1] advertise a set of services, [S2] receive and process unicast and multicast SrvRqsts. A SA MUST process Search Filters unless it only ever advertises services without Attributes. A [S3] SrvRply message is sent in reply to all SrvRqst messages, except a [S4] SAAdvert is returned for requests for the SA Service Type. A SA MUST perform [S5] active DA discovery initially, then either periodically or passively, interpreting DAAdvert messages. A SA MUST [S6] register all currently advertised services with DAs as they are discovered, then periodically if appropriate, before they expire. A SA MUST be [S7] be configurable with a Scope List and DA locations. A DA MUST receive and process unicast requests [D1] SrvRqst, [D2] SrvTypeRqst and [D3] AttrRqst, for which they MUST send replies [D4] SrvRply, [D5] SrvTypeRply and [D6] AttrRply, respectively. The only Guttman & Kempf Expires: 3 February 2003 [Page 16] Internet Draft SLPv2 Revision August 2002 exception is a SrvRqst for the DA Service Type, to which the DA responds with a [D7] DAAdvert. These same DAAdverts are [D8] multicast initially and periodically. A DA MUST [D9] process SrvReg messages and cache service advertisements registered, [D10] expire cached services when lifetimes expire and [D11] process SrvDereg messages to remove specified cached services. A DA MUST be [D12] configurable with a Scope List. 5.1 Transport of SLP Messages SLP messages MUST be sent using one of four different transport algorithms: (1) Multicast requests soliciting unicast replies (2) Unicast UDP requests soliciting unicast UDP replies (3) TCP requests soliciting TCP replies (4) Multicast unsolicited announcements The reserved listening port for SLP is 427, for both UDP and TCP. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port by UAs. DAs and SAs MUST send replies and acknowledgement messages from port 427 to the port from which the request was issued. The PR List SHOULD be used to provide a very limited form of reliable multicast. By default, the PR List is empty. Retransmitted requests use the same XID. This allows a DA or SA to briefly cache the reply to the original request and then send the cached reply again, should a duplicate request arrive. XIDs SHOULD be randomly chosen to avoid duplicate XIDs in requests if UAs restart frequently. 5.1.1 UDP Message Transmission Requests sent using UDP MUST NOT exceed the maximum transmission unit. The default maximum transmission unit for UDP messages is 1400 bytes excluding UDP and other headers. If a SLP reply message does not fit into a UDP datagram it MUST be truncated to fit, and the OVERFLOW flag is set in the reply message. A UA receiving a truncated message MAY open a TCP connection (see section 5.1.3) with the DA or SA and retransmit the request, using the same XID. The UA MAY also attempt to make use of the truncated reply or it MAY reformulate a more restrictive request which will result in a smaller reply. UDP requests to a DA or SA SHOULD be retransmitted until either a response (which might be an error) has been obtained, or for CONFIG_RETRY_MAX seconds. The initial retransmission MUST occur after a CONFIG_RETRY wait period. Retransmissions MUST occur after exponentially increasing wait intervals; that is, by doubling the wait each time, or the range of a uniformly distributed random wait interval. Guttman & Kempf Expires: 3 February 2003 [Page 17] Internet Draft SLPv2 Revision August 2002 5.1.1.1 Multicast UDP Transmission SLP messages are multicast to the administratively scoped SLP multicast [RFC 2365] address, which is 239.255.255.253. The default TTL to use for multicast is 255. In isolated networks, broadcasts MAY be used on the all hosts broadcast address, 255.255.255.255, in place of multicast. To that end, SAs SHOULD and DAs MUST listen for broadcast SLP messages at port 427. 5.1.1.2 Multicast Requests Multicast requests MUST set the RQST Flag in the SLP header. Multicast requests are used in three cases: - Active DA Discovery (UAs and SAs MUST support this). - Active SA Discovery (UAs MAY support this). - Multicast Requests (UAs MUST be able to multicast SrvRqst messages to SAs, who MUST be prepared to receive and process them.) One or more replies MAY be returned via unicast UDP. Errors MUST NOT be returned in response to multicast messages, only non-error, non-zero results. The one exception to this is a multicast AttrRqst for a service registered without any Attributes. A multicast AttrRqst for such a service MUST result in a unicast AttrRply with a zero length Attribute List. SAs MUST accept both multicast requests and unicast requests, although UAs SHOULD use multicast when contacting SAs directly. The SA can distinguish between multicast and unicast requests by whether the REQUEST MCAST flag is set in the SLP message header. DAs MUST accept multicast requests as part of DA discovery (see Section 9); otherwise, DAs MUST ignore multicast requests. Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds until a result has been obtained. Retransmission is not required if the requesting agent is prepared to use the first reply instead of as many replies as possible within a bounded time interval. An initial retransmission MUST occur after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals; that is,(doubling the wait each time, or the range of the uniformly distributed random wait interval. The message SHOULD be retransmitted until no further responses are elicited (see Section 4.3.1) or until CONFIG_MC_MAX seconds elapse. 5.1.1.3 Unicast UDP Requests Unicast requests to a DA or SA SHOULD be retransmitted until either a response (which might be an error) has been obtained, or for CONFIG_RETRY_MAX seconds. An initial retransmission MUST occur after a Guttman & Kempf Expires: 3 February 2003 [Page 18] Internet Draft SLPv2 Revision August 2002 CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals, doubling the wait each time. 5.1.2 TCP Requests If a SrvReg or SrvDeReg is too large to fit into a datagram, a TCP connection MUST be established by the SA to transmit the message. In addition, a UA MAY initiate a TCP connection with a DA or SA to send an initial request which is too large for a datagram or to resend a request if the return to a UDP or multicast transmitted request has the OVERFLOW flag set in the SLP header. DAs MUST be able to respond to UDP and TCP requests, as well as multicast DA Discovery SrvRqsts. SAs MUST be able to respond to TCP unless the SA will NEVER receive a request or send a reply which will exceed a datagram in size (e.g., some embedded systems). A TCP connection MAY be used for a single SLP transaction, or for multiple transactions. Since there are length fields in the message headers, SLP Agents can send multiple requests along a connection and read the return stream for acknowledgments and replies. The initiating agent SHOULD close the TCP connection. The DA SHOULD wait at least CONFIG_CLOSE_CONN seconds before closing an idle connection. DAs and SAs SHOULD close an idle TCP connection after CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the initiating agent neglects to close it. See Section 13 for timing rules. To avoid the need to implement TCP in UAs and SAs, their implementations and deployment MUST be constrained such that: - UAs never issue requests larger than the Path MTU, so SAs never have to receive TCP requests longer than the path MTU. - UAs can accept replies with the 'OVERFLOW' flag set, and make use of the first result included, or reformulate the request for a smaller reply. - The SA can send all SrvRply, SrvReg, and SrvDeReg messages in a single datagram. This means limiting the size of URLs, and the length of Attribute Lists and Scope Lists transmitted. 5.1.3 Multicast Announcement Unsolicited DAAdvert messages are sent initially and periodically sent by DAs via multicast to announce DA availability. The XID is set to 0. See Section 9.1.4. Guttman & Kempf Expires: 3 February 2003 [Page 19] Internet Draft SLPv2 Revision August 2002 6. Required Messages 6.1 Service Request This is the primary request message in SLP. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRqst = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.3.7) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList String The PRList SHOULD be included. See Section 4.3 if the PRList is omitted. Length of Service Type, Service Type String A Service Type String MUST be included. Length of Scope List, Scope List String A Scope List MUST be included, unless the Service Type String is either the DA or SA Service Type. In this case the Scope List MAY be omitted (see Section 4.3). Length of Filter, Filter String A Filter string is OPTIONAL (see Section 4.3 on omitted strings). Response messages differ depending on the Service Type field. If the Service Type field is set to DA Service Type, DAs MUST respond to the SrvRqst with a DAAdvert (see Section 9.2.1). If the Service Type field is set to the SA Service Type, SAs MUST respond with a SAAdvert (see Section 10). All other SrvRqst messages elicit a SrvRply (see Section 6.2). Requests that elicit a SrvRply are processed as follows. The Service Type field, Scope List field, and Language Tag field of the header MUST establish the base set of service advertisements over which the Filter is applied. If the Filter field is absent, the request MUST match all service advertisements having the indicated Service Type, Scopes, and language locale. If the Filter field is present, the Filter MUST be compared to each registered service, such that the Guttman & Kempf Expires: 3 February 2003 [Page 20] Internet Draft SLPv2 Revision August 2002 Language Tag of the request matches the the language locale of the advertised service. See Sections 4.2.6 and 4.2.7 for how to apply the Filter and Section 14 for how to apply Language Tags. Matching services are returned in the SrvRply message. Requests that elicit a DAAdvert response are processed as described in Section 9.2.1. Requests that elicit a SAAdvert response are processed as described in Section 10. Possible error results returned in SrvRply or DAAdvert, in addition to those listed in Section 4.1 with a '*' are: LANGUAGE_NOT_SUPPORTED Returned when the Service Type field and at least one Scope from the Scope List field match, the Filter field is not absent, but no services are advertised in the language specified in the Language Tag field of the header, though there are service advertisements registered under the default language locale, namely 'en'. MUST NOT be returned if there are no service advertisements for the Service Type advertised under the default language locale. MSG_NOT_SUPPORTED Returned when an SA that only accepts simple service queries receives a unicast SrvRqst including a complex search query. 6.2 Service Reply 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRply = 2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | URL Entry count | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status Code of the message (see Section 4.1 and 6.1). URL Entry Count The number of URL entry blocks following. MAY be zero. URL Entry 1 ... URL Entry N The URL Entry blocks. MUST be absent if URL Entry Count is 0. The SrvRply contains zero or more URL Entries (see Section 4.4). A SrvRply with zero URL entries MUST be returned in response to a unicast Service Reply if no matching service advertisements are present. If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless Guttman & Kempf Expires: 3 February 2003 [Page 21] Internet Draft SLPv2 Revision August 2002 it fits entirely without truncation. If the reply overflows a datagram and the 'O' flag in the header is set, the UA MAY simply use the URL entries in the list. A URL obtained by SLP MUST NOT be cached longer than the number of seconds in the Lifetime field of the URL Entry. 6.3 Service Registration 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvReg = 3) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | (Section 4.3.1)\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of attr-list string | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-2 | +-+-+-+-+-+-+-+-+ URL-Entry A URL Entry corresponding to the service advertisement MUST be present. Length of Service Type, Service Type String The Service Type of the service advertisement MUST be present. Length of Scope List, Scope List The Scope List of the service advertisement MUST be present. Length of Attribute List, Attribute List The Attribute List of the service advertisement MAY be omitted. See Section 4.3 concerning omitted strings. The Lifetime field of the URL Entry defines how long a DA can cache the registration. SAs SHOULD reregister before this lifetime expires but SHOULD NOT reregister more often than once per second or more often than the maximum reregistration interval advertised by the DA (see Section 9.3). The lifetime MAY be set to any value between 0 and 0xffff (maximum, around 18 hours). Long-lived registrations remain stale longer if the service fails and the SA does not deregister the service. The Service Type defines the service type of the URL to be registered, regardless of the scheme of the URL. The Scope List MUST contain the names of all Scopes configured for the SA. If Guttman & Kempf Expires: 3 February 2003 [Page 22] Internet Draft SLPv2 Revision August 2002 the same URL is registered under different Service Types and/or with different Language Tags, the Scope List MUST be identical for all registrations so that deregistration functions properly, see Section 7.6; otherwise, if the Scope List differs from a prior registration for the same URL, a SCOPE_NOT_SUPPORTED error is returned. The Attribute List, if present, specifies the Attributes and values to be associated with the URL in the service advertisement. The header FRESH flag MUST be set on all registrations. A new registration received for an existing service advertisement in which the header Language Tag, URL, and Service Type, all match MUST replace the previous advertisement. 6.4 Service Acknowledgment 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvAck = 5) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the message. A DA MUST return a SrvAck to an SA after a SrvReg or SrvDereg. The SrvAck carries only a two byte Error Code. In addition to the errors listed in Section 4.1 with a '*', the following error codes apply to SrvReg and SrvDereg messages: REFRESH_REJECTED If the header FRESH flag is not set, or if the SrvReg lifetime is less than the DA's advertised minimum refresh interval (see Section 9.3), the DA MAY reject the advertisement. If a SrvDereg includes an Attribute tag list, the DA SHOULD reject it. INVALID_REGISTRATION Returned if the SrvReg has problems with a non-string parameter, like a zero URL Entry Lifetime field,, or if a SrvDereg was sent for a nonexisting service advertisement, or an attempt was made to delete a service advertisement and the SrvDereg Scope List contains only a partial list of the Scopes in which the advertisement is registered. 6.5 DA Advertisement The DAAdvert is used for DA Discovery (see Section 9). Guttman & Kempf Expires: 3 February 2003 [Page 23] Internet Draft SLPv2 Revision August 2002 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = DAAdvert = 8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | DA Stateless Boot Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |DA Stateless Boot Time, contd. | Length of URL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-3 | BC-4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the message. See Section 4.1 and 6.1 for values. The Error Code is set to 0 when the DAAdvert is multicast. DA Stateless Boot Timestamp Indicates DA boot time and state. See Section 9.2 for details. Length of URL, URL The DA URL MUST NOT be omitted. Length of Scope List, Scope List The Scope List string. MUST NOT be absent. This list contains the Scope List of the DA, though it MAY include only the Scope List present in the SrvRqst which solicited the DAAdvert. If multicast, the Scope List MUST be the DA's entire configured Scope List. Length of Attribute List, Attribute List The DA Attribute List string MAY be omitted. See Section 9.2 for possible DA Attributes. The returned URL is "service:directory-agent://" of the DA, where is the dotted decimal numeric IP address of the DA. 6.6. SA Advertisement The SAAdvert is used by UAs to accumulate information about SAs, see Section 10. Since the SAAdvert is only returned in response to a multicast request, it contains no error code field because errors on multicast requests are silently dropped. 0 1 2 3 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 Guttman & Kempf Expires: 3 February 2003 [Page 24] Internet Draft SLPv2 Revision August 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SAAdvert = 11) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-5 | +-+-+-+-+-+-+-+-+ Length of URL, URL The SA's URL MUST NOT be omitted. Length of Scope List, Scope List The SA's Scope List MUST NOT be omitted. Length of Attribute List, Attribute List The Attribute List MAY be omitted only if the SA advertises no services (see Section 10). On omitted strings, see Section 4.3. The SA responds only to multicast SA discovery requests which: - have an empty or the includes one of the SA's Scopes, - have set to "service:service-agent". - if a is included in the request, the SA MUST match the Filter against the SA's Attributes. The SAAdvert MUST include a list of Attributes the SA supports. This Attribute List SHOULD be kept short so that the SAAdvert will not exceed the path MTU in size. The Attribute 'service-type' MUST be included in the Attribute List. The value of this Attribute is a list of string values, each value of which is a Service Type the SA is advertising (not including "service:service-agent"). The URL is "service:service-agent://" of the SA, where is the dotted decimal numeric address of the SA. 7. Optional Features A UA or SA can be fully compliant without implementing any features from this section. A SA SHOULD, however, support responding to AttrRqst unless the SA will never be used to advertise services with Attributes (see Appendix B). 7.1 SLP Extensions SLP extensions provide growth capability to the basic set of SLP messages. Guttman & Kempf Expires: 3 February 2003 [Page 25] Internet Draft SLPv2 Revision August 2002 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extension ID | Next Extension Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Offset, contd.| Extension Data \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Extension ID The extension identifier. Next Extension Offset Number of bytes to the next extension as an offset from the beginning of the SLP message. If the Next Extension Offset field is zero, there are no extensions following the current extension, and the length of the current extension MUST be calculated by subtracting the offset of the current extension from the total length of the SLP message as given in the header. Extension Data The contents of the extension. If an extension offset is specified, and an extension is not included in the request, the receiver MUST respond with a PARSE_ERROR, if the request was unicast. Extension IDs are assigned in the following way: 0x0000-0x3FFF Standardized: Optional to implement. Ignore if unrecognized. 0x4000-0x7FFF Standardized: Mandatory to implement. A UA or SA which receives this option in a reply and does not understand it MUST silently discard the reply. A DA or SA which receives this option in a request and does not understand it MUST return an OPTION_NOT_UNDERSTOOD error. 0x8000-0x8FFF For private use: Optional to implement. Ignore if unrecognized. 0x9000-0xFFFF Reserved: Do not use. Section 13 defines procedures for specifying new SLP extensions. 7.2 Service Type Request The Service Type Request (SrvTypeRqst) allows a UA to discover all types of services on a network. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvTypeRqst = 9) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Guttman & Kempf Expires: 3 February 2003 [Page 26] Internet Draft SLPv2 Revision August 2002 | length of PRList | (Section 4.3.1) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Naming Authority | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList The PRList MAY be omitted. See Section 4.3.3 and 4.3. Length of Naming Authority, Naming Authority The naming authority string MAY be zero length, in which case service types in the default naming authority (IANA) are returned. WARNING! SPECIAL CASE: If the length field is set to 0xFFFF: (1) the naming authority string is zero length, (2) all service types in all naming authorities are returned. THIS FIELD IS AN EXCEPTION TO HOW STRING LENGTHS ARE ENCODED IN SLP! Otherwise, if a naming authority string is included, only service types in that naming authority are returned. Length of Scope List, Scope List Only Service Types advertised in a Scope included in the Scope List are returned. The Naming Authority string determines which Service Types will be returned in the reply, as described above. Possible error returns, aside from those in Section 4.1 with a '*': MSG_NOT_SUPPORTED An SA that does not support SrvTypeRqst returns this error if a it receives a unicast SrvTypeRqst. 7.3 Service Type Reply The return message for SrvTypeRqst is the SrvTypeRply. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvTypeRply = 10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | length of List | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | List (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Error Code Status code of the messages. See section 4.1 and 7.3. Guttman & Kempf Expires: 3 February 2003 [Page 27] Internet Draft SLPv2 Revision August 2002 Length of Service Type List, Service Type List The list of Service Types. The Service Type names MUST include the naming authority string, if any. This string MUST be absent if the Service Type List result is zero (see Section 4.3). 7.4 Attribute Request The Attribute Request (AttrRqst) allows a UA to discover Attributes of a given service by supplying its URL. This information is also available by using the Attrlist Extension to the SrvRqst [RFC 3059]. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = AttrRqst = 6) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of PRList | String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of | (Section 4.3.3) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of string | (Section 4.5) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of PRList, PRList The PRList MAY be omitted. See Section 4.3.3 and 4.3. Length of URL, URL The URL of the service whose Attributes are being requested. MUST NOT be absent. Length of Scope List, Scope List The Scope List of the service whose Attributes are being requested. MUST NOT be absent. Length of Attribute Tag List, Attribute Tag List This string MAY be omitted, see Section 4.3. If present, only those Attributes whose tags are present in the list are returned in the AttrRply. The indicates the Attributes to return in the AttrRply. Wild card values in match Attributes any part of whose tag matches the part of the wild card. Possible error returns when the request is unicast, aside from those in Section 4.1 with a '*', are: LANGUAGE_NOT_SUPPORTED Guttman & Kempf Expires: 3 February 2003 [Page 28] Internet Draft SLPv2 Revision August 2002 Returned when the URL field and at least one Scope from the Scope List field match, but no services are advertised in the language specified in the Language Tag field of the header, though there is a service advertisements for the URL registered under the default language locale, namely 'en'. MUST NOT be returned if there is no service advertisement for the URL advertised under the default language locale. MSG_NOT_SUPPORTED Returned when a SA that does not support AttrRqst receives a unicast AttrRqst. INVALID_REGISTRATION The URL in the AttrRqst does not correspond to a service that the SA or DA is advertising. 7.5 Attribute Reply 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = AttrRply = 7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | length of | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (Section 4.3.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BC-7 | +-+-+-+-+-+-+-+-+ Error Code Status code of the message. See section 4.1 and 7.5. Length of Attribute List, Attribute List The requested Attribute List. These field is omitted if the status code of the result is not 0 or the service advertisement has no Attributes associated with it. WARNING! SPECIAL CASE: A SA that supports AttrRqst MUST return an AttrRply in response to a multicast AttrRqst that matches a service advertisement with no Attributes. THIS IS UNLIKE SrvTypeRply AND SrvRply WHERE ONLY NONZERO RESULTS ARE RETURNED IN RESPONSE TO MULTICAST QUERIES. Attribute replies SHOULD be returned with the original case of registered string tags and values intact, in case they must be displayed to users. Only one copy of each Attribute tag or String value SHOULD be returned, arbitrarily choosing one version with respect to upper and lower case and white space internal to the strings. Duplicate Guttman & Kempf Expires: 3 February 2003 [Page 29] Internet Draft SLPv2 Revision August 2002 Attributes and values SHOULD be removed. An arbitrary version of the string value and tag name is chosen for the merge. For example: "(A=a a,b)" merged with "(a=A A,B)" may yield "(a=a a,B)". 7.6 Service Deregistration A DA deletes a service registration when its lifetime expires. Services SHOULD be deregistered when they are no longer available, rather than leaving the registrations to time out. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvDeReg = 4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of | (Section 4.3.2) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Entry (Section 4.4) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of = 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Length of Scope List, Scope List MUST NOT be omitted. URL Entry The URL of the service to deregister. The URL in the entry MUST NOT be omitted. The lifetime in the URL Entry is ignored. Length of Attribute Tag List This field MUST be 0. See Section 4.3 on omitted strings. The URL indicates which service advertisement to deregister. The deregistration MUST remove all service advertisements associated with the URL, for all Scopes, language locales, and Service Types under which service advertisements for the URL were registered. The SA MUST issue the SrvDeReg with the same Scope List used to register the service. If this is not done, the DA MUST return a SCOPE_NOT_SUPPORTED error. The DA acknowledges a SrvDereg with a SrvAck. Once the SA receives an acknowledgment indicating success, the service is no longer advertised by the DA. Possible error codes beyond those in Section 4.1 marked with a '*': INVALID_REGISTRATION A DA sends this error if the SrvDeReg seeks to deregister a service that has not been registered with the DA. Guttman & Kempf Expires: 3 February 2003 [Page 30] Internet Draft SLPv2 Revision August 2002 INVALID_UPDATE A DA sends this error in response to a non-zero Attribute Tag List Length. 8. Scope List Configuration The default Scope List configuration for any agent is the string "DEFAULT". The chart below contains a prioritized list of options for Scope List configuration. Higher priority options override lower priority options. For example, if a static Scope List exists, DHCP option 79 is ignored. All SLP Agents MUST support static configuration of a Scope List. Other mechanisms are optional. Preference Mechanism Requirement level (1) Static configuration of Scope List MUST (2) Static configuration of DAs * MUST (3) DHCP SLP Scope configuration SHOULD (4) DHCP SLP DA configuration * SHOULD (5) Dynamic discovery (DAAdverts) ** MAY (6) Dynamic discovery (SAAdverts) ** MAY (7) Use of the Scope "DEFAULT" MUST (2) A SA or UA with a static configured list of DAs will unicast DA Discovery messages (see Section 9) to the DAs on the list and create a list of all Scopes those DAs support. This forms the agent's Scope List. (3) DHCP option 79 can explicitly configure a UA or SA's Scope list. [RFC 2610] (4) DHCP option 78 can supply a list of DA locations. The UA or SA acquires their Scope List, as per (2), above. [RFC 2610] (5) A UA or SA can use active and passive DA Discovery (see Section 9) to acquire a list of DAs. The combined list of their Scopes forms the agent's Scope List. (6) A UA can use active SA discovery (see Section 10) to obtain SAAdverts from SAs on the network. The combined list becomes the UA's Scope List. UAs can issue requests with any subset of Scopes with which they are configured. It is left up to the implementor whether to allow UAs to synthesize Scope Lists by using DA and SA discovery or only to support static and DHCP discovery. 9. DA Discovery UAs and SAs MUST attempt to discover DAs unless specifically configured not to do so. UAs and SAs MUST perform active DA discovery initially, upon initialization. SAs MUST and UAs SHOULD Guttman & Kempf Expires: 3 February 2003 [Page 31] Internet Draft SLPv2 Revision August 2002 perform passive DA discovery (UAs MAY instead periodically perform active DA discovery, for example, before requests are made, after [CONFIG_DA_FIND] seconds). 9.1 Active DA discovery DAs are discovered by sending a SrvRqst with the Service Type set to the DA Service Type. If a Filter is included in the SrvRqst, the DA SHOULD respond only if the Filter matches the DA's Attributes. If the requesting UA or SA is configured with a Scope List, the request MUST contain all configured scopes in the list. If the UA or SA is not configured with a Scope List, however, the field of the SrvRqst used in active DA discovery MAY be empty. This allows the UA or SA to derive a Scope List from DAAdverts it receives. 9.2 Passive DA discovery A DA MUST multicast (or broadcast) an unsolicited DAAdvert every CONFIG_DA_BEAT seconds. CONFIG_DA_BEAT SHOULD be specified to prevent DAAdverts from using more than 1% of the available network bandwidth. An unsolicited DAAdvert has an XID of 0. All UAs and SAs that receive the unsolicited DAAdvert SHOULD examine the DAAdvert DA Stateless Boot Timestamp. If the Stateless Boot Timestamp is zero, the DA is going down and no further messages should be sent to it. If a SA detects a DAAdvert with a nonzero DA Stateless Boot Timestamp but the SA has never encountered the DA before, the SA MUST send SrvRegs for all its advertised services if examination of the DAAdvert indicates that the SA must register. The SA MUST examine the DAAdvert's timestamp to determine if the DA has had a stateless reboot since the SA last registered with it. If so, and if the DA supports some set of Scopes with which the SA is configured, the SA registers with the DA. SAs MUST wait a random interval between 0 and CONFIG_REG_PASSIVE before beginning DA registration. If a UA with a configured scope list receives a DAAdvert that supports any Scope on its configured Scope List, it adds this DA to its list of DAs. 9.3 DA Attributes DAs MAY advertise Attributes. One Attribute is defined by SLPv2, the 'min-refresh-interval' attribute. A potential scaling problem occurs in SLPv2 if SAs choose too low a lifetime. In this case, an onerous amount of reregistration occurs as more services are deployed. SLPv2 allows DAs to control the Guttman & Kempf Expires: 3 February 2003 [Page 32] Internet Draft SLPv2 Revision August 2002 frequency of registration by advertising the "min-refresh-interval" attribute. A DA MAY reissue a DAAdvert with a new set of Attributes at any time, to change the reregistration behavior of SAs. These apply only to subsequent registrations; existing service registrations with the DA retain their registered lifetimes. If the DAAdvert includes the Attribute 'min-refresh-interval' it MUST be set to a single Integer value indicating a number of seconds. If this Attribute is present SAs MUST NOT issue registrations with lifetimes less than this value or refresh any particular service advertisement more frequently than this value. If SrvReg or SrvDereg for a particular service is received more frequently than or with the lifetime less than the DA's advertised 'min-refresh-interval' attribute the DA SHOULD reject the message and return a REFRESH_REJECTED error in the SrvAck. 10. SA Discovery A UA MAY, in the absence of knowledge of DAs, and other Scope list configuration, obtain SAAdverts from SAs on the network. This allows the UA to synthesize a Scope List it can use to issue requests. A SA MAY be configured with Attributes, and MUST support the Attribute 'service-type' whose value is all the Service Types of services represented by the SA. Further, SAs which support only simple Search Filters MUST include the Attribute definition "simple- query-only=true" in their Attribute List. A query for this Attribute can be included in the Filter to exclude SAs that do not accept simple queries. SAs MUST NOT respond if the SrvRqst Filter is not satisfied. For example, only SAs advertising 'nfs' services MUST respond with a SAAdvert to a SrvRqst for Service Type "service:service-agent" that includes a Filter "(service-type=nfs)". 11. Protocol Timing Defaults Interval name Section Default Value Meaning ------------------- ------- ------------- ------------------------ CONFIG_MC_MAX 6.3 15 seconds Max time to wait for a complete multicast query response (all values.) CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA discovery on reboot. CONFIG_RETRY 12.3 2 seconds Wait interval before initial retransmission of multicast or unicast requests. CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast request retransmission. CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs Guttman & Kempf Expires: 3 February 2003 [Page 33] Internet Draft SLPv2 Revision August 2002 passively detect new DAs. CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait before repeating Active DA discovery. CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services on passive DA discovery. CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services on active DA discovery. CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle connections. 12. Optional Configuration Broadcast Only Any SLP agent SHOULD be configurable to use broadcast only. Predefined DA A UA or SA SHOULD be configurable to use a predefined DA. No DA Discovery The UA or SA SHOULD be configurable to ONLY use predefined and DHCP-configured DAs and perform no active or passive DA discovery. Multicast TTL The default multicast TTL is 255. Agents SHOULD be configurable to use other values. A lower value may result in UAs obtaining different results for the identical requests depending on where they are connected to the network. Timing Values Time values in Section 11 MAY be configurable. Scopes The Scope List string MUST be configurable. DHCP Configuration DHCP options 78 and 79 MAY be used to configure SLP. [RFC 2610] Service Templates Service Template UAs and SAs MAY be configured by using Service Templates. These allow language translation, setting default values and API error checking. 13. IANA Considerations SLP includes four sets of identifiers which may be registered with IANA. The policies for these registrations (See [RFC 2434]) are noted in each case. New SLP Extensions with types in the range 2-65535 may be registered following review by a Designated Expert. New error numbers in the range 15-65535 are assigned on the basis of a Standards Action. Protocol elements used with Service Location Protocol may also require IANA registration actions. SLP is used in conjunction with "service:" URLs and Service Templates [RFC 2609]. These are Guttman & Kempf Expires: 3 February 2003 [Page 34] Internet Draft SLPv2 Revision August 2002 standardized by review of a Designated Expert and a mailing list (See [RFC 2609].) 14. Internationalization Considerations SLP supports service advertisements in multiple languages by providing a Language Tag field in the SLP message header (see Section 8). Services MAY be registered under multiple Language Tags. This provides Attributes so that users with different language skills can select services interactively. Services SHOULD be registered under the Language Tag 'en', the default Language Tag (English), to provide for a fallback in case the services are not registered under any another Language Tag. When processing requests, the Language Tag in the request MUST be compared using case insensitive equality to the Language Tag of the service advertisement. If the service advertisement's Language Tag doesn't match that in the request, the two MUST NOT match; otherwise, the two MUST match. A URL that is registered with multiple Language Tags may be queried under all Language Tags for which it is registered. The Language Tag of the SrvRqst or AttrRqst is used to perform the match. If the requested language is not supported, a LANGUAGE_NOT_SUPPORTED error MUST be returned for a SrvRqst if there are any service advertisements registered under the default Language Tag, or for an AttrRqst if there is an advertisement for the URL under the default Language Tag. If there is no advertisement registered under the default language tag, the LANGUAGE_NOT_SUPPORTED error MUST NOT be returned, and the request MUST be considered to have yielded no matches. SrvRply and AttrRply messages MUST contain the same Language Tag as that of the request. RFC 2609 [RFC 2609] provides more information about how language tags can be used in Service Templates. 15. Security Considerations The threats posed to clients using SLP to locate services and to services that use SLP to advertise themselves are threefold. First, a UA may be prevented from discovering a service that is present and should, in fact, be discoverable. This is a denial of service attack. SLP is vulnerable to denial of service attacks by (a) an attacker posing as a DA that withholds normally available service information, (b) an attacker actively deregistering services with DAs that should otherwise be available at the DAs. Second, a UA may discover a service that is not 'trustworthy' according to some policy of trust in an administered network. This is a masquerading attack. A user could be fooled into revealing Guttman & Kempf Expires: 3 February 2003 [Page 35] Internet Draft SLPv2 Revision August 2002 confidential information in interactions with a service registered by an attacker. Third, by observing and issuing SLP queries, an attacker could use SLP to catalogue either clients or services on a network. The threat here is breach of confidentiality. An attacker can learn what services the user prefers and what services are present on the network. This information could be useful to an attacker, for example, to inform how to launch future attacks. Previous versions of SLP provided for authentication of service URLs and Attribute Lists [SLPv2AS]. This scheme was not adopted, as it required SLP-specific key management, and it has been deprecated in this version of SLP. Instead, SLP agents use IPsec security associations [IPSEC] for unicast messages to protect against the above threats. Multicast requests are considered to be insecure and SHOULD NOT be used if the above attacks are considered likely. The following policies protect unicast SLP traffic: 1. Messages unicast from port 427 by SAs and DAs SHOULD initiate an IKE establishment of a security association [IKE] when: - An SA or DA responds to a UA request - An SA registers or deregisters with a DA 2. Those hosts which receive unicast SLP messages from port 427 SHOULD have a policy requiring the initiation of a IPsec security association when: - A UA receives a reply from a DA or SA - A SA receives a SrvAck from a DA - A DA receives a SrvReg or SrvDereg from a SA 3. IKE security association establishment MUST be predicated on possession of a certificate indicating that a host is a legitimate source of SLP messages. This requires distribution of certificates to all SLP agents, signed by a certificate authority operated by a trusted administration. During IKE security association establishment, certificates are verified versus the certificate authority's public key. If verified, the security association can be established and messages transmitted are be protected against the attacks listed above. 4. SLP messages that cannot be validated against an IPsec Authentication Header [AH] SHOULD be silently discarded. 5. For environments where confidentiality is desired, SLP messages MAY be protected by an IPsec Encapsulating Security Payload [ESP]. The security provided by the above policy is no replacement for application level security. That is, even if SLP is protected Guttman & Kempf Expires: 3 February 2003 [Page 36] Internet Draft SLPv2 Revision August 2002 against the above list of threats, it is not a substitute for client- server protocol security appropriate to satisfy the application's own security requirements. SLP is useful as a bootstrap protocol. It may be used in environments in which no preconfiguration is possible. In such situations, a certain amount of "blind faith" is required: Without any prior configuration it is impossible to secure SLP. Appendix A: Changes to SLPv2 compared to RFC 2608 [SLPv2AS] presents the details and backward compatibility issues concerning this specification compared to previous versions of SLP. Appendix B: SA support for Attributes Some special purpose SAs which will only ever advertise services without Attributes need not implement SrvRqst Search Filters or respond to AttrRqst with an AttrRply. All other SAs need to. This is the meaning of the statement SAs SHOULD reply to AttrRqst messages. Normative References [AH] Kent, S., and Atkinson, R., "IP Authentication Header," RFC 2402, November, 1998. [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security Payload (ESP)," RFC 2406, November, 1998. [IANA] http://www.iana.org/numbers.html [IPSEC] Kent, S., and Atkinson, R., "Security Architecture for the Internet Protocol," RFC 2401, November, 1998. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC 2252] Wahl, M., et. al., "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252, December 1997. [RFC 2254] Howes, T., "The String Representation of LDAP Search Filters", RFC 2254, December 1997. [RFC 2279] Yergeau, F., "UTF-8, a transformation format of unicode Guttman & Kempf Expires: 3 February 2003 [Page 37] Internet Draft SLPv2 Revision August 2002 and ISO 10646", RFC 2279, October 1998. [RFC 2365] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365, July 1998. [RFC 2396] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC 2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs, BCP 26, RFC 2434, October 1998. [RFC 2608] E. Guttman, C. Perkins, J. Veizades, and M. Day, "Service Location Protocol version 2", RFC 2608, July 1999. [RFC 2609] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and service: Schemes", RFC 2609, June 1999. [RFC 2610] Guttman, E., "DHCP Options for Service Location", draft- guttman-svrloc-rfc2610bis-01.txt, September 2001. A work in progress. [RFC 3066] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [SLPv2AS] Guttman, E., "Applicability Statement for Service Location Protocol, Version 2," draft-guttman-svrloc-as-00.txt, a work in progress. [vendorext] Guttman, E., "Vendor Extensions for Service Location Protocol, Version 2", draft-guttman-svrloc-vendor-ext-04.txt, a work in progress. Editors' Contact Information Erik Guttman James Kempf Sun Microsystems, Inc. Docomo Labs, USA Phone: +49 172 865 5497 Phone: +1 408 451 4711 Email: Erik.Guttman@Sun.Com Email: kempf@docomolabs-usa.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice Guttman & Kempf Expires: 3 February 2003 [Page 38] Internet Draft SLPv2 Revision August 2002 or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Table of Contents Abstract . . . . . . . . . . . 1 6.2 Service Reply . . . . . . 21 Acknowledgements . . . . . . . 1 6.3 Service Registration . . . 22 1. Introduction . . . . . . . 1 6.4 Service Acknowledgment . . 23 2. Terminology and Conventions 2 6.5 DA Advertisement . . . . . 23 3. Protocol Overview . . . . . 3 6.6 SA Advertisement . . . . 24 3.1 SLP Message Types . . . . 5 7. Optional Features . . . . . 25 4. Protocol Elements . . . . . 6 7.1 SLP Extensions . . . . . . 25 4.1 SLP Message Header . . . . 6 7.2 Service Type Request . . . 26 4.2 Error Codes . . . . . . . 7 7.3 Service Type Reply . . . . 27 4.3 Strings . . . . . . . . . 9 7.4 Attribute Request . . . . 28 4.3.1 General String Comparison 9 7.5 Attribute Reply . . . . . 29 4.3.2 Lists . . . . . . . . . 9 7.6 Service Deregistration . . 30 4.3.3 Previous Responder List 9 8. Scope List Configuration . 31 4.3.4 Service Type String . . 10 9. DA Discovery . . . . . . . 31 4.3.5 Scope List . . . . . . . 11 9.1 Active Discovery . . . . . 32 4.3.6 Attribute List . . . . . 11 9.2 Passive Discovery . . . . 32 4.3.7 Search Filter . . . . . 14 9.3 DA Attributes . . . . . . 32 4.3.8 Attribute Tag List . . . 15 10. SA Discovery . . . . . . 33 4.3.9 SLP SPI . . . . . . . . 15 11. Protocol Timing Defaults . 33 4.4 URL Entry . . . . . . . . 15 12. Optional Configuration . . 34 4.5 Required and Backward 13. IANA Considerations . . . 34 Compatibility . . . . . . 16 14. Internationalization 5. Required Features . . . . . 16 Considerations . . . . . . 35 5.1 Transport of SLP Messages 17 15. Security Considerations . 35 5.1.1 UDP Message Transmission 17 Appendix A: Changes to SLPv2 5.1.1.1 Multicast Transmission 18 compared to RFC 2608 . . . 37 5.1.1.2 Multicast Requests . . 18 Appendix B: SA support for 5.1.1.3 Unicast Requests . . . 18 Attributes . . . . . . . . 37 5.1.2 TCP Requests . . . . . . 19 Normative References . . . . . 37 5.1.3 Multicast Announcement . 19 Editors' Contact Information . 38 6. Required Messages . . . . . 20 Full Copyright Statement . . . 38 6.1 Service Request . . . . . 20 Guttman & Kempf Expires: 3 February 2003 [Page 39]