WDIFF

draft-ietf-svrloc-protocol-v2-05.txt --> draft-ietf-svrloc-protocol-v2-07.txt

Internet Engineering Task Force Erik Guttman
INTERNET DRAFT Charles Perkins
4 May
16 July 1998 Sun Microsystems
John Veizades
@Home Network
Michael Day
Intel

Service Location Protocol
draft-ietf-svrloc-protocol-v2-05.txt Protocol, Version 2
draft-ietf-svrloc-protocol-v2-07.txt

Status of This Memo

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

Distribution of this memo is unlimited.

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

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as ``work in progress.''

To view the entire list of current Internet-Drafts, please check
the ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Distribution of this memo is unlimited.

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.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page i]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

Contents

Status of This Memo i

Abstract i

1. Introduction 1
1.1. Applicability Statement . . . . . . . . . . . . . . . . . 2
1.2. Changes to the Service Location Protocol from v1 to v2 . 2

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

3. Protocol Overview 3 4

4. URLs used with Service Location 4 6
4.1. Service: URLs . . . . . . . . . . . . . . . . . . . . . . 4 6
4.2. Naming Authorities . . . . . . . . . . . . . . . . . . . 7
4.3. URL Entries . . . . . . . . . . . . . . . . . . . . . . . 6 8

5. Service Attributes 6 8

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

7. Errors 14

8. Required SLP Messages 11
7.1. 15
8.1. Service Request . . . . . . . . . . . . . . . . . . . . . 13
7.2. 16
8.2. Service Reply . . . . . . . . . . . . . . . . . . . . . . 15
7.3. 18
8.3. Service Registration . . . . . . . . . . . . . . . . . . 15
7.4. 19
8.4. Service Acknowledgment . . . . . . . . . . . . . . . . . 16
7.5. 20
8.5. Directory Agent Advertisement . . . . . . . . . . . . . . 17
7.6. 20
8.6. Service Agent Advertisement . . . . . . . . . . . . . . . 17

8. Errors 18 21

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page ii]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

10. Optional SLP Messages 24 27
10.1. Service Type Request . . . . . . . . . . . . . . . . . . 24 27
10.2. Service Type Reply . . . . . . . . . . . . . . . . . . . 25 28
10.3. Attribute Request . . . . . . . . . . . . . . . . . . . . 25 28
10.4. Attribute Reply . . . . . . . . . . . . . . . . . . . . . 26 29
10.5. Attribute Request/Reply Examples . . . . . . . . . . . . 27 30
10.6. Service Deregistration . . . . . . . . . . . . . . . . . 28 31

11. Scopes 29 32
11.1. Scope Rules . . . . . . . . . . . . . . . . . . . . . . . 29 32
11.2. Administrative and User Configurable Selectable Scopes . . . . . . . 30 . 33
11.3. Protected Scopes . . . . . . . . . . . . . . . . . . . . 30 33

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

13. Protocol Timing Defaults 35

14. SLP Protocol Extensions 35
14.1. 37
13.1. Required Attribute Missing Option . . . . . . . . . . . . 35
14.2. 37
13.2. Cryptographic Algorithm Request Option . . . . . . . . . 36 . . . . . 37

14. Protocol Timing Defaults 38

15. Optional Configuration 36 39

16. IANA Considerations 38 40

17. Internationalization Considerations 38 40

18. Security Considerations 39 41

19. Acknowledgments 40 42

20. Full Copyright Statement 40 42

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 using knowing the name of
a network host (a human readable text string) which is an alias for a
network address. The Service Location Protocol SLP eliminates the need for a user to know the name

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 1]

Internet Draft Service Location Protocol, Version 2 16 July 1998

of a network host supporting a service. Rather, the user names supplies
the desired type of service and supplies a set of attributes

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 1]

Internet Draft Service Location Protocol 4 May 1998 which describe
the service. The Based on that description, the Service Location
Protocol allows the
user to bind this description to resolves the network address of the service.

Service Location service for the user.

SLP provides a dynamic configuration mechanism for applications in
local area networks. It has been designed to serve
enterprise networks with shared services, and it may not necessarily
scale for wide-area service discovery throughout the global Internet. Applications are modeled as clients that need
to find servers attached to any of the available networks within the 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.

The

This document specifies the Service Location Protocol (SLP) is presented in
two main parts. The first are describes the required features of the
protocol. The second are describes the extended features of the protocol
which are optional or optional, and allow greater scalability.

2. Terminology

User Agent (UA)
A process working

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 user's behalf
scale of the Internet as a whole.

SLP has been designed to establish
contact serve enterprise networks with a useful service. The UA retrieves shared
services, and it may not necessarily scale for wide-area service
information from
discovery throughout the Service Agents global Internet, or Directory Agents.

Service Agent (SA)
A process working on the behalf in networks where
there are hundreds of one thousands of clients or more services tens of thousands of
services.

1.2. 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 reduced the number of 'required features.' SLPv2 clarifies
and changes the use of 'Scopes', eliminating support for 'unscoped
directory agents' and 'unscoped requests'. 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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 2]

Internet Draft Service Location Protocol, Version 2 16 July 1998

the absence of administrative configuration and DAs. This was not
possible in SLPv1.

SLPv2 is incompatible in some respects with SLPv1. If a DA supports
both SLPv1 and SLPv2 with the same scope, services advertised by SAs
using either version of the protocol will be available to both SLPv1
and SLPv2 UAs.

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 and caches service
advertisements from SAs. If there is a DA, UAs use them
in preference to SAs. 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 collection or set of services that make services, typically making up a logical
administrative group.

URL A Universal Resource Locator - see [9].

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 2]

Internet Draft Service Location Protocol 4 May 1998

SLP v1

SLPv1 The version of Service Location Protocol SLP specified in RFC 2165 [21]. [23].

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

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 3]

Internet Draft Service Location Protocol, Version 2 16 July 1998

Strings Strings in the protocol are All strings are encoded using the UTF8 [24]
transformation of the Unicode [6] character set and
are NOT null terminated.
They terminated when transmitted. Strings
are always proceeded preceded by a two byte length field.

String List This construct, used frequently in the protocol, is
a

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

3. Protocol Overview

The Service Location Protocol (SLP) provides supports a flexible and scalable framework for providing hosts with access to information about the
existence, location, by which client
applications are modeled as 'User Agents' and configuration of networked services.

SLP is a request-reply protocol; in a typical operation services are advertised
by 'Service Agents.' A third entity, called a 'Directory Agent'
provides scalability to the protocol.

The User Agent
(UA) issues a request for service information and awaits one or more
replies containing the requested information.

Depending 'Service Request' (SrvRqst) on behalf of the environment, replies
client application, specifying the characteristics of the service
which the client requires. The User Agent will be sent 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 UA by request
is multicast. Service Agents receiving a
SA, request for a DA, or by both. For smaller environments, SLP allows service which
they advertise unicast a simple
peer-to-peer deployment consisting only of UAs and SAs. For larger
environments, SLP allows reply containing the consolidation of service configuration
data at service's location.

