Tech-invite3GPPspaceIETF RFCsSIP
in Index   Prev   Next

RFC 2608

Service Location Protocol, Version 2

Pages: 54
Proposed Standard
Updates:  2165
Updated by:  3224
Part 2 of 3 – Pages 12 to 37
First   Prev   Next

Top   ToC   RFC2608 - Page 12   prevText

6. Required Features

This section defines the minimal implementation requirements for SAs and UAs as well as their interaction with DAs. 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 minimal implementation may consist of either a UA or SA or both. The only required features of a UA are that it can issue SrvRqsts according to the rules below and interpret DAAdverts, SAAdverts and SrvRply messages. The UA MUST issue requests to DAs as they are discovered. An SA MUST reply to appropriate SrvRqsts with SrvRply or SAAdvert messages. The SA MUST also register with DAs as they are discovered. UAs perform discovery by issuing Service Request messages. SrvRqst messages are issued, using UDP, following these prioritized rules: 1. A UA issues a request to a DA which it has been configured with by DHCP. 2. A UA issues requests to DAs which it has been statically configured with. 3. UA uses multicast/convergence SrvRqsts to discover DAs, then uses that set of DAs. A UA that does not know of any DAs SHOULD retry DA discovery, increasing the waiting interval between subsequent attempts exponentially (doubling the wait interval each time.) The recommended minimum waiting interval is CONFIG_DA_FIND seconds.
Top   ToC   RFC2608 - Page 13
    4. A UA with no knowledge of DAs sends requests using multicast
       convergence to SAs.  SAs unicast replies to UAs according to the
       multicast convergence algorithm.

   UAs and SAs are configured with a list of scopes to use according to
   these prioritized rules:

    1. With DHCP.

    2. With static configuration.  The static configuration may be
       explicitly set to NO SCOPE for UAs, if the User Selectable Scope
       model is used.  See section 11.2.

    3. In the absence of configuration, the agent's scope is "DEFAULT".

   A UA MUST issue requests with one or more of the scopes it has been
   configured to use.

   A UA which has been statically configured with NO SCOPE LIST will use
   DA or SA discovery to determine its scope list dynamically.  In this
   case it uses an empty scope list to discover DAs and possibly SAs.
   Then it uses the scope list it obtains from DAAdverts and possibly
   SAAdverts in subsequent requests.

   The SA MUST register all its services with any DA it discovers, if
   the DA advertises any of the scopes it has been configured with.  A
   SA obtains information about DAs as a UA does.  In addition, the SA
   MUST listen for multicast unsolicited DAAdverts.  The SA registers by
   sending SrvReg messages to DAs, which reply with SrvReg messages to
   indicate success.  SAs register in ALL the scopes they were
   configured to use.

6.1. Use of Ports, UDP, and Multicast

DAs MUST accept unicast requests and multicast directory agent discovery service requests (for the service type "service:directory- agent"). SAs MUST accept multicast requests and unicast requests both. The SA can distinguish between them by whether the REQUEST MCAST flag is set in the SLP Message header. The Service Location Protocol uses multicast for discovering DAs and for issuing requests to SAs by default. The reserved listening port for SLP is 427. This is the destination port for all SLP messages. SLP messages MAY be transmitted on an ephemeral port. Replies and acknowledgements are sent to the port
Top   ToC   RFC2608 - Page 14
   from which the request was issued.  The default maximum transmission
   unit for UDP messages is 1400 bytes excluding UDP and other headers.

   If a SLP 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 which receives a truncated message MAY open a TCP connection
   (see section 6.2) with the DA or SA and retransmit the request, using
   the same XID. It MAY also attempt to make use of the truncated reply
   or reformulate a more restrictive request which will result in a
   smaller reply.

   SLP Requests messages are multicast to The Administratively Scoped
   SLP Multicast [17] address, which is  The default
   TTL to use for multicast is 255.

   In isolated networks, broadcasts will work in place of multicast.  To
   that end, SAs SHOULD and DAs MUST listen for broadcast Service
   Location messages at port 427.  This allows UAs which do not support
   multicast the use of Service Location on isolated networks.

   Setting multicast TTL to less than 255 (the default) limits the range
   of SLP discovery in a network, and localizes service information in
   the network.

6.2. Use of TCP

A SrvReg or SrvDeReg may be too large to fit into a datagram. To send such large SLP messages, a TCP (unicast) connection MUST be established. To avoid the need to implement TCP, one MUST insure that: - UAs never issue requests larger than the Path MTU. SAs can omit TCP support only if they never have to receive unicast 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. - Ensure that a SA can send a SrvRply, SrvReg, or SrvDeReg in a single datagram. This means limiting the size of URLs, the number of attributes and the number of authenticators transmitted. 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).
Top   ToC   RFC2608 - Page 15
   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

