Internet Engineering Task Force                             Erik Guttman
INTERNET DRAFT                                           Charles Perkins
6 March 1998                                            Sun Microsystems
                                                           John Veizades
                                                           @Home Network
                                                             Michael Day

                       Service Location Protocol

Status of This Memo

   This document is a submission by the Service Location Working Group
   of the Internet Engineering Task Force (IETF).  Comments should be
   submitted to the mailing list.

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents 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.''

   To learn the current status of any Internet-Draft, please check
   the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
   Shadow Directories on (Africa), (North
   Europe), (South Europe), (Pacific Rim), (US East Coast), or (US West Coast).


   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

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page i]

Internet Draft          Service Location Protocol           6 March 1998


Status of This Memo                                                    i

Abstract                                                               i

 1. Introduction                                                       1

 2. Terminology                                                        2
     2.1. Notation Conventions  . . . . . . . . . . . . . . . . . .    3

 3. Protocol Overview                                                  3

 4. URLs used with Service Location                                    4
     4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . .    4
     4.2. URL Entries . . . . . . . . . . . . . . . . . . . . . . .    5

 5. Service Attributes                                                 6

 6. Required Features                                                  7
     6.1. Use of UDP, TCP, and Multicast  . . . . . . . . . . . . .    8
           6.1.1. UDP and Multicast Transmission of SLP Messages  .    9
     6.2. Use of TCP  . . . . . . . . . . . . . . . . . . . . . . .    9
           6.2.1. Retransmission of multicast messages  . . . . . .   10
     6.3. Strings in SLP messages . . . . . . . . . . . . . . . . .   10

 7. Required SLP Messages                                             11
     7.1. Service Request . . . . . . . . . . . . . . . . . . . . .   12
     7.2. Service Reply . . . . . . . . . . . . . . . . . . . . . .   14
     7.3. Service Registration  . . . . . . . . . . . . . . . . . .   15
     7.4. Service Acknowledgment  . . . . . . . . . . . . . . . . .   16
     7.5. Directory Agent Advertisement . . . . . . . . . . . . . .   16

 8. Errors                                                            17

 9. Optional Features                                                 17
     9.1. Service Location Protocol Extension Options . . . . . . .   17
     9.2. Authentication Blocks . . . . . . . . . . . . . . . . . .   18
           9.2.1. MD5 with RSA in Authentication Blocks . . . . . .   19
           9.2.2. DSA with SHA-1 in Authentication Blocks . . . . .   19
           9.2.3. Keyed HMAC with MD5 in Authentication Blocks  . .   20
     9.3. Authentication of a SrvRply . . . . . . . . . . . . . . .   20
     9.4. Optimizations with XIDs . . . . . . . . . . . . . . . . .   21
     9.5. Service Registration Updates  . . . . . . . . . . . . . .   21
     9.6. Naming Authorities  . . . . . . . . . . . . . . . . . . .   21
     9.7. Tag Lists . . . . . . . . . . . . . . . . . . . . . . . .   22

10. Optional SLP Messages                                             22

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page ii]

Internet Draft          Service Location Protocol           6 March 1998

    10.1. Service Type Request  . . . . . . . . . . . . . . . . . .   22
    10.2. Service Type Reply  . . . . . . . . . . . . . . . . . . .   23
    10.3. Attribute Request . . . . . . . . . . . . . . . . . . . .   24
    10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . .   25
    10.5. Attribute Request/Reply Examples  . . . . . . . . . . . .   25
    10.6. Service Deregistration  . . . . . . . . . . . . . . . . .   27

11. Scopes                                                            28
    11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . .   28
    11.2. Administrative and User Configurable Scopes . . . . . . .   28
    11.3. Protected Scopes  . . . . . . . . . . . . . . . . . . . .   29

12. Directory Agents                                                  29
    12.1. Directory Agent Rules . . . . . . . . . . . . . . . . . .   30
    12.2. Directory Agent Discovery . . . . . . . . . . . . . . . .   30
          12.2.1. Active DA Discovery . . . . . . . . . . . . . . .   31
          12.2.2. Passive DA Advertising  . . . . . . . . . . . . .   31
    12.3. Reliable Unicast to DAs . . . . . . . . . . . . . . . . .   32
    12.4. DA Scope Configuration  . . . . . . . . . . . . . . . . .   32
    12.5. DAs and Authentication Blocks . . . . . . . . . . . . . .   33

13. Protocol Timing Defaults                                          33

14. SLP Protocol Extensions                                           34
    14.1. Required Attribute Missing Option . . . . . . . . . . . .   34
    14.2. Cryptographic Algorithm Request Option  . . . . . . . . .   34

15. Optional Configuration                                            35

16. IANA Considerations                                               36

17. Internationalization Considerations                               37

18. Security Considerations                                           37

19. Acknowledgments                                                   38

20. Full Copyright Statement                                          38

1. Introduction

   Traditionally, users find services by using the name of a network
   host (a human readable text string) which is an alias for a network
   address.  The Service Location Protocol eliminates the need for
   a user to know the name of a network host supporting a service.
   Rather, the user names the service and supplies a set of attributes
   which describe the service.  The Service Location Protocol allows the
   user to bind this description to the network address of the service.

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 1]

Internet Draft          Service Location Protocol           6 March 1998

   Service Location provides a dynamic configuration mechanism for
   applications in local area networks.  It has been designed to serve
   enterprise networks with shared services, and it may not necessarily
   scale for wide-area service discovery throughout the global Internet.
   Applications are modeled as clients that need to find servers
   attached to any of the available networks within the enterprise.
   For cases where there are many different clients and/or services
   available, the protocol is adapted to make use of nearby Directory
   Agents that offer a centralized repository for advertised services.

   The Service Location Protocol (SLP) is presented in two parts.  The
   first are the required features of the protocol.  The second are the
   extended features of the protocol which are optional or allow greater

2. Terminology

      User Agent (UA)
                A process working on the user's behalf to establish
                contact with a useful service.  The UA retrieves service
                information from the Service Agents or Directory Agents.

      Service Agent (SA)
                A process working on the behalf of one or more services
                to advertise the services.

      Directory Agent (DA)
                A process which collects and caches service
                advertisements from SAs.  If there is a DA, UAs use them
                in preference to SAs.  There can only be one DA present
                per given host.

      Service Type
                Each type of service has a unique Service Type string.

      Naming Authority
                The agency or group which catalogues given Service Types
                and Attributes.  The default Naming Authority is IANA.

      Scope     A collection or set of services that make up a logical

      URL       A Universal Resource Locator - see [8].

      SLP v1    The version of Service Location Protocol specified in
                RFC 2165 [19].

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 2]

Internet Draft          Service Location Protocol           6 March 1998