+------------+ ----Multicast SrvRqst----> +---------------+
| User Agent | | Service Agent |
+------------+ <----Unicast SrvRply------ +---------------+

In larger networks, one or more DAs.

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

SLP Messages Directory Agents are normally transmitted 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 datagrams using UDP/IP.
Requests may reply (SrvAck).
These advertisements must be unicast, multicast, refreshed with the Directory Agent
or broadcast. When a UA they expire. User Agents unicast requests to Directory Agents
instead of Service Agents if any Directory Agents are known.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 3] 4]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

multicasts or broadcasts

User and Service Agents discover Directory Agents two ways. First,
they issue a request, it will often 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 more than
one reply. Replies must be unicast, though errors a DA
Advertisement (DAAdvert).

Services are NOT returned grouped together using 'scopes'. These are strings
which identify services which are administratively identified. A
scope could indicate a location, administrative grouping, proximity
in this case. In cases where a reply network topology or some other category. Service Agents and
Directory Agents are always assigned a scope string.

A User Agent is too large to fit within normally assigned a
datagram, the UA may reissue the request using TCP. Requests scope string (in which
are too large case the
User Agent will only be able to fit into discover that particular grouping
of services). This allows a datagram are always sent using TCP.

Hosts network administrator to 'provision'
services to users. Alternatively, the User Agent may be configured statically or by using DHCP options 78
with no scope at all. In that case, it will discover all available
scopes and
79 allow the client application to issue requests to specific SAs or DAs. Otherwise, SLP allows
a host to "bootstrap" itself, beginning with no knowledge of for any
services or SLP agents beyond its own UA. To bootstrap itself,
service available on the
host must multicast or broadcast its first request.

Certain conditions will influence network.

In the best strategy for deploying SLP
in specific environments. Centralizing service information using
DAs simplifies above illustration, the process by which UAs obtain User Agent is configured with scopes X
and Y. If a service information.
However, is sought in scope X, the request is multicast.
If it is not necessary sought in scope Y, the request is unicast to centralize service-related
information the DA.
Finally, if the request is to be made in smaller installations; multicast queries are
adequate. Specific environments may have special policies regarding
broadcasting or multicasting.

This document specifies a range of usage models for SLP, beginning
with a lightweight both scopes, the request
must be both unicast and simple minimal implementation multicast.

Scopes for smaller or
constrained environments. SLP can be scaled upward from which the minimal
implementation by deploying more richly featured UAs and SAs, User, Service or Directory Agents have associated
cryptographic keying material are called 'protected scopes'. These
allow Service Agents to digitally sign their advertisements. User
and by
adding DAs. Directory Agents verify this signature before accepting
advertisements in protected scopes.

The features described up to this point are required to implement.
A SLP v2 minimum implementation MAY support SLP v1 [21].

4. URLs used with consists of a User Agent, Service Agent or
both.

There are several optional features in the protocol.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 5]

Internet Draft Service Location

A Protocol, Version 2 16 July 1998

Service URL indicates the location Type Request A request for all types of a service. service on the
network. This URL may allows generic service browsers
to be of the service: scheme [14] 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 absense 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 absense 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 MAY support SLPv1 [23].

4. URLs used with Service Location

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

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

4.1. Service: URLs

Service URL syntax and semantics are defined in [14]. [15]. Any network
service may be encoded in a Service URL.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 4] 6]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

What follows is

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. An http service on a nonstandard port could be
"service:http://webby:8080''.
"service:http://webby:8080".

Service Types may SHOULD be defined by a "service template'' [14], template" [15], which
provides expected attributes, values and protocol behavior. That
document also describes 'Abstract Service Types.' An
abstract service type (also described in [15]) 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 string URL). This substring is the Naming Authority, as described in
Section 9.6. Service types with naming authorities different Naming Authorities are
quite distinct. In other words, service:x.one and service:x.two
are different service
types. types, as are service:abstract.one:y and
service:abstract.two:y.

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 5] 7]

Internet Draft Service Location Protocol 4 May 1998

4.2. URL Entries

0 1 2 3
0 1 Protocol, Version 2 3 4 5 6 7 8 9 0 16 July 1998

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 to select services in Service
Requests. Requests to select
appropriate services.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 8]

Internet Draft Service Location Protocol, Version 2 16 July 1998

