doc: Add RFC documents

1 files changed, 3027 insertions, 0 deletions

diff --git a/doc/rfc/rfc2608.txt b/doc/rfc/rfc2608.txt
new file mode 100644
index 0000000..fa7de62
--- /dev/null
+++ b/doc/rfc/rfc2608.txt
@@ -0,0 +1,3027 @@
+
+
+
+
+
+
+Network Working Group                                        E. Guttman
+Request for Comments: 2608                                   C. Perkins
+Updates: 2165                                          Sun Microsystems
+Category: Standards Track                                   J. Veizades
+                                                          @Home Network
+                                                                 M. Day
+                                                      Vinca Corporation
+                                                              June 1999
+
+
+                  Service Location Protocol, Version 2
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1999).  All Rights Reserved.
+
+Abstract
+
+   The Service Location Protocol provides a scalable framework for the
+   discovery and selection of network services.  Using this protocol,
+   computers using the Internet need little or no static configuration
+   of network services for network based applications.  This is
+   especially important as computers become more portable, and users
+   less tolerant or able to fulfill the demands of network system
+   administration.
+
+Table of Contents
+
+    1. Introduction                                                    3
+        1.1. Applicability Statement  . . . . . . . . . . . . . . .    3
+    2. Terminology                                                     4
+        2.1. Notation Conventions . . . . . . . . . . . . . . . . .    4
+    3. Protocol Overview                                               5
+    4. URLs used with Service Location                                 8
+        4.1. Service: URLs  . . . . . . . . . . . . . . . . . . . .    9
+        4.2. Naming Authorities   . . . . . . . . . . . . . . . . .   10
+        4.3. URL Entries  . . . . . . . . . . . . . . . . . . . . .   10
+    5. Service Attributes                                             10
+    6. Required Features                                              12
+        6.1. Use of Ports, UDP, and Multicast   . . . . . . . . . .   13
+
+
+
+Guttman, et al.             Standards Track                     [Page 1]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+        6.2. Use of TCP   . . . . . . . . . . . . . . . . . . . . .   14
+        6.3. Retransmission of SLP messages   . . . . . . . . . . .   15
+        6.4. Strings in SLP messages  . . . . . . . . . . . . . . .   16
+              6.4.1. Scope Lists in SLP . . . . . . . . . . . . . .   16
+    7. Errors                                                         17
+    8. Required SLP Messages                                          17
+        8.1. Service Request  . . . . . . . . . . . . . . . . . . .   19
+        8.2. Service Reply  . . . . . . . . . . . . . . . . . . . .   21
+        8.3. Service Registration . . . . . . . . . . . . . . . . .   22
+        8.4. Service Acknowledgment . . . . . . . . . . . . . . . .   23
+        8.5. Directory Agent Advertisement. . . . . . . . . . . . .   24
+        8.6. Service Agent Advertisement. . . . . . . . . . . . . .   25
+    9. Optional Features                                              26
+        9.1. Service Location Protocol Extensions . . . . . . . . .   27
+        9.2. Authentication Blocks  . . . . . . . . . . . . . . . .   28
+              9.2.1. SLP Message Authentication Rules . . . . . . .   29
+              9.2.2. DSA with SHA-1 in Authentication Blocks  . . .   30
+        9.3. Incremental Service Registration   . . . . . . . . . .   30
+        9.4. Tag Lists  . . . . . . . . . . . . . . . . . . . . . .   31
+   10. Optional SLP Messages                                          32
+       10.1. Service Type Request   . . . . . . . . . . . . . . . .   32
+       10.2. Service Type Reply   . . . . . . . . . . . . . . . . .   32
+       10.3. Attribute Request  . . . . . . . . . . . . . . . . . .   33
+       10.4. Attribute Reply  . . . . . . . . . . . . . . . . . . .   34
+       10.5. Attribute Request/Reply Examples . . . . . . . . . . .   34
+       10.6. Service Deregistration   . . . . . . . . . . . . . . .   36
+   11. Scopes                                                         37
+       11.1. Scope Rules  . . . . . . . . . . . . . . . . . . . . .   37
+       11.2. Administrative and User Selectable Scopes. . . . . . .   38
+   12. Directory Agents                                               38
+       12.1. Directory Agent Rules  . . . . . . . . . . . . . . . .   39
+       12.2. Directory Agent Discovery  . . . . . . . . . . . . . .   39
+             12.2.1. Active DA Discovery  . . . . . . . . . . . . .   40
+             12.2.2. Passive DA Advertising . . . . . . . . . . . .   40
+       12.3. Reliable Unicast to DAs and SAs. . . . . . . . . . . .   41
+       12.4. DA Scope Configuration   . . . . . . . . . . . . . . .   41
+       12.5. DAs and Authentication Blocks. . . . . . . . . . . . .   41
+   13. Protocol Timing Defaults                                       42
+   14. Optional Configuration                                         43
+   15. IANA Considerations                                            44
+   16. Internationalization Considerations                            45
+   17. Security Considerations                                        46
+    A. Appendix:  Changes to the Service Location Protocol from
+                  v1 to v2                                            48
+    B. Appendix:  Service Discovery by Type:  Minimal SLPv2 Features  48
+    C. Appendix:  DAAdverts with arbitrary URLs                       49
+    D. Appendix:  SLP Protocol Extensions                             50
+        D.1. Required Attribute Missing Option  . . . . . . . . . .   50
+
+
+
+Guttman, et al.             Standards Track                     [Page 2]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+    E. Acknowledgments                                                50
+    F. References                                                     51
+    G. Authors' Addresses                                             53
+    H. Full Copyright Statement                                       54
+
+1. Introduction
+
+   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.
+   Traditionally, users have had to find services by knowing the name of
+   a network host (a human readable text string) which is an alias for a
+   network address.  SLP eliminates the need for a user to know the name
+   of a network host supporting a service.  Rather, the user supplies
+   the desired type of service and a set of attributes which describe
+   the service.  Based on that description, the Service Location
+   Protocol resolves the network address of the service for the user.
+
+   SLP provides a dynamic configuration mechanism for applications in
+   local area networks.  Applications are modeled as clients that need
+   to find servers attached to any of the available networks within an
+   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.
+
+   This document updates SLPv1 [RFC 2165], correcting protocol errors,
+   adding some enhancements and removing some requirements.  This
+   specification has two parts.  The first describes the required
+   features of the protocol.  The second describes the extended features
+   of the protocol which are optional, and allow greater scalability.
+
+1.1. Applicability Statement
+
+   SLP is intended to function within networks under cooperative
+   administrative control.  Such networks permit a policy to be
+   implemented regarding security, multicast routing and organization of
+   services and clients into groups which are not be feasible on the
+   scale of the Internet as a whole.
+
+   SLP 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, or in networks where there
+   are hundreds of thousands of clients or tens of thousands of
+   services.
+
+
+
+
+
+
+Guttman, et al.             Standards Track                     [Page 3]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+2. Terminology
+
+      User Agent (UA)
+                A process working on the user's behalf to establish
+                contact with some 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 service
+                advertisements.  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 set of services, typically making up a logical
+                administrative group.
+
+      URL A Universal Resource Locator [8].
+
+2.1. Notation Conventions
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119  [9].
+
+      Syntax        Syntax for string based protocols follow the
+                    conventions defined for ABNF [11].
+
+      Strings       All strings are encoded using the UTF-8 [23]
+                    transformation of the Unicode [6] character set and
+                    are NOT null terminated when transmitted.  Strings
+                    are preceded by a two byte length field.
+
+      <string-list> A comma delimited list of strings with the
+                    following syntax:
+
+                       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.
+
+
+
+
+Guttman, et al.             Standards Track                     [Page 4]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+3. Protocol Overview
+
+   The Service Location Protocol supports a framework by which client
+   applications are modeled as 'User Agents' and services are advertised
+   by 'Service Agents.'  A third entity, called a 'Directory Agent'
+   provides scalability to the protocol.
+
+   The User Agent issues a 'Service Request' (SrvRqst) on behalf of the
+   client application, specifying the characteristics of the service
+   which the client requires.  The User Agent will receive a Service
+   Reply (SrvRply) specifying the location of all services in the
+   network which satisfy the request.
+
+   The Service Location Protocol framework allows the User Agent to
+   directly issue requests to Service Agents.  In this case the request
+   is multicast.  Service Agents receiving a request for a service which
+   they advertise unicast a reply containing the service's location.
+
+      +------------+ ----Multicast SrvRqst----> +---------------+
+      | User Agent |                            | Service Agent |
+      +------------+ <----Unicast SrvRply------ +---------------+
+
+   In larger networks, one or more Directory Agents are used.  The
+   Directory Agent functions as a cache.  Service Agents send register
+   messages (SrvReg) containing all the services they advertise to
+   Directory Agents and receive acknowledgements in reply (SrvAck).
+   These advertisements must be refreshed with the Directory Agent or
+   they expire.  User Agents unicast requests to Directory Agents
+   instead of Service Agents if any Directory Agents are known.
+
+ +-------+ -Unicast SrvRqst-> +-----------+ <-Unicast SrvReg- +--------+
+ | User  |                    | Directory |                   |Service |
+ | Agent |                    |   Agent   |                   | Agent  |
+ +-------+ <-Unicast SrvRply- +-----------+ -Unicast SrvAck-> +--------+
+
+   User and Service Agents discover Directory Agents two ways.  First,
+   they issue a multicast Service Request for the 'Directory Agent'
+   service when they start up.  Second, the Directory Agent sends an
+   unsolicited advertisement infrequently, which the User and Service
+   Agents listen for.  In either case the Agents receive a DA
+    Advertisement (DAAdvert).
+
+        +---------------+ --Multicast SrvRqst-> +-----------+
+        |    User or    | <--Unicast DAAdvert-- | Directory |
+        | Service Agent |                       |   Agent   |
+        +---------------+ <-Multicast DAAdvert- +-----------+
+
+
+
+
+
+Guttman, et al.             Standards Track                     [Page 5]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   Services are grouped together using 'scopes'.  These are strings
+   which identify services which are administratively identified.  A
+   scope could indicate a location, administrative grouping, proximity
+   in a network topology or some other category.  Service Agents and
+   Directory Agents are always assigned a scope string.
+
+   A User Agent is normally assigned a scope string (in which case the
+   User Agent will only be able to discover that particular grouping of
+   services).  This allows a network administrator to 'provision'
+   services to users.  Alternatively, the User Agent may be configured
+   with no scope at all.  In that case, it will discover all available
+   scopes and allow the client application to issue requests for any
+   service available on the network.
+
+   +---------+   Multicast  +-----------+   Unicast   +-----------+
+   | Service | <--SrvRqst-- |   User    | --SrvRqst-> | Directory |
+   |  Agent  |              |   Agent   |             |   Agent   |
+   | Scope=X |   Unicast    | Scope=X,Y |   Unicast   |  Scope=Y  |
+   +---------+ --SrvRply--> +-----------+ <-SrvRply-- +-----------+
+
+   In the above illustration, the User Agent is configured with scopes X
+   and Y. If a service is sought in scope X, the request is multicast.
+   If it is sought in scope Y, the request is unicast to the DA.
+   Finally, if the request is to be made in both scopes, the request
+   must be both unicast and multicast.
+
+   Service Agents and User Agents may verify digital signatures provided
+   with DAAdverts.  User Agents and Directory Agents may verify service
+   information registered by Service Agents.  The keying material to use
+   to verify digital signatures is identified using a SLP Security
+   Parameter Index, or SLP SPI.
+
+   Every host configured to generate a digital signature includes the
+   SLP SPI used to verify it in the Authentication Block it transmits.
+   Every host which can verify a digital signature must be configured
+   with keying material and other parameters corresponding with the SLP
+   SPI such that it can perform verifying calculations.
+
+   SAs MUST accept multicast service requests and unicast service
+   requests.  SAs MAY accept other requests (Attribute and Service Type
+   Requests).  SAs MUST listen for multicast DA Advertisements.
+
+   The features described up to this point are required to implement.  A
+   minimum implementation consists of a User Agent, Service Agent or
+   both.
+
+   There are several optional features in the protocol.  Note that DAs
+   MUST support all these message types, but DA support is itself
+
+
+
+Guttman, et al.             Standards Track                     [Page 6]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   optional to deploy on networks using SLP. UAs and SAs MAY support
+   these message types.  These operations are primarily for interactive
+   use (browsing or selectively updating service registrations.)  UAs
+   and SAs either support them or not depending on the requirements and
+   constraints of the environment where they will be used.
+
+  Service Type Request   A request for all types of service on the
+                         network.  This allows generic service browsers
+                         to be built.
+
+  Service Type Reply     A reply to a Service Type Request.
+
+  Attribute Request      A request for attributes of a given type of
+                         service or attributes of a given service.
+
+  Attribute Reply        A reply to an Attribute Request.
+
+  Service Deregister     A request to deregister a service or some
+                         attributes of a service.
+
+  Service Update         A subsequent SrvRqst to an advertisement.
+                         This allows individual dynamic attributes to
+                         be updated.
+
+  SA Advertisement       In the absence of Directory Agents, a User
+                         agent may request Service Agents in order
+                         to discover their scope configuration.  The
+                         User Agent may use these scopes in requests.
+
+   In the absence of Multicast support, Broadcast MAY be used.  The
+   location of DAs may be staticly configured, discovered using SLP as
+   described above, or configured using DHCP. If a message is too large,
+   it may be unicast using TCP.
+
+   A SLPv2 implementation SHOULD support SLPv1 [22].  This support
+   includes:
+
+    1. SLPv2 DAs are deployed, phasing out SLPv1 DAs.
+
+    2. Unscoped SLPv1 requests are considered to be of DEFAULT scope.
+       SLPv1 UAs MUST be reconfigured to have a scope if possible.
+
+    3. There is no way for an SLPv2 DA to behave as an unscoped SLPv1
+       DA. SLPv1 SAs MUST be reconfigured to have a scope if possible.
+
+    4. SLPv2 DAs answer SLPv1 requests with SLPv1 replies and SLPv2
+       requests with SLPv2 replies.
+
+
+
+
+Guttman, et al.             Standards Track                     [Page 7]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+    5. SLPv2 DAs use registrations from SLPv1 and SLPv2 in the same
+       way.  That is, incoming requests from agents using either version
+       of the protocol will be matched against this common set of
+       registered services.
+
+    6. SLPv2 registrations which use Language Tags which are greater
+       than 2 characters long will be inaccessible to SLPv1 UAs.
+
+    7. SLPv2 DAs MUST return only service type strings in SrvTypeRply
+       messages which conform to SLPv1 service type string syntax, ie.
+       they MUST NOT return Service Type strings for abstract service
+       types.
+
+    8. SLPv1 SrvRqsts and AttrRqsts by Service Type do not match Service
+       URLs with abstract service types.  They only match Service URLs
+       with concrete service types.
+
+   SLPv1 UAs will not receive replies from SLPv2 SAs and SLPv2 UAs will
+   not receive replies from SLPv1 SAs.  In order to interoperate UAs and
+   SAs of different versions require a SLPv2 DA to be present on the
+   network which supports both protocols.
+
+   The use of abstract service types in SLPv2 presents a backward
+   compatibility issue for SLPv1.  It is possible that a SLPv1 UA will
+   request a service type which is actually an abstract service type.
+   Based on the rules above, the SLPv1 UA will never receive an abstract
+   Service URL reply.  For example, the service type 'service:x' in a
+   SLPv1 AttrRqst will not return the attributes of 'service:x:y://orb'.
+   If the request was made with SLPv2, it would return the attributes of
+   this service.
+
+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 URI standard [8], except that URLs
+   without address specifications SHOULD NOT be advertised by SLP. The
+   service type for an 'generic' URL is its scheme name.  For example,
+   the service type string for "http://www.srvloc.org" would be "http".
+
+   Reserved characters in URLs follow the rules in RFC 2396 [8].
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                     [Page 8]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+4.1. Service: URLs
+
+   Service URL syntax and semantics are defined in  [13].  Any network
+   service may be encoded in a Service URL.
+
+   This section provides an introduction to Service URLs and an example
+   showing a simple application of them, representing standard network
+   services.
+
+   A Service URL may be of the form:
+
+      "service:"<srvtype>"://"<addrspec>
+
+   The Service Type of this service: URL is defined to be the string up
+   to (but not including) the final `:'  before <addrspec>, the address
+   specification.
+
+   <addrspec> is a hostname (which should be used if possible) or dotted
+   decimal notation for a hostname, followed by an optional `:'  and
+   port number.
+
+   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.  A
+   tftp service on a nonstandard port could be
+   "service:tftp://bad.glad.org:8080".
+
+   Service Types SHOULD be defined by a "Service Template" [13], which
+   provides expected attributes, values and protocol behavior.  An
+   abstract service type (also described in [13]) has the form
+
+      "service:<abstract-type>:<concrete-type>".
+
+   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
+   <srvtype> (or <abstract-type> in the case of an abstract service type
+   URL). This substring is the Naming Authority, as described in Section
+   9.6.  Service types with different Naming Authorities are quite
+   distinct.  In other words, service:x.one and service:x.two are
+   different service types, as are service:abstract.one:y and
+   service:abstract.two:y.
+
+
+
+Guttman, et al.             Standards Track                     [Page 9]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+4.2. Naming Authorities
+
+   A Naming Authority MAY optionally be included as part of the Service
+   Type string.  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.
+
+   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 8.1 and 8.3.  Service Types SHOULD be registered with IANA
+   to allow for Internet-wide interoperability.
+
+4.3. 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             |   URL Length  |
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |URL len, contd.|            URL (variable length)              \
+     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+     |# of URL auths |            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.
+
+5. Service Attributes
+
+   A service advertisement is often accompanied by Service Attributes.
+   These attributes are used by UAs in Service Requests to select
+   appropriate services.
+
+   The allowable attributes which may be used are typically specified 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.
+
+
+
+Guttman, et al.             Standards Track                    [Page 10]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   Non-standard attribute 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 [11] grammar defines attribute lists:
+
+   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*escape-val
+   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 / HTAB / `_'
+    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
+                   '='.  Booleans are case insensitive when compared.
+
+      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.
+
+      String       All other Strings are matched using strict lexical
+                   ordering (see Section 6.4).
+
+      Opaque       Opaque values are sequences of bytes.  These are
+                   distinguished from Strings since they begin with
+                   the sequence "\FF".  This, unescaped, is an illegal
+                   UTF-8 encoding, indicating that what follows is a
+                   sequence of bytes expressed in escape notation which
+                   constitute the binary value.  For example, a '0' byte
+                   is encoded "\FF\00".
+
+
+
+Guttman, et al.             Standards Track                    [Page 11]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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 PARSE_ERROR to the message.
+
+   A keyword has only an <attr-tag>, and no values.  Attributes can have
+   one or multiple values.  All 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,\ff\00\00 is
+   disallowed.  A DA or SA receiving such an <attr-list> MUST return an
+   INVALID_REGISTRATION error.
+
+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.
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 12]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+    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
+
+
+
+Guttman, et al.             Standards Track                    [Page 13]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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 239.255.255.253.  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).
+
+
+
+Guttman, et al.             Standards Track                    [Page 14]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   A TCP connection MAY be used for a single SLP transaction, or for
+   multiple transactions.  Since there are length fields in the message
+   headers, SLP Agents can send multiple requests along a connection and
+   read the return stream for acknowledgments and replies.
+
+   The initiating agent SHOULD close the TCP connection.  The DA SHOULD
+   wait at least CONFIG_CLOSE_CONN seconds before closing an idle
+   connection.  DAs and SAs SHOULD close an idle TCP connection after
+   CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
+   initiating agent neglects to close it.  See Section 13 for timing
+   rules.
+
+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
+
+
+
+Guttman, et al.             Standards Track                    [Page 15]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+
+
+
+Guttman, et al.             Standards Track                    [Page 16]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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:
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 17]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+      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).
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 18]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+
+
+
+Guttman, et al.             Standards Track                    [Page 19]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+               `wump'.
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 20]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+      <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
+               scope.
+
+      <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.
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 21]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+
+
+
+Guttman, et al.             Standards Track                    [Page 22]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 23]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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
+
+
+
+Guttman, et al.             Standards Track                    [Page 24]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+   AUTHENTICATION_UNKNOWN error.
+
+   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
+
+
+
+Guttman, et al.             Standards Track                    [Page 25]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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-
+   type=nfs)".
+
+      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.
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 26]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 27]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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.
+
+
+
+Guttman, et al.             Standards Track                    [Page 28]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+   DAAdverts.
+
+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.
+
+
+
+Guttman, et al.             Standards Track                    [Page 29]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 30]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   For example, suppose service:x://a.org has been registered with
+   attributes A=1, B=2, C=3.  If an incremental registration comes for
+   service:x://a.org 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
+   AUTHENTICATION_FAILED error.
+
+   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".
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 31]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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>.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 32]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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://igore.wco.ftp.com:515/draft" or
+   "nfs://max.net/znoo".  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.
+
+
+
+Guttman, et al.             Standards Track                    [Page 33]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+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://igore.wco.ftp.com/draft
+     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://igore.wco.ftp.com/draft
+     scope-list = Development
+
+
+
+Guttman, et al.             Standards Track                    [Page 34]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+     Lang. Tag  = de
+     Attributes = (Name=Igore),(Description=Nur fuer Entwickler),
+                  (Protocol=LPR),(location-description=13te Etage),
+                  (Operator=James Dornan \3cdornan@monster\3e),
+                  (media-size=na-letter),(resolution=res-600),x-OK
+
+     URL        = service:printer:http://not.wco.ftp.com/cgi-bin/pub-prn
+     scope-list = Development
+     Lang. Tag  = en
+     Attributes = (Name=Not),(Description=Experimental IPP printer),
+                  (Protocol=http),(location-description=QA bench),
+                  (media-size=na-letter),(resolution=other),x-BUSY
+
+   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://igore.wco.ftp.com/draft
+     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:
+
+     (protocols=http,LPR),(resolution=res-600,other),x-OK,x-BUSY
+
+   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, et al.             Standards Track                    [Page 35]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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
+   follows.
+
+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.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 36]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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.
+
+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 strings are case
+   insensitive.  The default SCOPE string is "DEFAULT".
+
+   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.
+
+11.1. Scope Rules
+
+   SLP messages which fail to contain a scope that the receiving Agent
+   is configured to use are dropped (if the request was multicast) or a
+   SCOPE_NOT_SUPPORTED error is returned (if the request was unicast).
+   Every SrvRqst (except for DA and SA discovery requests), SrvReg,
+   AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert 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.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 37]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+11.2. Administrative and User Selectable Scopes
+
+   All requests and services are scoped.  The two exceptions are
+   SrvRqsts for "service:directory-agent" and "service:service-agent".
+   These MAY have a zero-length <scope-list> when used to enable the
+   user to make scope selections.  In this case UAs obtain their scope
+   list from DAAdverts (or if DAs are not available, from SAAdverts.)
+
+   Otherwise, if SAs and UAs are to use any scope other than the default
+   (i.e., "DEFAULT"), the UAs and SAs are configured with lists of
+   scopes to use by system administrators, perhaps automatically by way
+   of DHCP option 78 or 79 [21].  Such 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 [12] and SMB [19] networking allow user selection
+   of AppleTalk Zone or workgroups.
+
+   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).
+
+12. Directory Agents
+
+   DAs cache service location and attribute information.  They exist to
+   enhance the performance and scalability of SLP. Multiple DAs provide
+   further scalability and robustness of operation, since they can each
+   store service information for the same SAs, in case one of the DAs
+   fails.
+
+   A DA provides a centralized store for service information.  This is
+   useful in a network with several subnets or with many SLP Agents.
+   The DA address can be dynamically configured with UAs and SAs using
+   DHCP, or by using static configuration.
+
+   SAs configured to use DAs with DHCP or static configuration MUST
+   unicast a SrvRqst to the DA, when the SA is initialized.  The SrvRqst
+   omits the scope list and sets the service type of the request to
+   "service:directory-agent".  The DA will return a DAAdvert with its
+   attributes, SLP SPI list, and other parameters which are essential
+   for proper SA to DA communication.
+
+   Passive detection of DAs by SAs enables services to be advertised
+   consistently among DAs of the same scope.  Advertisements expire if
+   not renewed, leaving only transient stale registrations in DAs, even
+
+
+
+Guttman, et al.             Standards Track                    [Page 38]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   in the case of a failure of a SA.
+
+   A single DA can support many UAs.  UAs send the same requests to DAs
+   that they would send to SAs and expect the same results.  DAs reduce
+   the load on SAs, making simpler implementations of SAs possible.
+
+   UAs MUST be prepared for the possibility that the service information
+   they obtain from DAs is stale.
+
+12.1. Directory Agent Rules
+
+   When DAs are present, each SA MUST register its services with DAs
+   that support one or more of its scope(s).
+
+   UAs MUST unicast requests directly to a DA (when scoping rules
+   allow), hence avoiding using the multicast convergence algorithm, to
+   obtain service information.  This decreases network utilization and
+   increases the speed at which UAs can obtain service information.
+
+   DAs MUST flush service advertisements once their lifetime expires or
+   their URL Authentication Block "Timestamp" of expiration is past.
+
+   DAAdverts MUST include DA Stateless Boot Timestamp, in the same
+   format as the Authentication Block (see Section 9.2).  The Timestamp
+   in the Authentication Block indicates the time at which all previous
+   registrations were lost (i.e., the last stateless reboot).  The
+   Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA
+   is going down.  DAs MUST NOT use equal or lesser Boot Timestamps to
+   previous ones, if they go down and restart without service
+   registration state.  This would mislead SAs to not reregister with
+   the DA.
+
+   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.
+
+   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.3.
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 39]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   See Section 6 regarding unsolicited DAAdverts.  Section 12.2.2
+   describes how SAs may reduce the number of times they must reregister
+   with DAs in response to unsolicited DAAdverts.
+
+   DAs MUST send unsolicited DAAdverts once per CONFIG_DA_BEAT. An
+   unsolicited DAAdvert has an XID of 0.  SAs MUST listen for DAAdverts,
+   passively, as described in Section 8.5.  UAs MAY do this.  If they do
+   not listen for unsolicited DAAdverts, however, they will not discover
+   DAs as they become available.  UAs SHOULD, in this case, do periodic
+   active DA discovery, see Section 6.
+
+   A URL with the scheme "service:directory-agent" indicates the DA's
+   location as defined in Section 8.5.  For example:
+   "service:directory-agent://foobawooba.org".
+
+   The following sections suggest timing algorithms which enhance the
+   scalability of SLP.
+
+12.2.1. Active DA Discovery
+
+   After a UA or SA restarts, its initial DA discovery request SHOULD be
+   delayed for some random time uniformly distributed from 0 to
+   CONFIG_START_WAIT seconds.
+
+   The UA or SA sends the DA Discovery request using a SrvRqst, as
+   described in Section 8.1.  DA Discovery requests MUST include a
+   Previous Responder List.  SrvRqsts for Active DA Discovery SHOULD NOT
+   be sent more than once per CONFIG_DA_FIND seconds.
+
+   After discovering a new DA, a SA 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.
+
+   All UAs and SAs which receive the unsolicited DAAdvert SHOULD examine
+   its DA stateless Boot Timestamp.  If it is set to 0, the DA is going
+   down and no further messages should be sent to it.
+
+   If a SA detects a DA it has never encountered (with a nonzero
+   timestamp,) the SA must register with it.  SAs MUST examine the
+   DAAdvert's timestamp to determine if the DA has had a stateless
+   reboot since the SA last registered with it.  If so it registers with
+   the DA. SAs MUST wait a random interval between 0 and
+   CONFIG_REG_PASSIVE before beginning DA registration.
+
+
+
+Guttman, et al.             Standards Track                    [Page 40]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+12.3. Reliable Unicast to DAs and SAs
+
+   If a DA or SA fails to respond to a unicast UDP message in
+   CONFIG_RETRY seconds, the message should be retried.  The wait
+   interval for each subsequent retransmission MUST exponentially
+   increase, doubling each time.  If a DA or SA fails to respond after
+   CONFIG_RETRY_MAX seconds, the sender should consider the receiver to
+   have gone down.  The UA should use a different DA. If no such DA
+   responds, DA discovery should be used to find a new DA. If no DA is
+   available, multicast requests to SAs are used.
+
+12.4. DA Scope Configuration
+
+   By default, DAs are configured with the "DEFAULT" scope.
+   Administrators may add other configured scopes, in order to support
+   UAs and SAs in non default scopes.  The default configuration MUST
+   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 can be phased-in as the SLP deployment grows.
+   Default scopes should be phased out only when the non-default scopes
+   are universally configured.
+
+   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.
+
+12.5. DAs and Authentication Blocks
+
+   DAs are not configured to sign service registrations or attribute
+   lists.  They simply cache services registered by Service Agents.  DAs
+   MUST NOT accept registrations including authentication blocks for SLP
+   SPIs which it is not configured with, see Section 8.5.
+
+   A DA protects registrations which are made with authentication blocks
+   using SLP SPIs it is configured to use.  If a service S is
+   registered, a subsequent registration (which will replace the
+   adertisement) or a deregistration (which will remove it) MUST include
+   an Authentication Block with the corresponding SLP SPI, see Section
+   8.3 and Section 10.6.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 41]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   Example:
+
+   A DA is configured to be able to verify Authentication Blocks with
+   SLP SPIs "X,Y", that is X and Y.
+
+   An SA registers a service with an Authentication Block with SPI "Z".
+   The DA stores the registration, but discards the Authentication
+   Block.  If a UA requests a service with an SLP SPI string "Z", the DA
+   will respond with an AUTHENTICATION_UNKNOWN error.
+
+   An SA registers a service S with Authentication Blocks including SLP
+   SPIs "X" and "Y".  If a UA requests a service with an SLP SPI string
+   "X" the DA will be able to return S (if the service type, language,
+   scope and predicate of the SrvRqst match S) The DA will also return
+   the Authentication Block with SLP SPI set to "X".  If the DA receives
+   a subsequent SrvDeReg for S (which will remove the advertisement) or
+   a subsequent SrvReg for S (which will replace it), the message must
+   include two URL Authentication Blocks, one each for SPIs "X" and "Y".
+   If either of these were absent, the DA would return an
+   AUTHENTICATION_ABSENT error.
+
+13. Protocol Timing Defaults
+
+Interval name        Section  Default Value   Meaning
+-------------------  -------  -------------   ------------------------
+CONFIG_MC_MAX        6.3      15 seconds      Max time to wait for a
+                                              complete multicast query
+                                              response (all values.)
+CONFIG_START_WAIT    12.2.1   3 seconds       Wait to perform DA
+                                              discovery on reboot.
+CONFIG_RETRY         12.3     2 seconds       Wait interval before
+                                              initial retransmission
+                                              of multicast or unicast
+                                              requests.
+CONFIG_RETRY_MAX     12.3     15 seconds      Give up on unicast
+                                              request retransmission.
+CONFIG_DA_BEAT       12.2.2   3 hours         DA Heartbeat, so that SAs
+                                              passively detect new DAs.
+CONFIG_DA_FIND       12.3     900 seconds     Minimum interval to wait
+                                              before repeating Active
+                                              DA discovery.
+CONFIG_REG_PASSIVE   12.2     1-3 seconds     Wait to register services
+                                              on passive DA discovery.
+CONFIG_REG_ACTIVE    8.3      1-3 seconds     Wait to register services
+                                              on active DA discovery.
+CONFIG_CLOSE_CONN    6.2      5 minutes       DAs and SAs close idle
+                                              connections.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 42]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+14. Optional Configuration
+
+      Broadcast Only
+               Any SLP agent SHOULD be configurable to use broadcast
+               only.  See Sections 6.1 and 12.2.
+
+      Predefined DA
+               A UA or SA SHOULD be configurable to use a predefined DA.
+
+      No DA Discovery
+               The UA or SA SHOULD be configurable to ONLY use
+               predefined and DHCP-configured DAs and perform no active
+               or passive DA discovery.
+
+      Multicast TTL
+               The default multicast TTL is 255.  Agents SHOULD be
+               configurable to use other values.  A lower value 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.
+
+      Timing Values
+               Time values other than the default MAY be configurable.
+               See Section 13.
+
+      Scopes
+               A UA 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.  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.
+
+      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.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 43]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+      Service Template
+               UAs and SAs MAY be configured by using 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.
+
+      SLP SPI for service discovery
+               Agents SHOULD be configurable to support SLP SPIs using
+               the following parameters:  BSD=2 (DSA with SHA-1) and
+               a public key identified by the SLP SPI String.  In
+               the future, when a Public Key Infrastructure exists,
+               SLP Agents may be able to obtain public keys and
+               cryptographic parameters corresponding to the names used
+               in SLP SPI Strings.
+
+               Note that if the SLP SPI string chosen is identical
+               to a scope string, it is effectively the same as a
+               Protected Scope in SLPv1.  Namely, every SA advertising
+               in that scope would be configured with the same Private
+               Key.  Every DA and UA of that scope would be configured
+               with the appropriate Public Key to verify signatures
+               produced by those SAs.  This is a convenient way to
+               configure SLP deployments in the absence of a Public Key
+               Infrastructure.  Currently, it would be too difficult to
+               manage the keying of UAs and DAs if each SA had its own
+               key.
+
+      SLP SPI for Directory Agent discovery
+               Agents SHOULD be configurable to support SLP SPIs as
+               above, to be used when discovering DAs.  This SPI SHOULD
+               be sent in SrvRqsts to discover DAs and be used to verify
+               multicast DAAdvert messages.
+
+      SA and DA Private Key
+               SAs and DAs which can generate digital signatures require
+               a Private Key and a corresponding SLP SPI indentifier
+               to include in the Authentication Block.  The SLP SPI
+               identifies the Public Key to use to verify the digital
+               signature in the Authentication Block.
+
+15. IANA Considerations
+
+   SLP includes four sets of identifiers which may be registered with
+   IANA. The policies for these registrations (See [18]) are noted in
+   each case.
+
+
+
+Guttman, et al.             Standards Track                    [Page 44]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   The Block Structure Descriptor (BSD) identifies the format of the
+   Authenticator which follows.  BSDs 0x8000-0x8FFF are for Private Use.
+
+   Further Block Structured Descriptor (BSD) values, from the range
+   0x0003-0x7FFF 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 Cryptographic BSD numbers on the basis of IETF
+   Consenus.
+
+   New function-IDs, in the range 12-255, may be standardized by the
+   method of IETF Consensus.
+
+   New SLP Extensions with types in the range 2-65535 may be registered
+   following review by a Designated Expert.
+
+   New error numbers in the range 15-65535 are assigned on the basis of
+   a Standards Action.
+
+   Protocol elements used with Service Location Protocol may also
+   require IANA registration actions.  SLP is used in conjunction with
+   "service:" URLs and Service Templates [13].  These are standardized
+   by review of a Designated Expert and a mailing list (See [13].)
+
+16. Internationalization Considerations
+
+   SLP messages support the use of multiple languages by providing a
+   Language Tag field in the common message header (see Section 8).
+
+   Services MAY be registered in multiple languages.  This provides
+   attributes so that users with different language skills may select
+   services interactively.
+
+   Attribute tags are not translated.  Attribute values may be
+   translated unless the Service Template [13] defines the attribute
+   values to be 'literal'.
+
+
+
+Guttman, et al.             Standards Track                    [Page 45]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   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.
+
+17. 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' inasmuch 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.
+
+   If Agents are not configured to generate Authentication Blocks and
+   Agents are not configured to verify them, 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 SLP SPIs prior to deploying the sensitive directory
+   agents or service agents.
+
+
+
+Guttman, et al.             Standards Track                    [Page 46]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   SLP is useful as a bootstrap protocol.  It may be used in
+   environments in which no preconfiguration is possible.  In such
+   situations, a certain amount of "blind faith" is required:  Without
+   any prior configuration it is impossible to use any of the security
+   mechanisms described above.  SLP 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 Authentication Blocks if
+   cryptographic information and SLP SPIs can be preconfigured with the
+   end systems before they use SLP.
+
+   SLPv2 enables a number of security policies with the mechanisms it
+   includes.  A SLPv2 UA could, for instance, reject any SLP message
+   which did not carry an authentication block which it could verify.
+   This is not the only policy which is possible to implement.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 47]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+A. Appendix:  Changes to the Service Location Protocol from v1 to v2
+
+   SLP version 2 (SLPv2) corrects race conditions present in SLPv1 [22].
+   In addition, authentication has been reworked to provide more
+   flexibility and protection (especially for DA Advertisements).  SLPv2
+   also changes the formats and definition of many flags and values and
+   reduces the number of 'required features.'  SLPv2 clarifies and
+   changes the use of 'Scopes', eliminating support for 'unscoped
+   directory agents' and 'unscoped requests'.  SLPv2 uses LDAPv3
+   compatible string encodings of attributes and search filters.  Other
+   changes (such as Language and Character set handling) adopt practices
+   recommended by the Internet Engineering Steering Group.
+
+   Effort has been made to make SLPv2 operate the same whether DAs are
+   present or not.  For this reason, a new message (the SAAdvert) has
+   been added.  This allows UAs to discover scope information in the
+   absence of administrative configuration and DAs.  This was not
+   possible in SLPv1.
+
+   SLPv2 is incompatible in some respects with SLPv1.  If a DA which
+   supports both SLPv1 and SLPv2 with the same scope is present,
+   services advertised by SAs using either version of the protocol will
+   be available to both SLPv1 and SLPv2 UAs.  SLPv1 DAs SHOULD be phased
+   out and replace with SLPv2 DAs which support both versions of the
+   protocol.
+
+   SLPv1 allows services to be advertised and requested without a scope.
+   Further, DAs can be configured without a scope.  This is incompatible
+   with SLPv2 and presents scalability problems.  To facilitate this
+   forward migration, SLPv1 agents MUST use scopes for all registrations
+   and requests.  SLPv1 DAs MUST be configured with a scope list.  This
+   constitutes a revision of RFC 2165 [22].
+
+B. Appendix:  Service Discovery by Type:  Minimal SLPv2 Features
+
+   Service Agents may advertise services without attributes.  This will
+   enable only discovery of services by type.  Service types discovered
+   this way will have a Service Template [13] defined which specifies
+   explicitly that no attributes are associated with the service
+   advertisement.  Service types associated with Service Templates which
+   specify attributes MUST NOT be advertised by SAs which do not support
+   attributes.
+
+   While discovery of service by service type is a subset of the
+   features possible using SLPv2 this form of discovery is consistent
+   with the current generation of products that allow simple browsing of
+   all services in a 'zone' or 'workgroup' by type.  In some cases,
+   attribute discovery, security and feature negotiation is handled by
+
+
+
+Guttman, et al.             Standards Track                    [Page 48]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   application layer protocols - all that is required is the basic
+   discovery of services that support a certain service.
+
+   UAs requesting only service of that service type would only need to
+   support service type and scope fields of the Service Request.  UAs
+   would still perform DA discovery and unicast SLPv2 SrvRqst messages
+   to DAs in their scope once they were discovered instead of
+   multicasting them.
+
+   SAs would also perform DA discovery and use a SLPv2 SrvReg to
+   register all their advertised services with SLPv2 DAs in their scope.
+   These advertisements would needless to say contain no attribute
+   string.
+
+   These minimal SAs could ignore the Language Tag in requests since
+   SrvRqst messages would contain no attributes, hence no strings would
+   be internationalized.  Further, any non-null predicate string would
+   fail to match a service advertisement with no attributes, so these
+   SAs would not have to parse and interpret search filters.  Overflow
+   will never occur in SrvRqst, SrvRply or SrvReg messages so TCP
+   message handling would not have to be implemented.  Finally, all
+   AttrRqst messages could be dropped by the SA, since no attributes are
+   supported.
+
+C. Appendix:  DAAdverts with arbitrary URLs
+
+   Using Active DA Discovery, a SrvRqst with its service type field set
+   to "service:directory-agent".  DAs will respond with a DAAdvert
+   containing a URL with the "service:directory-agent:" scheme.  This is
+   the same DAAdvert that such a DA would multicast in unsolicited DA
+   advertisements.
+
+   A UA or SA which receives an unsolicited DAAdvert MUST examine the
+   URL to determine if it has a recognized scheme.  If the UA or SA does
+   not recognize the DAAdvert's URL scheme, the DAAdvert is silently
+   discarded.  This document specifies only how to use URLs with the
+   "service:directory-agent:" scheme.
+
+   This provides the possibility for forward compatibility with future
+   versions of SLP and enables other services to advertise their ability
+   to serve as a clearinghouse for service location information.
+
+   For example, if LDAPv3 [15] is used for service registration and
+   discovery by a set of end systems, they could interpret a LDAP URL
+   [16] to passively discover the LDAP server to use for this purpose.
+   This document does not specify how this is done:  SLPv2 agents
+   without further support would simply discard this DAAdvert.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 49]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+D. Appendix:  SLP Protocol Extensions
+
+D.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 a
+   Required Attribute for the requested Service Type (according to the
+   Service Template), it MAY return 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> MUST NOT include wild cards.
+
+E. Acknowledgments
+
+   This document incorporates ideas from work on several discovery
+   protocols, including RDP by Perkins and Harjono, and PDS by Michael
+   Day.  We are grateful for contributions by Ye Gu and Peter Ford.
+   John Veizades was instrumental in the standardization of the Service
+   Location Protocol.  Implementors at Novell, Axis Communications and
+   Sun Microsystems have contributed significantly to make this a much
+   clearer and more consistent document.
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 50]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+F. References
+
+    [1] Port numbers, July 1997.
+        ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.
+
+    [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] Unicode Technical Report #8.  The Unicode Standard, version 2.1.
+        Technical report, The Unicode Consortium, 1998.
+
+    [7] Alvestrand, H., "Tags for the Identification of Languages",
+        RFC 1766, March 1995.
+
+    [8] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
+        Resource Identifiers (URI): Generic Syntax", RFC 2396,
+        August 1998.
+
+    [9] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+   [10] CCITT.  The Directory Authentication Framework.  Recommendation
+        X.509, 1988.
+
+   [11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
+        Specifications: ABNF", RFC 2234, November 1997.
+
+   [12] S. Gursharan, R. Andrews, and A. Oppenheimer.  Inside AppleTalk.
+        Addison-Wesley, 1990.
+
+   [13] Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
+        service: Schemes", RFC 2609, June 1999.
+
+   [14] Howes, T., "The String Representation of LDAP Search Filters",
+        RFC 2254, December 1997.
+
+   [15] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
+        Access Protocol (v3)", RFC 2251, December 1997.
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 51]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+   [16] Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
+        December 1997.
+
+   [17] Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
+        July 1998.
+
+   [18] Narten, T. and H. Alvestrand, "Guidelines for Writing
+        an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
+        October 1998.
+
+   [19] Microsoft Networks.  SMB File Sharing Protocol Extensions 3.0,
+        Document Version 1.09, November 1989.
+
+   [20] National Institute of Standards and Technology.  Digital
+        signature standard.  Technical Report NIST FIPS PUB 186, U.S.
+        Department of Commerce, May 1994.
+
+   [21] Perkins, C. and E. Guttman, "DHCP Options for Service Location
+        Protocol", RFC 2610, June 1999.
+
+   [22] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
+        Location Protocol", RFC 2165, July 1997.
+
+   [23] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
+        RFC 2279, January 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 52]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+G.  Authors' Addresses
+
+   Erik Guttman
+   Sun Microsystems
+   Bahnstr. 2
+   74915 Waibstadt
+   Germany
+
+   Phone:    +49 7263 911 701
+   EMail:    Erik.Guttman@sun.com
+
+
+   Charles Perkins
+   Sun Microsystems
+   901 San Antonio Road
+   Palo Alto, CA 94040
+   USA
+
+   Phone: +1 650 786 6464
+   EMail: cperkins@sun.com
+
+
+   John Veizades
+   @Home Network
+   425 Broadway
+   Redwood City, CA 94043
+   USA
+
+   Phone:    +1 650 569 5243
+   EMail:    veizades@home.net
+
+
+   Michael Day
+   Vinca Corporation.
+   1201 North 800 East
+   Orem, Utah 84097   USA
+
+   Phone: +1 801 376-5083
+   EMail: mday@vinca.com
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 53]
+
+RFC 2608         Service Location Protocol, Version 2          June 1999
+
+
+H.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1999).  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
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Guttman, et al.             Standards Track                    [Page 54]
+