2.1. Notation Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119  [9].

      Syntax        Syntax for string based protocols follow the
                    conventions defined for ABNF [12].

      Strings       Strings in the protocol are NOT null terminated.
                    They are always proceeded by a two byte length

      String List   This construct, used frequently in the protocol, is
                    a comma delimited list of strings with the following

                       string-list = string / string `,' string-list

   In format diagrams, any field ending with a \ indicates a variable
   length field, given by a prior length field in the protocol.

3. Protocol Overview

   The Service Location Protocol (SLP) provides a flexible and scalable
   framework for providing hosts with access to information about the
   existence, location, and configuration of networked services.

   SLP is a request-reply protocol; in a typical operation a User Agent
   (UA) issues a request for service information and awaits one or more
   replies containing the requested information.

   Depending on the environment, replies will be sent to the UA by a
   SA, a DA, or by both.  For smaller environments, SLP allows a simple
   peer-to-peer deployment consisting only of UAs and SAs.  For larger
   environments, SLP allows the consolidation of service configuration
   data at one or more DAs.

   DAs, in addition to consolidating service information, allow
   information to be organized according to administrative, usage, or
   type domains using "scopes."

   SLP Messages are normally transmitted in datagrams using UDP/IP.
   Requests may be unicast, multicast, or broadcast.  When a UA
   multicasts or broadcasts a request, it will often receive more than
   one reply.  Replies must be unicast.  In cases where a reply is too
   large to fit within a datagram, the UA may reissue the request using

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 3]

Internet Draft          Service Location Protocol           6 March 1998

   TCP. Requests which are too large to fit into a datagram are always
   sent using TCP.

   Hosts may be configured statically or by using DHCP options 78 and
   79 to issue requests to specific SAs or DAs.  Otherwise, SLP allows
   a host to "bootstrap" itself, beginning with no knowledge of any
   services or SLP agents beyond its own UA. To bootstrap itself, the
   host must multicast or broadcast its first request.

   Certain conditions will influence the best strategy for deploying SLP
   in specific environments.  Centralizing service information using
   DAs simplifies the process by which UAs obtain service information.
   However, it is not necessary to centralize service-related
   information in smaller installations; multicast queries are
   adequate.  Specific environments may have special policies regarding
   broadcasting or multicasting.

   This document specifies a range of usage models for SLP, beginning
   with a lightweight and simple minimal implementation for smaller or
   constrained environments.  SLP can be scaled upward from the minimal
   implementation by deploying more richly featured UAs and SAs, and by
   adding DAs.

   A SLP v2 implementation MAY support SLP v1 [19].

4. URLs used with Service Location

   A Service URL indicates the location of a service.  This URL may
   be of the service: scheme [13] (reviewed in section 4.1), or any
   other URL scheme conforming to the URL standard [8], except that
   URLs without address specifications MUST NOT be advertised by SLP.
   The service type for an arbitrary URL is typically its scheme name.
   For example, the service type string for "" is

   Reserved characters in URLs follow the rules in [8].

4.1. Service: URLs

   A Service URL is of the form:


   The Service Type of a service: URL is defined to be the string up to
   (but not including) the final `:'  before <addrspec>, the address

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 4]

Internet Draft          Service Location Protocol           6 March 1998

   <addrspec> is a hostname (which should be used if possible) or
   dotted decimal notation for a hostname, followed by an optional
   `:'  and port number.  For a definition of extended service URLs,
   see [13].

   Any service may be encoded in a service URL. By definition
   (see [13]), a service: scheme URL may be formed with any standard
   protocol name by concatenating "service:" and the reserved port [1]
   name.  For example, ``service:tftp://myhost'' would indicate a
   tftp service.  An http service on a nonstandard port could be

   Service Types may be defined by a ``service template'' [13], which
   provides expected attributes, values and protocol behavior.  That
   document also describes 'Abstract Service Types.'  An abstract
   service type has the form


   The service type string "service:<abstract-type>" matches all
   services of that abstract type.  If the concrete type is included
   also, only these services match the request.  For example:  a
   SrvRqst or AttrRqst which specifies "service:printer" as the
   Service Type will match the URL service:printer:lpr://hostname
   and service:printer:http://hostname.  If the requests specified
   "service:printer:http" they would match only the latter URL. An
   optional substring MAY follow the last `.'  character in the service
   type string is the Naming Authority, as described in Section 9.6.

4.2. URL Entries

      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             |# of URL auths |
     |          URL length           |     URL (variable length)     \
     |                     Auth. blocks (if any)                     \

   SLP stores URLs in protocol elements called URL Entries, which
   associate a length, a lifetime, and possibly authentication
   information along with the URL. URL Entries, defined as shown above,
   are used in Service Replies and Service Registrations.

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 5]

Internet Draft          Service Location Protocol           6 March 1998