An attribute list is a string encoding of the attributes of a
service. The following ABNF [13] grammar applies to lists of
attributes: 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" "true" / "FALSE" "false"
opaque = "\FF" 1* ( `\' HEXDIGIT HEXDIGIT ) 1*escape-val
safe-val = ; Any character except reserved.
safe-tag = ; Any character except reserved, star and bad-tag.

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

Internet Draft Service Location Protocol 4 May 1998
reserved = `(' / `)' / `,' / `\' / `!' / `<' / `=' / `>' / `~' / CTL
escape-val = `\' HEXDIG HEXDIG HEXDIGIT HEXDIGIT
bad-tag = CR / LF / HT / `_'
star =`*'

The <attr-list>, if present, must 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 values, escaped characters are not converted -
they are interpreted as bytes.

Boolean Strings which have the form "true" or "false" can
only take one value and may only be compared with '='
or '!='.
'='. 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
ordering (see Section 6.3. 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
UTF8 character, 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".

A string which contains escaped values other than from the reserved
set of characters is illegal. If such a string is included in an

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 9]

Internet Draft Service Location Protocol, Version 2 16 July 1998

<attr-list>, <tag-list> or search filter filter, the SA or DA which
receives it MUST return a PARSE_ERROR in to the reply. message.

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

All attribute values are expressed as strings.

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

Stored values must be consistent, i.e., x=4,true,sue,\ff\00\00 is
disallowed. A DA or SA receiving such an <attr-list> MUST return an
INVALID_REGISTRATION error.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 7]

Internet Draft Service Location Protocol 4 May 1998

6. Required Features

Service discovery

This section defines the minimal implementation requirements for
SAs and UAs as well as their interaction with DAs. A DA is performed on behalf of a client by not
required for SLP UA
functionality. A host's services are represented by a SA which
responds to UA requests. A third element in the framework function, but if it is present, the DA
which is a cache of service information. The UA and SA interaction
MUST interact with a DA is discussed here, but DA it as defined below.

A minimal implementation is not part 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
minimal specification.

Wants this information:
Client Application - - - - - - - - - - - - -> Service
USES USES
User Agent -----------------------+--> Service Agent
(Request: SrvRqst | ^ | (Request: SrvReg
Reply: 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 | | | Reply: SrvAck) or DAAdvert) | DAAdvert v
+---> Directory Agent
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 SrvRqst using multicast request to the assigned address,
requesting the service-type `directory-agent' and the scope list a DA which it has been configured with. If it receives any results, all subsequent
service with
by DHCP.

2. A UA issues requests SHOULD unicast to the DA indicated in the URL in
the DAAdvert reply. If it does not receive a reply, DAs which it multicasts
subsequent requests and SAs will respond. It should has been statically
configured with.

3. A 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 once every CONFIG_DA_FIND seconds if it knows of seconds.

4. A UA with no DAs,
if subsequent discovery is required. knowledge of DAs sends requests using multicast
convergence to SAs. SAs unicast replies to UAs MUST according to the
multicast convergence algorithm.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 10]

Internet Draft Service Location Protocol, Version 2 16 July 1998

1. With DHCP.

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

3. In the service information they obtain from DAs absense of configuration, the agent's scope is
stale.

The "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 also issues a SrvRqst for DAs, as described above. If any discovery to determine its scope list dynamically. In this
case it uses an empty scope list to discover DAs
are discovered, and possibly SAs.
Then it uses the scope list it obtains from DAAdverts and possibly
SAAdverts in subsequent requests.)

The SA MUST register all of its services with any DA it discovers, if
the DA
using a series advertises any of SrvReg requests. The SrvAck indicates whether the
DA scopes it has been successful.

SAs configured with. A
SA obtains information about DAs as a UA does. In addition, the SA
MUST listen for multicast messages. If they receive a SrvRqst, they
will respond with a SrvRply as defined below. If the SAs receive a
DAAdvert (which DAs periodically emit) they must remotely register
all services with it unsolicited DAAdverts. The SA registers
by sending SrvReg messages to DAs, which support one or more of the scopes in DA's
scope list.

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 8]

Internet Draft Service Location Protocol 4 May 1998 use.

6.1. Use of Ports, UDP, TCP, and Multicast

The Service Location Protocol uses multicast when supported at
the network layer. 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
from which the request was issued. The default maximum transmission
unit for UDP messages is 1400 bytes. The Administratively Scoped

If a SLP Multicast [17]
address message does not fit into a UDP datagram it MUST be
truncated to fit, and the OVERFLOW flag is 239.255.255.253. 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 Service Location The Administratively Scoped
SLP Multicast Address. [18] address, which is 239.255.255.253. The default
TTL to use for multicast is 32.

In isolated networks, broadcasts will work in place of multicast.
To that end, SAs SHOULD and DAs MUST listen for broadcast Service
Location request

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 11]

Internet Draft Service Location Protocol, Version 2 16 July 1998

Location messages to at port 427. This allows UAs which lack do not support
multicast capabilities to still make use of Service Location on isolated networks.

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

6.1.1. UDP and Multicast Transmission of SLP Messages

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

If a SLP message does not fit into a UDP datagram it MUST be
truncated to fit, and the OVERFLOW flag is set in the reply header.
A UA which receives such a truncated reply MAY open a TCP connection
with the DA or SA and retransmit the request, using the same XID. It
MAY also attempt to make use of the truncated reply or reformulate a
more restrictive request which will result in a smaller reply.

6.2. Use of TCP

A SrvReg or SrvDeReg may be too large to fit into a datagram. To
send such large SLP messages which do not fit in a datagram, 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 forego omit
TCP support only if they never have to receive unicast requests arriving for its services
will never be
longer than the path MTU.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 9]

Internet Draft Service Location Protocol 4 May 1998

- UAs can accept replies with the 'OVERFLOW' flag set, and make use
of the first result included. 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. This is possible if the SA is an size (e.g., some embedded
system, for instance, with a very limited set of service URLs and
attributes that it is configured with. systems).

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

The initiating agent is responsible for closing SHOULD close the TCP connection. The DA should SHOULD
wait at least CONFIG_CLOSE_CONN seconds before closing an idle
connection. DAs and SAs SHOULD eventually close an idle TCP
connections connection after
CONFIG_CLOSE_CONN seconds to ensure robust operation, even when the
initiating agent which
opened a connection neglects to close it. See Section 13 14 for timing
rules.

6.2.1.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 12]

Internet Draft Service Location Protocol, Version 2 16 July 1998

6.3. Retransmission of multicast SLP messages

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

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

When SLP SrvRqst, SrvTypeRqst, and AttrRqst messages are multicast,
they contain a <PRList> of previous responders. In those cases, Initially the
<PRList> is empty. 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.
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.'

Any DA or SA which sees its address in the <PRList> MUST NOT respond
to the request.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 10]

Internet Draft Service Location Protocol 4 May 1998

6.3.

UAs which retransmit a request use the same XID. This allows a DA or
SA to cache its reply to the original request and then send it again,
should a duplicate request arrive. This cached information should
only be held very briefly. XIDs SHOULD be randomly chosen to avoid
duplicate XIDs in requests if UAs restart frequently.

6.4. Strings in SLP messages

All strings are encoded using UTF8 [22] and are NOT null terminated
when transmitted.

The escape character is a backslash (ASCII (UTF8 0x5c) followed by the
two hexadecimal digits of the escaped character. Only reserved
characters are escaped. For example, a comma (ASCII (UTF8 0x29) is escaped
as `\29'. `\29', and a backslash `\' is escaped as `\5c'. String lists used
in SLP define the comma to be the delimiter between list elements 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 ASCII 0x00-0x7F subrange of UTF8: It UTF8 (which corresponds
to ASCII character encoding) Case insensitivity SHOULD be supported
throughout the entire UTF8 encoded Unicode [6] character set.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 13]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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 the character set of the
registration, UTF8 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.

7. Required SLP Messages

SLP messages have Errors

If the Error Code in a binary format 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 begin with a header.

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 the error code, except
possibly for some optional extensions to clarify the error, for
example as in section 13.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 a
cryptographic algorithm or key generation it cannot support.
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.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 14]

Internet Draft Service Location Protocol, Version 2 16 July 1998

MSG_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst
and does not support it.

8. Required SLP Messages

SLP messages all begin with the following header:

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Function-ID | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length, contd.|O|U|A|F|R| rsvd| contd.|O|F|R| rsvd | Language Tag Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Option Extension Offset | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\
| Language Tag (String using the ASCII subset of UTF8 encoding) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Message Type Abbreviation Function-ID

Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 11]

Internet Draft Service Location Protocol 4 May 1998
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. URLSIG (0x40) is set by
a SA when it registers a signed URL with a DA or a signed URL
is passed in a SrvRply to a UA. ATTRSIG (0x20) is set by a SA
when signed attributes are registered with a DA. FRESH (0x10) is set on
every new SrvReg. REQUEST MCAST (0x08) is set when multicasting
or broadcasting requests. Rsvd bits MUST be 0.
- Lang Tag Length indicates the length of the Language Tag field.
- Next Option Extension Offset is set to 0 unless extension options extensions are used.
See Section 9.1 for how to interpret unrecognized options.
The first extension begins at 'offset' bytes, from the message's
beginning, after the SLP message data. See Section 9.1 for how
to interpret unrecognized options.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 15]

Internet Draft Service Location Protocol, Version 2 16 July 1998

