tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 2608


Service Location Protocol, Version 2

Part 3 of 3, p. 37 to 54
Prev RFC Part


prevText      Top      Up      ToC       Page 37 
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

   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.

Top      Up      ToC       Page 38 
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

   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

Top      Up      ToC       Page 39 
   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.

Top      Up      ToC       Page 40 
   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:

   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

   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.

Top      Up      ToC       Page 41 
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.

Top      Up      ToC       Page 42 

   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

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

Top      Up      ToC       Page 43 
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.

               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.

Top      Up      ToC       Page 44 
      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

      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.

Top      Up      ToC       Page 45 
   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

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

Top      Up      ToC       Page 46 
   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.

Top      Up      ToC       Page 47 
   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.

Top      Up      ToC       Page 48 
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

   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

   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

Top      Up      ToC       Page 49 
   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

   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

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

   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.

Top      Up      ToC       Page 50 
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

   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

   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.

Top      Up      ToC       Page 51 
F. References

    [1] Port numbers, July 1997.

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

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

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

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

    [6] 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.

Top      Up      ToC       Page 52 
   [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.

Top      Up      ToC       Page 53 
G.  Authors' Addresses

   Erik Guttman
   Sun Microsystems
   Bahnstr. 2
   74915 Waibstadt

   Phone:    +49 7263 911 701

   Charles Perkins
   Sun Microsystems
   901 San Antonio Road
   Palo Alto, CA 94040

   Phone: +1 650 786 6464

   John Veizades
   @Home Network
   425 Broadway
   Redwood City, CA 94043

   Phone:    +1 650 569 5243

   Michael Day
   Vinca Corporation.
   1201 North 800 East
   Orem, Utah 84097   USA

   Phone: +1 801 376-5083

Top      Up      ToC       Page 54 
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

   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


   Funding for the RFC Editor function is currently provided by the
   Internet Society.