5. Service Attributes

   A service advertisement is often accompanied by Service Attributes.
   These attributes are used by UAs to select services in Service

   The attributes which may be used are typically defined by a Service
   Template  [13] for a particular service type.  Services which
   are advertised according to a standard template MUST register all
   service attributes which the standard template requires.  URLs with
   schemes other than "service:" MAY be registered with attributes.
   Non-standard attributes names should begin with "x-", because no
   standard attribute name will ever have those initial characters.

   An attribute list is a string encoding of the attributes of a
   service.  The following ABNF [12] grammar applies to lists of

   attr-list = attribute / attribute `,' attr-list
   attribute = `(' attr-tag `=' attr-val-list `)' / attr-tag
   attr-val-list = attr-val / attr-val `,' attr-val-list
   attr-tag = 1*safe-tag
   attr-val = intval / strval / boolval / opaque
   intval = [-]1*DIGIT
   strval = 1*safe-val
   boolval = "TRUE" / "FALSE"
   opaque = "\FF" 1* ( `\' HEXDIGIT HEXDIGIT )
   safe-val = Any character except reserved.
   safe-tag = Any character except reserved, star and bad-tag.
   reserved = `(' / `)' / `,' / `\' / `!'  / `<' / `=' / `>' / `~' / CTL
   escape-val = `\' HEXDIG HEXDIG
   bad-tag = CR / LF / HT
    star =`*'

   The <attr-list>, if present, must be scanned prior to evaluation for
   all occurrences of the escape character `\'.  Reserved characters
   MUST be escaped (other characters MUST NOT be escaped).  All escaped
   characters must be restored to their value before attempting string
   matching.  For Opaque values escaped characters are not converted -
   they are interpreted as bytes.

      Boolean      Strings which have the form "true" or "false" can
                   only take one value and may only be compared with '='
                   or '!='.

      Integer      Strings which take the form [-] 1*<digit> and fall
                   in the range "-2147483648" to "2147483647" are
                   considered to be Integers.  These are compared using
                   integer comparison.

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 6]

Internet Draft          Service Location Protocol           6 March 1998

      String       All other Strings are matched using strict lexical
                   ordering; see Section 6.3.

      Opaque       Opaque values are sequences of bytes.  These are
                   distinguished from Strings since they begin with the
                   byte \FF which is an illegal UTF8 character.  What
                   follows is a sequence of bytes expressed in escape
                   notation which constitute the binary value.

   A string which contains escaped values other than from the reserved
   set of characters is illegal.  If such a string is included in
   an <attr-list>, <tag-list> or search filter the SA or DA which
   receives it MUST return a PROTOCOL_PARSE_ERROR in the reply.

   A keyword has only an <attr-tag>, and no values.  Attributes can
   have one or multiple values.  All values are expressed as strings.

   All attribute values are expressed as strings.  When values have
   been advertised by a SA or are registered in a DA, they can take on
   implicit typing rules for matching incoming requests.

   Stored values must be consistent, i.e., x=4,true,sue,\00\00\00 is
   disallowed.  A DA or SA MUST return an INVALID_REGISTRATION error.

6. Required Features

   Service discovery is performed on behalf of a client by SLP UA
   functionality.  A host's services are represented by a SA which
   responds to UA requests.  A third element in the framework is the DA
   which is a cache of service information.  The UA and SA interaction
   with a DA is discussed here, but DA implementation is not part of the
   minimal specification.

                        Wants this information:
   Client Application  - - - - - - - - - - - - -> Service
        USES                                       USES
      User Agent -----------------------+--> Service Agent
              (Request: SrvRqst         |    ^       | (Request: SrvReg
               Reply:   SrvRply         |    |       |  Reply:   SrvAck)
                        or DAAdvert)    |   DAAdvert v
                                        +---> Directory Agent

   The UA issues a SrvRqst using multicast to the assigned address,
   requesting the service-type `directory-agent' and the scope list it
   has been configured with.  If it receives any results, all subsequent
   service requests SHOULD unicast to the DA indicated in the URL in
   the DAAdvert reply.  If it does not receive a reply, it multicasts
   subsequent requests and SAs will respond.  It should retry DA

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 7]

Internet Draft          Service Location Protocol           6 March 1998

   discovery once every CONFIG_DA_FIND seconds if it knows of no DAs,
   if subsequent discovery is required.  UAs MUST be prepared for the
   possibility that the service information they obtain from DAs is

   The SA also issues a SrvRqst for DAs, as described above.  If any DAs
   are discovered, the SA MUST register all of its services with the DA
   using a series of SrvReg requests.  The SrvAck indicates whether the
   DA has been successful.

   SAs listen for multicast messages.  If they receive a SrvRqst, they
   will respond with a SrvRply as defined below.  If the SAs receive a
   DAAdvert (which DAs periodically emit) they must remotely register
   all services with it which support one or more of the scopes in DA's
   scope list.

   Scope strings are used for scalability.  UAs, DAs and SAs are
   assigned scopes to provision services:  UAs request services in
   scopes which administrators desire they use.  SAs advertise services
   in their their assigned scopes.  DAs use scope to cache only a subset
   of all services, and respond to requests by a subset of all UAs.  A
   scope is called 'protected' if it is associated with a particular
   mechanism for authentication (see section 11).

6.1. Use of UDP, TCP, and Multicast

   The Service Location Protocol uses multicast when supported at
   the network layer.  The reserved port for SLP is 427.  This is
   the destination port for all SLP messages.  SLP messages MAY be
   transmitted on an ephemeral port.  The default maximum transmission
   unit is 1400 bytes.  The Administratively Scoped SLP Multicast
   address is  SLP Requests messages are multicast to
   the Service Location Multicast Address.  The default TTL to use for
   multicast is 32.

   In isolated networks, broadcasts will work in place of multicast.
   To that end, SAs SHOULD and DAs MUST listen for broadcast Service
   Location request messages to port 427.  This allows UAs which lack
   multicast capabilities to still make use of Service Location on
   isolated networks.

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

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 8]

Internet Draft          Service Location Protocol           6 March 1998

6.1.1. UDP and Multicast Transmission of SLP Messages

   UAs MUST be able to issue requests to DAs using UDP and SAs using
   multicast/convergence.  SAs MUST be able to respond to UDP and
   multicast requests.

   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 header.
   A UA which receives such a truncated reply MAY open a TCP connection
   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.

6.2. Use of TCP

   A SrvReg or SrvDeReg may be too large to fit into a datagram.  To
   send SLP messages which do not fit in a datagram, a TCP connection
   MUST be established.

   To avoid the need to implement TCP, one MUST insure that:

    -  UAs never issue requests larger than the Path MTU.

    -  UAs can accept replies with the 'OVERFLOW' flag set, and make use
       of the first result included.

    -  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

   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 send a reply which will exceed a datagram
   in size.  This is possible if the SA is an embedded system, for
   instance, with a very limited set of service URLs and attributes that
   it is configured with.

   A TCP connection initiated by an Agent MAY be used for a single
   transaction.  It may MAY be used for multiple transactions.  Since
   there are length fields in the message headers, the Agents can send
   multiple requests along a connection and read the return stream for
   acknowledgments and replies.

   The initiating agent is responsible for closing the TCP connection.
   The DA should wait at least CONFIG_CLOSE_CONN seconds before closing
   an idle connection.  DAs and SAs SHOULD eventually close idle TCP
   connections to ensure robust operation, even when the agent which

Guttman,Perkins,Veizades,Day      Expires 6 September 1998      [Page 9]

Internet Draft          Service Location Protocol           6 March 1998

   opened a connection neglects to close it.  See Section 13 for timing

6.2.1. Retransmission of multicast messages

   Requests to SAs are multicast repeatedly (with a recommended wait
   interval of CONFIG_MC_RETRY) until there are no new responses, or
   CONFIG_MC_MAX seconds have elapsed.  DA discovery requests use
   different timing for repeated requests, CONFIG_DA_RETRY.

   Multicast requests SHOULD be reissued over 15 seconds (say 3 times
   total) until a result has been obtained.  SAs MUST register with all
   discovered DAs.  UAs need only wait till they obtain the first reply
   which matches their request.  Unicast requests (SrvReg or SrvRqst)
   to a DA should be retried until either a response (which might be an
   error) has been obtained, or for 5 seconds.

   When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
   they contain a <PRList> of previous responders.  In those cases,
   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.  Any DA or SA which
   sees its address in the <PRList> MUST NOT respond to the request.

6.3. Strings in SLP messages

   All strings are encoded using UTF8 [20] and are NOT null terminated
   when transmitted.  The escape character is a backslash (ASCII 0x5c)
   followed by the two hexadecimal digits of the escaped character.
   Only reserved characters are escaped.  For example, a comma (ASCII
   0x29) is escaped as `\29'.  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.

   String matching in SLP is case insensitive.  White space (SPACE,
   CR, LF, TAB) internal to a string value is folded to a single SPACE
   character for the sake of string comparisons.  For example, "  Some
   String  " matches "SOME    STRING".

   String comparisons (using comparison operators such as `<=' or
   `>=') are done using lexical ordering in the character set of the
   registration, not using any language specific rules.  The ordering is
   strictly by the character value, i.e.  `0' <= `A' is true when the
   character set is US-ASCII, since `0' has the value of 48 and `A' has
   the value 65.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 10]

Internet Draft          Service Location Protocol           6 March 1998

   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.

7. Required SLP Messages

   SLP messages have a binary format and begin with a 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    |  Function-ID  |            Length             |
     |O|Q|U|A|F|R|      reserved     |       Language Tag Length     |
     |      Next Option Offset       |              XID              |
     \                 Language Tag (ASCII string)                   \

          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

   SAs and UAs MUST support SrvRqst, SrvRply and DAAdvert.  SAs MUST
   also support SrvReg 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.  URLSIG (0x40) is set by
       a SA when it registers a signed URL with a DA or a signed URL
       is passed in a SrvRply to a UA. ATTRSIG (0x20) is set by a SA
       when signed attributes are registered with a DA. FRESH (0x10)
       is set on every new SrvReg.  REQUEST MCAST (0x08) is set when
       multicasting requests.
     - Lang Tag Length indicates the length of the Language Tag field.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 11]

Internet Draft          Service Location Protocol           6 March 1998

     - Next Option Offset is set to 0 unless extension options are used.
       See Section 9.1 for how to interpret unrecognized options.  The
       first extension begins at 'offset' bytes, from the message's
       beginning, after the SLP message data
     - 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.
     - Language Tag conforms to [6].  The Language Tag in a reply MUST
       be the same as the Language Tag in the request.

   If a flag indicates an authentication block will follow, or an option
   is specified, and these fields are not included in the message, the
   receiver MUST respond with a PROTOCOL_PARSE_ERROR.

7.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>  \

   In order for a Service to match a SrvRqst, it must belong to a
   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.  At least one scope in the SrvRqst Scope List
   must match the scope of the SA.

   <PRList> is the Previous Responder List.  This <string-list>
   contains either fully qualified domain names or dotted decimal
   notation IP (v4) addresses, and is iteratively multicast to obtain
   all possible results (see Section 6.2.1).  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 drops all requests silently which include
   the SA's address in the <PRList>.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 12]

Internet Draft          Service Location Protocol           6 March 1998

   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
   SCOPE_NOT_SUPPORTED error if the <scope-list> is omitted or fails to
   include a scope they support (see Section 11).  The only exception to
   this is describe in Section 11.2.  SAs drop multicast requests which
   do not include a scope they support.

   The <service-type> string is discussed in Section 4.  If it is set
   to "service:directory-agent", the SrvRqst will elicit a DAAdvert
   message.  Otherwise it will obtain SrvRply messages.

   The <predicate> is a LDAPv3 search filter [14].  This field may be
   omitted if services are to be discovered simply by type and scope.
   Otherwise, services are discovered which satisfy the included search
   filter.  If the filter is present, it is applied to each registered
   service.  If the attribute in the filter has been registered with
   multiple values, the filter is applied to each value and the result
   is 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 'or'.

   Wildcard matching can ONLY be done with the '=' filter.  In any
   other case, a PROTOCOL_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 and Strings don't match

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

      <t>=service:http  <s>=DEFAULT  <p>=NONE
               This is a minimal request string.  It matches all http

      <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

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 13]