- XID is set to a unique value for each unique request. If the
request is retransmitted, the same XID is used. Replies set
the XID to the same value as the xid in the request. Only
unsolicited DAAdverts are sent with an XID of 0.
- Language Tag conforms to [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].

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 12]

Internet Draft Service Location Protocol 4 May 1998

7.1.

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

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

<PRList> is the Previous Responder List. This <string-list>
contains either fully qualified domain names or dotted decimal
notation IP (v4) addresses, and is iteratively multicast to obtain
all possible results (see Section 6.2.1). 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 silently which include
the SA's address in the <PRList>. Once a Previous Responder list <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,Perkins,Veizades,Day Expires 16 January 1999 [Page 16]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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 describe 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 7.5.) If
set to "service:service-agent", SAs respond with a SAAdvert (see
Section 7.6.)

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 13]

Internet Draft Service Location Protocol 4 May 1998 Section 8.5.) If
set to "service:service-agent", SAs respond with a SAAdvert (see
Section 8.6.)

The <predicate> is a LDAPv3 search filter [15]. [16]. This field may be
omitted if services are to be discovered simply by type and scope.
Otherwise, services are discovered which satisfy the included search
filter. <predicate>.
If the filter is present, it is applied compared to each registered service. If the
attribute in the filter has been registered with multiple values, the
filter is applied compared to each value and the result
is results are ORed together,
i.e., "(x=3)" matches a registration of (x=1,2,3);
"(Y!=0)" "(!(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
satisfied, because of the 'or'. `|' (boolean disjunction).

Wildcard matching can ONLY 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 and Integer; Strings don't match Integers.

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

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

<t>=service:pop3 <s>=SALES,DEFAULT ="(user=wump)" =(user=wump)
This is a request for all pop3 services available in
the SALES or DEFAULT scope which serve mail to the user
`wump'.

<t>=service:backup <s>=BLDG 32 ="(&(q<=3)(speed>=1000))" =(&(q<=3)(speed>=1000))
This returns the backup service which has a queue length

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 17]

Internet Draft Service Location Protocol, Version 2 16 July 1998

less than 3 and a speed greater than 1000. It will
return this only for services registered with the BLDG 32
scope.

DAs are discovered by sending a SrvRqst with the service
type set to "service:directory-agent" and the "service:directory-agent". If a predicate
omitted. The scope list is
included in the SrvRqst, the DA SHOULD respond only if
the predicate can be set to satisfied with the DA's attributes.
The <scope-list> SHOULD contain all scopes configured
scope list of
for the service. (OPTIONALLY the scope list
may be If omitted, see Section 11.2.) 11.2. For
example:

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 14]

Internet Draft Service Location Protocol 4 May 1998

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

7.2.

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 a list of one or more URL entries (see Section 4.2)
which 4.3)
that satisfy a SrvRqst. If the reply overflows, the UA MAY
simply use the first URL Entry in the list. A URL obtained by
SLP may not be cached longer than Lifetime seconds, unless there
is a URL Authenticator block present. In that case, the cache
lifetime is indicated by the Timestamp in the URL Authenticator
(see Section 9.2). One authentication block is returned for each
protected scope the service was registered in which was present in
the <scope-list> of the SrvRqst.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 18]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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 as defined in (see section 4.2. 4.3). The Lifetime defines
how long a DA can maintain cache the registration. SAs SHOULD reregister with DAs
before this lifetime expires (but no SHOULD NOT more often

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 15]

Internet Draft Service Location Protocol 4 May 1998 than once every CONFIG_REG_SPEED seconds).
per second). The Lifetime can MAY be set to the any value between 0 and
0xffff (maximum, around 18 hours) and simply reregistered in
response to a DAAdvert. This has the disadvantage that hours). Long-lived registrations remain
stale longer if the SA or
the service fails, fails and the stale registration will be cached longer. SA does not deregister the
service.

The <service-type> defines the service type of the URL to be
registered. This field is authoritative over the URL for the
purposes
registered, regardless of registration: It MAY differ from the service type scheme of the
URL registered. URL. The <scope-list>
MUST be set to contain the configured Scope list names of all scopes configured for the SA. The
default value is "DEFAULT'' "DEFAULT" (see Section 11). The <attr-list>, if
present, specifies the attributes and values to be associated with
the URL by the DA (see Section 5).

If the registration occurs in a protected scope, the ATTRSIG flag is
set in the header, and an Attr Authentication
block (see Section 9.2) is transmitted included for each protected scope,
for each protected scope the service is registered
in. This Key Generation Number supported. It is calculated over <ATTRS LENGTH, ATTRS, TIMESTAMP, LENGTH
OF SCOPE STRING, SCOPE STRING>. Note that signatures are case and
order sensitive. DSA Authentication blocks MUST be included, if any
are, though others may be sent in addition.

The FRESH flag is set in
the SrvReg header unless ordered tuple (16-bit length of <attr-list>, <attr-list>,
timestamp, 16-bit length of scope string, scope string), where the 'Update'
optimization
timestamp is being used (see Section 9.5). The taken from the Authentication block.

A registration with the FRESH flag set will replace *entirely* any
previous registration for the same URL in the same language.

7.4. If
the FRESH flag is not set, the registration is an "incremental"
registration (see Section 9.4).

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 19]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 16]

Internet Draft Service Location Protocol 4 May 1998

7.5. 7).

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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DA Stateless boot Boot Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL | URL \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ authentication
| # Auth Blocks | Authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DAs respond with DAAdverts only to SrvRqsts with the MCAST RQST
flag set with
DAAdverts. set. The scope list <scope-list> of the SrvRqst must either be omitted
or include a scope which the DA supports. Error codes are never
returned. The DA Stateless boot Boot
Timestamp indicates the state of the DA (see section 12.2.2).

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

The DAAdvert MAY contain a URL authenticator, which will be generated
using a DA Advertising private key. This authenticator is calculated
over the following fields: <DA STATELESS BOOT TIMESTAMP, LENGTH
OF ordered tuple: (DA Stateless Boot Timestamp,
Length of URL, URL, LENGTH OF SCOPE LIST, SCOPE LIST, AUTHENTICATOR
TIMESTAMP>. Length of <scope-list>, <scope-list>,
Timestamp), where the Timestamp is taken from the Authentication
block. The protected scope field Protected Scope String of the authentication block is
omitted in a DAAdvert. DAAdvert (i.e., the Protected Scope String Length is
zero). The Authenticator Timestamp is set to the time when the
DAAdvert expires (may no longer be cached). Note that
signatures

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 20]

Internet Draft Service Location Protocol, Version 2 16 July 1998

If multiple Key Generation Numbers are case and order sensitive. supported for DAAdvert
authenication, the DA MUST include one Authentication Block for each
generation number. See Section 9.2.

UAs SHOULD be configured with DA Advertisement public keys so they
can verify the authenticity of DAAdverts. If the UA can verify
DAAdverts, and detects a
authentication failure of the DAAdvert fails to be verified, DAAdvert, the UA MUST discard it.

7.6.

8.6. Service Agent Advertisement