6.3. Retransmission of SLP messages

Requests which fail to elicit a response are retransmitted. The initial retransmission occurs after a CONFIG_RETRY wait period. Retransmissions MUST be made with exponentially increasing wait intervals (doubling the wait each time). This applies to unicast as well as multicast SLP 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. Multicast requests SHOULD be reissued over CONFIG_MC_MAX seconds until a result has been obtained. UAs need only wait till they obtain the first reply which matches their request. That is, 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.' When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast, they contain a <PRList> of previous responders. Initially the <PRList> is empty. When these requests are unicast, the <PRList> is always empty. Any DA or SA which sees its address in the <PRList> MUST NOT respond to the request. The message SHOULD be retransmitted until the <PRList> causes no further responses to be elicited or the previous responder list and the request will not fit into a single datagram or until CONFIG_MC_MAX seconds elapse. UAs which retransmit a request use the same XID. This allows a DA or SA to cache its reply to the original request and then send it again, should a duplicate request arrive. This cached information should only be held very briefly. XIDs SHOULD be randomly chosen to avoid
Top   ToC   RFC2608 - Page 16
   duplicate XIDs in requests if UAs restart frequently.

6.4. Strings in SLP messages

The escape character is a backslash (UTF-8 0x5c) followed by the two hexadecimal digits of the escaped character. Only reserved characters are escaped. For example, a comma (UTF-8 0x29) is escaped as `\29', and a backslash `\' is escaped as `\5c'. String lists used in SLP define the comma to be the delimiter between list elements, so commas in data strings must be escaped in this manner. Backslashes are the escape character so they also must always be escaped when included in a string literally. String comparison for order and equality in SLP MUST be case insensitive inside the 0x00-0x7F subrange of UTF-8 (which corresponds to ASCII character encoding). Case insensitivity SHOULD be supported throughout the entire UTF-8 encoded Unicode [6] character set. The case insensitivity rule applies to all string matching in SLPv2, including Scope strings, SLP SPI strings, service types, attribute tags and values in query handling, language tags, previous responder lists. Comparisons of URL strings, however, is case sensitive. White space (SPACE, CR, LF, TAB) internal to a string value is folded to a single SPACE character for the sake of string comparisons. White space preceding or following a string value is ignored for the purposes of string comparison. For example, " Some String " matches "SOME STRING". String comparisons (using comparison operators such as `<=' or `>=') are done using lexical ordering in UTF-8 encoded characters, not using any language specific rules. The reserved character `*' may precede, follow or be internal to a string value in order to indicate substring matching. The query including this character matches any character sequence which conforms to the letters which are not wildcarded.

6.4.1. Scope Lists in SLP

Scope Lists in SLPv2 have the following grammar: scope-list = scope-val / scope-val `,' scope-list scope-val = 1*safe safe = ; Any character except reserved. reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL / `;' / `*' / `+' escape-val = `\' HEXDIG HEXDIG
Top   ToC   RFC2608 - Page 17
   Scopes which include any reserved characters must replace the escaped
   character with the escaped-val format.

7. Errors

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 possibly for some optional extensions to clarify the error, for example as in section D.1. Errors are only returned for unicast requests. Multicast requests are silently discarded if they result in an error. LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in the scope in the AttrRqst or SrvRqst, but not in the requested language. PARSE_ERROR = 2: The message fails to obey SLP syntax. INVALID_REGISTRATION = 3: The SrvReg has problems -- e.g., a zero lifetime or an omitted Language Tag. SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in its <scope-list> supported by the SA or DA. AUTHENTICATION_UNKNOWN = 5: The DA or SA receives a request for an unsupported SLP SPI. AUTHENTICATION_ABSENT = 6: The DA expected URL and ATTR authentication in the SrvReg and did not receive it. AUTHENTICATION_FAILED = 7: The DA detected an authentication error in an Authentication block. VER_NOT_SUPPORTED = 9: Unsupported version number in message header. INTERNAL_ERROR = 10: The DA (or SA) is too sick to respond. DA_BUSY_NOW = 11: UA or SA SHOULD retry, using exponential back off. OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an unknown option from the mandatory range (see section 9.1). INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for an unregistered service or with inconsistent Service Types. MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst and does not support it. REFRESH_REJECTED = 15: The SA sent a SrvReg or partial SrvDereg to a DA more frequently than the DA's min-refresh-interval.

8. Required SLP Messages

All length fields in SLP messages are in network byte order. Where ' tuples' are defined, these are sequences of bytes, in the precise order listed, in network byte order. SLP messages all begin with the following header:
Top   ToC   RFC2608 - Page 18
      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    |  Function-ID  |            Length             |
     | Length, contd.|O|F|R|       reserved          |Next Ext Offset|
     |  Next Extension Offset, contd.|              XID              |
     |      Language Tag Length      |         Language Tag          \

          Message Type             Abbreviation     Function-ID

          Service Request          SrvRqst              1
          Service Reply            SrvRply              2
          Service Registration     SrvReg               3
          Service Deregister       SrvDeReg             4
          Service Acknowledge      SrvAck               5
          Attribute Request        AttrRqst             6
          Attribute Reply          AttrRply             7
          DA Advertisement         DAAdvert             8
          Service Type Request     SrvTypeRqst          9
          Service Type Reply       SrvTypeRply          10
          SA Advertisement         SAAdvert             11

   SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert.  SAs MUST
   also support SrvReg, SAAdvert and SrvAck.  For UAs and SAs, support
   for other messages are OPTIONAL.

     - Length is the length of the entire SLP message, header included.
     - The flags are:  OVERFLOW (0x80) is set when a message's length
       exceeds what can fit into a datagram.  FRESH (0x40) is set on
       every new SrvReg.  REQUEST MCAST (0x20) is set when multicasting
       or broadcasting requests.  Reserved bits MUST be 0.
     - Next Extension Offset is set to 0 unless extensions are used.
       The first extension begins at 'offset' bytes, from the message's
       beginning.  It is placed after the SLP message data.  See
       Section 9.1 for how to interpret unrecognized SLP Extensions.
     - XID is set to a unique value for each unique request.  If the
       request is retransmitted, the same XID is used.  Replies set
       the XID to the same value as the xid in the request.  Only
       unsolicited DAAdverts are sent with an XID of 0.
     - Lang Tag Length is the length in bytes of the Language Tag field.
     - Language Tag conforms to [7].  The Language Tag in a reply MUST
       be the same as the Language Tag in the request.  This field must
       be encoded 1*8ALPHA *("-" 1*8ALPHA).
Top   ToC   RFC2608 - Page 19
   If an option is specified, and not included in the message, the
   receiver MUST respond with a PARSE_ERROR.

8.1. Service Request

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 <PRList> | <PRList> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <service-type> | <service-type> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request <predicate> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <SLP SPI> string | <SLP SPI> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In order for a Service to match a SrvRqst, it must belong to at least one requested scope, support the requested service type, and match the predicate. If the predicate is present, the language of the request (ignoring the dialect part of the Language Tag) must match the advertised service. <PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means. A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned. Once a <PRList> plus the request exceeds the path MTU, multicast convergence stops. This algorithm is not intended to find all instances; it finds 'enough' to provide useful results. The <scope-list> is a <string-list> of configured scope names. SAs and DAs which have been configured with any of the scopes in this list will respond. DAs and SAs MUST reply to unicast requests with a
Top   ToC   RFC2608 - Page 20
   SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
   include a scope they support (see Section 11).  The only exceptions
   to this are described in Section 11.2.

   The <service-type> string is discussed in Section 4.  Normally, a
   SrvRqst elicits a SrvRply.  There are two exceptions:  If the
   <service-type> is set to "service:directory-agent", DAs respond to
   the SrvRqst with a DAAdvert (see Section 8.5.)  If set to
   "service:service-agent", SAs respond with a SAAdvert (see Section
   8.6.)  If this field is omitted, a PARSE_ERROR is returned - as this
   field is REQUIRED.

   The <predicate> is a LDAPv3 search filter [14].  This field is
   OPTIONAL. Services may be discovered simply by type and scope.
   Otherwise, services are discovered which satisfy the <predicate>.  If
   present, it is compared to each registered service.  If the attribute
   in the filter has been registered with multiple values, the filter is
   compared to each value and the results are ORed together, i.e.,
   "(x=3)" matches a registration of (x=1,2,3); "(!(Y=0))" matches
   (y=0,1) since Y can be nonzero.  Note the matching is case
   insensitive.  Keywords (i.e., attributes without values) are matched
   with a "presence" filter, as in "(keyword=*)".

   An incoming request term MUST have the same type as the attribute in
   a registration in order to match.  Thus, "(x=33)" will not match '
   x=true', etc.  while "(y=foo)" will match 'y=FOO'.
   "(|(x=33)(y=foo))" will be satisfied, even though "(x=33)" cannot be
   satisfied, because of the `|' (boolean disjunction).

   Wildcard matching MUST be done with the '=' filter.  In any other
   case, a PARSE_ERROR is returned.  Request terms which include
   wildcards are interpreted to be Strings.  That is, (x=34*) would
   match 'x=34foo', but not 'x=3432' since the first value is a String
   while the second value is an Integer; Strings don't match Integers.

   Examples of Predicates follow.  <t> indicates the service type of the
   SrvRqst, <s> gives the <scope-list> and <p> is the predicate string.

      <t>=service:http  <s>=DEFAULT  <p>=  (empty string)
               This is a minimal request string.  It matches all http
               services advertised with the default scope.

      <t>=service:pop3  <s>=SALES,DEFAULT  <p>=(user=wump)
               This is a request for all pop3 services available in
               the SALES or DEFAULT scope which serve mail to the user
Top   ToC   RFC2608 - Page 21
      <t>=service:backup  <s>=BLDG 32  <p>=(&(q<=3)(speed>=1000))
               This returns the backup service which has a queue length
               less than 3 and a speed greater than 1000.  It will
               return this only for services registered with the BLDG 32

      <t>=service:directory-agent  <s>=DEFAULT  <p>=
               This returns DAAdverts for all DAs in the DEFAULT scope.

   DAs are discovered by sending a SrvRqst with the service type set to
   "service:directory-agent".  If a predicate is included in the
   SrvRqst, the DA SHOULD respond only if the predicate can be satisfied
   with the DA's attributes.  The <scope-list> MUST contain all scopes
   configured for the UA or SA which is discovering DAs.

   The <SLP SPI> string indicates a SLP SPI that the requester has been
   configured with.  If this string is omitted, the responder does not
   include any Authentication Blocks in its reply.  If it is included,
   the responder MUST return a reply which has an associated
   authentication block with the SLP SPI in the SrvRqst.  If no replies
   may be returned because the SLP SPI is not supported, the responder
   returns an AUTHENTICATION_UNKNOWN error.

8.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <URL Entry 1> ... <URL Entry N> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The service reply contains zero or more URL entries (see Section 4.3). A service reply with zero URL entries MUST be returned in response to a unicast Service Request, if no matching URLs are present. A service reply with zero URL entries MUST NOT be sent in response to a multicast or broadcast service request (instead, if there was no match found or an error processing the request, the service reply should not be generated at all). If the reply overflows, the UA MAY simply use the first URL Entry in the list. A URL obtained by SLP may not be cached longer than Lifetime seconds, unless there is a URL Authenticator block present.
Top   ToC   RFC2608 - Page 22
   In that case, the cache lifetime is indicated by the Timestamp in the
   URL Authenticator (see Section 9.2).

   An authentication block is returned in the URL Entries, including the
   SLP SPI in the SrvRqst.  If no SLP SPI was included in the request,
   no Authentication Blocks are returned in the reply.  URL
   Authentication Blocks are defined in Section 9.2.1.

   If a SrvRply is sent by UDP, a URL Entry MUST NOT be included unless
   it fits entirely without truncation.

8.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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <URL-Entry> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of service type string | <service-type> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of attr-list string | <attr-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of AttrAuths |(if present) Attribute Authentication Blocks...\ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <entry> is a URL Entry (see section 4.3). The Lifetime defines how long a DA can cache the registration. SAs SHOULD reregister before this lifetime expires (but SHOULD NOT more often than once per second). 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, which the DA it is registering with supports. The default value for the <scope-list> is "DEFAULT" (see Section 11). The SA MUST register consistently with all DAs. If a SA is configured with scopes X and Y and there are three DAs, whose scopes are "X", "Y" and "X,Y" respectively, the SA will register the with all three DAs in their respective scopes. All future updates and deregistrations of the service must be sent to the same set of DAs in
Top   ToC   RFC2608 - Page 23
   the same scopes the service was initially registered in.

   The <attr-list>, if present, specifies the attributes and values to
   be associated with the URL by the DA (see Section 5).

   A SA configured with the ability to sign service registrations MUST
   sign each of the URLs and Attribute Lists using each of the keys it
   is configured to use, and the DA it is registering with accepts.
   (The SA MUST acquire DAAdverts for all DAs it will register with to
   obtain the DA's SLP SPI list and attributes, as described in Section
   8.5).  The SA supplies a SLP SPI in each authentication block
   indicating the SLP SPI configuration required to verify the digital
   signature.  The format of the digital signatures used is defined in
   section 9.2.1.

   Subsequent registrations of previously registered services MUST
   contain the same list of SLP SPIs as previous ones or else DAs will
   reject them, replying with an AUTHENTICATION_ABSENT error.

   A registration with the FRESH flag set will replace *entirely* any
   previous registration for the same URL in the same language.  If the
   FRESH flag is not set, the registration is an "incremental"
   registration (see Section 9.3).

8.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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ A DA returns a SrvAck to an SA after a SrvReg. It carries only a two byte Error Code (see Section 7).
Top   ToC   RFC2608 - Page 24

8.5. Directory Agent Advertisement

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 <scope-list> | <scope-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of <attr-list> | <attr-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of <SLP SPI List> | <SLP SPI List> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | # Auth Blocks | Authentication block (if any) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Error Code is set to 0 when the DAAdvert is multicast. If the DAAdvert is being returned due to a unicast SrvRqst (ie. a request without the REQUEST MCAST flag set) the DA returns the same errors a SrvRply would. The <scope-list> of the SrvRqst must either be omitted or include a scope which the DA supports. The DA Stateless Boot Timestamp indicates the state of the DA (see section 12.1). The DA MAY include a list of its attributes in the DAAdvert. This list SHOULD be kept short, as the DAAdvert must fit into a datagram in order to be multicast. 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 SAs frequency of registration. 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 refresh any particular service advertisement more frequently than this value. If SrvReg with the FRESH FLAG not set or SrvDereg with a non-empty tag list updating a
Top   ToC   RFC2608 - Page 25
   particular service are received more often than the value for the
   DA's advertised "min-refresh-interval" attribute the DA SHOULD reject
   the message and return a REFRESH_REJECTED error in the SrvAck.

   The URL is "service:directory-agent://"<addr> of the DA, where <addr>
   is the dotted decimal numeric address of the DA. The <scope-list> of
   the DA MUST NOT be NULL.

   The SLP SPI List is the list of SPIs that the DA is capable of
   verifying.  SAs MUST NOT register services with authentication blocks
   for those SLP SPIs which are not on the list.  DAs will reject
   service registrations which they cannot verify, returning an

   The format of DAAdvert signatures is defined in Section 9.2.1.

   The SLP SPI which is used to verify the DAAdvert is included in the
   Authentication Block.  When DAAdverts are multicast, they may have to
   transmit multiple DAAdvert Authentication Blocks.  If the DA is
   configured to be able to generate signatures for more than one SPI,
   the DA MUST include one Authentication Block for each SPI.  If all
   these Authentication Blocks do not fit in a single datagram (to
   multicast or broadcast) the DA MUST send separate DAAdverts so that
   Authentication Blocks for all the SPIs the DA is capable of
   generating are sent.

   If the DAAdvert is being sent in response to a SrvRqst, the DAAdvert
   contains only the authentication block with the SLP SPI in the
   SrvRqst, if the DA is configured to be able to produce digital
   signatures using that SLP SPI. If the SrvRqst is unicast to the DA
   (the REQUEST MCAST flag in the header is not set) and an unsupported
   SLP SPI is included, the DA replies with a DAAdvert with the Error
   Code set to an AUTHENTICATION_UNKNOWN error.

   UAs SHOULD be configured with SLP SPIs that will allow them to verify
   DA Advertisements.  If the UA is configured with SLP SPIs and
   receives a DAAdvert which fails to be verified using one of them, the
   UA MUST discard it.

8.6. Service Agent Advertisement

User Agents MUST NOT solicit SA Advertisements if they have been configured to use a particular DA, if they have been configured with a <scope-list> or if DAs have been discovered. UAs solicit SA Advertisements only when they are explicitly configured to use User Selectable scopes (see Section 11.2) in order to discover the scopes that SAs support. This allows UAs without scope configuration to make use of either DAs or SAs without any functional difference
Top   ToC   RFC2608 - Page 26
   except performance.

   A SA MAY be configured with attributes, and SHOULD support the
   attribute 'service-type' whose value is all the service types of
   services represented by the SA. SAs MUST NOT respond if the SrvRqst
   predicate is not satisfied.  For example, only SAs offering 'nfs'
   services SHOULD respond with a SAAdvert to a SrvRqst for service type
   "service:service-agent" which includes a predicate "(service-

      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 = SAAdvert = 11)     |
     |         Length of URL         |              URL              \
     |     Length of <scope-list>    |         <scope-list>          \
     |     Length of <attr-list>     |          <attr-list>          \
     | # auth blocks |        authentication block (if any)          \

   The SA responds only to multicast SA discovery requests which either
   include no <scope-list> or a scope which they are configured to use.

   The SAAdvert MAY 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 URL is "service:service-agent://"<addr> of the SA, where <addr>
   is the dotted decimal numeric address of the SA. The <scope-list> of
   the SA MUST NOT be null.

   The SAAdvert contains one SAAdvert Authentication block for each SLP
   SPI the SA can produce Authentication Blocks for.  If the UA can
   verify the Authentication Block of the SAAdvert, and the SAAdvert
   fails to be verified, the UA MUST discard it.

9. Optional Features

The features described in this section are not mandatory. Some are useful for interactive use of SLP (where a user rather than a program will select services, using a browsing interface for example) and for scalability of SLP to larger networks.
Top   ToC   RFC2608 - Page 27

9.1. Service Location Protocol Extensions

The format of a Service Location Extension is: 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 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 (not standardized). Optional to implement. Ignore if unrecognized. 0x9000-0xFFFF Reserved. The three byte offset to next extension indicates the position of the next extension as offset from the beginning of the SLP message. The offset value is 0 if there are no extensions following the current extension. If the offset is 0, the length of the current Extension Data is determined by subtracting total length of the SLP message as given in the SLP message header minus the offset of the current extension. Extensions defined in this document are in Section D. See section 15 for procedures that are required when specifying new SLP extensions.
Top   ToC   RFC2608 - Page 28

9.2. Authentication Blocks

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Block Structure Descriptor | Authentication Block Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SLP SPI String Length | SLP SPI String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Structured Authentication Block ... \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Authentication blocks are returned with certain SLP messages to verify that the contents have not been modified, and have been transmitted by an authorized agent. The authentication data (contained in the Structured Authentication Block) is typically case sensitive. Even though SLP registration data (e.g., attribute values) are typically are not case sensitive, the case of the registration data has to be preserved by the registering DA so that UAs will be able to verify the data used for calculating digital signature data. The Block Structure Descriptor (BSD) identifies the format of the Authenticator which follows. BSDs 0x0000-0x7FFF will be maintained by IANA. BSDs 0x8000-0x8FFF are for private use. The Authentication Block Length is the length of the entire block, starting with the BSD. The Timestamp is the time that the authenticator expires (to prevent replay attacks.) The Timestamp is a 32-bit unsigned fixed-point number of seconds relative to 0h on 1 January 1970. SAs use this value to indicate when the validity of the digital signature expires. This Timestamp will wrap back to 0 in the year 2106. Once the value of the Timestamp wraps, the time at which the Timestamp is relative to resets. For example, after 06h28 and 16 seconds 5 February 2106, all Timestamp values will be relative to that epoch date. The SLP Security Parameters Index (SPI) string identifies the key length, algorithm parameters and keying material to be used by agents to verify the signature data in the Structured Authentication Block. The SLP SPI string has the same grammar as the <scope-val> defined in Section 6.4.1. Reserved characters in SLP SPI strings must be escaped using the same convention as used throughout SLPv2.
Top   ToC   RFC2608 - Page 29
   SLP SPIs deployed in a site MUST be unique.  An SLP SPI used for
   BSD=0x0002 must not be the same as used for some other BSD.

   All SLP agents MUST implement DSA [20] (BSD=0x0002).  SAs MUST
   register services with DSA authentication blocks, and they MAY
   register them with other authentication blocks using other
   algorithms.  SAs MUST use DSA authentication blocks in SrvDeReg
   messages and DAs MUST use DSA authentication blocks in unsolicited

9.2.1. SLP Message Authentication Rules

The sections below define how to calculate the value to apply to the algorithm identified by the BSD value. The components listed are used as if they were a contiguous single byte aligned buffer in the order given. URL 16-bit Length of SLP SPI String, SLP SPI String. 16-bit Length of URL, URL, 32-bit Timestamp. Attribute List 16-bit Length of SLP SPI String, SLP SPI String, 16-bit length of <attr-list>, <attr-list>, 32-bit Timestamp. DAAdvert 16-bit Length of SLP SPI String, SLP SPI String, 32-bit DA Stateless Boot Timestamp, 16-bit Length of URL, URL, 16-bit Length of <attr-list>, <attr-list>, 16-bit Length of DA's <scope-list>, DA's <scope-list>, 16-bit Length of DA's <SLP SPI List>, DA's <SLP SPI List>, 32-bit Timestamp. The first SLP SPI is the SLP SPI in the Authentication Block. This SLP SPI indicates the keying material and other parameters to use to verify the DAAdvert. The SLP SPI List is the list of SLP SPIs the DA itself supports, and is able to verify. SAAdvert 16-bit Length of SLP SPI String, SLP SPI String, 16-bit Length of URL, URL, 16-bit Length of <attr-list>, <attr-list>, 16-bit Length of <scope-list>, <scope-list>, 32-bit Timestamp.
Top   ToC   RFC2608 - Page 30

9.2.2 DSA with SHA-1 in Authentication Blocks

BSD=0x0002 is defined to be DSA with SHA-1. The signature calculation is defined by [20]. The signature format conforms to that in the X.509 v3 certificate: 1. The signature algorithm identifier (an OID) 2. The signature value (an octet string) 3. The certificate path. All data is represented in ASN.1 encoding: id-dsa-with-sha1 ID ::= { iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 } i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately by: Dss-Sig-Value ::= SEQUENCE { r INTEGER, s INTEGER } i.e., the binary ASN.1 encoding of r and s computed using DSA and SHA-1. This is followed by a certificate path, as defined by X.509 [10], [2], [3], [4], [5]. Authentication Blocks for BSD=0x0002 have the following format. In the future, BSDs may be assigned which have different formats. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASN.1 encoded DSA signature \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

9.3. Incremental Service Registration

Incremental registrations update attribute values for a previously registered service. Incremental service registrations are useful when only a single attribute has changed, for instance. In an incremental registration, the FRESH flag in the SrvReg header is NOT set. The new registration's attributes replace the previous registration's, but do not affect attributes which were included previously and are not present in the update.
Top   ToC   RFC2608 - Page 31
   For example, suppose service:x:// has been registered with
   attributes A=1, B=2, C=3.  If an incremental registration comes for
   service:x:// with attributes C=30, D=40, then the attributes for
   the service after the update are A=1, B=2, C=30, D=40.

   Incremental registrations MUST NOT be performed for services
   registered with Authentication Blocks.  These must be registered with
   ALL attributes, with the FRESH flag in the SrvReg header set.  DAs
   which receive such registration messages return an

   If the FRESH flag is not set and the DA does not have a prior
   registration for the service, the incremental registration fails with
   error code INVALID_UPDATE.

   The SA MUST use the same <scope-list> in an update message as was
   used in the prior registration.  If this is not done, the DA returns
   a SCOPE_NOT_SUPPORTED error.  In order to change the scope of a
   service advertisement it MUST be deregistered first and reregistered
   with a new <scope-list>.

   The SA MUST use the same <service-type> in an update message as was
   used in a prior registration of the same URL. If this is not done,
   the DA returns an INVALID_UPDATE error.

9.4. Tag Lists

Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a <tag-list> item is: tag-filter = simple-tag / substring simple-tag = 1*filt-char substring = [initial] any [final] initial = 1*filt-char any = `*' *(filt-char `*') final = 1*filt-char filt-char = Any character excluding <reserved> and <bad-tag> (see grammar in Section 5). Wild card characters in a <tag-list> item match arbitrary sequences of characters. For instance "*bob*" matches "some bob I know", "bigbob", "bobby" and "bob".
Top   ToC   RFC2608 - Page 32