Internet Draft          Service Location Protocol           6 March 1998

      <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

               DAs are discovered by sending a SrvRqst with the service
               type set to "service:directory-agent" and the predicate
               omitted.  The scope list SHOULD be set to the configured
               scope list of the service.  (OPTIONALLY the scope list
               may be omitted, see Section 11.2.)  For example:

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

7.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 a list of URL entries (see Section 4.2)
   which satisfy a SrvRqst.  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.  In that case, the cache
   lifetime is indicated by the Timestamp in the URL Authenticator
   (see Section 9.2).  One authentication block is returned for each
   protected scope the service was registered in which was present in
   the <scope-list> of the SrvRqst.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 14]

Internet Draft          Service Location Protocol           6 March 1998

7.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 as defined in section 4.2.  The Lifetime
   defines how long a DA can maintain the registration.  SAs SHOULD
   reregister with DAs before this lifetime expires (but no more often
   than once every CONFIG_REG_SPEED seconds).  The Lifetime can be set
   to the 0xffff (maximum, around 18 hours) and simply reregistered in
   response to a DAAdvert.  This has the disadvantage that if the SA or
   the service fails, the stale registration will be cached longer.

   The <service-type> defines the service type of the URL to be
   registered.  This field is authoritative over the URL for the
   purposes of registration.

   The <scope-list> MUST be set to the configured Scope list of the SA.
   The default value is ``DEFAULT'' (see Section 11).

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

   If the ATTRSIG flag is set in the header, an Attr Authentication
   block (see Section 9.2) is transmitted.  This is calculated over
   STRING>.  Note that signatures are case and order sensitive.

   The FRESH flag is set in the SrvReg header unless the 'Update'
   optimization is being used (see Section 9.5).  The registration with
   the FRESH flag set will replace *entirely* any previous registration
   for the same URL in the same language.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 15]

Internet Draft          Service Location Protocol           6 March 1998

7.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 = 4)      |
     |          Error Code           |

   A DA returns a SrvAck to an SA after a SrvReg.  It carries only a two
   byte Error Code (see Section 8).

7.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          |    DAAdvert Sequence Number   |
     |         Length of URL         |              URL              \
     |     Length of <scope-list>    |          <scope-list>         \
     |              authentication block (if included)               \

   The DAAdvert uses the same error codes as a SrvRply.  If the error
   code is nonzero, data will follow.

   The sequence number indicates the state of the DA (see 12.2.2).

   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 DAAdvert MAY contain a URL authenticator, which will be generated
   using a DA Advertising private key.  UAs SHOULD be configured with
   DA Advertisement public keys so they can verify the authenticity of
   DAAdverts.  If the UA can verify DAAdverts, and the DAAdvert fails to
   be verified, the UA MUST discard it.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 16]

Internet Draft          Service Location Protocol           6 March 1998

8. 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.

   LANGUAGE_NOT_SUPPORTED = 1: There is data for the service type in the
         scope in the SrvRqst, but not in the requested language.
   PARSE_ERROR = 2: The message fails to obey SLP syntax.
   INVALID_REGISTRATION = 3: The SrvReg has problems i.e., a 0 lifetime,
         an omitted language tag, etc.
   SCOPE_NOT_SUPPORTED = 4: The DA did not find a scope for which it has
         been configured to store the requested information.
   AUTHENTICATION_ABSENT = 6: The DA expects URL and ATTR authentication
         in the SrvReg and did not receive it.
   AUTHENTICATION_FAILED = 7: The DA determines the URL or ATTR
         signature in the SrvReg came out bad
   VER_NOT_SUPPORTED = 9: Ver was set to an unsupported version number.
   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 Option from
         the Mandatory range which is not understood.
   INVALID_UPDATE = 13: The DA received a SrvReg without FRESH set, for
         an unregistered service.  See Section 9.5.

9. Optional Features

   The features described in this section are not mandatory.  They 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.

9.1. Service Location Protocol Extension Options

   A service location extension option must be specified by a standards
   track document.  The option may be defined to accompany any or all
   Service Location Messages.  A conforming SLP implementation MUST
   be able to ignore Service Location Extension Options it does not

   The format of a Service Location Extension Option is:

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 17]

Internet Draft          Service Location Protocol           6 March 1998

      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
     |      Option Extension ID      |          Option Length        |
     \                       Extension Contents                      \

   The Option Extension ID is defined by a IETF Standards document which
   also defines the contents of the extension.  The offset to next
   option is 0 if there is no option following or is set to the length
   of the current Extension contents.  The 'last option' in the sequence
   is determined implicitly by summing the length parsed and comparing
   it to the total length of the message given in the SLP header.

   Options Extension IDs are assigned in the following way:

   0x0000-0x3FFF Standardized.  Optional to implement.  Ignore if
   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 NOT Standardized, for private use.  Optional to
         implement.  Ignore if unrecognized.
   0x9000-0xFFFF Reserved:  Do not use.

   Options defined in this document are in Section 14.

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   |            Length             |
     | Protected Scope String Length |   Protected Scope String      \
     |                                                               |
     +                           Timestamp                           +
     |                                                               |
     \              Structured Authentication Block ...              \

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 18]