UAs

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 17]

Internet Draft Service Location Protocol 4 May 1998 allows UAs without scope configuration
to make use of either DAs or SAs without any functional difference
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> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # auth blocks | authentication block (if any) \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

The URL is "service:service-agent://''<addr> of the DA, where
<addr> "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 URL Authentication block for each protected
scope the SA supports, for every Key Generation Number the SA

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 21]

Internet Draft Service Location Protocol, Version 2 16 July 1998

supports. If the UA can verify the protected scope 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.

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 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Data \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The offset to next extension is 0 if there are no extensions
following or is set to the dotted decimal numeric address of the DA. The
<scope-list> length of the DA MUST NOT be null.

The SAAdvert contains a URL authenticator, one for each protected
scope the SA supports. If the UA can verify the protected scope
SAAdvert, and the SAAdvert fails to be verified, the UA MUST discard
it.

8. Errors current Extension Data.
If the Error Code in a SLP reply message offset is nonzero, 0, the rest length 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.

Errors are only returned for unicast requests. Requests which are
multicast are dropped if they result in an error.

LANGUAGE_NOT_SUPPORTED = 1: There current Extension Data is data for the service type in
the scope in
determined implicitly by use of the AttrRqst or SrvRqst, but not in total length of the requested
language.
PARSE_ERROR = 2: The message fails to obey SLP syntax.
INVALID_REGISTRATION = 3: The SrvReg has problems i.e., a 0 lifetime,
an omitted language tag, etc.
SCOPE_NOT_SUPPORTED = 4: The SLP message did not include a scope in
its scope list the SA or DA was configured to use.
AUTHENTICATION_ABSENT = 6: The DA expects URL and ATTR authentication
as given in the SrvReg and did not receive it.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 18]

Internet Draft Service Location Protocol 4 May 1998

AUTHENTICATION_FAILED = 7: The DA determines the URL or ATTR
signature SLP message header.

Extension IDs are assigned in the SrvReg came out bad
VER_NOT_SUPPORTED = 9: Ver was set following way:

0x0000-0x3FFF Standardized. Optional to an unsupported version number.
INTERNAL_ERROR = 10: The DA (or SA) is too sick implement. Ignore if
unrecognized.
0x4000-0x7FFF Standardized. Mandatory to respond.
DA_BUSY_NOW = 11: implement. A UA or SA SHOULD retry, using exponential back off.
OPTION_NOT_UNDERSTOOD = 12: The DA (or SA) received an Option from
the Mandatory range
which is receives this option in a reply and does not understood.
INVALID_UPDATE = 13: The understand
it MUST silently discard the reply. A DA received a SrvReg without FRESH set, for
an unregistered service. See Section 9.5.
RQST_NOT_SUPPORTED = 14: The SA received an AttrRqst or SrvTypeRqst SA which receives
this option in a request and does not support it.

9. understand it MUST return
an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF For private use (not standardized). Optional Features

The features described to
implement. Ignore if unrecognized.
0x9000-0xFFFF Reserved.

Extensions defined in this section are not mandatory. They document are
useful for interactive use of SLP (where a user rather than a program
will select services, using a browsing interface for example) and in Section 13. See
section 16 for
scalability of SLP to larger networks.

9.1. Service Location Protocol Extension Options

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

The format of a
extensions.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 22]

Internet Draft Service Location Extension Option is: Protocol, Version 2 16 July 1998

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Extension ID Block Structure Descriptor | Authentication Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Generation Number | Option Protected Scope String Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Extension Contents Protected Scope String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 Option Extension ID authentication data
(contained in the Structured Authentication Block) is defined typically
case sensitive. Even though SLP registration data (e.g., attribute
values) are typically are not case sensitive even for protected
scopes, the case of the registration data has to be preserved by a IETF Standards document which
also defines the contents
registering DA so that UAs will be able to verify the authentication
data.

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

The offset to next
option is 0 if there is no option following or Authentication Block Length is set to the length of the current Extension contents. entire block,
starting with the BSD.

The length Key Generation Number (KGN) identifies the 'generation' of the 'last option'
key associated with the Protected Scope string which follows. The
value 0 indicates KGNs are not being used and the values 1-255 are
reserved. KGNs need not be configured sequentially - they are simply
identifiers of keying material.

There may be several 'key generations' deployed in a network
simultaneously. This allows gradual rekeying of a network. For
example, a network is determined implicitly by summing keyed with keys for protected scope 'foo'
with KGN 1022. Later, SAs are rekeyed to also have KGN '1023'.
Eventually, when all UAs and DAs in the length parsed network are rekeyed with keys
with KGN '1023', SAs need no longer support KGN '1022' keys.

A SA which supports multiple KGNs for a protected scope MUST register
Authentication Blocks generated with each KGN with DAs. DAs and comparing
it to the total length of the message given in the SLP header.

Options Extension IDs are assigned SAs
MUST include authentication blocks in the following way: each KGN associated with a

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 19] 23]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

0x0000-0x3FFF Standardized. Optional to implement. Ignore if
unrecognized.
0x4000-0x7FFF Standardized. Mandatory to implement. A

protected scope unless the UA or SA which receives this option in a reply and does not understand
it MUST silently discard initiated the reply. A DA or SA which receives
this option in a request and does not understand it MUST return
an OPTION_NOT_UNDERSTOOD error.
0x8000-0x8FFF NOT Standardized, for private use. Optional to
implement. Ignore if unrecognized.
0x9000-0xFFFF Reserved: Do not use.

Options defined in this document includes a
Cryptographic Request Option specifying a particular KGN.

Note that many SLP messages are in Section 14.

9.2. sent using UDP datagrams. These have
a limited payload so few Authentication Blocks

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Block Structure Descriptor | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protected Scope String Length | Protected Scope String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ Structured Authentication Block ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Authentication blocks are returned with certain will fit into a SLP data to verify
that the contents have not been modified.
message. For this reason, as few Key Generations as possible should
be supported simultaneously: Ideally only ONE should be used except
during transitions.

The Block Structure Descriptor (BSD) Protected scope string identifies the format of the
Authenticator which follows. BSDs 0x0000-0x7FFF will keying material to be identified
used by IANA. BSDs 0x8000-0x8FFF are for private use. agents to verify the signature data in the Structured
Authentication Block.

The Timestamp is the time that the service reply authenticator expires (to
prevent replay attacks.) The Timestamp is a 32-bit unsigned
fixed-point number of seconds relative to 0h on 1 January 1900, in SNTP
NTP format [18]. [19]. SAs and DAs MAY use this value to indicate how
long they expect the service to be available for (for instance, in
DAAdverts and SAAdverts).

All SLP agents MUST implement DSA [19] [21] (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.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 20]

Internet Draft Service Location Protocol 4 May 1998

9.2.1. MD5 with RSA in Authentication Blocks

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

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

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 24]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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

9.2.3. Keyed HMAC with MD5 in Authentication Blocks

BSD=0x0003 is defined to be HMAC [16] [17] using keyed-MD5 [20].

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 21]