10. Optional SLP Messages

The additional requests provide features for user interaction and for efficient updating of service advertisements with dynamic attributes.

10.1. Service Type Request

The Service Type Request (SrvTypeRqst) allows a UA to discover all types of service on a network. This is useful for general purpose service browsers. 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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of PRList | <PRList> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of Naming Authority | <Naming Authority String> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <PRList> list and <scope-list> are interpreted as in Section 8.1. The Naming Authority string, if present in the request, will limit the reply to Service Type strings with the specified Naming Authority. If the Naming Authority string is absent, the IANA registered service types will be returned. If the length of the Naming Authority is set to 0xFFFF, the Naming Authority string is omitted and ALL Service Types are returned, regardless of Naming Authority.

10.2. Service Type 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 = SrvTypeRply = 10) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Error Code | length of <srvType-list> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <srvtype--list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The service-type Strings (as described in Section 4.1) are provided in <srvtype-list>, which is a <string-list>.
Top   ToC   RFC2608 - Page 33
   If a service type has a Naming Authority other than IANA it MUST be
   returned following the service type string and a `.'  character.
   Service types with the IANA Naming Authority do not include a Naming
   Authority string.

10.3. Attribute Request

The Attribute Request (AttrRqst) allows a UA to discover attributes of a given service (by supplying its URL) or for an entire service type. The latter feature allows the UA to construct a query for an available service by selecting desired features. The UA may request that all attributes are returned, or only a subset of them. 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 | <PRList> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of URL | URL \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> string \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <tag-list> string | <tag-list> string \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <SLP SPI> string | <SLP SPI> string \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <PRList>, <scope-list> and <SLP SPI> string are interpreted as in Section 8.1. The URL field can take two forms. It can simply be a Service Type (see Section 4.1), such as "http" or "service:tftp". In this case, all attributes and the full range of values for each attribute of all services of the given Service Type is returned. The URL field may alternatively be a full URL, such as "service:printer:lpr://" or "nfs://". In this, only the registered attributes for the specified URL are returned. The <tag-list> field is a <string-list> of attribute tags, as defined in Section 9.4 which indicates the attributes to return in the AttrRply. If <tag-list> is omitted, all attributes are returned. <tag-list> MUST be omitted and a full URL MUST be included when attributes when a SLP SPI List string is included, otherwise the DA will reply with an AUTHENTICATION_FAILED error.
Top   ToC   RFC2608 - Page 34

10.4. 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 <attr-list> | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | <attr-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |# of AttrAuths | Attribute Authentication Block (if present) \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The format of the <attr-list> and the Authentication Block is as specified for SrvReg (see Section 9.2.1). Attribute replies SHOULD be returned with the original case of the string registration intact, as they are likely to be human readable. In the case where the AttrRqst was by service type, all attributes defined for the service type, and all their values are returned. Although white space is folded for string matching, attribute tags and values MUST be returned with their original white space preserved. 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 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)".

10.5. Attribute Request/Reply Examples

Suppose that printer services have been registered as follows: Registered Service: URL = service:printer:lpr:// scope-list = Development Lang. Tag = en Attributes = (Name=Igore),(Description=For developers only), (Protocol=LPR),(location-description=12th floor), (Operator=James Dornan \3cdornan@monster\3e), (media-size=na-letter),(resolution=res-600),x-OK URL = service:printer:lpr:// scope-list = Development
Top   ToC   RFC2608 - Page 35
     Lang. Tag  = de
     Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
                  (Protocol=LPR),(location-description=13te Etage),
                  (Operator=James Dornan \3cdornan@monster\3e),

     URL        = service:printer:
     scope-list = Development
     Lang. Tag  = en
     Attributes = (Name=Not),(Description=Experimental IPP printer),
                  (Protocol=http),(location-description=QA bench),

   Notice the first printer, "Igore" is registered in both English and
   German.  The `<' and `>' characters in the Operator attribute value
   which are part of the Email address had to be escaped, as they are
   reserved characters for values.

   Attribute tags are not translated, though attribute values may be,
   see [13].

   The attribute Request:

     URL        = service:printer:lpr://
     scope-list = Development
     Lang. Tag  = de
     tag-list   = resolution,loc*

   receives the Attribute Reply:

     (location-description=13te Etage),(resolution=res-600)

   The attribute Request:

     URL        = service:printer
     scope-list = Development
     Lang. Tag  = en
     tag-list   = x-*,resolution,protocol

   receives an Attribute Reply containing:


   The first request is by service instance and returns the requested
   values, in German.  The second request is by abstract service type
   (see Section 4) and returns values from both "Igore" and "Not".