Internet Draft          Service Location Protocol           6 March 1998

   Authentication blocks are returned with certain SLP data to verify
   that the contents have not been modified.

   The Block Structure Descriptor (BSD) identifies the format of the
   Authenticator which follows.  BSDs 0x0000-0x7FFF will be identified
   by IANA. BSDs 0x8000-0x8FFF are for private use.

   SLP agents MUST implement DSA [17] (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 DAAdverts.

9.2.1. MD5 with RSA in Authentication Blocks

   BSD=0x0001 indicates that md5withRSAEncryption is selected as the
   authentication algorithm for the Structured Authentication Block.
   The Authentication Block will start with the ASN.1 Distinguished
   Encoding (DER) [10] for "md5WithRSAEncryption", which has the as its
   value the bytes (MSB first in hex):

      "30 0d 06 09 2a 86 48 86 f7 0d 01 01 04 05 00"

   This is then immediately followed by an ASN.1 Distinguished Encoding
   (as a "Bitstring") of the RSA encryption (using the protected
   scope's private key) of a bitstring consisting of the OID for "MD5"
   concatenated by the MD5 [18] message digest computed over the fields
   above.  The exact construction of the MD5 OID and digest can be found
   in RFC 1423 [7].

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 [17].  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 }

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 19]

Internet Draft          Service Location Protocol           6 March 1998

   i.e., the ASN.1 encoding of 1.2.840.10040.4.3 followed immediately

        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 [11], [2], [3], [4], [5].

9.2.3. Keyed HMAC with MD5 in Authentication Blocks

   BSD=0x0003 is defined to be HMAC [15].  using keyed-MD5 [18].

   Given a secret key K and the data to authenticate, the Authentication
   Block is computed as follows:
    1. opad := 0x36363636363636363636363636363636 (128 bits)

    2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
    3. zero_extended_key := K extended by zeroes to be 128 bits long
    4. opadded_key := zero_extended_key XOR opad
    5. ipadded_key := zero_extended_key XOR ipad
    6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))

   The authenticator is the 128-bit value HMAC_result.

   Note that this authentication scheme works for peer-to-peer
   implementations (where hosts can both verify and generate
   authenticators) but not for client-server applications where clients
   are NOT trusted to create authenticators for services of a protected
   scope.  In this case, Public Key cryptography is used.

9.3. Authentication of a SrvRply

   Each SA MUST sign the SrvRply if it is responding to a SrvRqst made
   to a protected scope, adding an Authentication Block containing the
   signature.  The authentication data MUST be calculated over the
   STRING, SCOPE STRING>.  The Timestamp is the time that the service
   reply expires (to prevent replay attacks.)  The Timestamp is an 8
   byte value in NTP format [16].  The BSD auth bytes are calculated
   according to the algorithm indicated by the BSD value.  Note that
   signatures are case sensitive, so implementations must transmit URLs
   in the same case as used to calculate the signature.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 20]

Internet Draft          Service Location Protocol           6 March 1998

9.4. Optimizations with XIDs

   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
   duplicate XIDs in requests if UAs restart frequently.

9.5. Service Registration Updates

   Registrations of a previously registered service are considered an
   update.  Partial updates of service registration are useful when only
   a single attribute has changed, for instance.  In an update, 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.

   For example, suppose service:x:// has been registered
   with attributes A=1, B=2, C=3.  If a new 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.

   Updates MUST NOT be performed for services registered in protected
   scopes.  These must be registered with ALL attributes, with the
   "FRESH" flag in the SrvReg header set.

   If an update is sent and the DA does not have a prior registration
   for the service, the update fails and the DA responds with a

   If the update includes a scope list other than the one in the
   prior registration, 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 in a new scope.

9.6. Naming Authorities

   A Naming Authority MAY optionally be included as part of the Service
   Type string, see Section 4.1.  The Naming Authority of a service
   defines the meaning of the Service Types and attributes registered
   with and provided by Service Location.  The Naming Authority itself
   is typically a string which uniquely identifies an organization.
   IANA is the implied Naming Authority when no string is appended.
   "IANA" itself MUST NOT BE included explicitly.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 21]

Internet Draft          Service Location Protocol           6 March 1998

   Naming Authorities may define Service Types which are experimental,
   proprietary or for private use.  Using a Naming Authority, one
   may either simply ignore attributes upon registration or create a
   local-use only set of attributes for one's site.  The procedure to
   use is to create a 'unique' Naming Authority string and then specify
   the Standard Attribute Definitions as described above.  This Naming
   Authority will accompany registration and queries, as described in
   Sections 7.1 and 7.3.  Service Types SHOULD be registered with IANA
   to allow for Internet-wide interoperability.

9.7. 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".

10. Optional SLP Messages

   The additional requests provided for SLP 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.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 22]

Internet Draft          Service Location Protocol           6 March 1998

      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 7.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

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           |    number of service types    |
     |length of SrvType <string-list>|     SrvType <string-list>     \

   Service Type Strings (as described in Section 4.1) are provided in

   If the 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.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 23]

Internet Draft          Service Location Protocol           6 March 1998

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       \

   The <PRList> and <scope-list> are interpreted as in Section 7.1.

   The URL field can take two forms.  It can simply be a Service Type
   (see Section 4.1), such as "http" or "nfs".  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 attributes for the
   service of the specified URL is defined are returned.

   The <tag-list> field is a string list of attribute tags, as defined
   in Section 9.7 which indicates the attributes to return in the
   AttrRply.  If <tag-list> is omitted, all attributes are returned.
   <tag-list> MUST be omitted when attributes are requested in a
   protected scope from a DA, otherwise the DA will reply with an

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 24]

Internet Draft          Service Location Protocol           6 March 1998

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> string |
     \                      <attr-list>              \ # Auth Blocks |
     \          (if present) Attribute Authentication Blocks...      \

   The format of the <attr-list> and the Attr Authentication Block is
   identical to that used for SrvReg, see Section 9.2.

   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.
   Only one copy of each attribute tag or String value should be
   returned, arbitrarily choosing one version (with respect to upper and
   lower case).

   Note that the <attr-list> returned from a DA in a protected scope
   MUST be identical to the <attr-list> registered by a SA, in order
   for the Attr Authenticator to be successful.

   One attribute authentication block is returned for each scope in the
   <scope-list> which is a protected scope.

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),

     URL        = service:printer:lpr://
     scope-list = Entwicklung
     Lang. Tag  = de

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 25]

Internet Draft          Service Location Protocol           6 March 1998

     Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler),
                  (Protocol=LPR),(Standort-beschreibung=13te Etage),
                  (Techniker=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.

   The string "PROTOCOL" is 'literal' so it is not translated to
   different languages, see [13].

   The attribute Request:

     URL        = service:printer:lpr://
     scope-list = Entwicklung
     Lang. Tag  = de
     tag-list   = Resolution,St*

   receives the Attribute Reply:

     (Standort-beschreibung=13te Etage),(Resolution=res-600)

   The attribute Request:

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

   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".

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 26]

Internet Draft          Service Location Protocol           6 March 1998

10.6. Service Deregistration

   A service which is registered will time out at the DA 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 = 5)     |
     | length of Scope <string-list> |     Scope <string-list>       |
     |         length of URL         |              URL              \
     | #auth blocks |   (if present) authentication blocks .....     \
     |  length of <tag-list> string  |            <tag-list>         \

   The scope list is a <string-list> of scopes.

   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, it can assume that
   the service is 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.

   If the URL deregistered has not been registered with the DA in the
   scope specified in the SrvDeReg message, an INVALID_REGISTRATION
   error is returned.

   The <tag-list> is a <string-list> of attribute tags to deregister
   as defined in Section 9.7.  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 in protected scopes 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 in a protected
   scope, a URL authentication block for that protected scope must be
   included.  Otherwise, the DA returns an AUTHENTICATION_ABSENT error
   is returned.  If the message fails to be verified by the DA, an
   AUTHENTICATION_FAILED error is returned by the DA.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 27]

