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.
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 . 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  and SMB  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
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
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.
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.
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.
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
of multicast or unicast
CONFIG_RETRY_MAX 12.3 15 seconds Give up on unicast
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
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
14. Optional Configuration
Any SLP agent SHOULD be configurable to use broadcast
only. See Sections 6.1 and 12.2.
A UA or SA SHOULD be configurable to use a predefined DA.
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.
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.
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 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
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
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 ) are noted in
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 . These are standardized
by review of a Designated Expert and a mailing list (See .)
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
Attribute tags are not translated. Attribute values may be
translated unless the Service Template  defines the attribute
values to be 'literal'.
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
 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
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)  to provide confidentiality for Service
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.
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.
A. Appendix: Changes to the Service Location Protocol from v1 to v2
SLP version 2 (SLPv2) corrects race conditions present in SLPv1 .
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 .
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  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
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
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
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  is used for service registration and
discovery by a set of end systems, they could interpret a LDAP URL
 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.
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.
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.
 Port numbers, July 1997.
 ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 4 to ISO/IEC 9594-2, December 1996.
 ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 2 to ISO/IEC 9594-6, December 1996.
 ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-7, December 1996.
 ISO/IEC JTC1/SC 21. Certificate Extensions. Draft Amendment
DAM 1 to ISO/IEC 9594-8, December 1996.
 Unicode Technical Report #8. The Unicode Standard, version 2.1.
Technical report, The Unicode Consortium, 1998.
 Alvestrand, H., "Tags for the Identification of Languages",
RFC 1766, March 1995.
 Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform
Resource Identifiers (URI): Generic Syntax", RFC 2396,
 Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 CCITT. The Directory Authentication Framework. Recommendation
 Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
 S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
 Guttman, E., Perkins, C. and J. Kempf, "Service Templates and
service: Schemes", RFC 2609, June 1999.
 Howes, T., "The String Representation of LDAP Search Filters",
RFC 2254, December 1997.
 Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
Access Protocol (v3)", RFC 2251, December 1997.
 Howes, T. and M. Smith, "The LDAP URL Format", RFC 2255,
 Meyer, D., "Administratively Scoped IP Multicast", RFC 2365,
 Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs, BCP 26, RFC 2434,
 Microsoft Networks. SMB File Sharing Protocol Extensions 3.0,
Document Version 1.09, November 1989.
 National Institute of Standards and Technology. Digital
signature standard. Technical Report NIST FIPS PUB 186, U.S.
Department of Commerce, May 1994.
 Perkins, C. and E. Guttman, "DHCP Options for Service Location
Protocol", RFC 2610, June 1999.
 Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service
Location Protocol", RFC 2165, July 1997.
 Yergeau, F., "UTF-8, a transformation format of ISO 10646",
RFC 2279, January 1998.
G. Authors' Addresses
Phone: +49 7263 911 701
901 San Antonio Road
Palo Alto, CA 94040
Phone: +1 650 786 6464
Redwood City, CA 94043
Phone: +1 650 569 5243
1201 North 800 East
Orem, Utah 84097 USA
Phone: +1 801 376-5083
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
"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."
Funding for the RFC Editor function is currently provided by the