Internet Draft Service Location Protocol 4 May 1998 [22].

Given a secret key K and the data to authenticate, the Authentication
Block is computed as follows:
1. opad := 0x36363636363636363636363636363636 (128 bits)
2. ipad := 0x5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C5C (128 bits)
3. zero_extended_key := K extended by zeroes to be 128 bits long
4. opadded_key := zero_extended_key XOR opad
5. ipadded_key := zero_extended_key XOR ipad
6. HMAC_result := MD5 (opadded_key , MD5 (ipadded_key, data))

The authenticator is the 128-bit value HMAC_result.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 25]

Internet Draft Service Location Protocol, Version 2 16 July 1998

9.3. Authentication of a SrvRply

Each SA MUST sign the

A SrvRply if it is responding to containing a SrvRqst made
to URL from a service in a protected scope, adding scope MUST
include an Authentication Block containing the
signature. for each protected scope. The authentication
Authentication data MUST be calculated over the following data: <LENGTH OF ordered
tuple: (Length of URL, URL, TIMESTAMP, LENGTH OF SCOPE
STRING, SCOPE STRING>. Timestamp, 16-bit Length of Scope
String, Scope String). The BSD auth bytes are Authentication block is calculated
according to the algorithm indicated by the BSD value. Note that signatures
are case sensitive, so implementations must transmit URLs in the same
case as used to calculate the signature.

9.4. Optimizations with XIDs

UAs which retransmit a request use value using the same XID. This allows a DA or
SA to cache its reply to
cryptographic key identified by the original request and then send it again,
should a duplicate request arrive. This cached information should
only be held very briefly. XIDs SHOULD be randomly chosen to avoid
duplicate XIDs protected scope string and Key
Generation Number in requests if UAs restart frequently.

9.5. the Authentication Block.

9.4. Incremental Service Registration Updates

Registrations of

Incremental registrations update attribute values for a previously
registered service. Incrmental service are considered an
update. Partial updates of service registration registrations are useful when
only a single attribute has changed, for instance. In an update, incremental
registration, the FRESH flag in the SrvReg header is NOT set.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 22]

Internet Draft Service Location Protocol 4 May 1998

The new registration's attributes replace the previous
registration's, but do not affect attributes which were
included previously and are not present in the update.

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

Updates

Incremental registrations MUST NOT be performed for services
registered in protected scopes. These must be registered with ALL
attributes, with the
"FRESH" FRESH flag in the SrvReg header set. DAs which
receive such update registration messages return an AUTHENTICATION_FAILED
error.

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

If the update includes a scope list other than the one in the
prior registration, the DA returns a SCOPE_NOT_SUPPORTED error. In
order to change the scope of a service advertisement it must be
deregistered first and reregistered in a new scope.

9.6. Naming Authorities

A Naming Authority MAY optionally be included as part of the Service
Type string, see Section 4.1. The Naming Authority of a service
defines the meaning of the Service Types and attributes registered
with and provided by Service Location. The Naming Authority itself
is typically a string which uniquely identifies an organization.
IANA is the implied Naming Authority when no string FRESH flag 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 not 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 DA does not have a prior
registration and queries, as described for the service, the incremental registration fails with
error code INVALID_UPDATE.

If the update includes a <scope-list> other than the one in
Sections 7.1 and 7.3. Service Types SHOULD the
prior registration, the DA returns a SCOPE_NOT_SUPPORTED error. In
order to change the scope of a service advertisement it MUST be registered
deregistered first and reregistered with IANA
to allow for Internet-wide interoperability.

9.7. a new <scope-list>.

9.5. Tag Lists

Tag lists are used in SrvDeReg and AttrReq messages. The syntax of a
<tag-list> item is:

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 23] 26]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

tag-filter = simple-tag / substring
simple-tag = 1*filt-char
substring = [initial] any [final]
initial = 1*filt-char
any = `*' *(filt-char `*')
final = 1*filt-char
filt-char = Any character excluding <reserved> and <bad-tag> (see
grammar in Section 5).

Wild card characters in a <tag-list> item match arbitrary sequences
of characters. For instance "*bob*" matches "some bob I know",
"bigbob", "bobby" and "bob".

10. Optional SLP Messages

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

10.1. Service Type Request

The Service Type Request (SrvTypeRqst) allows a UA to discover all
types of service on a network. This is useful for general purpose
service browsers.

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 | <Naming Authority String> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <PRList> list and <scope-list> are interpreted as in
Section 7.1. 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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 24]

Internet Draft Service Location Protocol 4 May 1998
omitted and ALL Service Types are returned, regardless of Naming
Authority.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 27]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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 | length of SrvType <string-list>| <srvType-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SrvType <string-list> <srvtype--list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Type

The service-type Strings (as described in Section 4.1) are provided
in <srvtype-list>, which is a <string-list>.

If the 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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 25]

Internet Draft Service Location Protocol 4 May 1998 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.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 28]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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
service of the specified URL is defined are returned.

The <tag-list> field is a string list <string-list> of attribute tags, as
defined in Section 9.7 9.5 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 are requested in a protected scope from a
DA, otherwise the DA will reply with an AUTHENTICATION_FAILED error.

10.4. Attribute Reply

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = AttrRply = 7) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\
| <attr-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Auth Blocks |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
\ (if |(if present) Attribute Authentication Blocks... \ Blocks...\
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

Attribute replies SHOULD be returned with the original case of the
string registration intact, as they are likely to be human readable.
In the case where the AttrRqst was by service type, all attributes
defined for the service type, and all their values are returned.

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

One Attribute Authentication Block is returned for each protected
scope in the <scope-list>, for each Key Generation number supported.
Note that the <attr-list> returned from a DA in a protected scope
MUST be identical to the <attr-list> registered by a SA, in order
for the Attr Authenticator to be successful.

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 26] 29]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

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 = Entwicklung
Lang. Tag = de
Attributes = (Name=Igore),(Beschreibung=Nur fuer Entwickler),
(Protocol=LPR),(Standort-beschreibung=13te Etage),
(Techniker=James Dornan \3cdornan@monster\3e),
(Format=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.

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

The attribute Request:

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

receives the Attribute Reply:

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

The attribute Request:

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 27] 30]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

URL = service:printer
scope-list = Development
Lang. Tag = en
tag-list = x-*,resolution,protocols 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".

10.6. Service Deregistration

A service which is registered will time out at the 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 = 5) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length Length of Scope <string-list> | Scope <string-list> <scope-list> | <scope-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| URL Entry | \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length Length of <tag-list> string | <tag-list> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The scope list <scope-list> is a <string-list> of scopes. (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, it can assume that the service is 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.

If the URL deregistered has not been registered with the DA in the scope specified
in the SrvDeReg message, an INVALID_REGISTRATION error is returned.
The lifetime Lifetime field in the URLEntry field URL Entry is ignored for the purposes of
the SrvDeReg.

The <tag-list> is a <string-list> of attribute tags to deregister
as defined in Section 9.7. 9.5. If no <tag-list> is present, the
SrvDeReg deregisters the service in all languages it has been

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 28] 31]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