Internet Draft          Service Location Protocol           6 March 1998

11. Scopes

   Scopes are sets of services.  The primary use of Scopes is to provide
   the ability to create administrative groupings of services.  A set
   of services may be assigned a scope by network administrators.  A
   client seeking services is configured to use one or more scopes.  The
   user will only discover those services which have been configured
   for him or her to use.  By configuring UAs and SAs with scopes,
   administrators may provision services.

   Scopes are the primary means an administrator has to scale SLP
   deployments to larger networks.  When DAs with NON-DEFAULT scopes are
   present on the network, further gains can be had by configuring UAs
   and SAs to have a predefined non-default scope.  These agents can
   then perform DA discovery and make requests using their scope.  This
   will limit the number of replies.

   The default SCOPE string is ``DEFAULT''.

11.1. Scope Rules

   SLP messages which fail to contain the scope that the receiving Agent
   is configured to use are either dropped or a SCOPE_NOT_SUPPORTED
   error is returned.  See Section 7.1.  Every AttrRqst, SrvTypeRqst,
   DAAdvert, SrvReg and SrvRqst (except for DA discovery request)
   message MUST include a scope list.

   A UA MUST unicast its SLP messages to a DA which supports the desired
   scope, in preference to multicasting a request to SAs.  A UA MAY
   multicast the request if no DA is available in the scope it is
   configured to use.

11.2. Administrative and User Configurable Scopes

   All requests and services are scoped.  There are two possible ways
   they could be configured with scope strings:

               No configuration at all is done.  The scope ``DEFAULT''
               is used.  The list of scopes obtained from these
               DAAdverts can be presented to the user to select one to
               use with subsequent requests or registrations.

               UAs and SAs are configured with lists of scopes to use by
               system administrators.  If this is the case, all requests
               issued by the UA and all services registered by the SA

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 28]

Internet Draft          Service Location Protocol           6 March 1998

               will specify some or all of these scopes.  The user MUST
               NOT be presented with other scopes than the preconfigured

   Administrative scoping allows services to be provisioned, so that
   users will only see services they are intended to see.

   User configurable scopes allow a user to discover any service, but
   require them to do their own selection of scope.  This is similar to
   the way AppleTalk and LanManager networking allow user selection of
   AppleTalk Zone or Windows Workgroups.  User selectable scopes REQUIRE
   that there are DAs available which support every scope which the user
   can select, or that SAs support the 'DEFAULT' scope so that users can
   discover all services in the absense of DAs.

   Note that the two configuration choices are not compatible.  One
   model allows administrators control over service provision.  The
   other delegates this to users (who may not be prepared to do any
   configuration of their system).