Top   ToC   RFC2608 - Page 36
   An attribute Authentication Block is returned if an authentication
   block with the SLP SPI in the AttrRqst can be returned.  Note that
   the <attr-list> returned from a DA with an Authentication Block MUST
   be identical to the <attr-list> registered by a SA, in order for the
   authentication verification calculations to be possible.

   A SA or DA only returns an Attribute Authentication Block if the
   AttrRqst included a full URL in the request and no tag list.

   If an SLP SPI is specified in a unicast request (the REQUEST MCAST
   flag in the header is not set) and the SA or DA cannot return an
   Authentication Block with that SLP SPI, an AUTHENTICATION_UNKNOWN
   error is returned.  The # of Attr Auths field is set to 0 if there no
   Authentication Block is included, or 1 if an Authentication Block

10.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 <scope-list> | <scope-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | URL Entry \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length of <tag-list> | <tag-list> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The <scope-list> is a <string-list> (see section 2.1). The SA MUST retry if there is no response from the DA, see Section 12.3. The DA acknowledges a SrvDeReg with a SrvAck. Once the SA receives an acknowledgment indicating success, the service and/or attributes are no longer advertised by the DA. The DA deregisters the service or service attributes from every scope specified in the SrvDeReg which it was previously registered in. The SA MUST deregister all services with the same scope list used to register the service with a DA. If this is not done in the SrvDeReg message, the DA returns a SCOPE_NOT_SUPPORTED error. The Lifetime field in the URL Entry is ignored for the purposes of the SrvDeReg.
Top   ToC   RFC2608 - Page 37
   The <tag-list> is a <string-list> of attribute tags to deregister as
   defined in Section 9.4.  If no <tag-list> is present, the SrvDeReg
   deregisters the service in all languages it has been registered in.
   If the <tag-list> is present, the SrvDeReg deregisters the attributes
   whose tags are listed in the tag spec.  Services registered with
   Authentication Blocks MUST NOT include a <tag-list> in a SrvDeReg
   message:  A DA will respond with an AUTHENTICATION_FAILED error in
   this case.

   If the service to be deregistered was registered with an
   authentication block or blocks, a URL authentication block for each
   of the SLP SPIs registered must be included in the SrvDeReg.
   Otherwise, the DA returns an AUTHENTICATION_ABSENT error.  If the
   message fails to be verified by the DA, an AUTHENTICATION_FAILED
   error is returned by the DA.

(page 37 continued on part 3)

Next Section