registered in. If the <tag-list> is present, the SrvDeReg
deregisters the attributes whose tags are listed in the tag
spec. Services registered in protected scopes MUST NOT include
a <tag-list> in a SrvDeReg message: A DA will respond with an
AUTHENTICATION_FAILED error in this case.

If the service to be deregistered was registered in a protected
scope, a URL authentication block for that protected scope must and Key
Generation Number MUST be included. Otherwise, the DA returns an
AUTHENTICATION_ABSENT error is returned. If the message fails to be
verified by the DA, an AUTHENTICATION_FAILED error is returned by the
DA.

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.

Scopes strings are case insensitive. The default SCOPE string is
"DEFAULT".

11.1. Scope Rules

SLP messages which fail to contain the 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 AttrRqst, SrvTypeRqst, DAAdvert, SAAdvert, SrvReg and SrvRqst (except for DA and SA discovery requests) requests), SrvReg,
AttrRqst, SrvTypeRqst, DAAdvert, and SAAdvert message MUST include a
scope list.
<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,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 29] 32]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

11.2. Administrative and User Configurable Selectable Scopes

All requests and services are scoped. The two exceptions are
SrvRqsts for "service:directory-agent" and "service:service-agent".
These MAY exclude a scope list in the request but are only used to
support the 'USER SELECTABLE SCOPE' model.

There are two possible ways to configure SAs and UAs with scope
strings:

DEFAULT
The scope "DEFAULT" is used.

ADMINISTRATIVE
UAs and SAs are configured with lists of scopes to use by
system administrators. If this is the case, UA requests
will specify some or all of these scopes and services
registered by SAs will specify all of these scopes. The
user MUST NOT be presented with other scopes than the
preconfigured ones.

Administrative scoping allows services to be provisioned, so that
users will only see services they are intended have a zero-length <scope-list> when used to see.

Additionally, it is possible enable the
user to explicitely configure UAs with no make scope list at all. selections. In this case UAs obtain their scope
list from DAAdverts (or if DAs are not available, from SAAdverts.) This allows

Otherwise, if SAs and UAs are to use any scope other than the user default
(i.e., "DEFAULT"), the UAs and SAs are configured with lists of
scopes to select his use by system administrators, perhaps automatically by way
of DHCP option 78 or her own scope. 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 [14] and LanManager [25] networking allow user
selection of AppleTalk Zone or Windows 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).

11.3. Protected Scopes

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 30]

Internet Draft Service Location Protocol 4 May 1998 with a
possibly large collection of UAs.

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

12. Directory Agents

DAs cache service location and attribute information. They exist to
enhance the performance and upward scalability of SLP. Multiple DAs
may provide
further scalability and robustness of operation. The DAs operation, since they can each
store replicated service information which remains available even
when for the same SAs, in case one of the DAs
fails.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 33]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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

Passive detection of DAs by 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 enables services to possible.

UAs be advertised
consistently among DAs of prepared for the same scope. Invalid advertisements age
out, leaving only transient stale registrations in DAs, even in possibility that the
case of a failure of a SA. service information they
obtain from DAs is stale.

12.1. Directory Agent Rules

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

Furthermore,

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

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

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

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 31]

Internet Draft Service Location Protocol 4 May 1998

DAAdverts MUST include DA Stateless boot Boot Timestamp, in the same
format as the Authentication Block, see Block (see Section 9.2. If the DA comes
up stateless, this is the current time. If 9.2). The Timestamp
in the DA keeps service
advertisements between boots, this timestamp Authentication Block indicates the time at which all previous
registrations were lost (i.e., the last stateless reboot. This timestamp reboot). The
Timestamp is set to 0 in a DAAdvert to notify UAs and SAs that the DA
is going down.

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 send an initial and periodic unsolicited DAAdvert messages.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 34]

Internet Draft Service Location Protocol, Version 2 16 July 1998

12.2. Directory Agent Discovery

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

See Section 6 which describes regarding unsolicited DAAdverts and how SAs
respond to them. DAAdverts. Section 12.2.2 includes an optimization which
describes how SAs may use to minimize reduce the number of times they must reregister
with
DAs.

SAs MUST listen for DAAdverts, passively, as described DAs in
Section 7.5. UAs SHOULD do this. 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 SHOULD do this.

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

The following sections describe suggested suggest timing algorithms which
allow SLP to scale to larger deployments. enhance the
scalability of SLP.

12.2.1. Active DA Discovery

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 32]

Internet Draft Service Location Protocol 4 May 1998

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

SAs which discover DAs actively SrvRqsts for Active DA Discovery SHOULD NOT
be sent more than once per CONFIG_DA_FIND seconds.

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 35]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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: CONFIG_REG_PASSIVE. registration.

12.3. Reliable Unicast to DAs

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

12.4. DA Scope Configuration

By default, DAs are configured with the "DEFAULT" scope, by default. scope.
Administrators may add other configured scopes, in order to support
UAs and SAs in non default scopes. The default configuration SHOULD 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.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 33]

Internet Draft Service Location Protocol 4 May 1998

Non-default scopes should can be phased-in as the SLP deployment grows.
Default scopes should be phased out only when the non-default scopes
are well deployed. 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 with protected scope private keys. This means
they will not be able to sign URLs and Attribute lists, <attr-list>s, but only cache
them for SAs, forwarding them to UAs. Consequently, in a protected
scope the DA will not accept: SrvReg without the FRESH flag set or
AttrRqst or SrvDeReg with a <tag-list> included. In these cases an
AUTHENTICATION_FAILED error is returned.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 34] 36]

Internet Draft Service Location Protocol 4 May 1998

13. Protocol Timing Defaults

Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_MC_RETRY 6.2.1 each second, Retry multicast query
backing off until no new values
gradually arrive.
CONFIG_MC_MAX 6.2.1 15 seconds Max time to wait for a
complete multicast query
response (all values.)
CONFIG_START_WAIT 12.2.1 3 seconds Wait to perform DA
discovery on reboot.
CONFIG_DA_RETRY 12.3 2 seconds Retransmit DA discovery,
try it 3 times.
CONFIG_DA_MAX 12.3 6 seconds Give up on requests sent
to a DA.
CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
before repeating Active
DA discovery.
CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_REG_ACTIVE 7.3 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_CLOSE_CONN 6.2 5 minutes DAs and SAs close idle
connections.

14. Protocol, Version 2 16 July 1998

13. SLP Protocol Extensions

14.1.

13.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 [14]. [15].

If a SA or DA receives a SrvRqst or a SrvReg which fails to include
an attribute which is required
a Required Attribute for the requested Service Type, Type (according
to the service template), it

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 35]

Internet Draft Service Location Protocol 4 May 1998

returns 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> may not MUST NOT include wild cards.

14.2.