11.3. Protected Scopes

   A protected scope is identical to a non protected scope except that
   it allows authentication of service information.  If a `protected
   scope' is configured, it must be accompanied by a key so that
   authentication calculation is possible.  For example, a shared secret
   could be installed for each host using a protected scope.  It is far
   wiser to use public key cryptography.

   In protected scopes, only a subset of SLP functionality is possible:
   AttrRqst and SrvDeReg messages MUST NOT contain a <tag-list>.  DAs
   MUST verify SrvReg and SrvDeReg messages sent by SAs which select
   protected scopes.  UAs MUST verify SrvRply and AttrRply messages sent
   using protected scopes before returning them to client processes.

12. Directory Agents

   DAs cache service location and attribute information.  They exist to
   enhance the performance and upward scalability of SLP. Multiple DAs
   may provide further scalability and robustness of operation.  The DAs
   can store replicated service information which remains available even
   when one of the DAs fails.

   For use in networks with multiple subnets, a DA can be used to
   provide a central clearing house of information for UAs.  The DA
   address can be dynamically configured with Agents using DHCP, or
   determined by static configuration.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 29]

Internet Draft          Service Location Protocol           6 March 1998

   Passive detection of DAs by SAs enables services to be advertised
   consistently among DAs of the same scope.  Invalid advertisements age
   out, leaving only transient stale registrations in DAs, even in the
   case of a failure of a SA.

12.1. Directory Agent Rules

   When DAs are present, each SA MUST register all its service with DAs
   that support one or more of its scope(s).

   Furthermore, UAs SHOULD unicast requests directly to a DA (when
   scoping rules allow), hence avoiding using the multicast and
   convergence algorithm, to obtain service information.  This decreases
   network utilization and increases the speed at which UAs can obtain
   service information.

   A single DA can support many UAs.  Moreover, many DAs can reside
   together on a network, enabling load balancing and redundancy.
   DAs reduce the load on SAs, making simpler implementations of SAs

   UAs send the same requests to DAs that they would send to SAs and
   expect the same results.

   DAs MUST flush service advertisements once their lifetime expires or
   their URL Authentication Block "Timestamp" of expiration is past.

   DAs which receive a multicast SrvRqst for the service type
   "service:directory-agent" MUST silently discard it if the
   <scope-list> is (a) not omitted and (b) does not include a scope
   they are configured to use.  Otherwise the DA MUST respond with a
   DAAdvert.  This is the only case when an omitted scope list in a
   request does not cause a SCOPE_NOT_SUPPORTED error to be returned.

   DAs MUST send an initial and periodic unsolicited DAAdvert messages.

   DAs MUST respond to AttrRqst and SrvTypeRqst messages (these are
   OPTIONAL only for SAs, not DAs.)

12.2. Directory Agent Discovery

   UAs can discover DAs using static configuration, DHCP options 78 and
   79, or by multicasting (or broadcasting) Service Requests using the
   convergence algorithm in Section 6.2.1.

   See Section 6 which describes unsolicited DAAdverts and how SAs
   respond to them.  Section 12.2.2 includes an optimization which SAs

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 30]

Internet Draft          Service Location Protocol           6 March 1998

   may use to minimize the number of times they must reregister with

   SAs MUST listen for DAAdverts, passively, as described in
   Section 7.5.  UAs SHOULD do this.

   DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An
   unsolicited DAAdvert has an XID of 0.

   The DAAdvert Sequence Number is 0 when the DA comes up initially and
   increases by one each time the DAAdvert is sent unsolicited.  Once it
   reaches 0xFFFE the sequence number wraps back to 0x0100.  DAs which
   store service advertisements in a nonvolatile store will set their
   initial sequence number to 0x0100.  The sequence number will be used
   by SAs to determine if they must reregister services when a DA is
   discovered.  The DAAdvert Sequence number 0xFFFF is reserved:  It is
   used to indicate that the DA is going down and no further messages
   should be sent to it.  See Section 12.2.2.

   A URL with the Service Type "service:directory-agent" is synthesized
   to indicate the DA's location as defined in Section 7.5.  For
   example:  "service:directory-agent://".

   The following sections describe suggested timing algorithms which
   allow SLP to scale to larger deployments.

12.2.1. Active DA Discovery

   After a UA or SA restarts, their initial DA discovery request SHOULD
   be delayed for some random time uniformly distributed from 0 to

   The UA or SA sends the DA Discovery request using a SrvRqst, as
   described in Section 7.1.  DA Discovery requests MUST include
   previous responders in a Previous Responder List.

   SAs which discover DAs actively MUST wait a random time between 0 and
   CONFIG_REG_ACTIVE seconds before registering their services.

12.2.2. Passive DA Advertising

   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 bandwidth.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 31]

Internet Draft          Service Location Protocol           6 March 1998

   All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
   its Sequence Number.  If the Sequence number is 0xFFFF, the DA is
   going down and no further messages should be sent to it.

   If the DA has never before been heard from or if the Sequence Number
   is less than it was previously and less than 0x0100, an SA should
   assume the DA does not have its service registration, even if it once
   did.  If this is the case and the DA has the proper scope, an SA
   should register all service information with the DA, after waiting a
   random interval CONFIG_REG_PASSIVE.

12.3. Reliable Unicast to DAs

   If a DA fails to respond to a unicast UDP message in CONFIG_DA_RETRY
   seconds, the message should be retried.  If a DA fails to respond
   after CONFIG_DA_MAX seconds, the SA should consider the DA to have
   gone down and not .  The UA should use a different DA. If no such
   DA responds, DA discovery should be used to find a new DA. Care
   should be taken not to do Active DA Discovery more than once per
   CONFIG_DA_FIND seconds.  If no DA is available, multicast is used.

12.4. DA Scope Configuration

   DAs are configured with the "DEFAULT" scope, by default.
   Administrators may add other configured scopes, in order to support
   UAs and SAs in non default scopes.  The default configuration SHOULD
   NOT be removed from the DA unless:

    -  There are other DAs which support the "DEFAULT" scope, or

    -  All UAs and SAs have been configured with non-default scopes.

   Non-default scopes should be phased-in as the SLP deployment grows.
   Default scopes should be phased out only when the non-default scopes
   are well deployed.

   If a DA and SA are coresident on a host (quite possibly implemented
   by the same process), configuration of the host is considerably
   simplified if the SA supports only scopes also supported by the DA.
   That is, the SA SHOULD NOT advertise services in any scopes which are
   not supported by the coresident DA. This means that incoming requests
   can be answered by a single data store; the SA and DA registrations
   do not need to be kept separately.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 32]

Internet Draft          Service Location Protocol           6 March 1998

12.5. DAs and Authentication Blocks

   DAs are not configured with protected scope private keys.  This
   means they will not be able to sign URLs and Attribute lists, but
   only cache them for SAs, forwarding them to UAs.  Consequently, in
   a protected scope the DA will not accept:  SrvReg without the FRESH
   flag set or AttrRqst or SrvDeReg with a <tag-list> included.  In
   these cases an AUTHENTICATION_FAILED error is returned.

13. Protocol Timing Defaults

Interval name        Section  Default Value  Meaning
-------------------  -------  -------------  ------------------------
CONFIG_MC_RETRY      6.2.1    each second,   Retry multicast query
                              backing off    until no new values
                              gradually      arrive.
CONFIG_MC_MAX        6.2.1    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_DA_RETRY      12.3     2 seconds      Retransmit DA discovery,
                                             try it 3 times.
CONFIG_DA_MAX        12.3     6 seconds      Give up on requests sent
                                             to a DA.
CONFIG_DA_BEAT       12.2.2   3 hours        DA Heartbeat, so that SAs
                                             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    7.3      1-3 seconds    Wait to register services
                                             on active DA discovery.
CONFIG_CLOSE_CONN    6.2      5 minutes      DAs and SAs close idle

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 33]

Internet Draft          Service Location Protocol           6 March 1998

14. SLP Protocol Extensions

14.1. Required Attribute Missing Option

      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 Type = 0x0001    |        Extension Length       |
     |      Template IDVer Length    |     Template IDVer String     \
     |Required Attr <tag-list> Length|    Required Attr <tag-list>   \

   Required attributes and the format of the IDVer string are defined
   by [13].

   If a SA or DA receives a SrvRqst or a SrvReg which fails to include
   an attribute which is required for the requested Service Type, it
   returns the Required Attribute Extension in addition to the reply
   corresponding to the message.  The sender SHOULD reissue the message
   with a search filter including the attributes listed in the returned
   Required Attribute Extension.  Similarly, the Required Attribute
   Extension may be returned in response to a SrvDereg message that
   contains a required attribute tag.

   The Template IDVer String is the name and version number string of
   the service template which defines the given attribute as required.
   It SHOULD be included, but can be omitted if a given SA or DA has
   been individually configured to have 'required attributes.'

   The Required Attribute <tag-list> may not include wild cards.

14.2. Cryptographic Algorithm Request Option

   If a UA wishes to obtain an Authentication Block using a non-default
   algorithm (i.e., not using DSA), it includes a SLP Extension option
   requesting a particular BSD.

      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 Type = 0x0002    |        Extension Length       |
     |        Desired BSD            |

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 34]

Internet Draft          Service Location Protocol           6 March 1998

   The Extension Contents are a two byte value representing the desired
   BSD, see Section 9.1.  If the DA or SA does not support this OPTIONAL
   extension, it will ignore it and return a DSA authentication block.
   If it does support the Extension, but not the algorithm identified by
   the BSD, it will return an AUTHENTICATION_ALGO_UNKNOWN error.  If it
   supports the extension and the algorithm identified by BSD it will
   return an authentication block using the desired algorithm.

15. Optional Configuration

               An SLP Agent SHOULD be configurable to use broadcast
               only.  See Sections 6.1 and 12.2.

               A UA or SA SHOULD be configurable to use a predefined DA.

               The UA or SA SHOULD be configurable to ONLY use
               predefined and DHCP-configured DAs and perform no active
               or passive DA discovery.

               The default multicast TTL is 32.  Agents SHOULD be
               configurable to other values.  A lower value will
               focus the multicast convergence algorithm on smaller
               subnetworks, decreasing the number of responses and
               increases the performance of service location.  This
               may result in UAs obtaining different results for the
               identical requests depending on where they are connected
               to the network.

               Non default time values MAY be configurable.  See
               Section 13.

               A UA or SA MAY be configurable to support User
               Selectable scopes by omitting all predefined scopes.  See
               Section 11.2.  A UA or SA MUST be configurable to use
               specific scopes by default.  Additionally, a UA or SA
               MUST be configurable to use specific scopes for requests
               for and registrations of specific service types.

      DA SCOPE
               The scope or scopes of a DA MUST be configurable.  The
               default value for a DA is to have the scope "DEFAULT" if
               not otherwise configured.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 35]

Internet Draft          Service Location Protocol           6 March 1998

      DHCP Configuration
               DHCP options 78 and 79 may be used to configure SLP.
               If DA locations are configured using DHCP, these
               SHOULD be used in preference to DAs discovered actively
               or passively.  One or more of the scopes configured
               using DHCP MUST be used in requests.  The entire
               configured scope list MUST be used in registration and DA
               configuration messages.

               UAs and SAs MAY be configured with Service Templates.
               Besides simplifying the specification of attribute
               values, this also allows them to enforce the inclusion
               of 'required' attributes in SrvRqst, SrvReg and SrvDeReg
               messages.  DAs MAY be configured with templates to
               allow them to WARN UAs and SAs in these cases.  See
               Section 10.4.

               If an Administrative Multicast Scope Discovery Protocol
               is used, this protocol SHOULD be used to discover and
               the enclosing Administratively Scoped multicast address
               ranges.  The address to for SLP is always '2' down from
               the top of the from the 'relative administrative scoped
               multicast address assignment range' in any scope.  By
               default the address to use is "".

16. IANA Considerations

   Further Block Structured Descriptor (BSD) values may be standardized
   in the future by submitting a document which describes:

      -     The data format of the Structured Authenticator block.

      -     Which cryptographic algorithm to use (including a reference
            to a technical specification of the algorithm.)

      -     The format of any keying material required for
            preconfiguring UAs, DAs and SAs.  Also include any
            considerations regarding key distribution.

      -     Security considerations to alert others to the strengths and
            weaknesses of the approach.

   The IANA will assign BSD numbers (from the range 0x0003 to 0x7FFF) on
   a first come, first served basis.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 36]

Internet Draft          Service Location Protocol           6 March 1998

17. Internationalization Considerations

   SLP messages support the use of multiple languages by providing a
   Language Tag field in the common message header (see Section 7).

   Services MAY be registered in multiple languages.  This provides
   attributes so that users with different language skills may select
   services interactively.

   A service which is registered in multiple languages may be queried in
   multiple languages.  The language of the SrvRqst or AttrRqst is used
   to satisfy the request.  If the requested language is not supported,
   a LANGUAGE_NOT_SUPPORTED error is returned.  SrvRply and AttrRply
   messages are always in the same language of the request.

   A DA or SA MAY be configured with translations of Service Templates
   [13] for the same service type.  This will allow the DA or SA to
   translate a request (say in Italian) to the language of the service
   advertisement (say in English) and then translate the reply back to
   Italian.  Similarly, a UA MAY use templates to translate outgoing
   requests and incoming replies.

   The dialect field in the Language Tag MAY be used:  Requests which
   can be fulfilled by matching a language and dialect will be preferred
   to those which match only the language portion.  Otherwise, dialects
   have no effect on matching requests.

18. Security Considerations

   SLP provides for authentication of service URLs and service
   attributes.  This provides UAs and DAs with knowledge of the
   integrity of service URLs and attributes included in SLP messages.
   The only systems which can generate digital signatures are those
   which have been configured by administrators in advance.  Agents
   which verify signed data may assume it is 'trustworthy' in as much as
   administrators have ensured the cryptographic keying of SAs and DAs
   reflects 'trustworthiness.'

   Service Location does not provide confidentiality.  Because the
   objective of this protocol is to advertise services to a community
   of users, confidentiality might not generally be needed when this
   protocol is used in non-sensitive environments.  Specialized schemes
   might be able to provide confidentiality, if needed in the future.
   Sites requiring confidentiality should implement the IP Encapsulating
   Security Payload (ESP) [3] to provide confidentiality for Service
   Location messages.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 37]

Internet Draft          Service Location Protocol           6 March 1998

   Using unprotected scopes, an adversary might easily use this protocol
   to advertise services on servers controlled by the adversary and
   thereby gain access to users' private information.  Further, an
   adversary using this protocol will find it much easier to engage in
   selective denial of service attacks.  Sites that are in potentially
   hostile environments (e.g., are directly connected to the Internet)
   should consider the advantages of distributing keys associated with
   protected scopes prior to deploying the sensitive directory agents or
   service agents.

   Service Location 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 use any of the security
   mechanisms described above.  Service Location will make use of
   the mechanisms provided by the Security Area of the IETF for key
   distribution as they become available.  At this point it would only
   be possible to gain the benefits associated with the use of protected
   scopes if some cryptographic information can be preconfigured with
   the end systems before they use Service Location.

19. Acknowledgments

   This document incorporates ideas from work on several discovery
   protocols, including RDP by Perkins and Harjono, and PDS by Michael

20. Full Copyright Statement

   Copyright (C) The Internet Society (1997).  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 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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 38]

Internet Draft          Service Location Protocol           6 March 1998

   This document and the information contained herein is provided on an


    [1] Port numbers, July 1997.

    [2] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 4 to ISO/IEC 9594-2, December 1996.

    [3] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 2 to ISO/IEC 9594-6, December 1996.

    [4] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 1 to ISO/IEC 9594-7, December 1996.

    [5] ISO/IEC JTC1/SC 21.  Certificate Extensions.  Draft Amendment
        DAM 1 to ISO/IEC 9594-8, December 1996.

    [6] H. Alvestrand.  Tags for the Identification of Languages.  RFC
        1766, March 1995.

    [7] D. Balenson.   Privacy Enhancement for Internet Electronic
        Mail:  Part III: Algorithms, Modes, and Identifiers.  RFC 1423,
        February 1993.

    [8] T. Berners-Lee, L. Masinter, and M. McCahill.  Uniform Resource
        Locators (URL).  RFC 1738, December 1994.

    [9] S. Bradner.  Key words for use in RFCs to Indicate Requirement
        Levels.  RFC 2119, March 1997.

   [10] CCITT.  Specification of the Abstract Syntax Notation One
        (ASN.1).  Recommendation X.208, 1988.

   [11] CCITT.  The Directory Authentication Framework.  Recommendation
        X.509, 1988.

   [12] D. Crocker and P. Overell.  Augmented BNF for Syntax
        Specifications:  ABNF.  RFC 2234, November 1997.

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 39]

Internet Draft          Service Location Protocol           6 March 1998

   [13] E. Guttman, C. Perkins, and J. Kempf.  Service Templates and
        service:  Schemes.  draft-ietf-svrloc-service-scheme-05.txt,
        November 1997.  (work in progress).

   [14] T. Howes.  The string representation of LDAP search filters.
        draft-ietf-asid-ldapv3-filter-03.txt, October 1997.  (work in

   [15] H. Krawczyk, M. Bellare, and R. Cannetti.  HMAC: Keyed-Hashing
        for Message Authentication.  RFC 2104, February 1997.

   [16] D. Mills.  Simple Network Time Protocol (SNTP) Version 4 for
        IPv4, IPv6 and OSI.  RFC 2030, October 1996.

   [17] National Institute of Standards and Technology.  Digital
        signature standard.  Technical Report NIST FIPS PUB 186, U.S.
        Department of Commerce, May 1994.

   [18] Ronald L. Rivest.  The MD5 Message-Digest Algorithm.  RFC 1321,
        April 1992.

   [19] J. Veizades, E. Guttman, C. Perkins, and S. Kaplan.  Service
        Location Protocol.  RFC 2165, July 1997.

   [20] F. Yergeau.  UTF-8, a transformation format of ISO 10646.  RFC
        2279, January 1998.

Authors' Addresses

             Erik Guttman              Charles Perkins
             Sun Microsystems          Sun Microsystems
             Bahnstr. 2                901 San Antonio Road
             74915 Waibstadt           Palo Alto, CA 94040
             Germany                   USA

   Phone:    +49 7263 911701           +1 650 786 6464
   Fax:                                +1 650 786 6445

             John Veizades             Michael Day
             @Home Network             Intel
             385 Ravendale Dr.         734 E. Utah Valley Dr., Ste. 300
             Mountain View, CA 94043   American Fork, Utah, 84003
             USA                       USA

   Phone:    +1 650 569 5243           +1 801 763 2341
   Fax:                                +1 801 756 8349

Guttman,Perkins,Veizades,Day     Expires 6 September 1998      [Page 40]