13.2. Cryptographic Algorithm Request Option

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

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extension Type = 0x0002 | Extension Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Desired BSD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Key Generation Number(optional)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 37]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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

If it
supports a Key Generation Number is included, the extension host receiving the
request MUST reply with an Authentication Block which uses the key
with the requested Key Generation Number (see Section 9.2). To omit
a Key Generation Number in the Cryptographic Request Option, the Key
Generation Number field is set to 0.

If the SA or DA supports this option and receives a multicast request
for a Key Generation Number or a cryptographic algorithm it does not
support, it returns an AUTHENTICATION_UNKNOWN error.

14. Protocol Timing Defaults

Interval name Section Default Value Meaning
------------------- ------- ------------- ------------------------
CONFIG_MC_RETRY 6.3 each second, Retry multicast query
backing off until no new values
gradually arrive.
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_DA_RETRY 12.3 2 seconds Retransmit DA discovery,
try it 3 times.
CONFIG_DA_MAX 12.3 6 seconds Give up on requests sent
to a DA.
CONFIG_DA_BEAT 12.2.2 3 hours DA Heartbeat, so that SAs
passively detect new DAs.
CONFIG_DA_FIND 12.3 900 seconds Minimum interval to wait
before repeating Active
DA discovery.
CONFIG_REG_PASSIVE 12.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_REG_ACTIVE 8.3 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_CLOSE_CONN 6.2 5 minutes DAs and the algorithm identified by BSD it will
return an authentication block using the desired algorithm. SAs close idle
connections.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 38]

Internet Draft Service Location Protocol, Version 2 16 July 1998

15. Optional Configuration

BROADCAST ONLY
An

Broadcast Only
Any SLP Agent agent SHOULD be configurable to use broadcast
only. See Sections 6.1 and 12.2.

PREDEFINED

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

No DA DISCOVERY Discovery
The UA or SA SHOULD be configurable to ONLY use

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 36]

Internet Draft Service Location Protocol 4 May 1998
predefined and DHCP-configured DAs and perform no active
or passive DA discovery.

MULTICAST

Multicast TTL
The default multicast TTL is 32. 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.

ENHANCED TIMING
Non default time

Timing Values
Time values other than the default MAY be configurable.
See Section 13.

SCOPES 14.

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.

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

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
<scope-list> MUST be used in registration and DA
configuration messages.

SERVICE TEMPLATE

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 39]

Internet Draft Service Location Protocol, Version 2 16 July 1998

Service Template
UAs and SAs MAY be configured with 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.

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 37]

Internet Draft Service Location Protocol 4 May 1998

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

16. IANA Considerations

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

- The data format of the Structured Authenticator block.

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

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

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

The IANA will assign BSD approach.

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

New function-IDs, in the range 12-255, may be standardized by the
method of IETF Consensus [20]. Similarly, new extensions with types
in the range 3-65535 may be standardized by the method of IETF
Consensus. Specification and Expert Review is required for the
assignment of new error numbers (from in the range 0x0003 to 0x7FFF) on of 15-65535.

Protocol elements used with Service Location Protocol may also
require IANA registration actions. SLP is used in conjunction with
"service:" URLs and service templates [15]. These are standardized
by the method of a first come, first served basis. Designated Expert and a mailing list (see [15].)

17. Internationalization Considerations

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

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

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 40]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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
[14]
[15] 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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 38]

Internet Draft Service Location Protocol 4 May 1998
advertisement (say in English) and then translate the reply back to
Italian. Similarly, a UA MAY use templates to translate outgoing
requests and incoming replies.

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

18. Security Considerations

SLP provides for authentication of service URLs and service
attributes. This provides UAs and DAs with knowledge of the
integrity of service URLs and attributes included in SLP messages.
The only systems which can generate digital signatures are those
which have been configured by administrators in advance. Agents
which verify signed data may assume it is 'trustworthy' in as much 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.

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

Service Location is useful as a bootstrap protocol. It may be used

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 41]

Internet Draft Service Location Protocol, Version 2 16 July 1998

in environments in which no preconfiguration is possible. In such
situations, a certain amount of "blind faith" is required: Without
any prior configuration it is impossible to use any of the security
mechanisms described above. Service Location will make use of
the mechanisms provided by the Security Area of the IETF for key
distribution as they become available. At this point it would only
be possible to gain the benefits associated with the use of protected

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 39]

Internet Draft Service Location Protocol 4 May 1998
scopes if some cryptographic information can be preconfigured with
the end systems before they use Service Location.

19. Acknowledgments

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

20. Full Copyright Statement

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

References

[1] Port numbers, July 1997.
ftp://ftp.isi.edu/in-notes/iana/assignments/port-numbers.

Guttman,Perkins,Veizades,Day Expires 16 January 1999 [Page 42]

Internet Draft Service Location Protocol, Version 2 16 July 1998

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

Guttman,Perkins,Veizades,Day Expires 4 November 1998 [Page 40]

Internet Draft Service Location Protocol 4 May 1998

[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 #4. The unicode standard, version 2.0.
Technical Report ISBN 0-201-48345-9, The Unicode Consortium,
1996.

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

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

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

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

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

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

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

[14] S. Gursharan, R. Andrews, and A. Oppenheimer. Inside AppleTalk.
Addison-Wesley, 1990.

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

[15]

[16] T. Howes. The string representation String Representation of LDAP search filters.
draft-ietf-asid-ldapv3-filter-03.txt, October Search Filters.
RFC 2254, December 1997. (work in
progress).

[16]

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

[17] David Meyer. Administratively Scoped IP Multicast.
draft-ietf-mboned-admin-ip-space-04.txt, November 1997. (work
in progress).

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 41] 43]

Internet Draft Service Location Protocol 4 May Protocol, Version 2 16 July 1998

[18] D. David Meyer. Administratively Scoped IP Multicast. RFC 2635,
July 1998.

[19] David L. Mills. Simple Network Time Protocol (SNTP) Version 4 for
IPv4, IPv6 (Version 3):
Specification, Implementation and OSI. Analysis. RFC 2030, October 1996.

[19] 1305, March
1992.

[20] Thomas Narten and Harald Tveit Alvestrand. Guidelines
for Writing an IANA Considerations Section in RFCs.
draft-iesg-iana-considerations-04.txt, May 1998. (work in
progress).

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

[20]

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

[21]

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

[22]

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

[25] Microsoft Networks, SMB File Sharing Protocol Extensions 3.0,
Document Version 1.09, November, 1989.

Authors' Addresses

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

Phone: +49 7263 911701 911 701 +1 650 786 6464
Fax: +1 650 786 6445
Email: Erik.Guttman@sun.com cperkins@sun.com

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

Phone: +1 650 569 5243 +1 801 763 2341
Fax: +1 801 756 8349
Email: veizades@home.net Michael_Day@ccm.ut.intel.com Michael.David.Day@worldnet.att.net

Guttman,Perkins,Veizades,Day Expires 4 November 1998 16 January 1999 [Page 42] 44]

----