WDIFF

draft-ietf-svrloc-protocol-12.txt --> draft-ietf-svrloc-protocol-13.txt

draft-ietf-svrloc-protocol-12.txt

Internet Engineering Task Force John Veizades
INTERNET-DRAFT TGV, Inc.
INTERNET DRAFT @Home Network
10 June 1996 Erik Guttman
Sun Microsystems
Charles Perkins
IBM Research
Scott Kaplan
March 11, 1996

Service Location Protocol

1.0
draft-ietf-svrloc-protocol-13.txt

Status of this memo This Memo

This draft document is a product of the IETF Service Location Working Group;
Group of the Internet Engineering Task Force (IETF); it will be
submitted to the RFC editor as a standards document. Please respond
with comments to the srvloc@tgv.com 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. Internet-Drafts months
and may be updated, replaced, or obsoleted by other documents at
any time. It is not appropriate inappropriate to use Internet-Drafts as reference
material or to cite them other than as
a "working draft" or "work ``work in progress." progress.''

To learn the current status of any Internet-Draft, please check
the
1id-abstracts.txt ``1id-abstracts.txt'' listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
munnari.oz.au.

2.0
ftp.isi.edu (US West Coast).

Abstract

The service location Service Location protocol provides a scalable framework for
the discovery and selection of network services. It relies on multicast support
at the network layer of the protocol stack it is using. It does not
specifically rely upon the TCP/IP protocol stack but makes use of
concepts that are found in most TCP/IP protocol implementations.

Traditionally, users find services Using this
protocol, computers using the name Internet no longer need so much static
configuration of a network host
(a human readable text string) which is an alias services for a network
address. The service location protocol eliminates the need for a
user based applications.
This is especially important as computers become more portable, and
users less tolerant or able to know the name of a network host supporting a service.
Rather, fulfill the user supplies a set demands of attributes which describe the
service. The service location protocol allows the user to bind this
description to the network address of the service.

Service Location provides a dynamic configuration mechanism for
applications in a tightly coupled set of local area networks. It is
not a global resolution system for the entire Internet, rather it is
intended to serve institutional networks with shared services.

Service Location WG
administration.

Veizades,Guttman,Perkins,Kaplan Expires August 21, 10 December 1996 [Page 1]

INTERNET-DRAFT i]

Internet Draft Service Location Protocol March-96

Table of 10 June 1996

Contents

1.0

Status of this memo..............................................1
2.0 Abstract.........................................................1
3.0 This Memo i

Abstract i

1. Recent Changes 2

2. Introduction 5

3. Terminology 5
3.1. Notation Conventions.............................................3
4.0 Terminology......................................................3
5.0 Protocol Overview................................................5
5.1 Protocol Transactions........................................5
5.2 Conventions . . . . . . . . . . . . . . . . . . 6
3.2. Service Information and Predicate Representation.........................7
5.3 Additional Notes.............................................7
5.3.1 The 'service:' URL scheme.............................7
5.3.2 Interpretation of Service Location Replies............7
5.3.3 Use of TCP and Multicast in Service Location..........7
5.3.4 Multilingual Support..................................7
5.3.5 Standard Attribute Definitions........................8
5.3.6 Naming Authority......................................8
5.3.7 No Synchronous Assumption.............................9
5.4 Service Location PDU header..................................9
5.4.1 Version...............................................9
5.4.2 Functions.............................................9
5.4.3 Length................................................9
5.4.4 Error Codes...........................................9
5.4.5 Transaction Identifier (XID).........................10
5.4.6 Flags................................................10
5.4.7 Time To Live.........................................10
5.4.8 Character Encoding...................................10
5.4.9 Representation . . . . 7
3.3. Specification Language Code........................................10
5.5 Service Request and Reply...................................10
5.6 Directory Agent Discovery Request...........................13
5.7 Service Type Request........................................14
5.8 Attribute Request and . . . . . . . . . . . . . . . . . 7

4. Protocol Overview 8
4.1. Protocol Transactions . . . . . . . . . . . . . . . . . . 9
4.2. Schemes . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. The 'service:' URL scheme . . . . . . . . . . . 11
4.3. Standard Attribute Reply.......................15
5.9 Service Discovery Request...................................17
6.0 Directory Agents................................................18
6.1 Introduction................................................18
6.2 Directory Agent Discovery...................................18
6.3 Service Registration........................................20
6.4 Service Unregister..........................................22
6.5 SCOPE Discovery and Use.....................................23
6.6 Definitions . . . . . . . . . . . . . 11
4.4. Naming Authority . . . . . . . . . . . . . . . . . . . . 12
4.5. Interpretation of Service Location Scaling Replies . . . . . . . 12
4.6. Use of TCP, UDP and Operating Modes................24
7.0 Multicast in Service Location Connections....................................25
8.0 Security Considerations.........................................26
9.0 . . . . 13
4.6.1. Multicast vs. Broadcast.........................................26
9.1 Single Subnet...............................................26
9.2 Multiple Subnets............................................26
9.3 Service Multicast Address...................................26
10.0 Broadcast . . . . . . . . . . . . 13
4.7. Service Location in the Internet...............................27
11.0 Protocol Formats...............................................27
11.1 Fields Used in Scaling, and Multicast Operating Modes . 14

5. Service Location Packets....................27
11.1.1 Previous Responders' Address Specification..........27
11.1.2 General Message Format 15
5.1. Use of Transaction IDs (XIDs) . . . . . . . . . . . . . . 17
5.2. URL Entry Lifetime . . . . . . . . . . . . . . . . . . . 18

6. Service Request Predicate...........................28
11.1.3 Reply...............................................31
11.1.4 Service Registration Information....................31
11.1.5 Service Unregister Information......................31
11.1.6 Attribute List......................................31

Veizades, Kaplan, Guttman, Perkins [Page 2]

INTERNET-DRAFT Message Format 18
6.1. Service Location Protocol March-96

11.1.7 Service Type........................................32
11.2 ADDRESS SPECIFICATIONs in Service Location.................32
11.3 Attribute Value encoding rules.............................32
12.0 Implementation Requirements....................................33
13.0 Configuration Parameters and Defaults..........................35
13.1 Multicast vs. Broadcast....................................35
13.2 Multicast Radius...........................................35
13.3 Directory Agent Address....................................35
13.4 Request Usage . . . . . . . . . . . . . . . . . . 20
6.2. Directory Agent Scope Assignment...........................35
14.0 Interesting Constants..........................................35
15.0 Acknowledgments................................................36
16.0 References.....................................................36
17.0 Author's Addresses.............................................38
18.0 Document Expiration............................................38
Appendix A - Technical contents Discovery Request . . . . . . . . . . . . 21
6.3. Explanation of ISO 639:1988.....................39

3.0 Notation Conventions

<> Values set off in this manner are fully described in section
11.0.

In General, all definitions Terms of items in packets are described
in section 11.0.

| |
\ \ Packet layouts with this notation indicate a variable length
| | field.

4.0 Terminology

User Agent (UA) A process working on the user's behalf to
acquire service attributes and configuration.
The User Agent retrieves service information
from the Predicate Grammar . . . . . . . . 22
6.4. Service Agents or Directory Agents. Request Predicate Grammar . . . . . . . . . . . . 24
6.5. String Matching for Requests . . . . . . . . . . . . . . 25

7. Service Agent (SA) A process working on the behalf of one or more
services to advertise service attributes and
configuration. Reply Message Format 26

8. Service Application A process working on behalf of one or more
services to advertise service attributes and
configuration. Unlike an SA the application
will not directly respond to service queries
and will merely register with Directory Agents. Type Request Message Format 27

9. Service Information A collection of attributes and configuration
information associated with a single service.
The Type Reply Message Format 29

10. Service Agents advertise service
information for a collection of service
instances.

Veizades, Kaplan, Guttman, Perkins [Page 3]

INTERNET-DRAFT Registration Message Format 30

11. Service Acknowledgement Message Format 33

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page ii]

Internet Draft Service Location Protocol March-96 10 June 1996

12. Service The service is a process or system providing a
facility to the network. The goal of service
location is to provide sufficient information
to the user, via the User Agent, to find the
service. The service itself is accessed using
a communication mechanism external to the
the service location protocol. Deregister 34

13. Attribute Request Message Format 35

14. Attribute Reply Message Format 37

15. Directory Agent (DA) A process which collects information from
Service Advertisement Message Format 39

16. Directory Agents to provide a single repository
of service information in order to centralize
it for efficient access by User Agents. There
can only be one DA present per given host.

Service Type Each type of service has a unique Service Type
string. The Service Type defines a template
including expected attributes, values 40
16.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 40
16.2. Finding Directory Agents . . . . . . . . . . . . . . . . 40

17. Scope Discovery and
protocol behavior. Well known Service Types
are registered with the IANA Use 42

18. Language and templates are
available as RFCs. Private Service Types may
also be supported.

Naming Authority The agency or group which catalogues
given Service Types Character Encoding Issues 43
18.1. Character Encoding and Attributes. The
default Naming Authority is IANA. Otherwise
the Service Type String Issues . . . . . . . . . . 44
18.1.1. Substitution of the service has the Naming
Authority appended to the end, following a '.'
separator.

Attribute A {class, value} pair describing a
characteristic Character Escape Sequences . . . 45
18.2. Language Dialect . . . . . . . . . . . . . . . . . . . . 45
18.3. Language-Independent Strings . . . . . . . . . . . . . . 46

19. Service Location Transactions 46
19.1. Service Location Connections . . . . . . . . . . . . . . 46

20. Security Considerations 47

21. String Formats used with Service Location Messages 48
21.1. Previous Responders' Address Specification . . . . . . . 49
21.2. Reply and Registration Information . . . . . . . . . . . 49
21.3. Attribute Information . . . . . . . . . . . . . . . . . . 50
21.3.1. Service Type String . . . . . . . . . . . . . . . 50
21.4. Address Specification in Service Location . . . . . . . . 50
21.5. Attribute Value encoding rules . . . . . . . . . . . . . 51

22. Implementation Requirements 52

23. Configurable Parameters and Default Values 55
23.1. Service Agent: Use Predefined Directory Agent(s) . . . . 56
23.2. Time Out Intervals . . . . . . . . . . . . . . . . . . . 57

24. Non-configurable Parameters 58

25. Acknowledgments 58

A. Appendix: Technical contents of ISO 639:1988 (E/F): "Code for
the representation of names of languages" 59

B. Appendix: For Further Reading 60

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 1]

Internet Draft Service Location Protocol 10 June 1996

1. Recent Changes

After much thought, we decided to change the way service attributes
are requested by clients. Whereas before we specified a /Select/
clause within the Service Request as well as another Attribute
Request message type, now attributes will be requested only by use
of the Attribute Request message type. The Service Request will not
have a /Select/ clause, and will return URLs only. Conceptually,
this is fairly minor change to the protocol, but it has had a pretty
substantial effect on the wording in the document.

In addition, we have broken out the Service Type message as a
different message type, and the Directory Agent now can make use of
an Advertisement message.

All of these changes have been made to simplify the protocol as well
as the description of the protocol. We reached the decision only
after much hand-wringing. We believe that the gain in protocol
quality is worth the cost of making modifications at this late date,
and that the resulting protocol is powerful yet simple enough that no
further such changes will be needed.

In addition, and as part of the abovementioned modifications, we have
addressed all of the language, consistency, and security concerns
that have been brought during the recent last call period.

1. The predicate grammar has changed:

- To disambiguate the grammar, parentheses are required for
keywords in where-list queries.

- The predicate query no longer contains a SELECT clause. The
select list has been moved to the AttrRqst. This simplifies
the query grammar and functionality of the SrvRqst.

2. The header has changed:

- Error codes have been removed from the header. This shrinks
the header, and since only half of the PDUs need to carry
an Error field: DAAdvert, SrvTypeRply, SrvRply, AttrRply,
SrvAck.

- TTL has been removed from the header. It has been renamed
Lifetime. The name TTL was confusing to people for whom it
had other associations. Having the TTL in the header did
not allow multiple services which were returned to be given
distinct lifetime values.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 2]

Internet Draft Service Location Protocol 10 June 1996

3. SrvRqst changed quite a bit. It now merely returns a URL, not
attributes.

SrvRqst had too much functionality. It allowed Service Type
discovery, DA Discovery, Service Discovery and Attribute
selection. This made it complex to explain and subtle to specify
and code. The elements have been broken into clear and distinct
interactions.

- The SELECT of the predicate clause has been removed.
Attribute information is no longer returned with the SrvRply
therefore SELECT is unneeded. It was complex to explain how
this feature worked. Removing all attribute information from
the SrvRqst <---> SrvRply transaction greatly simplifies the
protocol and predicate syntax.

- WILD CARD Service Types are no longer possible. This was
used to allow Service Type discovery and constituted a
special case. This was not at all elegant. One might even
use the word kludge here.

4. AttrRqst changed quite a bit. It now does all attribute
functions. SrvRqst and the grammar it used were very
complicated. This change takes on the attribute functions
in a clean and simple fashion which increases the clarity of
the protocol. It also makes it possible to ignore attributes
entirely if one wishes.

- There are more fields. AttrRqst used to have only a
ServiceType. It returned all the attributes and values of
that Service Type. Now a URL String, Scope String and Select
String are included. The URL String can be either merely a
Service Type or it can be a complete URL. This returns all
attributes and values as before, THAT SATISFY THE PROVIDED
SCOPE AND SELECT CLAUSE.

- This mechanism is more powerful than the original AttrRqst,
in that it allows a Selection of WHICH attributes are to be
returned. It also simplifies the protocol by combining all
attribute requests into one function.

5. SrvRply changed as a result of changes to SrvReq. It now
contains an Error field and it returns URL Entries not URL
Strings and Attribute information for each Service in the reply.

- An error field included, to make it clear how to handle
errors.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 3]

Internet Draft Service Location Protocol 10 June 1996

- URL Entries used, no attributes included. Lifetime had to be
associated with each entry in the reply not with the entire
reply. Attribute info may now only be obtained with the
AttrRqst.

6. SrvTypeRqst and SrvTypeRply were created in order to further
simplify (and rationalize) SrvReq.

- This request now has weaker semantics than before, since it
is impossible to specify a SELECT clause in the SrvTypeRqst.
This means that you can't say "Give me all service types that
start with the letter Q" or "Give me all service types except
the following list". Such things are not really needed and
add complexity to the wrong part of the protocol.

- There is no longer any special case or wild card necessary
for doing service type requests.

- The Naming Authority and Scope field for the SrvTypeRqst are
still included.

7. Created DAAdvert for the reply for a SrvRqst for Service Type
"directory-agent".

The reply for a DA must include the Scope of the DA. Since
Attributes are no longer included in SrvRply messages, a distinct
message type was required. This message is also periodically
transmitted even if unsolicited.

8. There is now a character escape mechanism almost exactly as used
in HTML, so that characters which are part of service location
protocol syntax can appear in attribute tags and values.

9. Added rules and conditions for use of multiple character sets to
satisfy Harald Alverstrand's rejection of slp draft 12.

10. Added security comments and requirements to satisfy last call
issues raised.

11. The SrvDereg message now includes a list of attributes to
deregister. In the previous version of the protocol the service
had to be deregistered as a whole, which was deemed to coarse
and easily correctible. If this field is excluded, the SrvDereg
functions exactly as before.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 4]

Internet Draft Service Location Protocol 10 June 1996

2. Introduction

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

Service Location provides a dynamic configuration mechanism for
applications in local area networks. It is not a global resolution
system for the entire Internet; rather it is intended to serve
enterprise networks with shared services. Applications are modeled
as clients that need to find servers attached to the enterprise
network at a possibly distant location. 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.

3. Terminology

User Agent (UA)
A process working on the user's behalf to acquire service
attributes and configuration. The User Agent 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 service attributes and configuration.

Service Information
A collection of attributes and configuration information
associated with a single service. The Service Agents
advertise service information for a collection of service
instances.

Service
The service is a process or system providing a facility
to the network. The service itself is accessed using
a communication mechanism external to the the service
location protocol.

Directory Agent (DA)
A process which collects information from Service Agents
to provide a single repository of service information

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 5]

Internet Draft Service Location Protocol 10 June 1996

in order to centralize it for efficient access by User
Agents. There can only be one DA present per given host.

Service Type
Each type of service has a unique Service Type string.
The Service Type defines a template including expected
attributes, values and protocol behavior.

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

Keyword
A string describing a characteristic of a service.

Attribute
A (class, value-list) pair of strings describing a
characteristic of a service. The value string may be
interpreted as a boolean, integer or opaque value if it
takes specific forms (see section 21.5).

Predicate
A boolean expression of attributes, relations and logical
operators. The predicate is used to find services which
satisfy particular requirements. See section 6.3.

Scope
A collection of services that make up a logical group.
See sections 17 and 4.7.

Site Network
All the hosts accessible within the Agent's multicast
radius, which defaults to a value appropriate for
reaching all hosts within a site (see section 23). If
the site does not support multicast, the agent's site
network is restricted to a single subnet.

Address Specification
This is the network layer protocol dependent mechanism
for specifying an Agent. For Internet systems this is
part of a URL (Universal Resource Locator - see [7]).

3.1. Notation Conventions

CAPS Strings which appear in all capital letters are protocol
literal. All string comparison is case insensitive,
however, (see section 6.5). Some strings are quoted in

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 6]

Internet Draft Service Location Protocol 10 June 1996

this document to indicate they should be used literally.
Single characters inside apostrophes should be included
literally.

<> Values set off in this manner are fully described in
section 21. In general, all definitions of items in
messages are described in section 21 or immediately
following their first use.

| |
\ \ Message layouts with this notation indicate a variable
| | length field.

3.2. Service Information and Predicate Representation

Service information is represented in a text format. The goal is
that the format be human readable and transmissible via email. The
location of network services is encoded as a Universal Resource
Locator (URL) which is also human readable and well defined. Only
the datagram headers are encoded in a form which is not human
readable.

Predicates are expressed in a simple boolean notation using keywords,
attributes, and logical connectives, as described in Section 6.4.
The logical connectives and subexpressions are presented in
prefix-order, so that the connective comes first and the expressions
it operates on follow afterwards.

3.3. Specification Language

In this document, several words are used to signify the requirements
of the specification. These words are often capitalized.

MUST This word, or the adjective "required", means that
the definition is an absolute requirement of the
specification.

MUST NOT This phrase means that the definition is an absolute
prohibition of the specification.

SHOULD This word, or the adjective "recommended", means
that, in some circumstances, valid reasons may exist
to ignore this item, but the full implications must
be understood and carefully weighed before choosing
a different course. Unexpected results may result
otherwise.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 7]

Internet Draft Service Location Protocol 10 June 1996

MAY This word, or the adjective "optional", means that this
item is one of an allowed set of alternatives. An
implementation which does not include this option MUST
be prepared to interoperate with another implementation
which does include the option.

silently discard
The implementation discards the datagram without
further processing, and without indicating an error
to the sender. The implementation SHOULD provide the
capability of logging the error, including the contents
of the discarded datagram, and SHOULD record the event
in a statistics counter.

4. Protocol Overview

The basic operation in Service Location is that a client attempts
to discover the location of a Service. In smaller installations,
each service will be configured to respond individually to each
client. In larger installations, services will register their
services with one or more Directory Agents, and clients will
contact the Directory Agent to fulfill requests for Service Location
information. Clients may discover the whereabouts of a Directory
Agent by preconfiguration, DHCP [2, 10], or by issuing queries to the
Directory Agent Discovery multicast address.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 8]

Internet Draft Service Location Protocol 10 June 1996

4.1. Protocol Transactions

The diagram below illustrates the relationships described below:

+---------------+ we want this info: +-----------+
| Application | - - - - - - - - - - - -> | Service |
+---------------+ +-----------+
/|\ | |
| +-------------+ |
| | |
\|/ \|/ \|/
+---------------+ +-----------+ +----------------+
| User Agent |<-------->| Service | | Service |
+---------------+ | Agent | | Agent which |
| +-----------+ | does not reply |
| | | to UA requests |
| \|/ +----------------+
| +-------------+ |
+------------------>| Directory |<----------+
| Agent |
+-------------+ ___________
/|\ / Many other\
+------------>| SA's |
\___________/

The following describes the operations a User Agent would employ
to find services on the site's network. The User Agent needs no
configuration to begin network interaction. The User Agent can
acquire information to construct predicates which describe the
services that match the user's needs. The User Agent may build on
the information received in earlier network requests to find the
Service Agents advertising service information.

A User Agent will operate two ways: If the User Agent has already
obtained the location of a Directory Agent, the User Agent will
unicast a request to it in order to resolve a particular request.
The Directory Agent will unicast a reply to the User Agent. The
User Agent will retry a request to a Directory Agent until it gets
a reply, so if the Directory Agent cannot service the request (say
it has no information) it must return an response with zero values,
possibly with an error code set.

If the User Agent does not have knowledge of a Directory Agent or if
there are no Directory Agents available on the site network, a second
mode of discovery is used. The User Agent multicasts a request to
the service-specific multicast address, to which the service it
wishes to locate will respond. All the Service Agents which are
listening to this multicast address will respond, provided they can

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 9]

Internet Draft Service Location Protocol 10 June 1996

satisfy the User Agent's request. A similar mechanism is used for
Directory Agent discovery; see section 6.2. Service Agents which
have no information for the User Agent MUST NOT respond.

When a User Agent wishes to obtain an enumeration of ALL services
which satisfy the query, a retransmission/convergence algorithm is
used. The User Agent resends the request, together with a list of
previous responders. Only those Service Agents which are not on
the list respond. Once there are no new responses to the request
the accumulation of responses is deemed complete. Depending on the
length of the request, around 60 previous responders may be listed
in a single datagram. If there are more responders than this, the
scaling mechanisms described in section 4.7 should be used.

While the multicast/convergence model may be important for
discovering services (such as Directory Agents) it is the exception
rather than the rule. Once a User Agent knows of the location of a
Directory Agent, it will use a unicast request/response transaction.

The Service Agent SHOULD listen for multicast requests on the
service-specific multicast address, and MUST register with an
available Directory Agent. This Directory Agent will resolve
requests from User Agents as described above. This means that
a Directory Agent must first be discovered, using the multicast
mechanism described above.

A Service Agent which does not respond to multicast requests will not
be useful in the absence of Directory Agents. Some Service Agents
may not include this functionality, if an especially light-weight
implementation is required.

If the service is to become unavailable, it should be deregistered
with the Directory Agent. The Directory Agent responds with an
acknowledgment to either a registration or deregistration. Service
Registrations include a Lifetime value and will eventually expire.
Service Registrations need to be refreshed by the Service Agent
before their Lifetime runs out.

4.2. Schemes

The Service Location Protocol, designed as a way for clients to
access resources on the network, is a natural application for
Universal Resource Locators (URLs). It is intended that by re-using
URL specification and technology from the World Wide Web, clients and
servers will be more flexible and able to be written using already
existing code. Moreover, it is hoped that browsers will be written
to take advantage of the similarity in locator format, so that a

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 10]

Internet Draft Service Location Protocol 10 June 1996

client can dynamically formulate requests for services that are
resolved differently depending upon the circumstances. There is
the possibility for beneficial interaction between Directory Agents
and Web Browsers which we wish to facilitate by means of compatible
locator format.

4.2.1. The 'service:' URL scheme

The service URL scheme is used by Service Location. It is used to
specify a Service Location. Many Service Types will be named by
including a scheme name after the 'service:' scheme name. Service
Types are used by SAs to register and deregister Services with DAs.
It is also used by SAs and DAs to return Service Replies to UAs. The
formal definition of the 'service:' URL scheme is in section 21.
The format of the information which follows the 'service:' scheme
should as closely as possible follow the URL structure and semantics
as formalized by the IETF standardization process.

Well known Service Types are registered with the IANA and templates
are available as RFCs. Private Service Types may also be supported.

4.3. Standard Attribute Definitions

Service Types used with the service location protocol must describe
the following:

Service Type string of the service
Service-specific multicast address, if used
Attributes and Keywords
Attribute Descriptions and interpretations

Service Types note registered with IANA will use their own Naming
Authority string and, possibly, a service-specific multicast
address from the unassigned range. This is only an option for
a site-specific deployment, as there may be conflicts with this
multicast address somewhere, in some other site.

If a service-specific multicast address is not supplied by a
standards document registered with IANA, nor is a site specific
address being used, the Service Location General Multicast address
is the default. All Service Agents SHOULD listen to this address,
especially if they have not registered their service information
with any Directory Agent. The service-specific multicast address is
merely used for efficiency and is not strictly needed for correct
operation.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 11]

Internet Draft Service Location Protocol 10 June 1996

Services which advertise a particular Service Type must support the
complete set of standardized attributes. They may support additional
attributes, beyond the standardized set. Unrecognized attributes
MUST be ignored by User Agents.

Service Type names which begin with "x-" are guaranteed not to
conflict with any officially registered Service Type names. It
is suggested that this prefix be used for experimental or private
Service Type names. Similarly, attribute names which begin with "x-"
are guaranteed not to be used for any officially registered attribute
names.

A service of a given Service Type should accept the networking
protocol which is implied in its definition. If a Service Type
can accept multiple protocols, configuration information SHOULD
be included in the Service Type attribute information. This
configuration information will enable an application to use the
results of a Service Request and Attribute Request to directly
connect to a service. Note that

See section 21.3.1 for the format of a
class Service Type String as used in
the Service Location Protocol.

4.4. Naming Authority

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 a string. Values are optional.
An attribute without a value string which uniquely
identifies an organization. If no string is a keyword.
A value provided IANA is the
default.

Naming Authorities may define Service Types which are experimental,
proprietary or for private use. The procedure to use is to create
a 'unique' Naming Authority string which may be interpreted and then specify the Standard
Attribute Definitions as a string, or described above. This Naming Authority
will accompany registration and queries, as a boolean, integer or
opaque value if described in sections 10
and 6.

4.5. Interpretation of Service Location Replies

Replies should be considered to be valid at the value string takes
specific forms (see section 11.3.) time of delivery.
The service information advertised by a Service
Agent may include more than one value per
class.

Predicate A boolean expression may, however, fail or change between the time of attributes, relations the
reply and logical operators. The predicate is used the moment an application seeks to find services which satisfy particular
requirements. See section 11.1.2.

Scope A collection of systems, networks and other
network components that make up a logical
group. See section 6.5 and 6.6.

Campus A campus is a collection use of networks, hosts
and related network infrastructure the service.
The application making use of service location SHOULD be prepared for
the possibility that the service information provided is
grouped together for geographical either stale
or political
reasons.

Veizades, Kaplan, Guttman, Perkins incomplete. In the case where the service information provided

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 4]

INTERNET-DRAFT 12]

Internet Draft Service Location Protocol March-96

Agent's Internet All the hosts accessible within 10 June 1996

does not allow a User Agent to connect to a service as desired, the Agent's
multicast radius
Service Request may be resubmitted.

Service specific configuration information (such as which defaults protocol
to the Agent's
site (see section 13.0.) If the network does
not support multicast, the agent's internet is
defined by its broadcast radius. The
discovery method use) should be included as attribute information in Service
Registrations. These configuration attributes will be used by
applications which interpret the Service Location Reply.

4.6. Use of TCP, UDP and Multicast in Service Location

The service location protocol requires these techniques to start up
and provide stable operation. Servers outside
of the Agent's radius are considered "outside implementation of the user's internet."

Address Specification This
connectionless and a connection oriented transport protocols. The
latter is the network layer protocol dependent
mechanism used for specifying bulk transfer, only when necessary. Connections
are always initiated by an User Agent. For
Internet systems this is agent request or registration, not
by a URL (Universal
Resource Locator see RFC 1738).

5.0 Protocol Overview

5.1 Protocol Transactions replying Directory Agent. The diagram below illustrates the relationships described below:

+---------------+ we want this info: +-----------+
| Application | - - - - - - - - - - - -> | Service |
+---------------+ +-----------+
/|\ | |
| +-------------+ |
| | |
\|/ \|/ \|/
+---------------+ +-----------+ +-------------+
| User Agent |<-------->| Service | | Service |
+---------------+ | Agent | | Application |
| +-----------+ +-------------+
| | |
| \|/ |
| +-------------+ |
+------------------>| Directory |<----------+
| Agent |
+-------------+ ___________
/|\ / Many other\
+------------>| SA's |
\___________/ Location discovery
mechanisms use possibly internetwork-wide multicast. The following describes the operations protocol
will operate in a User Agent employs to find
services on the attached Internet. broadcast environment with limitations detailed in
section 4.6.1.

4.6.1. Multicast vs. Broadcast

The User Agent does not need any
configuration to begin service location protocol was designed for use in networks where
multicast at the network interaction. The User Agent layer is supported; in some instances
multicast may
build on the information received not be supported. To support this protocol in earlier network requests to
find the Service Agents advertising service information, and
subsequently networks
where multicast is not supported the terms used following modifications are
made to describe services that it support the protocol in an environment where network layer
broadcast is
interested in. supported.

4.6.1.1. Single Subnet

If a network is not connected to any other networks simple network
layer broadcasts will work in place of multicast.

4.6.1.2. Multiple Subnets

The User Directory Agent can use this provides a central clearing house of information to construct
predicates which describe the services that match the user's needs.

Veizades, Kaplan, Guttman, Perkins [Page 5]

INTERNET-DRAFT Service Location Protocol March-96

A
for User Agent will operate two ways: Agents. If the User Agent has already
obtained the location of network is designed so that a Directory
Agent address is statically configured with each User Agent, the User
Directory Agent will
unicast a request to it in order to resolve act as a particular request. bridge for information that resides on
different subnets. The Directory Agent address can be dynamically
configured with Agents using DHCP or staticly configured, but Agents
will unicast a reply not be able to the User Agent. The
User Agent discover DAs on non-bridged subnets.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 13]

Internet Draft Service Location Protocol 10 June 1996

As dynamic discovery is not feasible in a broadcast environment with
multiple subnets and manual configuration is difficult, deploying
multiple DAs in multiple subnets will retry require use of multicast
discovery with multiple hops (i.e., TTL > 1 in the IP header).

4.6.1.3. Service-Specific Multicast Address

Each service type MAY have a request unique multicast address which is
expected to a Directory Agent until it gets
a reply, be used for discovering services of that type. This
multicast address may be obtained from the naming authority (e.g.,
IANA). This mechanism is used so if that the Directory Agent cannot number of datagrams any one
service agent receives is minimized. The Service Location General
Multicast Address may be used to query for any service, though one
should use the request (say
it has no information) service-specific multicast address if it must return an response with zero values,
possibly with an error code set. exists.

If the User Agent site network does not have knowledge support multicast then the query
should be broadcast to the Service Location port. If the underlying
hardware will not support the number of needed multicast addresses
the service location general multicast address may be used. Service
Agents which have not registered with a Directory Agent or
if there are no Directory Agents available listen on
this multicast address as well as the User Agent's
internet, service-specific multicast
addresses for the service types they advertise.

4.7. Service Location Scaling, and Multicast Operating Modes

In a second mode of discovery very small network, with few nodes, no DA is used. The required. A User
Agent
multicasts can detect services by multicasting requests. Service Agents
will then reply to them. Further, Service Agents which respond to
user requests must be used to make service information available.
This does not scale to environments with many hosts and services.

When scaling service location systems to intermediate sized networks,
a request central repository (Directory Agent) may be added to reduce the service multicast address, which
number of Service Location messages transmitted in the
service it wishes network
infrastructure. Since the central repository can respond to locate all
Service Requests, fewer Service Replies will respond to. All be needed; for the
same reason, there is no need to differentiate between Directory
Agents. Service Agents which are listening to should register with this multicast address will respond,
provided DA even if they can satisfy the User Agent's request. Service Agents are
configured to specifically register with DAs which have no information for the User Agent DO NOT respond.

In the case where the User Agent wishes to obtain a complete answer,
an enumeration specific
scope or set of ALL services which satisfy the query, there is a
retransmission/convergence algorithm. The scopes. User Agent resends the
request, together with a list of previous responders. Only those
Service Agents which are not on the list respond. Once there may query DAs without scopes,
even if they are no
new responses configured to the request the accumulation of responses is deemed
complete. Depending on the length of the request, around 60
previous responders may be listed in a single datagram (without
exceding the size of use DAs with a single datagram and requiring fragmentation.)
If there are more responders than this, the scaling mechanisms
described in section 6.6 should be used.

It certain scope. This
is important to stress that while because any DA with no Scope will have all the multicast/convergence model available service
information.

A site may be important for discovering services (such as Directory Agents)
it is the exception rather than the rule. Once a User Agent knows
of the location of also grow to such a Directory Agent, size that it will use a unicast
request/response transaction.

A service is not feasible to
maintain only one central repository of service information. In this

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 14]

Internet Draft Service Location Protocol 10 June 1996

case more Directory Agents are needed. The services (and service
agents) advertised by an application which registers the
service information with a Directory Agent. This several Directory Agent
will resolve requests from User Agents as described above. This
means are collected
together into logical groupings called "scopes". All Service
Registrations that have a Directory Agent scope must first be discovered, using registered with all DAs
(within the appropriate multicast mechanism described above. If the service is to become
unavailable, it radius) of that scope which have
been or are subsequently discovered. Unscoped services should be unregistered with the Directory Agent.
The Directory Agent responds
registered with an acknowledgment all DAs as they are implicitly Global in scope. User
Agents make requests of DAs whose Scope they are configured to either a
registration or unregistration.

The use.

It is possible to specially configure Service Agent or Application must Agents to register
only with an a specific set of DAs (see Section 23.1). In that case,
services may not be available to User Agents via all Directory Agent. The Service Agent must additionally listen for
multicast requests on the service specific multicast address.
Service Applications will fail in an internet where there
Agents, but some network administrators may deem this appropriate.

There are thus 3 distinct operating modes. The first requires no
Directory Agents. Service Applications are present in this
protocol to provide a lightweight service registration mechanism.

Veizades, Kaplan, Guttman, Perkins [Page 6]

INTERNET-DRAFT Service Location Protocol March-96

5.2 Service and Predicate Representation

Service information is represented in
administrative intervention. The second requires only that a text format. DA be
run. The goal is last requires that the format all DAs be human readable configured to have Scope and transmittable via email.
The location
that a coherent strategy of network assigning Scopes to services is encoded as a Universal
Resource Locator (URL) be followed.
Users must be instructed which is also human readable and well
defined. Only the datagram headers Scopes are in an encoded form which
is not human readable.

5.3 Additional Notes

5.3.1 The 'service:' URL scheme

The service URL scheme is used by Service Location. It is used appropriate for them to specify a Service Location.
use. This is used by SAs and Service
Applications to register and unregister Services with DAs. It is
also used by SAs administrative effort will allow users and DAs applications to return
subsequently dynamically discover services without assistance.

A subsequent protocol document will describe mechanisms for
supporting a service discovery protocol for the global Internet.

5. Service Replies to UAs. Location General Message Format

The
formal definition of the 'service:' URL scheme following header is used in section 11.
The format all of the information which follows the 'service:' scheme
should as closely as possible follow the URL structure message descriptions below
and
semantics as formalized is abbreviated by using "Service location header =" followed by
the IETF standarization process.

5.3.2 Interpretation function being used.

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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|M| rsvd | Dialect | Language Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Char Encoding | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version This protocol document defines version 1 of the service
location protocol.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 15]

Internet Draft Service Location Replies

Replies should Protocol 10 June 1996

Function Service location datagrams can be considered identified as to be valid at their
operation by the time of delivery. function field. The service may, however, fail or change between following are the time
defined operations:

Message Type Abbreviation Function Value

Service Request SrvReq 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Deregister SrvDereg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7
DA Advertisement DAAdvert 8
Service Type Request SrvTypeRqst 9
Service Type Reply SrvTypeRply 10

Length The number of bytes in the
reply and the moment an application seeks to make use of message, including the service. Service
Location Header.

O The application making use of service location must be prepared 'Overflow' bit. See Section 19 for the possibility that the service information provided is either
stale or incomplete. In the case where use of this
field.

M The 'Monolingual' bit. Requests with this bit set
indicate the service information
provided does not allow a User Agent to connect to a service as
desired, the request may be resubmitted.

Service specific configuration information (such as which protocol
to use) should be included as attribute information in Service
Registrations. These configuration attributes will be used by
applications which interpret the Service Location Reply.

5.3.3 Use of TCP and Multicast only accept responses in Service Location

The service location protocol requires
the implementation of
connectionless and a connection oriented transport protocols. The
latter language (see section 18) that is used for bulk transfer, only when necessary. Connections
are always initiated by an agent request or registration, not by a
replying Directory Agent.

The indicated by the
Service Location discovery mechanisms use internetwork wide
multicast. The protocol will operate or Attribute Request.

rsvd MUST be zero.

Dialect Dialect tags are used in Service Location messages to
indicate a broadcast environment
with limitations detailed variant of vocabulary used.

Language Code
Strings within the remainder of the message which follows
are to be interpreted in section 9.0.

5.3.4 Multilingual Support

All Service Registrations declare the language encoded (see
appendix A) in which the this field. See also section 18.

Character Encoding
The characters making up strings
in within the service attributes are written by specifying remainder of
the appropriate

Veizades, Kaplan, Guttman, Perkins message may be encoded in any standardized encoding
(see section 18.1).

Transaction Identifier (XID)
The XID (transaction ID) field allows the requester to
match replies to individual requests (see section 5.1).

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 7]

INTERNET-DRAFT 16]

Internet Draft Service Location Protocol March-96

code in the packet header. For each language the Service advertises
a separate registration takes place. The Service needs to be
unregistered only once since the information 10 June 1996

When URLs are registered, they have lengths and lifetimes. These
two values are associated with it will
be unique. There can only be one service the URL for the duration of a given type at a given
address specification even if it the
registration. The triplet (length, lifetime, URL) is registered in multiple languages.

All Service Requests specify known as a requested language in
"URL-entry", and has the packet
header. following format when used in Service
Replies and Service Registrations:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lifetime | Length of URL String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Directory Agent or Service Agent will respond in the
same language as the request, if it has a registration in the same
language as the request. If this language is not supported, a reply
can be sent in the default language (which is English.) URL string conforms to RFC 1738 [7]. If the
'monolingual bit' flag scheme used in
the header is set and the requested
language is URL does not supported, have a SrvRply standardized representation, the minimal
requirement is:

service:<srvtype>://<addr-spec>

The "SERVICE" string is not returned: Instead
return a SrvAck with the error field set to LANGUAGE_NOT_SUPPORTED.

5.3.5 Standard Attribute Definitions URL scheme of all Service Types used with the service location protocol must
describe the following: Location
Information included in Service Type string of the service
Multicast address, if used
Attributes (Tag and values)
Attribute Descriptions Registrations and interpretations Service Types defined outside of Replies.
Each entry in the IANA standardization process Reply will use their own Naming Authority string and, possibly, always have a
multicast address from <srvtype>. It may also
include an <addr-spec> except in the unassigned range. If case of a reply to a Service
Type does
not define its own multicast address, request (see section 8).

5.1. Use of Transaction IDs (XIDs)

Retransmission is used to ensure reliable transactions in the
Service Location General
Multicast address is used, as the default.

Services which advertise Protocol. If a particular User Agent or Service Type must support Agent sends
a message and fails to receive an expected response, the
complete set message
will be sent again. Retransmission of standardized attributes. They may support
additional attributes, beyond the standardized set. Unrecognized
attributes should be ignored by User Agents.

Service Type names which begin with 'x-' are guaranteed not to
conflict with any officially registered Service Type names. same service location
datagram should not contain an updated XID. It is
suggested that this prefix be used for experimental quite possible the
original request reached the DA or private
Service Type names. Similarly, attribute names which begin with
'x-' are guaranteed not SA, but reply failed to reach the
requester. Using the same XID allows the 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 used for any officially registered
attribute names.

5.3.6 Naming Authority

The Naming Authority of held very
briefly (CONFIG_INTERVAL_0.) Any registration or deregistration at
a Directory Agent, or change of service defines information at a SA should
flush this cache so that the semantic meaning of information returned to the Service Types and attributes registered with and provided by
Service Location. The Naming Authority itself is a string which
uniquely identifies an organization. If no string is provided IANA client is
always valid.

The requester creates the default.

Naming Authorities may define Service Types which are experimental,
proprietary or XID from an initial random seed and
increments it by one for private use. each request it makes. The procedure XIDs will
eventually wrap back to zero and continue incrementing from there.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 17]

Internet Draft Service Location Protocol 10 June 1996

Directory Agents use XID values in their DA Advertisements to
indicate their state (see section 16.2).

5.2. URL Entry Lifetime

The Lifetime field is set to create the number of minutes the reply can be
cached by any agent. A value of 0 means the information must not
be cached. User Agents MAY cache service information, but if they
do, they must provide a
'unique' Naming Authority string way for applications to flush this cached
information and then specify issue the Standard

Veizades, Kaplan, Guttman, Perkins [Page 8]

INTERNET-DRAFT Service Location Protocol March-96

Attribute Definitions as described above. This Naming Authority request directly onto the network.

Services should be registered with DAs with a Lifetime, the suggested
value being CONFIG_INTERVAL_1. The service must be reregistered
before this interval elapses, or the service advertisement will
accompany registration
no longer be available. Thus, services which vanish and queries, as described below.

5.3.7 No Synchronous Assumption

There fail to
deregister eventually become automatically deregistered.

6. Service Request Message Format

The Service Request is no requirement that one transaction complete before used to obtain URLs from a
given host begins another. An agent may have multiple outstanding
transactions, initiated either using UDP Directory Agent or TCP.

5.4
Service Location PDU header

NOTE: Agents.

The following header is used in all format of the packet descriptions
below and Service Request is abbreviated by using "Service location header" followed
by the function being used. as follows:

The <Previous Responders Addr Spec> is described in sections 8
and 21.1.

After a User Agent restarts (say, after rebooting of a system,
loading of the network kernel), Service Requests should be delayed
for some random time uniformly distributed within a one second

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 18]

Internet Draft Service Location Protocol 10 June 1996

interval centered about a configured delay value (by default,
CONFIG_INTERVAL_4).

The Service Request allows the User Agent to specify the Service Type
of the service and a Predicate in a specific language. The general
form of a Service Request is shown below:

<srvtype>[.<na>]/[<scope>]/[<where>]/

The punctuation is necessary even where the fields are omitted.

- The <srvtype> refers to Live | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Language Code | Reserved (Language Dialect) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.4.1 Version the Service Type. For each type of
service available, there is a unique Service type name string.
See section 21.3.1.

- The <na> is the Naming Authority. This protocol document defines version 1 string determines the
semantic interpretation of the attribute information in the
<where> part of the service location
protocol.

5.4.2 Functions Service location datagrams can be identified as Request.

- The <scope> is a string used to their operation
by restrict the function field. range of the query.
Scope is determined administratively, at a given site. It is
not necessarily related to network topology (see Section 17).
Leaving this field out means that the request can be satisfied
under any scope.

- The following are <where> string is the defined operations:

Packet Type Abbreviation Function Value

Service Request SrvRqst 1
Service Reply SrvRply 2
Service Registration SrvReg 3
Service Unregister SrvUnreg 4
Service Acknowledge SrvAck 5
Attribute Request AttrRqst 6
Attribute Reply AttrRply 7

5.4.3 Length Where Clause of the request. It
contains query which specify which service instances the User
Agent is interested in. The length query includes attributes, boolean
operators and relations. (See section 6.3.)

In the case of a multicast request, a list of previous responders is
sent. This list will prevent those in the number list from responding, to
be sure that responses from other sources are not drowned out. The
request is multicast repeatedly (with a recommended wait interval of bytes after
CONFIG_INTERVAL_2) until there are no new responses, or a certain
time (CONFIG_INTERVAL_3) has elapsed.

In order for a request to succeed in matching registered information,
the following conditions must be met:

1. The result must have the same Service Location Header.

5.4.4 Error Codes

Error codes may only Type as the request.

2. It must have a nonzero value in a SrvRply and a SrvAck.

Veizades, Kaplan, Guttman, Perkins the same Naming Authority.

3. It must have the same Scope (unless the <scope> of the request
was omitted.)

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 9]

INTERNET-DRAFT 19]

Internet Draft Service Location Protocol March-96

5.4.5 Transaction Identifier (XID) 10 June 1996

4. The XID (transaction ID) field allows conditions specified in the requester to Where Clause must match replies
to individual requests. A Service Reply will contain the same XID
as
attributes and keywords registered for the service.

6.1. Service Request. A Request Usage

The User Agent may form Service Acknowledge will contain the same
XID as Requests using preconfigured
knowledge of a Service Type's attributes. It may also issue
Attribute Requests to obtain the attribute values for a Service Register or Unregister.

Retransmission of Type
before issuing Service Requests (see Section 13). Having obtained
the same attributes which describe a particular kind of service location datagram should not
contain an updated XID. The requester creates the XID from an
initial random seed and increments it by one for each request it
makes. The XIDs will eventually wrap back
Attribute Request, (or using configured knowledge of a service's
attributes,) the User Agent can build a predicate that describes the
service needs of the user.

Service Requests may be sent directly to zero and continue
incrementing from there.

5.4.6 Flags

The flags field a Directory Agent. Suppose
a printer supporting the lpr protocol is needed on the 12th floor
which has UNRESTRICTED_ACCESS and prints 12 pages per minute.
Suppose further that a bit field. Bit 0 Attribute Request indicates that there is a
printer on the 'Overflow bit.' See
Section 7.0 for 12th floor, a printer that prints 12 pages per minute,
and a complete description for printer that offers UNRESTRICTED_ACCESS. To check whether they
are same printer, issue the use of this field.
Bit 1 following request:

lpr://(& (PAGES PER MINUTE==12)
(UNRESTRICTED_ACCESS)
(LOCATION==12TH FLOOR))/

Suppose there is the 'Monolingual bit.' Requests no such printer. The Directory Agent responds
with this bit set indicate a Service Reply with 0 in the number of responses and no reply
values.

The User Agent will only accept responses in the language that is
indicated by then tries a less restrictive query to find a printer,
using the Service or Attribute Request. Replies in other
languages should not be sent for 12th floor as "where" criteria.

lpr://(LOCATION==12TH FLOOR)/

In this request. All other bits must
be set to zero.

5.4.7 Time to Live case, there is now only one reply:

Returned URL: service:lpr://igore.wco.ftp.com:515
Returned Attrs: ((PAGES PER MINUTE = 3),(PROTOCOL=LPR,PCNFS))

The TTL field Address Specification for the printer is: igore.wco.ftp.com:515.
This is set to the number location of minutes the reply can printer. Files would be
cached printed by any intermediary service. A value
spooling to that port on that host.

In the absence of 0 means a Directory Agent, the
information must not request above could
be cached. User Agents must multicast. In this case it would be sent to the printer
Multicast Address and not cache to the Directory Agent. Service information. Requests by a User Agent must be issued
directly onto

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 20]

Internet Draft Service Location Protocol 10 June 1996

Agents that can satisfy the network.

5.4.8 Character Encoding

The encoding predicate will determine reply. Service
Agents which cannot support the interpretation character set of the request MUST
return CHARSET_NOT_UNDERSTOOD in the SrvTypeRply. In all character data other
circumstances, Service Agents which follows. There is no cannot satisfy the reply do not
send any reply at all.

The only way to mix ASCII and UNICODE, for
example. Values for character encoding a User Agent can be found in the Internet
Assigned Numbers Authority's (IANA) database
http://www.isi.edu/in-notes/iana/assignments/character-sets and have sure there are no services which
match the values refered query is by retrying the MIBEnum value.

5.4.9 Language Code

The language code (see Appendix A) is encoded in this field. ALL
strings within request (CONFIG_INTERVAL_8). If
no response comes, the packet which follows User Agent gives up and assumes there are to be interpreted in
this language. Some strings, no
such as printers.

Another form of query is a simpler 'join' query. Its syntax has no
parentheses or logical operators. Each term is conjoined (AND-ed
together.) Rewriting the initial query provides an example:

lpr://PAGES PER MINUTE==12,
UNRESTRICTED_ACCESS,
LOCATION==12TH FLOOR/

6.2. Directory Agent Discovery Request

Normally a Service Type names, have
standard definitions. These strings should be considered as
tokens and not as words in Request returns a language Service Reply. The sole
exception to be translated. This will
be noted where appropriate throughout this document.

The language dialect field is reserved for future use.

5.5 a Service Request and Reply

The for the Service Type
"directory-agent". This Service Request is used to obtain nearly all information in the

Veizades, Kaplan, Guttman, Perkins [Page 10]

INTERNET-DRAFT answered with a DA
Advertisement.

Without configured knowledge of a Directory Agent (DA), a User Agent
or Service Location Protocol March-96 Agent uses a Service Location Protocol. It is Request to discover a general mechanism DA. (See
section 16.1 for mechanisms by which a client may be configured to
have knowledge of a DA.) Such a Service Request used for delivering Directory
Agent Discovery includes a predicate of the form:

directory-agent:///

This query is always sent to a the Directory Agent or Discovery multicast
address. The Service Agents. Depending on the
format Type of the query, different information can be obtained. There
are three ways the Service Query may be used: a Directory Agent
Discovery Request, a is "directory-agent",
hence it is the Service Type Request and a Services Discovery
Request. These are described used in the sections which follow.

There request. No scope is an additional mechanism for determining
included in the range of
service attributes. This request, since the query is global in scope. No
Naming Authority is included, so "IANA" is assumed. We want to reach
all the Attribute Request. It available directory agents. If the scope were supplied, only
DAs supporting that scope would reply.

Replies may arrive from different sources, similar in form to:

URL returned: directory-agent://slp-resolver.catch22.com
Scope returned: ACCOUNTING

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 21]

Internet Draft Service Location Protocol 10 June 1996

URL returned: directory-agent://204.182.15.66
Scope returned: JANITORIAL SERVICES

If the goal is used merely to
obtain discover any Directory Agent, the tags and values of attributes which first
reply will be used do. If the goal, however, is to
formulate Service Discovery Requests.

While discover all of these types of queries may reachable
DAs, the request must be useful, retransmitted after an interval (the
recommended time is CONFIG_INTERVAL_5). This retransmitted request
will include a list of DAs which have already responded. See
sections 8 and 21.1. Directory Agents which receive the request will
only one
which is essential is respond if they are not on this list. After there are no new
replies, all DAs are presumed to have been discovered.

If a DA fails to respond after CONFIG_INTERVAL_6 seconds, the UA or
Service Discovery Request. Agent should use a different DA. DA addresses may be cached
from previous discovery attempts, preconfigured, or by use of DHCP
(see section 16.2). If no such DA responds, DA discovery should be
used to find a User
Agent has enough a priori knowledge of what it is looking for new DA. Only after CONFIG_INTERVAL_7 seconds should
it
can simply issue a Service Discovery Request be assumed that no DA exists and multicast based Service Requests
should be done with it.
The point used.

6.3. Explanation of the other requests is to allow a User Agent to
formulate a query when it Terms of Predicate Grammar

A predicate has limited or no a priori knowledge of
the services available simple structure, which depends on parentheses,
commas and their attributes.

The Service Request allows the User Agent slashes to specify delimit the Service
Type elements. Examples of proper usage
are given throughout this document. The terms used in the service and a Predicate grammar
are as follows:

predicate:

Placed in a specific language. The
general form of a Service Request Request, this is shown below:

SERVICE TYPE[.NAMING AUTHORITY]:/SCOPE/SELECT CLAUSE/WHERE CLAUSE/

Briefly, the SERVICE TYPE of the service interpreted by a Service
Agent or Directory Agent to determine what information to
return.

scope:

If this is absent in a unique service type
name. The NAMING AUTHORITY determines Service Request, the semantic interpretation request will match
any service regardless of scope. If it is present, only
services registered under that scope will match the SERVICE TYPE and the attributes used in request.

where-clause:

This determines which services the SELECT and WHERE
CLAUSE. request matches. An empty
where-clause will match all services. The SCOPE is used for range of the query (SCOPEs are
determined administratively, not by network topology as request will be
described later.) The SELECT CLAUSE lists which attributes
limited to return
with the reply. The WHERE CLAUSE contains the attributes services which
determine have the instances of specified Service Type, so
the service (identified by where-clause is not the SERVICE
TYPE) sole factor in picking out which
services match the request.

In the case of a multicast request, a list of previous responders is
sent. This list will prevent those in the list from responding, to
be sure that responses from other sources are not drowned out.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 22]

Internet Draft Service Location Protocol 10 June 1996

where-list:

The
request where-list is multicast repeatedly (with a recommended wait interval of logical expression. It can be a second) until there are no new responses, or single
expression, a certain time has
elapsed. The User Agent may configure disjunction or a certain 'time out' duration conjunction. A single
expression must apply for example, with the Service Location implementation or where-clause to match. A
disjunction matches if any expression in the case
where the User Agent doesn't need ALL OR list matches.
A conjunction matches only if all elements in the replies, as when any one
service will do.

In order for AND list
match.

Note that there is no logical negation operator: This is
because there is no notion of returning "everything except"
what matches a request to succeed in matching registered information
4 conditions must given criteria.

A where-list can be met:

(1). The result must have the same Service Type as the request.
(2). It must have nested and complex. For example, the same Naming Authority.
(3). It
following requires that three subexpressions must have the same Scope.
(4). The conditions specified all be true:

(& (| <query-item> <query-item>)
<query-item>
(& <query-item> <query-item> <query-item>)
)

Notice that white space, tabs or carriage returns can be added
anywhere outside query-items. Each list has 2 or more items in
it, and lists can be nested. Services which fulfill the WHERE CLAUSE must entire
logical expression match the attributes where-clause.

'(' '|' <query-item> ')' and keywords registered for '(' '&' <query-item> ')' are
degenerate expressions but they should be tolerated. They are
equivalent to <query-item>.

query-item:

A query item has the service.

Veizades, Kaplan, Guttman, Perkins form:

'(' <attr-tag> <comp-op> <attr-val> ')'

'(' <keyword> ')'

Examples of this would be:

(SOME ATTRIBUTE == SOME VALUE)
(RESERVED)
(QUEUE LENGTH <= 234)

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 11]

INTERNET-DRAFT 23]

Internet Draft Service Location Protocol March-96 10 June 1996

query-join:

The format query-join is a comma delimited list of conditions which
the Service Request service must satisfy in order to match the query. The
items are considered to be logically conjoined. Thus the
query-join:

ATTR1=VALUE1, KEYWORD1, KEYWORD2, ATTR2>=34

is equivalent to the where-list:

(& (ATTR1=VALUE1) (KEYWORD1) (KEYWORD2) (ATTR2>=34))

The query-join cannot be mixed with a where-list. It is
provided as follows:

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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number a convenient mechanism to provide a statement of previous responders |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Request Predicate> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
necessary conditions without building a logical expression.

6.4. Service Request

User Agent requests that Predicate Grammar

Service Requests can precisely describe the services they need by
including a Predicate the body of the Request. This Predicate must
be constructed according to the grammar below.

<predicate> ::= <srvtype>['.'<na>]'/'<scope>'/'<where>'/'

<srvtype> ::= string representing type of service. Only
'a' to 'z', 'A' to 'Z', '+' and '-' are allowed.

<na> ::= string representing the Naming Authority.
Only characters from 'a' to 'z', 'A' to 'z',
'+' and '-' are generated by a genesis event, i.e., allowed. If this field is
omitted then "IANA" is assumed.

<scope> ::= string representing the
rebooting directory agent scope.
'/', ',' (comma) and ':' are not allowed in
this string. The scopes "LOCAL" and "REMOTE"
are reserved.

<attr-tag> ::= class name of a system, loading an attribute of a given Service
Type. This tag cannot include the network kernel, etc. should be
sent after following
characters: '(', ')', ',', '=', '!', '>',
'<', '/', '*', except where escaped (see 18.1.)

<keyword> ::= a random interval between 0 and 3 seconds.

The general form class name of an individual reply is as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of URL attribute which will have
no values. This string has the same limits
as the <attr-tag>. In addition white space
internal to the keyword is illegal.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 24]

Internet Draft Service Location Protocol 10 June 1996

<where> ::= <where-any> | <URL String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
<where-list> |
\ <URL String>, Continued. \
<query-join>

<where-any> ::=
That is NOTHING or white space.

<where-list> ::= '(' '&' <where-list> <query-list> ')' |
'(' '|' <where-list> <query-list> ')' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
'(' <keyword> ')'
'(' <attr-tag> <comp-op> <attr-val> ')'

<query-list> ::= <where-list> | Length of Attributes String
<where-list> <query-list>
<query-join> ::= <keyword> | <Attributes String>
<join-item> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<query-join> ',' <keyword> |
<query-join> ',' <join-item>

<join-item> ::= <attr-tag> <comp-op> <attr-val>

<comp-op> ::= "!=" |
\ <Attributes String>, Continued. \ "==" | '<' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The URL "<=" | '>' | ">="

<attr-val> ::= any string conforms to RFC 1738. If (see Section 21.5 for the Service Type does ways
in which attr-vals are interpreted.)
Value strings may not
have a standardized representation, the minimal requirement is:

service:service-type:// ADDRESS SPECIFICATION /

The reply will always contain the Service Type and the ADDRESS
SPECIFICATION.

The Keywords '/', ','
'=', '<', '>', except where escaped (see 18.1.).

'(' and Attributes String ')' may not be included, if there
were no attributes returned as used in attribute values
for the result purpose of encoding a binary values.
Binary encodings (See Section 10.3) may
include the query. Attributes above reserved characters.

6.5. String Matching for Requests

All strings are included in the reply depending case insensitive, with respect to string matching on
queries. All preceding or trailing blanks should not be considered
for a match, but blanks internal to a string are relevant. For
example " Some String " matches "SOME STRING" but not "some
string".

String matching may only be performed over the same character sets.
If a query cannot be satisfied due to a lack of service information
in the "select clause" character set of the
query. A NULL "SELECT CLAUSE" will not include any attribute

Veizades, Kaplan, Guttman, Perkins request a CHARSET_NOT_SUPPORTED error is
returned.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 12]

INTERNET-DRAFT 25]

Internet Draft Service Location Protocol March-96

information. A LIST selection will specify which attributes to
return information about. A WILD selection will return information
about all attributes. (See Section 5.7.)

If attributes 10 June 1996

String comparisons (using comparison operators such as '<' or
'>=') are returned done using lexical ordering in the string takes character set of the form (with
arbitrarily many attributes
registration, not using any language specific rules. The ordering
is strictly by the character value, i.e. "0" < "A" is true when the
character set is US-ASCII, since "0" has the value of 48 and values):

(ATTR1 = VAL), Keyword1,(ATTR2 = VAL1, VAL2), KEYWORD2

TTLs are not returned in "A" has
the value 65.

String matching is done after escape sequences have been substituted.
See sections 18, 6.3, 18.1.

7. Service Replies. Reply Message Format

The format of a the Service Reply Message 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | number of replies returned | <Reply 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Reply 1> (cont.) <URL Entry>-1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Reply N> <URL Entry>-N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Each Service Reply

5.6 Directory Agent Discovery Request

Without a priori knowledge message is composed of a Directory Agent (DA), a User Agent,
Service Application or Service Agent uses a Service Request to
discover a DA. (See section 6.1 for a priori mechanisms for
knowledge list of URL Entries.

The Error Code may have one of a DA.)

This request is generated by the User Agent or Service Agent following values:

0 Success

LANGUAGE_NOT_SUPPORTED
A SA or
Service Application in order to discover DA returns this when a Directory Agent. This request is received
from a normal Service Request. The Service Request predicate used for
Directory Agent Discovery takes the form:

DIRECTORY-AGENT//SCOPE//

This query UA which is to the Directory Agent multicast address. The Service
Type of in a Directory Agent is 'DIRECTORY-AGENT', hence it language for which there is the no
registered Service Type used in the request. No scope is included in the
request, since Information and the query is GLOBAL in scope. No Naming Authority
is included, so 'IANA' is assumed. We want to reach all request arrived
with the
available directory agents. The query selects "SCOPE", so SCOPE
attribute information will be returned, if there is any. The where
clause Monolingual bit set. See Section 18.

PROTOCOL_PARSE_ERROR
A SA or DA returns this error when a SrvReq is empty in the query, so all DAs will match the request.

Veizades, Kaplan, Guttman, Perkins [Page 13]

INTERNET-DRAFT Service Location Protocol March-96

The replies may arrive from different sources. They will received
which cannot be similar
to:

URL returned: SERVICE:DIRECTORY-AGENT://slp-resolver.catch22.com
Attrs returned: (SCOPE=Accounting)

URL returned: SERVICE:DIRECTORY-AGENT://204.182.15.66
Attrs returned: (SCOPE=Janitorial Services)

If the goal parsed.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 26]

Internet Draft Service Location Protocol 10 June 1996

SCOPE_NOT_SUPPORTED
A DA which is merely configured to discover any Directory Agent, the first
reply have a scope will do. If the goal, however, return this
error if it receives a request which is set to have a
scope which it does not support. An SA will not return
this error, it will simply not reply to discover all reachable
DAs, the multicast
request.

CHARSET_NOT_UNDERSTOOD
If the DA or SA receives a request must be retransmitted after an interval (the
recommended time is 3 seconds.) This retransmitted request will
include or registration in a list of DAs
character set which have already responded. This it does not support, it will return
this error.

Each <URL Entry> in the list
takes has the same form as defined at the list of DAs above: a series end of

SERVICE:DIRECTORY-AGENT://ADDRESS SPECIFICATION/

strings. Directory Agents which receive Directory Agent requests
will only respond if they are not on this list. After there are no
new replies, all DAs are presumed to
Section 5.

The URL strings in the reply have been discovered.

5.7 no delimiters between them, other
than the length fields. The length fields indicate where the strings
end.

8. Service Type Request Message Format

The User Agent may use the Service Type Request is used to find determine all the types of
services that are available supported on a network.

The format of the Service Type Request is special in that it
specifies no Service Type for the service type. Instead a '*' is
used to denote a wild card.' The request may should be sent directly to any
Directory Agent. This will return all the Service Types that a DA (though it
knows about.

The request may also be
sent to the Service Location General Multicast Address, Address), in order
to find out all services available on the User Agent's internet site network (which are
advertised by Directory Agents and Service Agents.) A
client can If no DA is
available, a User Agent MAY issue more than one request to insure
that all replies have been received. In each subsequent request, a
User Agent adds
the list of included those Service Types that it is aware of. When no
new replies arrive within CONFIG_INTERVAL_3 from a request, the User
Agent can presume that it has acquired a complete set of available
Service Types.

*//SA Multicast Address//

* is the wild card

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 27]

Internet Draft Service Type. Location Protocol 10 June 1996

The Naming format of a Service Type Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvTypeRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of prev resp string |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of naming authority | <Naming Authority is not
included so 'IANA' is assumed. There is no scope specified in this
example, as the String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Naming Authority String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of scope is GLOBAL (ie. all Service Agents will
respond.) The SELECT CLAUSE requests string | <Scope String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Scope String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that the SA Multicast Address
be returned. This will allow multicast queries in the future.
Finally, the WHERE CLAUSE is empty so the request will match all
services.

Replies are sent by Directory Agents (and Service Agents, in the
case where the request <Previous Responders Addr Spec> is multicast.) These replies take a comma delimited
list. (See section 21.1.) The 'length of prev responder list' field
indicates the form:

Veizades, Kaplan, Guttman, Perkins [Page 14]

INTERNET-DRAFT Service Location Protocol March-96

URL returned: service:printer://
Attributes returned: (SA Multicast Address=224.0.3.10)
URL returned: service:http://
Attributes returned: (SA Multicast Address=224.0.3.24)
URL returned: service:nfs-server://
Attributes returned: (SA Multicast Address=224.0.3.115)

NOTE: These multicast addresses are examples only, length of the official
numbers have not yet been assigned at comma delimited list string. A previous
responder list with 3 elements takes this time.

The service URL defines the type of service. form:

<addr-spec>,<addr-spec>,<addr-spec>

The SA Multicast
Address attribute defines Naming Authority, if included, will limit the multicast address which can be used replies to
send queries Service
Type Requests to Service Agents Types which advertise have the Service Type.
Only specified Naming
Authority. If this field is omitted (i.e., the SA Multicast address length field is returned, since only that was
selected. All Service Types were returned since
zero), the where-clause
was NULL. default Naming Authority ("IANA") is assumed. If the User Agent
length field is already aware of certain Service Types, as in
the case where it has already received several replies, but wants to
be sure that -1, service types from all Service Types naming authorities are discovered, another request is
multicast, with a selection specifying which Service Type information
it is NOT interested in, as:

*//SA Multicast Address/(& (SERVICE TYPE != PRINTER)
(SERVICE TYPE != HTTP)
(SERVICE TYPE != NNTP)
(SERVICE TYPE != NFS-SERVER))/

Only Directory Agents or Service Agents which have services other
than these four types will respond to the request.
requested.

The Naming
Authority is implicitly 'IANA' as none was specified, so only
services registered under this Naming Authority Scope String Field, if included, will have their
information returned.

To request all services which exist under a different Naming
Authority such as, say, IBM, the following query would be used:

*.ibm//SA Multicast Address/()/

5.8 Attribute Request and Attribute Reply

Once a User Agent selects a single Service Type, it may issue a "get
attributes request" limit replies to find all the attributes associated with that Service Type. Since different instances of a given service can, and
very likely will,
Types which have different values for the attributes defined
by the Service Type, the User Agent must form a union of all
attributes returned by specified Scope. If this field is omitted, all service Agents. The Attribute information
will be used to form
Service Queries.

Veizades, Kaplan, Guttman, Perkins Types (from the specified Naming Authority) are returned.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 15]

INTERNET-DRAFT 28]

Internet Draft Service Location Protocol March-96

It 10 June 1996

9. Service Type Reply Message Format

The Service Type Reply has the following form: format:

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) SrvTypeRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Multicast Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number
| Error Code | number of previous responders |<Previous Responders Addr Spec>| service types |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Previous Responders Addr Spec>, continued <Service Type Item>-1 \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Type String> Item>-N \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Request

If sent to a Directory Agent, the number

The format of previous responders a Service Type Item is
zero and there are no Previous Responder Address Specification.
These fields are only used for repeated multicasting, exactly as
for the Service Request.

The replies take the form: follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of Service location header (function = AttrRply) Type String | <Service Type String> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute List> <Service Type String>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of addr spec string | <addr spec> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <addr spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The attribute list has the same form as the attribute list at the
end Error Code may have one of a reply.

For example, an Attribute Request for "printer" might elicit the following reply (UNRESTRICTED_ACCESS is a keyword):

(PAPER COLOR=WHITE,BLUE),
(PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED),
UNRESTRICTED_ACCESS,
(PAGES PER MINUTE=1,3,12),
(LOCATION=12th floor, outside deb's cube),
(PROTOCOL=LPR, PCNFS),
(QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD)

Veizades, Kaplan, Guttman, Perkins values:

0 Success

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 16]

INTERNET-DRAFT 29]

Internet Draft Service Location Protocol March-96

5.9 Service Discovery Request

Having obtained the entire list of attributes used to describe a
particular kind of service from a Get Attributes Request, (or using
a priori knowledge of a service's attributes,) the User Agent can
build a predicate that describes the service needs of the user.

This query 10 June 1996

PROTOCOL_PARSE_ERROR
A SA or DA returns this error when a SrvTypeRqst is sent directly
received which cannot be parsed.

SCOPE_NOT_SUPPORTED
A DA which is configured to have a Directory Agent. Following the
example of the last section, suppose scope will return this
error if it receives a printer is needed on the 12th
floor SrvTypeRqst which has UNRESTRICTED_ACCESS and prints 12 pages per minute.
The response shown above from the Get Attribute Request indicates
that there is set to have a printer on the 12th floor and that there is one that
prints 12 pages per minute, and one that is UNRESTRICTED. To check
whether they are one and
scope which it does not support. An SA will not return
this error, it will simply silently discard the same printer, issue multicast
request.

CHARSET_NOT_UNDERSTOOD
If the following
request:

printer//PROTOCOL/(& (PAGES PER MINUTE==12)
UNRESTRICTED_ACCESS
(LOCATION==12th floor))/

Suppose there is no such printer. The Directory Agent responds with DA receives a Service Reply with 0 SrvTypeRqst in the number of responses and no reply
values.

The User Agent then tries a less restrictive query to find a
printer, using the 12th floor as "where" criteria, but selecting the
PAGES PER MINUTE attribute, to find out how slow character set which
it will be and
whether does not support, it has UNRESTRICTED_ACCESS:

printer//PROTOCOL,PAGES PER MINUTE,UNRESTRICTED_ACCESS/
(LOCATION==12th floor)/

In MUST this case, there is now only one reply:

Returned URL: service:printer://igore.wco.ftp.com:515
Returned Attrs: ((PAGES PER MINUTE = 3),(PROTOCOL=LPR,PCNFS)) error.

The Address Specification for the printer is: igore.wco.ftp.com:515.
This is the location of the printer. Files would be printed by
spooling to that port on that host. Note that the keyword was not
returned. This service type's name is provided in the case because this particular printer did not
have this keyword (it does *not* have UNRESTRICTED_ACCESS.)

In <Service Type String>.
See section 21.3.1 for the absence formal definition of a Directory Agent, the request above could be
multicast. In this case it would be sent to field. The
<addr spec> format is described in 21.4. This field provides
the printer service specific multicast address. If the service specific
multicast address is omitted, the General Service Location Multicast
Address is assumed. User Agents may then use this multicast address
for issuing Service and not Attribute Requests directly to the Directory Agent address above. SAs.

Example Service
Agents that can satisfy the predicate will reply. Type Replies might be:

Multicast Address Service Agents
which cannot satisfy Type String

224.0.3.10 service:lpr://
224.0.3.24 service:http://
224.0.3.115 service:nfs://

NOTE: These multicast addresses are examples only, the reply do official
numbers have not send any reply at all. The
only way yet been assigned.

10. Service Registration Message Format

After a User Service Agent can be sure there are no has found a Directory Agent, it begins to
register its advertised services which match one at a time. A Service Agent
must wait for some random time uniformly distributed within the query is
range specified by retrying the request (say 3 times, 3 seconds apart).
If no response comes, CONFIG_INTERVAL_11 before registering again.
Registration is done using the User Service Registration message
specifying all attributes for a service. A Directory Agent gives up and assumes there are
no such printers.

Veizades, Kaplan, Guttman, Perkins must
acknowledge each service registration request.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 17]

INTERNET-DRAFT 30]

Internet Draft Service Location Protocol 10 June 1996

The format of a Service Registration 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location Protocol March-96

Another form location header (function = SrvReg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL-Entry> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of query is a simpler 'join' query. Its syntax has
no parentheses or logical operators. Each term Attr List String | <attr-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <attr-list>, Continued. \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The <URL-Entry> is conjoined (AND-ed
together.) Rewriting defined at the initial query provides an example:

printer//PROTOCOL/PAGES PER MINUTE==12,
UNRESTRICTED_ACCESS,
LOCATION==12th floor/

One final note: The select field end of the query is used to control
how much information Section 5. The <attr-list>
is returned by the Directory Agent or Service
Agent. As described in full defined in Section 11.1.2, there are 3 ]
different selections possible. A NULL selection will return no
attribute information, merely a 21.2.

Service Type, the Address
Specification. A LIST selection specifies which attributes should be
returned. Finally, a WILD selection can be sent, which will return
all attributes/values. This WILD selection registration may produce use a large
reply, so connectionless protocol (e.g. UDP),
or a TCP connection oriented protocol (e.g. TCP). If the registration
operation may need to contain more information than can be established. Refer sent in one
datagram, the Service Agent MUST use a connection oriented protocol
to
Section 7.0 register itself with the DA. When a Service Agent registers the
same attribute class more than once for details.

6.0 Directory Agents

6.1 Introduction

A a service instance, the
Directory Agent acts on behalf overwrites the all the values associated with that
attribute class for that service instance. Separate registrations
must be made for each language that the service is to be advertised
in.

An example of many Service Registration information is:

Lifetime (minutes): 16-bit unsigned integer
URL (at least): service:<srvtype>://<addr-spec>
Attributes (if any): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2)

In order to offer continuously advertised services, Service Agents and
should start the reregistration process before the Lifetime they used
in the registration expires.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 31]

Internet Draft Service
Applications. It acquires information from them and acts as a
single point Location Protocol 10 June 1996

An example of contact to supply that information to User Agents. a service registration (valid for one day) is as
follows:

Lifetime: 1440
URL: service:lpr://igore.wco.ftp.com:515
Attributes: (SCOPE=DEVELOPMENT),
(PAPER COLOR=WHITE),
(PAPER SIZE=LETTER),
UNRESTRICTED_ACCESS,
(LANGUAGE=POSTSCRIPT, HPGCL),
(LOCATION=12 FLOOR)

The queries same registration could be done again, as shown below, in German;
however, note that a User Agent multicasts to Service Agents (in "lpr", "service", and "SCOPE" are reserved terms
and will remain in the language they were originally registered
(English).

Lifetime: 1440
URL: service:lpr://igore.wco.ftp.com:515
Attributes: (SCOPE=ENTWICKLUNG),
(PAPIERFARBE=WEISS),
(PAPIERFORMAT=BRIEF),
UNBEGRENTZTER_ZUGANG,
(DRUECKERSPRACHE=POSTSCRIPT,HPGCL),
(STANDORT=11 ETAGE)

Registrations must contain an
environment without a Directory Agent) Attribute of SCOPE unless they are
unscoped and then they must be registered with all directory agents.
In the same queries that example above, the
User Agent unicasts SCOPE is set to DEVELOPMENT (in English)
and ENTWICKLUNG (in German). Recall that all strings in a message
must be in one language, which is specified in the header. The
string SCOPE is *not* translated, as it is one of the reserved
strings in the Service Location Protocol (see section 4.3.)

The Directory Agent. A User Agent may cache
information about return a server error in the presence acknowledgment.
This error is carried in the Error Codes field of alternate the service
location message header. A Directory Agents Agent MUST decline to use
in case register
a selected service if it is specified with an unsupported Scope. A Directory
Agent fails.

When scaling service location systems to the size of a campus, SHOULD always accept Service Registrations which have no Scope.
In this case a
central repository SCOPE_NOT_SUPPORTED error is added to limit the amount of general queries returned in the network infrastructure. SrvAck.

An unscoped service registration will match all requests. A site may also grow to such request
which specifies a size certain scope will therefore return services which
have that it scope and services which are unscoped. It is not feasible to maintain only strongly
suggested that one central repository of
service information. In this case more Directory Agents are needed.
Multiple Directory Agents are supported within should use scopes in all registrations or none.
See Sections 17 and 4.7 for details.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 32]

Internet Draft Service Location Protocol 10 June 1996

11. Service Acknowledgement Message Format

A Service Acknowledgement is sent as the framework result of this
protocol.

Each Service Agent or application may register with each a DA receiving
and
hosts may choose processing a DA to use.

Directory Agents, in Service Registration or Service Deregistration. An
acknowledgment indicating success must have the future, may use mechanisms outside of this
protocol error code set to coordinate the maintenance of
zero. Once a DA acknowledges a distributed database of service location information, and thus scale registration it makes the
information available to enterprise networks
or larger administrative domains.

6.2 Directory Agent Discovery

A User or clients.

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 Agent location header (function = SrvAck) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Error Code may have one of the following values:

0 Success

PROTOCOL_PARSE_ERROR
A DA returns this error when the SrvReg or Service Application may SrvDereg could
not be statically
configured to use parsed.

INVALID_REGISTRATION
A DA returns this error when a particular DA. This SrvReg is discouraged unless the
application resides on a network where any form of multicast invalid (it
parses badly or

Veizades, Kaplan, Guttman, Perkins [Page 18]

INTERNET-DRAFT Service Location Protocol March-96

broadcast is impossible.

Alternatively, a host poorly formed in some way.)

SCOPE_NOT_SUPPORTED
A DA which uses DHCP may use it is configured to obtain have a
Directory Agent's address. A DHCP option scope will be assigned for
this purpose. It has not yet been, at the time return this document was
written.

The third way to discover DAs is dynamically. This occurs actively
by sending out
error if it receives a Directory Agent Discovery request.

Lastly, the agent may be informed passively as follows:

When SrvReq which is set to have a Directory Agent first comes on-line
scope which it sends an unsolicited
Service Reply to the general service location multicast address. does not support.

CHARSET_NOT_UNDERSTOOD
If a the DA supports receives a particular scope SrvReg or set of scopes these are
placed SrvDereg in the reply. The class for this attribute is 'SCOPE'.

Every 6 hours a Directory Agent will send an unsolicited Service
Reply again. This will ensure that eventually it will be discovered
by all applications character
set which are concerned.

When a Directory Agent first comes up it begins with 0 as its XID, does not support, it will return this error.

AUTHENTICATION_FAILED
If the DA uses IP Security Authentication and increments the
SA sending a SrvReg or SrvDereg message fails to be
authenticated, the DA will return this by one each time it sends an unsolicited reply. error.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 33]

Internet Draft Service Location Protocol 10 June 1996

12. Service Deregister

When a service is no longer available for use, the counter wraps, it should go Service Agent must
deregister itself from 0xFFFF to 0x0100, not 0.
If the Directory Agent Agents that it has stored all of the been registered
with. A service information
in a nonvolitile store, it should initially set uses the XID following PDU to 256, as
it is not coming up 'stateless.'

All deregister itself.

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 Agents and location header (function = SrvDereg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL> of Service to Deregister \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of tag spec string | <tag spec> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <tag spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Service Applications which receive the
unsolicited reply should examine its XID. If the Directory Agent
has never before been heard from or should retry this operation if the XID there is less than it was
previously and less than 256, no response
from the Service Directory Agent. The Directory Agent or Service
Application should register all service information acknowledges this
operation with the
Directory Agent, after waiting a random interval of between 1 and
3 seconds.

An example of what such an unsolicited reply would look like is:

URL: service:directory-agent://slp-resolver.catch22.com
Attributes: (SCOPE=ADMIN)

This directory agent can be reached at the Address Specification
specified, and supports service acknowledgment. Once the SCOPE called 'ADMIN'.

When a Service Agent or Application, or User Agent first comes
on-line
receives an acknowledgment indicating success, it can assume that the
service is no longer advertised by the Directory Agent. The Error
Code in the Acknowledgment of the Service Deregistration may issues a Directory Agent Discovery Request, have the
same values as
defined described in 5.6 above.

A section 11.

The Service Agent or Application registers information with ALL newly
discovered Directory Agents when either of Deregister Information sent to the above two events take
place. When scopes are being used on Directory Agent is a campus,
URL followed by a Service Agent or
Application may choose <tag-list>, where a set <tag-list> is described by the
following grammar:

<tag-list> ::= <attr-tag> | <keyword> |
<attr-tag> ',' <tag-list> |
<keyword> ',' <tag-list>

For definitions of scopes to be advertised in <attr-tag> and need
only register with <keyword> see 6.4.

This will deregister the specified attributes from the service
information from the Directory Agents that support Agent. If no attribute tags are
included, the scopes entire service information is deregistered in which
they wish to be registered. Services may be every
language and every scope it was registered with DAs

Veizades, Kaplan, Guttman, Perkins in. To deregister the
printer, use:

service:lpr://igore.wco.ftp.com:515

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 19]

INTERNET-DRAFT 34]

Internet Draft Service Location Protocol March-96

which have no scope.

Note that while it 10 June 1996

13. Attribute Request Message Format

The Attribute Request is very highly recommended that all services are
registered with used to obtain attribute information. The
UA supplies a request and the appropriate attribute information is
returned.

If the UA supplies only a Service Type, and the reply includes
all unscoped DAs attributes and with all DAs values for that Service Type. The reply
includes only those attributes for which have a
certain (set of) SCOPE values, it is not strictly required. If services exist and are
advertised by the DA or SA which received the Attribute Request.
Since different instances of a given service isn't registered this way, can, and very likely
will, have different values for the availability of attributes defined by the Service
Type, the User Agent must form a union of all attributes returned by
all service
advertisement Agents. The Attribute information will be limited and possibly inconsistent between DAs. used to form
Service Requests.

If the UA supplies a URL, the reply will contain service information
corresponding to that URL.

Attribute Requests include a 'select clause'. This situation may be acceptable if UAs are preconfigured
(statically or by DHCP) used to only use one particular DA in all
situations. This approach leaves open
limit the chance amount of failure if information returned. If the
preconfigured DA select clause is not available.

Once
empty, all information is returned. Otherwise, the UA supplies
a User Agent becomes aware comma delimited list of a Directory Agent it will unicast
its queries there. In attribute tags and keywords. If the event that more than one Directory Agent
attribute or keyword is detected, defined for a service, it will select one to communicate with. When scopes
are supported, the User Agent will direct its queries to different
Directory Agents depending on which scopes are appropriate domains
for the query to be answered in.

The protocol will cause all DAs (of returned
in the same scope) to eventually
obtain consistent information. Thus one DA should be as good as
any other Attribute Reply, along with all registered values for obtaining service information. There may be temporary
inconsistencies between DAs.

6.3 Service Registration

After a Service Agent that
attribute. If the attribute selected has found a Directory Agent, it begins to
register its advertised services one at a time. A Service Agent
must wait not ben registered for some random interval between 0 and 3 seconds between
each registration. Registration is done using that
URL or Service Type, the attribute or keyword information is simply
not returned.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 35]

Internet Draft Service
Registration packet specifying all attributes for a service. A
Directory Agent must acknowledge each service registration request. Location Protocol 10 June 1996

The format of a Service Registration is: Attribute Request message has the following form:

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) AttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|length of prev responders list |<Previous Responders Addr Spec>|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length |
\ <Previous Responders Addr Spec>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of URL String | <URL String> <URL> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String> <URL>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length length of Attr List String <scope> | <Attribute String> <scope> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute List>, Continued. <Scope>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <select-list> | <select-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <select-list>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Registration

Veizades, Kaplan, Guttman, Perkins [Page 20]

INTERNET-DRAFT Service Location Protocol March-96

Service registration may use a connectionless protocol (e.g. UDP),
or a connection oriented protocol (e.g. TCP).

The registration
operation may contain more information than can be sent <Previous Responder Address List> functions exactly as introduced
in one
datagram. In this case the Service Agent or Application must use
a connection oriented protocol to register itself with the DA.
When Section 8. See also Section 21.1.

The URL String can take two forms: Either it is simply a Service Agent
Type, such as "service:http:", or Application registers the same attribute
class more than once for a service instance, the Directory Agent
overwrites the all the values associated with that attribute class.
Separate registrations must be made for each language that the
service is to it can be advertised in.

Service Registration information is sent in exactly the same form as
a Service Reply:

URL (at least): SERVICE:SERVICE-TYPE://ADDRESS SPECIFICATION
Attributes (if any): (ATTR1=VALUE),KEYWORD,(ATTR2 = VAL1, VAL2)

An example of a service registration is URL, such as follows:

URL: service:printer://igore.wco.ftp.com:515
Attributes: (SCOPE=DEVELOPMENT),
(PAPER COLOR=WHITE),
(PAPER SIZE=LETTER),
UNRESTRICTED_ACCESS,
(LANGUAGE=POSTSCRIPT, HPGCL),
(LOCATION=12 Floor),
(PROTOCOL=LPR,PCNFS)

The same registration could be done again, in German (note that
'printer'
"service:lpr://igore.wco.ftp.com:515". In the SERVICE TYPE and SCOPE are IANA terms former case, all
attributes and will remain
in the language they were originally registered with IANA, i.e.
English):

URL: service:printer://igore.wco.ftp.com:515
Attributes: (SCOPE=ENTWICKLUNG),
(PAPIERFARBE=WEISS),
(PAPIERFORMAT=BRIEF),
UNBEGRENTZTER_ZUGANG,
(DRUECKERSPRACHE=POSTSCRIPT,HPGCL),
(STANDORT=11 Etage),
(PROTOKOLL=LPR,PCNFS)

Registrations must contain an Attribute full range of SCOPE unless they are
unscoped and then they must be registered with all directory agents. values for each attribute for the
Service Type is returned. In the example above, latter case, only the SCOPE attributes
for the service whose URL is set to DEVELOPMENT (in English)
and ENTWICKLUNG (in German.) Recall defined are returned.

The Scope String is provided so that all strings in a packet
must Attribute Requests for Service
Types can be in one language, which is specified in made so that only the header.

The Directory Agent may return Attribute information pertaining
to a server error in the acknowledgment. specific scope will be returned. This error field is carried ignored in the Error Codes field of the service
location packet header. A Directory Agent may decline to register a
service if it is specified with an unsupported SCOPE. In this
case when a SCOPE_NOT_SUPPORTED error full URL is returned sent in the SrvAck.

Veizades, Kaplan, Guttman, Perkins Attribute Request. The rules for
encoding of the Scope String are given in Section 6.4.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 21]

INTERNET-DRAFT 36]

Internet Draft Service Location Protocol March-96

An unscoped service registration will match 10 June 1996

The select list takes the form:

<select-list> ::= <select-item> |
<select-item> ',' <select-list>

<select-item> ::= <keyword> | <attr-tag> | <partial-tag> '*'

<partial-tag> ::= the partial class name of an attribute
followed by an '*' matches all requests. A request
which specifies a certain scope will therefore return services class names
which
have that scope begin with the characters preceding
the '*'

For definitions of <attr-tag> and services which are unscoped. It <keyword> see 6.4.

An example of a select-list following the printer example is:

PAGES PER MINUTE, UNRESTRICTED_ACCESS, LOCATION

If sent to a Directory Agent, the number of previous responders is strongly
suggested that one should use scopes in all registrations or none.
See Section 6.5
zero and Sections 6.6 there are no Previous Responder Address Specification.
These fields are only used for repeated multicasting, exactly as for details.

A non-error acknowledgment must have
the error code set to zero.
Once a DA acknowledges a service registration it makes Service Request.

14. Attribute Reply Message Format

An Attribute Reply Message takes the
information available to clients. form:

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) AttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | length of <attr-list> string |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <attr-list> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Error Code may have the following values:

0 Success

LANGUAGE_NOT_SUPPORTED
A SA or DA returns this when a request is received

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 37]

Internet Draft Service Acknowledgment

In order to offer continuously advertised services, Location Protocol 10 June 1996

from a UA which is in a language for which there is no
registered Service Agents Information and Applications should start the reregistration process before request arrived
with the Monolingual bit set. See Section 18.

PROTOCOL_PARSE_ERROR
A DA or SA returns this error when the AttrRqst could not
be parsed.

SCOPE_NOT_SUPPORTED
A DA which is configured to have a scope will return this
error if it receives an AttrRqst which is set to have
a scope which it does not support. SAs will silently
discard multicast AttrRqst messages for scopes they do
not support.

CHARSET_NOT_UNDERSTOOD
If the
TTL DA receives an AttrRqst in a character set which
it does not support, it will return this error. SAs will
silently discard multicast AttrRqst messages which arrive
using character sets they used do not support.

The <attr-list> (attribute list) has the same form as the attribute
list at the end of a reply, see Section 21.2 for registration expires.

6.4 Service Unregister

When a service is no longer available formal definition
of this field.

An Attribute Request for use, "lpr" might elicit the following reply
(UNRESTRICTED_ACCESS is a keyword):

(PAPER COLOR=WHITE,BLUE),
(PAPER SIZE=LEGAL,LETTER,ENVELOPE,TRACTOR FEED),
UNRESTRICTED_ACCESS,
(PAGES PER MINUTE=1,3,12),
(LOCATION=12TH, NEAR ARUNA'S OFFICE),
(QUEUES=LEGAL,LETTER,ENVELOPE,LETTER HEAD)

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 38]

Internet Draft Service Location Protocol 10 June 1996

15. Directory Agent or
Application must unregister itself from Advertisement Message Format

Directory Agents that it has
been registered with. A service uses Agent Advertisement Messages have the following PDU to
unregister itself. format:

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 = SrvUnreg) DAAdvert) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | Length of URL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <URL String <URL> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length of Service to Unregister> <scope-list> | <scope-list> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <scope-list>, continued \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Unregister

The Service Agent should retry this operation if there Error Code is no
response from set when a DA Advertisement is returned as the Directory Agent.
result of a Service Request. It will always be set to 0 in the case
of an unsolicited DA Advertisement. The Error Code may take the
values specified in Section 7.

The URL corresponds to the Directory Agent acknowledges
this operation with Agent's location. The
<scope-list> is a service acknowledgment. Once comma delimited list of Scopes which the Service
Agent receives this acknowledgment, it can assume that DA
supports, in the service
is no longer advertised by following format:

<scope-list> ::= <scope> | <scope-list> ',' <scope>
<scope> ::= String representing a scope

See Section 6.4 for the Directory Agent.

The Service Unregister Information lexical rules regarding <scope>.

DA Advertisements sent in reply to the a Directory Agent Discovery
Request has the following form:

SERVICE:SERVICE-TYPE:// ADDRESS SPECIFICATION

Veizades, Kaplan, Guttman, Perkins same format as the unsolicited DA Advertisement, for
example:

URL: directory-agent://SLP-RESOLVER.CATCH22.COM
SCOPE List: ADMIN

The Directory Agent can be reached at the Address Specification
returned, and supports the SCOPE called "ADMIN".

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 22]

INTERNET-DRAFT 39]

Internet Draft Service Location Protocol March-96

This will unregister the service from the 10 June 1996

16. Directory Agents

16.1. Introduction

A Directory Agent in every
language it was registered in. To unregister the printer above use:

service:printer://igore.wco.ftp.com:515

6.5 SCOPE Discovery acts on behalf of many Service Agents. It acquires
information from them and Use

The scope mechanism in the service location protocol is an important
feature to enhance its scalability. The primary use acts as a single point of scopes is contact to
provide the capability supply
that information to organize User Agents.

The queries that a campus along administrative
lines. A set of services can be assigned User Agent multicasts to a given department of Service Agents (in an organization, to a certain building or geographical area or for
environment without a
certain purpose. The users of Directory Agent) are the system can be presented with
these organizational elements same as a top level selection, before
services within this domain are sought.

A campus that has grown beyond a size queries that can be reasonably
serviced by a few DAs can use the SCOPE mechanism. DAs have
the
attribute class "SCOPE". The values for this attribute are User Agent might unicast to a list
of strings that represent the administrative areas for which this Directory Agent. A User Agent is an authority. The semantics and language of may
cache information about the
strings used presence of alternate Directory Agents to describe the SCOPE are entirely
use in case a selected Directory Agent fails.

Aside from enhancing the choice scalability of the
administrative entity protocol (see
section 4.7), running multiple DAs provides robustness of the particular domain in which these SCOPEs
exist. operation.
The values DAs have replicated service information which remain accessible
even when one of SCOPE should be configurable, so the system
administrator can set its value. The SCOPE "LOCAL" is reserved and
must not be used, DAs fail. Directory Agents, in the future, may
use mechanisms outside of this reserved value may be defined in a
future protocol document.

Services with to coordinate the attribute SCOPE should only be registered maintenance
of a distributed database of service location information, and thus
scale to enterprise networks or larger administrative domains.

Each Service Agent must register with all DAs which support they are configured to
use. UAs may choose among DAs they are configured to use.

Locally, Directory Agent consistency is guaranteed using mechanisms
in the same scope or protocol. There isn't any Directory to Directory Agent
protocol yet. Rather, passive detection of DAs which have no SCOPE. by SAs ensures that
eventually service information will be registered consistently
between DAs. Invalid data will age out of the Directory Agents advertise
leaving only transient stale registrations even in the list case of all scopes that are
available. A a
failure of a Service Agent Agent.

16.2. Finding Directory Agents

A User or Service Application Agent may then choose
at least one scope in which to be registered, and should register
with all Directory Agents in that scope, as well as all DAs statically configured to use a
particular DA. This is discouraged unless the application resides on
a network where any form of multicast or broadcast is impossible.

Alternatively, a host which
have no scope. Failure uses DHCP [2, 10] may use it to obtain a
Directory Agent's address. A DHCP option will be comprehensive in registration
according to assigned for this rule will mean that the service advertisement may
purpose. It has not be discoverable yet been, at the time this document was written.

The third way to discover DAs is dynamically. This occurs actively
by all User Agents.

A Directory Agent which has sending out a SCOPE will send replies to Directory Agent Discovery requests with request (see Section 6.2).

Lastly, the scope information included. Note
that Directory Agent Requests should always select that SCOPE
information agent may be returned. Note that the directory-agent Service Type
is registered with the IANA naming authority (which is automatically
selected by leaving the Naming Authority field empty.)

The query:

directory-agent//SCOPE//

Could receive the following reply:

Returned URL: service:directory-agent://diragent.void.com
Returned Attribute: (SCOPE=ADMINISTRATION)

Veizades, Kaplan, Guttman, Perkins informed passively as follows:

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 23]

INTERNET-DRAFT 40]

Internet Draft Service Location Protocol March-96

The same 10 June 1996

When a Directory Agent if first comes on-line it had no SCOPE value would reply:

Returned URL: service:directory-agent://diragent.void.com
Returned Attributes: sends an unsolicited DA
Advertisement to the service location general multicast address. If
a DA supports a particular scope or set of scopes these are placed in
the reply. The class for this attribute is 'SCOPE'.

Every CONFIG_INTERVAL_9 a Directory Agent supported more than will send an unsolicited
DA Advertisement again. This will ensure that eventually it will be
discovered by all applications which are concerned.

When a Directory Agent first comes up it begins with 0 as its XID,
and increments this by one scope each time it sends an unsolicited DA
Advertisement. When the counter wraps, it would reply as:

Returned URL: service:directory-agent://123.12.34.56
Returned Attributes: (SCOPE=ADMIN,DEV,SALES)

Normally all Directory Agents respond should go from 0xFFFF to a Directory Agent Request.
0x0100, not 0.

If only the Directory Agents Agent has stored all of the service information in
a particular nonvolatile store, it should initially set of scopes are desired,
issue a query like the following:

directory-agent//SCOPE/(SCOPE=ADMIN,SALES)/

Here the SCOPE field of the request is left blank, but the WHERE
clause of the request XID to 0x100, as it
is filled not coming up 'stateless.' If it stores service registrations in with a list of the scopes which
can be used
memory only, it will restart without any state. It should indicate
this by resetting its XID to satisfy 0.

All Service Agents which receive the request. Normally a single SCOPE would
be filled in for a query, in unsolicited DA Advertisement
should examine its XID. If the SCOPE field, but in Directory Agent has never before
been heard from or if the XID is less than it was previously and
less than 256, the Service Agent should assume the special
case of a DA query does not have
its service registration, even if it once did. If this is not done.

A the case
and the DA which has no scope will reply to any the proper Scope, the SA should register all service
information with the Directory Agent, after waiting a random interval
CONFIG_INTERVAL_10.

When a Service Agent Discovery
Request.

Being or User Agent first comes on-line it must issue
a member Directory Agent Discovery Request unless it is using static or DHCP
configuration, as described in 6.2.

A Service Agent registers information with ALL newly discovered
Directory Agents when either of a scope means that an agent the above two events take place.
When scopes are being used, a Service Agent may use choose a specific set of
scopes to be advertised in and need only register with Directory
Agents that support its scope. User Agents send all
requests to DAs which support the indicated scope. scopes in which they wish to be registered.
Services are MUST be registered with the DA(s) in their scope. For a UA to find a
service DAs that is registered in a particular support their scope they must send
requests to a DA and
those which supports the indicated scope. There is have no
limitation on scope membership built into the protocol; that is scope, unless specifically configured not to
say, do
so (see section 23.1.)

Once a User Agent or Service Agent or Application may be a member becomes aware of a Directory Agent it will unicast
its queries there. In the event that more than one scope. Membership is open to all, unless some
external authorization mechanism Directory Agent
is added detected, it will select one to limit access.

6.6 Service Location Scaling and Operating Modes

In a very small network, with few nodes, no DA is required. A communicate with. When scopes
are supported, the User Agent can detect services by multicasting requests. Service will direct its queries to different
Directory Agents depending on which scopes are appropriate domains
for the query to be answered in.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 41]

Internet Draft Service Location Protocol 10 June 1996

The protocol will then reply cause all DAs (of the same scope) to eventually
obtain consistent information. Thus one DA should be as good as any
other for obtaining service information. There may be temporary
inconsistencies between DAs.

17. Scope Discovery and Use

The scope mechanism in the service location protocol enhances its
scalability. The primary use of scopes is to them. This does not scale provide the capability
to environments with
many hosts. Further, Service Agents not Service Applications must organize a site network along administrative lines. A set of
services can be used assigned to make service information available.

In a larger but still administratively simple network, given department of an organization,
to a single DA
may suffice. In this network, the DA will not have any SCOPE. DAs
that are discovered will return no list certain building or geographical area or for a certain purpose.
The users of SCOPES. Service Agents
and Service Applications should register the system can be presented with these organizational
elements as a top level selection, before services within this DA even if they domain
are configured to specifically register with DAs which have sought.

A site network that has grown beyond a
specific scope or set of scopes. User Agents will query size that can be reasonably
serviced by a few DAs without
scopes, even if they are configured to can use the Scope mechanism. DAs with a certain scope.
This is because when a DA with no SCOPE is discovered, it will have
all the available service information
attribute class "SCOPE". The values for this attribute are a list
of strings that represent the administrative areas for which this
Directory Agent is an authority. The semantics and no scoped DAs will language of the
strings used to describe the Scope are almost entirely the choice of
the administrative entity of the particular domain in which these
Scopes exist.

Veizades, Kaplan, Guttman, Perkins [Page 24]

INTERNET-DRAFT Service Location Protocol March-96

In a large campus or organization several DAs will The values of SCOPE should be used in order
to divide configurable, so the load of maintaining service information
system administrator can set its value. The scopes "LOCAL" and
"REMOTE" are reserved and SHOULD NOT be used. Use of these reserved
values is to
organize which services should be used by which community. In this
case ALL DAs SHOULD HAVE A SCOPE. All Service Registrations that
have defined in a scope future protocol document.

Services with the attribute SCOPE should only be registered with all DAs of that
which support the same scope or DAs which have been or are subsequently discovered. Unscoped services should
be registered no Scope.

Directory Agents advertise the available scopes. A Service Agent may
then choose a scope in which to register, and SHOULD register with
all DAs as they are implicitly GLOBAL in scope.
User Directory Agents make requests of in that scope, as well as all DAs which whose SCOPE they are
configured have no
scope. Failure to use.

In each case where 'should' is used above, one should keep be comprehensive in mind
that if the registration according to this
rule is not followed the availability of will mean that the service
information advertisement may not be limited or inconsistent across discoverable
by all User Agents.

A Directory Agent which has a Scope will send replies to Directory
Agent Discovery requests with the service
location system.

There are thus 3 distinct operating modes. scope information included. Note
that the directory-agent Service Type is registered with the IANA
naming authority (which is automatically selected by leaving the
Naming Authority field empty.)

The first requires no
administrative intervention. query:

directory-agent:/MATH DEPT//

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 42]

Internet Draft Service Location Protocol 10 June 1996

Could receive the following DA Advertisement:

Returned URL: directory-agent://diragent.blah.edu
Returned SCOPE: MATH DEPT

The second requires only that same Directory Agent if it had no Scope value would reply:

Returned URL: directory-agent://diragent.void.com
Returned SCOPE:

If a Directory Agent supported more than one scope it would reply as:

Returned URL: directory-agent://srv.domain.org
Returned SCOPE: MATH DEPT,ENGLISH DEPT,CS DEPT

A DA be
run. The last requires that all DAs be configured to have SCOPE and
that a coherent strategy of assigning SCOPES to services be
followed. Users must be instructed which SCOPES are appropriate for
them to use. This administrative cost has no scope will allow users and
applications reply to dynamically discover services without assistance.

7.0 Service Location Connections

When a Service Location Request results in any Directory Agent Discovery
Request.

Being a reply from member of a Service or scope means that an agent may use those Directory Agent
Agents that will overflow a datagram, the support its scope. User Agent can
open a connection Agents send all requests to DAs
which support the Agent and reissue the request over the
connection.

The reply will be returned indicated scope. Services are registered with the overflow bit set (see section
5.4.6). The reply will contain data, as much as will fit into
DA(s) in their scope. For a
single packet. If no MTU information is available for the route,
assume that UA to find a maximum packet size service that is 1400.

When a request results registered
in overflowed data that cannot be correctly
parsed (say, because of duplicate or dropped IP packets), a User
Agent that wishes to reliably obtain the overflowed data particular scope they must
establish send requests to a connection with DA which supports
the Directory Agent or Service Agent
with indicated scope. There is no limitation on scope membership
built into the data. The request protocol; that is simply sent again (with to say, a User Agent or Service
Agent may be a new XID,
however.) The reply member of more than one scope. Membership is returned over the connection stream.

A open to
all, unless some external authorization mechanism is added to limit
access.

18. Language and Character Encoding Issues

All Service registration Registrations declare the language in which exceeds one packet the strings
in length should be
made the service attributes are written by establishing a connection with a Directory Agent and sending specifying the registration over appropriate
code in the message header. For each language the connection stream.

Directory Agents and Service Agents must respond to connection
requests and Services whose advertises
a separate registration takes place. The Service needs to be
deregistered only once since the information associated with it will
be unique. There can exceed only be one service of a given type at a packet given
address specification even if it is registered in
length must be able to connect multiple languages.

Service Registrations in different languages are mutually
unintelligible. They share no information except for their service
type and send. User Agents should be able
to make requests over a connection. If they fail to implement this, URL string with which they must be able were registered. No attempt is
made to interpret partial replies and/or reissue
requests match queries with more selective criteria "language independence." Instead, queries
are handled using string matching against registrations in the same
language as the query.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 43]

Internet Draft Service Location Protocol 10 June 1996

Service Types which are standardized will have definitions for
all attributes and value strings. Official translations to reduce other
languages of the attribute tags and values may be created and
submitted as part of the standard; this is not feasible for all
languages. For those languages which are not defined as part of the size
Service Type, a best effort translation of the standard definitions
of the
replies.

Veizades, Kaplan, Guttman, Perkins [Page 25]

INTERNET-DRAFT Service Location Protocol March-96

A connection initiated by an Agent may type's attribute strings MAY be used for used.

All Service Requests specify a single
transaction. It may also be used for multiple transactions. Since
there are length fields requested language in the packet headers, message
header. The Directory Agent or Service Agent will respond in the Agents may send
multiple requests along
same language as the request, if it has a connection and read registration in the return stream for
acknowledgments same
language as the request. If this language is not supported, and replies. The Agent the
Monolingual bit is responsible for closing not specified, a reply can be sent in the TCP connection. The DA should wait at least 30 seconds before
closing an idle connection.

8.0 Security Considerations

There are no provisions default
language (which is English.) If the 'monolingual bit' flag in this protocol the
header is set and the requested language is not supported, a SrvRply
is returned with the error field set to insure data integrity,
data authority or data confidentiality. Mechanisms LANGUAGE_NOT_SUPPORTED.

If a query is in the
underlying network layer protocol a supported language on a SA or at DA, but has a
different dialect than the available service access point
may information, the query
MUST be used to provide these functions. An Agent may choose to
ignore a transaction based serviced on security information supplied by
other (underlying) services. As a best-effort basis. If possible, the query
should be matched against the same dialect. If that is not possible,
it MAY be matched against any dialect of the same language.

18.1. Character Encoding and String Issues

Values for character encoding can be found in the absense of Service Location,
end-to-end authentication should be used between clients Internet Assigned
Numbers Authority's (IANA) database
(http://www.isi.edu/in-notes/iana/assignments/character-sets), and
services.

9.0 Multicast vs. Broadcast
have the values referred by the MIBEnum value.

The service location protocol was designed for use in networks
where multicast at encoding will determine the network layer interpretation of all character data
which follows the Service Location protocol header. There is supported; in some instances
multicast may not no way
to mix ASCII and UNICODE, for example. All responses must be supported. To support this protocol in
networks where multicast is not supported the following
modifications are made to support
character set of the protocol in an environment
where network layer broadcast is supported.

9.1 Single Subnet request or use US-ASCII. If a network request is not connected sent
to any other networks simple network
layer broadcasts will work in place of multicast.

9.2 Multiple Subnets

The Directory Agent provides a central clearing house of information
for User Agents. If the network DA or SA or a registration is designed so that sent to a Directory
Agent address DA, which is statically configured with each User Agent, unable to
manipulate or store the
Directory Agent character set of the incoming message, the
request will act as a bridge for information that resides on
different subnets. fail. The Directory Agent address can be dynamically
configured with Agents using DHCP SA or staticly configured, but Agents
will not be able to discover DAs on non-bridged subnets.

As dynamic discovery is not feasible in DA returns a broadcast environment and
manual configuration is difficult, multiple DAs CHARSET_NOT_UNDERSTOOD
error in a broadcast
environment may SrvAck message in this case. Requests using US-ASCII will
never fail for this reason, since all SAs and DAs must be difficult to deploy.

9.3 Service Multicast Address

Each service MAY have a unique multicast address able to which it belongs
to. This multicast address may be obtained from IANA. This
mechanism
accept this character set.

Certain characters are illegal in certain contexts of the protocol.
Since the protocol is largely character string based, in some
contexts characters are used so that as protocol delimiters. In these cases
the number of datagrams any one service
receives is minimized. The Service Location General Multicast
Address may delimiter characters must not be used to query for any service, though one should use

Veizades, Kaplan, Guttman, Perkins as 'data text.'

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 26]

INTERNET-DRAFT 44]

Internet Draft Service Location Protocol 10 June 1996

18.1.1. Substitution of Character Escape Sequences

The Service Location Protocol March-96 has an 'escape mechanism' which
is consistent with HTTP 2.0 [6] and SGML [13]. If the service-specific multicast address if it exists.

When undirected queries character
sequence "&#" is followed by one or more digits, followed by
a semicolon ';' the entire sequence is interpreted as a single
character. The digits are made concerning this type of service, interpreted as a decimal value in the query should be sent to
character set of the matching multicast address. If request, as specified by the
subnet does header. Thus, in
US-ASCII &#44; would be interpreted as a comma. Substitution of
these escape strings must be done in all <attr-list> and strings
present in SrvReq and AttrRqst messages. Only numerical character
references are accepted, not support multicast then the query 'Entity References,' as defined in HTML.
These escape values should only be broadcast used to the Service Location port. If the underlying hardware will not
support the number provide a mechanism for
including reserved characters in attribute tag and value strings.

The interpretation of need multicast addresses all services can use these escape values is different than in
HTML in one respect: In HTML the general service location multicast address.

10.0 escape values are considered to
be in the ISO Latin-1 character set. In Service Location they
are interpreted in the Internet

A subsequent protocol document will describe character set defined in the header of the
message.

This escape mechanism for
supporting allows characters like commas to be included in
attribute tags and values, which would otherwise be illegal as the
comma is a service discovery protocol delimiter.

Attribute tags and values of different languages are considered to be
mutually unintelligible. A query in a global Internet.

11.0 Protocol Formats

11.1 Fields Used one language SHOULD use service
information registered in that language.

18.2. Language Dialect

Dialect tags are used in Service Location Packets

The following section supplies formal definitions for all protocol
elements introduced in the sections above.

Protocol Element Used in
----------------------------------- -------------
11.1.1 <Previous Responders' Addr Spec> SrvRqst
11.1.2 <Service Request Predicate> SrvRqst
11.1.3 <Reply> SrvRply
11.1.4 <Service Registration Information> SrvReg
11.1.5 <Service Unregister Information> SrvUnReg
11.1.6 <Attribute List> AttrRply
11.1.7 <Service Type String> AttrRqst

11.1.1 Previous Responders' Address Specification

The previous responders' Address Specification messages to indicate a
variant of vocabulary used. If one service is specified as

ie. registered in more
than one dialect, a list separated and terminated by commas DA or SA SHOULD return the one with no intervening
white space. The Address Specification is the address of same
dialect tag as in the
Directory Agent or Service Agent which supplied query, but MAY choose to return any registered
service that matches the previous
response. The format for Address Specifications criteria.

Dialects (unlike languages) are assumed to be mutually intelligible,
but may have variations in Service Location spelling. Since string matching is defined used,
it is advantageous in 11.2.

Example:

some.corp.com,128.127.203.63,

Veizades, Kaplan, Guttman, Perkins some cases to register service information in
multiple dialects.

Dialect tags will be assigned as enumerated values to correspond to
the official dialects registered with the IANA. There are as of this
writing no enumerated dialect values; they will be created as needed.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 27]

INTERNET-DRAFT 45]

Internet Draft Service Location Protocol March-96

11.1.2 10 June 1996

18.3. Language-Independent Strings

Some strings, such as Service Request Predicate

The following grammar expresses Type names, have standard definitions.
These strings should be considered as tokens and not as words in a
language to be translated.

Reserved String Section Definition
--------------- ------- --------------------------------------
SCOPE 4, 16 Used to limit the form scope of requests.
SERVICE TYPE 8 Used in Service Type requests.
SERVICE 10, 7 The URL scheme of all Service Location
information registered with a DA or
returned from a Service Request
Predicate:

<predicate> ::= <srvtype>[.<na>]/<scope>/<select>/<where>/ Request.
<srvtype> ::= string representing type of service. Only
'a' to 'z', '+' 21.3.1 Used in all service registrations
and '-' are allowed.
<na> ::= string representing the Naming Authority.
Only characters from 'a' to 'z', '+' replies.
domain names 21.4 A fully qualified domain name, used
in registrations and '-'
are allowed. If this field is omitted 'IANA' replies.
SA MULTICAST ADDRESS 8 An attribute whose value is assumed.
<scope> ::= string representing the directory agent scope.
'/' and ':' are not allowed in this string.
service-specific multicast address.
IANA 4.3 The scopes 'LOCAL' and 'REMOTE' are reserved.

<select> ::= <select-list> |
<select-all> |
<select-none>
<select-list>::= <select-item> |
<select-item>, <select-list>
<select-item>::= <keyword> | <attr-tag> | <partial-attr-tag>*
<attr-tag> ::= class name of an attribute of default naming authority.
LOCAL 17 Reserved.
REMOTE 17 Reserved.
TRUE 21.5 Boolean true.
FALSE 21.5 Boolean false.

19. Service Location Transactions

19.1. Service Location Connections

When a given Service Type.
This tag cannot include Location Request or Attribute Request results in a
UDP reply from a Service or Directory Agent that will overflow a
datagram, the following
characters: '(', ')', ',', '=', '!', '>',
'<', '/', '*'
<keyword> ::= User Agent can open a class name of an attribute which connection to the Agent and
reissue the request over the connection. The reply will have
no values. This string has be returned
with the same limits overflow bit set (see section 5). The reply will contain as
much data as will fit into a single datagram. If no MTU information
is available for the <attr-tag>. In addition white space
internal to route, assume that the keyword MTU is illegal.
<partial-tag>::= the partial class name 1400; this value
is configurable (see section 23).

When a request results in overflowed data that cannot be correctly
parsed (say, because of an attribute
followed by an '*' matches all class names
which begin duplicate or dropped IP datagrams), a
User Agent that wishes to reliably obtain the overflowed data must
establish a TCP connection with the characters preceding Directory Agent or Service Agent
with the '*'
<select-all> ::= *
<select-none>::=
That data. The request is NOTHING or white space.

<query-list> ::= <where-list> |
<query-item> |
<query-item> <query-list>
<query-item> ::= (<attr-tag> <comp-op> <attr-val>) |
<keyword>
<query-join> ::= <join-item> |
<join-item>, <query-join>

Veizades, Kaplan, Guttman, Perkins returned over the connection stream.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 28]

INTERNET-DRAFT 46]

Internet Draft Service Location Protocol 10 June 1996

When registration data exceeds one datagram in length, the Service
Registration should be made by establishing a connection with a
Directory Agent and sending the registration over the connection
stream.

Directory Agents and Service Agents must respond to connection
requests; services whose registration data can overflow a datagram
must be able to use TCP to send the registration. User Agents should
be able to make Service Location Protocol March-96

<join-item> ::= <attr-tag> |
<attr-tag> <comp-op> <attr-val>
<comp-op> ::= != | == | < | <= | > | >=
<attr-val> ::= any string (see Section 10.3 for Requestsequests using TCP. If they fail to
implement this, they must be able to interpret partial replies and/or
reissue requests with more selective criteria to reduce the ways
in which attr-vals are interpreted.)
Value strings size of
the replies.

A connection initiated by an Agent may not contain '/', ','
'=', '<', '>'. '(' and ')' can only be used for the purpose of encoding a binary values.
Binary encodings (See Section 10.3) single
transaction. It may
include the above reserved characters.

Note on string matches: All strings are case insensitive, with respect
to string matching on queries. All preceding or trailing blanks should
not also be considered used for multiple transactions. Since
there are length fields in the message headers, the Agents may send
multiple requests along a match, but blanks internal connection and read the return stream for
acknowledgments and replies.

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

There is no requirement that one transaction complete before a string
given host begins another. An agent may have multiple outstanding
transactions, initiated either using UDP or TCP.

All Service Location actions are
relevant. For example " Some String " matches "SOME STRING" but not
"some string".

A predicate has a simple structure, which depends on the parentheses,
commas idempotent. Of course registration
and slashes to delimit deregistration will change the elements. Examples state of proper usage a DA, but repeating these
actions will have been given throughout exactly the document. same effect each time.

20. Security Considerations

The terms used above are
described below:

predicate:
Placed in a Service Request, Location protocol does not provide authentication,
integrity or confidentiality. Because the objective of this
protocol is interpreted by a Service
Agent or Directory Agent to determine what information advertise services to
return.

scope:
If a community of users,
confidentiality might not generally be needed when this protocol is absent
used in non-sensitive environments. Authentication and integrity
are functionally equivalent in a Service Request, the request will match
any service regardless context of scope. If it this protocol.
Authentication is present, only generally needed with this protocol.

An adversary can easily use this protocol to advertise services registered under that scope will match on
servers controlled by the request.

select-clause:
This determines what information adversary and thereby gain access to return. There are 3 types users'
private information. Further, an adversary using this protocol
will find it much easier to engage in selective denial of select-clause: NULL, ANY and LIST.
NULL: The reply returns no attribute information for the
PARTICULAR services which satisfy the where-clause.
ANY: The reply returns all attribute information, as above.
LIST: The reply returns service

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 47]

Internet Draft Service Location Protocol 10 June 1996

attacks. Sites that are in potentially hostile environments (e.g.
are directly connected to the attribute information for Internet) should consider the
attributes whose class names are listed, as above.
Recall that an attribute has a class name and a set security
risks of values. deploying this protocol prior to deploying it.

The list contains a set of class names.
Elements security risks in the list this protocol can be partial names, as 'INT*'
will match 'INTERFACE 1' and 'INTERNAL'.

where-clause:
This determines which services the request matches. An empty
where-clause will match all services. The request will be
limited to services which have significantly reduced or
eliminated by using the IP Authentication Header [5, 3] with all
Service Type which was defined
prior to Location messages. It is recommended that sites use the predicate, so
IP Authentication header with all Service Location messages. For
the where-clause security considerations listed above, it is not the sole
factor in picking out recommended that
all nodes which services match implement Service Location also implement the request.

where-list:
The where-list IP
Authentication Header.

Sites requiring confidentiality should implement the IP Encapsulating
Security Payload (ESP) [4] to provide confidentiality for Service
Location messages.

Service Location is useful as a logical expression. bootstrap protocol. It can may be a single

Veizades, Kaplan, Guttman, Perkins [Page 29]

INTERNET-DRAFT Service Location Protocol March-96

expression, a disjunction or a conjunction. A single expression
must apply for the where-clause to match. A disjunction matches
if any expression
used in the OR list matches. A conjunction matches
only if all elements environments in the AND list match.

Note that there is which no logical negation operator: This preconfiguration is
because there possible. In
such situations, a certain amount of "blind faith" is no notion required:
Without any prior configuration it is impossible to use any of returning "everything except" what
matches a given criteria.

A where-list can be nested and complex. For example:
(& (| <query-item> <query-item> <query-item>)
<query-item>
(& <query-item> <query-item> <query-item> <query-item>)
)

Notice that white space, tabs or carriage returns can be added
anywhere outside query-items. Each list has 2 or more items in
it, and lists can be nested. Services which fulfill the entire
logical expression match
security mechanisms described above. Service Location will make
use of the where-clause.

(| <query-item>) and (& <query-item>) are degenerate expressions
but they should be tolerated. They are equivalent to
<query-item>.

query-item:
A query item has mechanisms provided by the form:
(<attr-tag> <comp-op> <attr-val>)
or
<keyword>

Examples Security Area of the IETF for
key distribution as they become available. At this point it would be:
(SOME ATTRIBUTE == SOME VALUE)
RESERVED
(QUEUE LENGTH <= 234)

query-join:
The query-join is a comma delimited list of conditions which the
service must satisfy in order
only be possible to match deploy the query. The items are
considered to IP Authentication Header if some
certificate information can be logically conjoined. Thus preconfigured with the query-join:

attr1=value1, keyword1, keyword2, attr2>=34

is equivalent to end systems
before they use Service Location.

21. String Formats used with Service Location Messages

The following section supplies formal definitions for fields and
protocol elements introduced in the where-list:

(& (attr1=value1) keyword1 keyword2 (attr2>=34)) sections indicated.

Protocol Element Defined in Used in
----------------------------------- ------------ ------------
<Previous Responders' Addr Spec> 21.1 SrvReq
Service Request <predicate> 6.4 SrvReq
<URL-String> 21.2 SrvReg,
SrvDereg,
SrvRply
<attr-list> 21.3 SrvReg,
SrvRply,
AttrRply
<Service Registration Information> 10 SrvReg
<Service Deregister Information> 12 SrvDereg
<Service Type String> 21.3.1 AttrRqst

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 48]

Internet Draft Service Location Protocol 10 June 1996

21.1. Previous Responders' Address Specification

The query-join cannot be mixed with a where-list. It previous responders' Address Specification is provided specified as

i.e., a convenient mechanism to provide a statement list separated and terminated by commas with no intervening
white space. The Address Specification is the address of necessary
conditions without building a logical expression.

Veizades, Kaplan, Guttman, Perkins [Page 30]

INTERNET-DRAFT the
Directory Agent or Service Agent which supplied the previous
response. The format for Address Specifications in Service Location Protocol March-96

11.1.3
is defined in section 21.4. The comma delimiter is required between
each <addr-spec>. The use of dotted decimal IP address notation
should only be used in environments which have no Domain Name
Service.

Example:

RESOLVO.NEATO.ORG,128.127.203.63

21.2. Reply and Registration Information

Service Replies and Service Registrations have two fields, fields -- a URL String
and an attribute list.
URL Strings URLs are as per defined in RFC 1738. 1738 [7]. They
should contain at least:

SERVICE:SERVICE-TYPE:// ADDRESS SPECIFICATION

SERVICE is least:

<url> ::= service:<srvtype>://<addr-spec>

where:

service the URL scheme for service location, to return
Replies.
SERVICE-TYPE is

<srvtype> a string. string; Service Types may be standardized
by developing a specification for the "service
type"-specific part and registering it with the
IANA. See section 5.3.4.
ADDRESS SPECIFICATION is 18.

<addr-spec> the service access point of the service. It is the
network address or domain name where the service can
be accessed. See section 21.4.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 49]

Internet Draft Service Location Protocol 10 June 1996

21.3. Attribute Information

The <attr-list> is returned if in the select-clause of Attribute Reply if the query is Attribute
Request does not NULL. result in an empty result.

<attr-list> ::= <attribute> | <attribute>, <attr-list>
<attribute> ::= (<attr-tag>=<attr-val-list>) | <keyword>
<attr-val-list> ::= <attr-val> | <attr-val>, <attr-val-list>

An attribute with <attr-list> must be scanned prior to evaluation for all
occurrences of the string "&#" followed by one or more digit followed
by ';'. See Section 18.1 and specifically Section 18.1.1.

A keyword has only an attr-tag <attr-tag>, and no values is a keyword. values.

A comma cannot appear in an attr-val, <attr-val>, as the comma is used as the
multiple value delimiter. Examples of an attr-list <attr-list> are:

(SCOPE=ADMINISTRATION)
(COLOR=RED, WHITE, BLUE)
(DELAY=10 Mins),BUSY,(MOST RECENT MINS),BUSY,(LATEST BUILD=10-5-95),(PRIORITY=L,M,H)

The third example has three attributes in the list. Color can take
on the values red, white and blue. There are several other examples
of replies throughout the document.

11.1.4 Service Registration Information

The Service Registration Information has the same form as a Reply
in the section above. The attribute list must be complete.

11.1.5 Service Unregister Information

The Service Unregister Information takes the form:

SERVICE:SERVICE-TYPE:// ADDRESS SPECIFICATION

SERVICE-TYPE and ADDRESS SPECIFICATION are described above.

11.1.6 Attribute List

The Attribute List is defined in 11.1.3 as <attr-list>.

Veizades, Kaplan, Guttman, Perkins [Page 31]

INTERNET-DRAFT Service Location Protocol March-96

11.1.7

21.3.1. Service Type String

The Service Type is a string describing the type of service. These
strings may only be comprised of 'a' through 'z', '+' and '-'. Upper
case is considered equivalent to lower case in Service Type names.

If the Service Type name is followed by a '.' and a string (which
has the same limitations) the 'suffix' is considered to be the Naming
Authority of the service. If the Naming Authority is omitted, IANA
is assumed to be the Naming Authority.

Service Types developed for in-house or experimental use may have any
name and attribute semantics provided that they do not conflict with
the standardized Service Types. The Service Type's Service
Discovery specific
Multicast Address used should taken from the range of experimental
multicast addresses reserved by the IANA.

11.2 ADDRESS SPECIFICATIONs

21.4. Address Specification in Service Location

The address specification as described used in RFC 1738 Service Location is:

//<user>:<password>@<host>:<port>

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 50]

Internet Draft Service Location Protocol 10 June 1996

<addr-spec> ::= [<user>:<password>@]<host>[:<port>]

<host> ::= Fully qualified domain name |
dotted decimal IP address notation

It is preferable to use a fully qualified domain name wherever
possible as renumbering of host addresses will make ip IP addresses
invalid over time.

When no Domain Name Server is available SAs and DAs must use dotted
decimal conventions for IP addresses.

Generally

Generally, just the host domain name (or address) is sufficient to
return. When there is a non-standard port for the protocol, that
should be returned as well. Some applications may make use of the
<user>:<password>@ syntax, but its use is discouraged not encouraged in this
context as information registered until mechanisms are established to maintain confidentiality.

Address specification in Service Location is so easily
accessible.

11.3 consistent with standard
URL format [7].

21.5. Attribute Value encoding rules

Attribute values, and attribute tags are CASE INSENSITIVE for
purposes of lexical comparison.

Attribute values can have be any string with the exception of '(',
')', '=', '>', '<', '/' and ',' (the comma) except in the case
described below where opaque values are encoded. These characters
may be included using the character value escape mechanism described
in section 18.1.

While an attribute can take any value, there are three types
of values which differentiate themselves from general strings:
Booleans, Integers and Opaque values.

- Boolean values are either "TRUE" or "FALSE". This is the case
regardless of the language (i.e. in French or Telugu, Boolean
TRUE is "TRUE", as well as in English.) Boolean attributes can
take only one value.

Veizades, Kaplan, Guttman, Perkins [Page 32]

INTERNET-DRAFT Service Location Protocol March-96

- Integer values are expressed as a sequence of numbers. The range
of allowable values, for this 32 bit quantity, is "-2147483648"
to "2147483647". Note: No other form of numeric representation
is interpreted as such, save integers. For example, hexadecimal
numbers such as "0x342" are not interpreted as integers, but as
strings.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 51]

Internet Draft Service Location Protocol 10 June 1996

- Opaque values (i.e. binary values) are expressed in radix-64
notation. The syntax is:

<opaque-val> ::= (<len>:<radix-64-data>)
<len> ::= integer length number of bytes of the original binary data
<radix-64-data> ::= An radix-64 encoding of the binary original data into a new
format.

Radix-64 encodes every 3 bytes of binary data into 4 bytes of
ASCII data which is in the range of characters which are fully
printable and transferable by mail. For a formal definition of
the Radix-64 format see RFC 1521, 1521 [8], MIME Part One, Section 5.2
Base64 Content Transfer Encoding, page 21.

Opaque values can pass things such as bitmaps for building a
service browsing graphical interface or application specific data.

12.0 21.

22. Implementation Requirements

A User Agent MAY:

- Provide a way for the application to configure the default DA, so
that it can be used without needing to find it each initially.

- Be able to request the address of a DA from DHCP, if configured
to do so.

- Ignore any unauthenticated Service Reply or Attribute Reply.

- Be able to issue requests in any language or character set
provided that it can switch to the default language and character
set if the request can not be serviced by DAs and SAs at the
site.

A User Agent SHOULD:

- Listen on the Service Location General Multicast address for
unsolicited Directory Agent Replies. DA Advertisements. This will increase the set
of Directory Agents available to it for making replies. See
Section
6.2. 16.2.

If this is not done, new DAs will not be passively detected. A UA
which does not have a configured DA and has not yet discovered one
and is not listening for unsolicited replies DA Advertisements will remain
ignorant of DAs. It may then do a DA discovery before each query
performed or it may simply use multicasted queries to Service Agents.

A User Agent MUST:

- Be able to unicast requests and receive replies from a DA.
Transactions should be made reliable by using retransmission

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 52]

Internet Draft Service Location Protocol 10 June 1996

of the request if the reply does not arrive within a timeout
interval.

- Be able to detect DAs using a Directory Agent Discovery request
issued when the UA starts up.

- Be able to send requests to a multicast address. If the
multicast address is not known, the UA must be able to use a
Service Type query to obtain the multicast address for the
Service Type of the request.

- Be able to handle numerous replies after a multicast request.
The implementation may be configurable so it will either return
the first reply, all replies until a timeout or keep trying till
the

Veizades, Kaplan, Guttman, Perkins results converge.

- Ignore any unauthenticated Service Reply or Attribute Reply when
an appropriate IPSec Security Association for that Reply exists.

- Use the IP Authentication Header or IP Encapsulating Payload in
all Service Location messages, whenever an appropriate IPSec
Security Association exists.

- Be able to issue requests using the US-ASCII character set.

A Service Agent MAY be able to:

- Get the address of a local Directory Agent by way of DHCP.

- Accept requests in non-US-ASCII character encodings. This is
encouraged, especially for UNICODE [1] and UTF-8 [17] encodings.

- Register services with a DA in non-US-ASCII character encodings.
This is encouraged, especially for UNICODE [1] and UTF-8 [17]
encodings.

A Service Agent SHOULD be able to:

- Listen to the service-specific multicast address of the service
it is advertising. The incoming requests should be filtered:
If the Address Specification of the SA is in the Previous
Responders Address Specification list, the SA SHOULD NOT respond.
Otherwise, a response to the multicast query SHOULD be unicast to
the UA which sent the request.

- Listen for and respond to broadcast requests and TCP connection
requests, to the Service Location port.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 33]

INTERNET-DRAFT 53]

Internet Draft Service Location Protocol March-96

results converge.

A 10 June 1996

- Listen to the Service Location General Multicast address for
queries (e.g., Service Type Requests). If the query can be
replied to by the Service Application and Agent, the Service Agent MAY be able to:
- Get must do
so. It MUST check first to make sure it is not on the address of a local Directory Agent by way list of DHCP.
'previous responders.'

A Service Application Agent MUST be able to:

- Listen to the Service Location General Multicast address for
unsolicited Directory Agent Replies. DA Advertisements. If one is detected, and the DA
has the right scope, all services which are currently being
advertised SHOULD MUST be registered with the DA. See Section 6.2. DA (unless configured to
only use a single DA (see section 23.1), or the DA has already
been detected, subject to certain rules (see section 16.2)).

- Unicast registrations and unregistrations deregistrations to a DA. Transactions
should be made reliable by using retransmission of the request if
the reply does not arrive within a timeout interval.

- Be able to detect DAs using a Directory Agent Discovery request
issued when the SA starts up (unless configured to only use a
single DA, see section 23.1.)

- Use the IP Authentication Header or IP Encapsulating Payload in
all Service Location messages, whenever an appropriate IPSec
Security Association exists.

- Be able to register service information with a DA using US-ASCII
character encoding. It must also be able to reply to requests
from UAs which use US-ASCII character encoding.

- Reregister with a DA before the Lifetime of registered service
information elapses.

A Directory Agent MAY:

- Ignore any unauthenticated Service Registration or Service
Deregistration.

- Accept registrations and requests in non-US-ASCII character
encodings. This is encouraged, especially for UNICODE [1] and
UTF-8 [17] encodings.

A Directory Agent MUST be able to:

- Send an unsolicited DA Advertisements to the Service Location
General Multicast address on startup and repeat it periodically.
This reply has an XID which is incremented by one each time. If

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 54]

Internet Draft Service Location Protocol 10 June 1996

the DA starts with state, it initializes the XID to 0x0100. If
it starts up stateless, it initializes the XID to 0x0000.

- Listen on the Directory Agent Discovery Multicast Address for
Directory agent discovery requests. Filter these requests if the
Previous Responder Address Specification list includes the DA's
Address Specification.

- Listen for broadcast requests to the Service Application starts up.

A Service Agent MUST be able to: Location port.

- Listen to on the TCP and UDP Service Location General Multicast address Ports for
unsolicited Directory Agent Replies. If one is detected, unicast
requests, registrations and deregistrations and service them.

- Provide a way in which Scope information can be used to configure
the
DA has Directory Agent.

- Age out the right scope, all services which are currently being
advertised SHOULD be have been registered with so that when
the DA. See Section 6.2. service registration's Lifetime expires, the service
advertisement is withdrawn.

- Unicast Ignore any unauthenticated Service Location messages when an
appropriate IPSec Security Association exists for that request.

- Use the IP Authentication and IP Encapsulating Security Payload
in Service Location messages whenever an appropriate IPSec
Security Association exists.

- Accept requests and registrations in US-ASCII.

NOTE: Service Agents and unregistrations User Agents use ephemeral ports for
transmitting information to a DA. Transactions
should be made reliable by using retransmission of the request service location port.

23. Configurable Parameters and Default Values

There are several configuration parameters for Service Location.
The protocol will work fine if
the reply does not arrive within a timeout interval.
- Listen only default values are used. Due
to the multicast address nature of the service protocol, it is advertising.
The incoming requests should may be filtered: If the Address
Specification deployed in many different
environments. The configuration options parameters will allow an
implementation of the SA is Service Location to be useful in the Previous Responders Address
Specification list, the SA should not respond. Otherwise, a
response to the variety of
different scenarios.

Multicast vs. Broadcast
All Service Location entities must use multicast query should be unicast by
default. The ability to the UA
which sent the request.
- Listen for use broadcast requests and TCP connection requests, messages must
be configurable. Broadcast messages are to
the be used in
environments where not all Service Location port.
- Listen to the entities have
hardware or software which supports multicast.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 55]

Internet Draft Service Location General Protocol 10 June 1996

Multicast address for
queries of any type. If the query can Radius
Multicast requests should be replied sent to by the
Service Agent, all subnets in a
site. The default multicast radius for a site is 32.
This value must be configurable. The value for the Service
site's multicast TTL may be obtained from DHCP. The DHCP
option has not yet been assigned.

Directory Agent Address
The Directory Agent address discovery mechanism must do so. It must check first
to make sure it is not on be
configurable. There are three possibilities for this
configuration: A default address, no default address
and the list use of 'previous responders.'
It will receive 'Service Type' requests this way.
- Be able DHCP to detect DAs using locate a Directory Agent Discovery request
issued when DA as described in
section 16.2. The default value should be "no default
address." In this case the UA or SA starts up.

A must do a Directory
Agent MUST be able to:
- Send an unsolicited Discovery query.

Directory Agent Discovery reply Scope Assignment
The scope or scopes of a DA must be configurable. The
default value for a DA is to have no scope if not
otherwise configured.

Default Path MTU
The default path MTU is assumed to be 1400. This value
may be too large for the
Service Location General Multicast address on startup infrastructure of some sites.
For this reason this value MUST be configurable for all
SAs and repeat
it periodically. This DAs.

If a UA issues a request which will result in a
reply has which is too large, the SA or DA will return an
abbreviated response (in a unique XID for datagram the life size of the
DA; this XID changes on each reboot (see Section 6.2).
- Listen on
site's MTU) which has the Directory Agent Multicast Address for Directory
agent discovery requests. Filter these requests 'Overflow' bit flag set.
The UA must then issue the request again using a tcp
connection.

Similarly, if a SA attempts to register a service with a
DA and the Previous
Responder Address Specification list includes registration is larger than the DA's Address
Specification.
- Listen for broadcast requests to site path MTU
the Service Location port.
- Listen on DA will reply with a SrvAck, with the TCP error set to
INVALID_REGISTRATION and UDP the 'Overflow' byte set.

23.1. Service Location Ports for unicast
requests, registrations Agent: Use Predefined Directory Agent(s)

A Service Agent's default configuration is to do passive and unregistrations active
DA discovery and service them.
- Provide a way in to register with all DAs which SCOPE information can are properly scoped.

A Service Agent SHOULD be used configurable to configure
the Directory Agent.

Veizades, Kaplan, Guttman, Perkins allow a special mode of
operation: They will use only preconfigured DAs. This means they
will *NOT* actively or passively detect DAs.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 34]

INTERNET-DRAFT 56]

Internet Draft Service Location Protocol March-96

- Age out 10 June 1996

If a Service Agent is configured this way, knowledge of the services which have been registered so that when DA must
come through another channel, either static configuration or by the
service registration's TTL expires,
use of DHCP.

The availability of the service advertisement is
withdrawn.

NOTE: Service Applications, Service Agents and User Agents use
ephemeral ports for transmitting information to will not be consistent
between DAs. The mechanisms which achieve eventual consistency
between DAs are ignored by the SA, so their service location
port.

13.0 Configuration Parameters and Defaults

13.1 Multicast vs. Broadcast

All Service Location entities must use multicast by default.
The ability to use broadcast messages must information will
not be configurable.
Broadcast messages distributed. This leaves the SA open to failure if the DA
they are configured to use fails.

23.2. Time Out Intervals

These values should be used configurable in environments where not all case the site deploying
Service Location entities have hardware or software has special requirements (such as very slow links.)

Interval name Section Default Value Meaning
----------------- ------- ------------- -----------------------
CONFIG_INTERVAL_0 5.1 1 minute Cache replies by XID.
CONFIG_INTERVAL_1 5.2 1440 minutes registration Lifetime,
(ie. 1 day) after which supports
multicast.

13.2 Multicast Radius

Multicast requests should be sent to all subnets in a site. The
default ad expires
CONFIG_INTERVAL_2 6 each second, Retry multicast radius query
backing off until no new values
gradually arrive.
CONFIG_INTERVAL_3 6 15 seconds Max time to wait for a site is 32. This value must be
configurable. The value for the site's
complete multicast TTL may be
obtained from DHCP. The DHCP option has not yet been assigned.

13.3 Directory Agent Address

The Directory Agent address discovery mechanism must be
configurable. There are three possibilities for this configuration:
A default address, no default address and the use of DHCP query
response (all values.)
CONFIG_INTERVAL_4 10 3 seconds Wait to register on
reboot.
CONFIG_INTERVAL_5 6.2 3 seconds Retransmit DA discovery,
try it 3 times.
CONFIG_INTERVAL_6 6.2 5 seconds Give up on requests sent
to locate a DA.
CONFIG_INTERVAL_7 6.2 15 seconds Give up on DA as described in section 6.2. The default value should be "no
default address." In discovery
CONFIG_INTERVAL_8 6.1 15 seconds Give up on requests
sent to SAs.
CONFIG_INTERVAL_9 16.2 3 hours DA Heartbeat, so that SAs
will
passively detect new DAs.
CONFIG_INTERVAL_10 16.2 1-3 seconds Wait to register services
on passive DA discovery.
CONFIG_INTERVAL_11 10 1-3 seconds Wait to register services
on active DA discovery.
CONFIG_INTERVAL_12 19.1 5 minutes DAs and SAs close idle
connections.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 57]

Internet Draft Service Location Protocol 10 June 1996

A note on CONFIG_INTERVAL_9: While it might seem advantageous to
have frequent heartbeats, this case the UA or SA must do poses a Directory
Agent Discovery query.

13.4 Directory Agent Scope Assignment

The scope or scopes significant risk of generating
a DA must be configurable. The default lot of overhead traffic. This value
for a DA is should be kept high to have no scope if not otherwise configured.

14.0 Interesting Constants prevent
routine protocol operations from using any significant bandwidth.

24. Non-configurable Parameters

IP Port number for unicast requests to Directory Agents:

UDP and TCP Port Number: 427

Multicast Addresses

Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35

Further service-specific multicast address will be assigned for specific types of
service through the IANA.

Veizades, Kaplan, Guttman, Perkins [Page 35]

INTERNET-DRAFT Service Location Protocol March-96

Error Codes

No Error 0
LANGUAGE_NOT_SUPPORTED 1
PROTOCOL_PARSE_ERROR 2
INVALID_REGISTRATION 3
SCOPE_NOT_SUPPORTED 4

15.0 Acknowledgments

This protocol owes some of the original ideas to other service
location protocols found in many other networking protocols. Leo
McLaughlin and Mike Ritter (Metricom) provided much input into early
version of this document. Thanks also to Steve Deering (Xerox) for
providing his insight into distributed multicast protocols. Harry
Harjono and Charlie Perkins supplied the basis for the URL based
wire protocol in their Resource Discovery Protocol. Their comments
have been very valuable. Thanks also to Peerlogic, Inc. for
supporting this work.

16.0 References

[1] Freier, A. O. "Network Binding Protocol" Xerox Corporation
Unpublished, June 1986.

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

[3] Deering, S., "Host Extensions for IP Multicasting", RFC 1112, NIC,
August 1989.

[4] Saltzer, J., "On the Naming and Binding of Network Destinations",
RFC 1498, M.I.T. Laboratory for Computer Science, August 1993.

[5] Accetta, M. "Resource Location Protocol", RFC 887, NIC, December
1983

[6] Legato Systems, "The Legato Resource Administration Platform",
Legato Systems, 1991.

[7] C. McManis and R. Rom, "The Zeus Name Service Architecture", Sun
Microsystems, 1990.

[8] S. Dyer, "The Hesiod Name Server", Winter Usenix Conference, pp.
183-187, Feb 1988.

[9] D. Oppen and Y. Dalal, "The Clearinghouse: A Decentralized Agent
for Locating Named Objects in a Distributed Environment," Tech. Rep.
OPD-78103, Xerox Office Products Division, 1981.

[10] B. Lampson, "Designing a Global Name Service", Proceedings assigned for
specific types of service through the
5th ACM Symposium on Principles IANA.

Error Codes:

No Error 0
LANGUAGE_NOT_SUPPORTED 1
PROTOCOL_PARSE_ERROR 2
INVALID_REGISTRATION 3
SCOPE_NOT_SUPPORTED 4
CHARSET_NOT_UNDERSTOOD 5
AUHENTICATION_FAILED 6

25. Acknowledgments

This protocol owes some of Distributed Computing, pp. 1-10,
1986.

Veizades, Kaplan, Guttman, Perkins [Page 36]

INTERNET-DRAFT Service Location Protocol March-96

[11] D. Cheriton and T. Mann, "Uniform Access the original ideas to Distributed Name
Interpretations other service
location protocols found in the V-system".

[12] P. Mockapetris. "Domain Names - Concepts and Facilities". RFC
1034, NIC, November 1987

[13] P. Mockapetris. "Domain Names - Implementation many other networking protocols. Leo
McLaughlin and Specification".
RFC 1035, NIC. November 1987

[14] S. Deering. "Router Discovery Protocol". RFC 1256, NIC 1991.

[15] ISO 639:1988 (E/F) "Code for the representation of names Mike Ritter (Metricom) provided much input into early
version of
languages"; ISO, Geneve, 1988.

[16] T. Berners-Lee, L. Masinter and M. McCahill "Uniform Resource
Locators". RFC 1738, NIC 1994.

[17] N. Borenstein, N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms this document. Thanks also to Steve Deering (Xerox) for Specifying and Describing the
Format of Internet Message Bodies". RFC 1521, NIC 1993.

[18] S. Alexander, R. Droms, "DHCP Options
providing his insight into distributed multicast protocols. Harry
Harjono and BOOTP Vendor
Extensions". RFC 1533, NIC 1993.

[19] R. Droms, "Dynamic Host Configuration Protocol". RFC 1541,
NIC 1993.

Veizades, Kaplan, Guttman, Perkins [Page 37]

INTERNET-DRAFT Service Location Protocol March-96

17.0 Author's Addresses

John Veizades
TGV, Inc.
370A Waller St.
San Francisco, CA 94117

Phone: +1 415 252 8203
Fax: +1 415 252 8248

Email: veizades@tgv.com

Scott Kaplan
346 Fair Oaks St.
San Francisco, CA 94110

Phone: +1 415 285 4526

Email: scott@catch22.com

Erik Guttman
Sun Microsystems
2550 Garcia Avenue, MS PAL01-550
Mountain View, CA 94043-1100

Phone: +1 415 336 6697

Email: Erik.Guttman@eng.sun.com

Charles Charlie Perkins
IBM Corporation
P.O. Box 704
Yorktown Heights NY 10598

Phone: +1 914 784 7350

EMail: perk@watson.ibm.com

18.0 Document Expiration

This document expires September 11, supplied the basis for the URL based
wire protocol in their Resource Discovery Protocol. Thanks also to
Peerlogic, Inc. for supporting this work.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996

Veizades, Kaplan, Guttman, Perkins [Page 38]

INTERNET-DRAFT 58]

Internet Draft Service Location Protocol March-96

Appendix A - 10 June 1996

A. Appendix: Technical contents of ISO 639:1988 (E/F) (E/F): "Code for the
representation of names of languages". languages"

Two-letter lower-case symbols are used. The Registration Authority
for ISO 639 [12] is Infoterm,Osterreiches Infoterm, Osterreiches Normungsinstitut (ON),
Postfach 130, A-1021 Vienna, Austria. Contains additions from ISO
639/RA Newsletter No.1/1989

aa Afar gn Guarani mr Marathi
ab Abkhazian gu Gujarati ms Malay
af Afrikaans mt Maltese
am Amharic ha Hausa my Burmese
ar Arabic hi Hindi he Hebrew
as Assamese hr Croatian hi Hindi na Nauru
ay Aymara hu Hungarian hr Croatian ne Nepali
az Azerbaijani hy Armenian hu Hungarian nl Dutch
hy Armenian no Norwegian
ba Bashkir ia Interlingua
be Byelorussian ie Interlingue ia Interlingua oc Occitan
bg Bulgarian ik Inupiak in Indonesian om (Afan) Oromo
bh Bihari in Indonesian ie Interlingue or Oriya
bi Bislama is Icelandic ik Inupiak
bn Bengali; Bangla it Italian is Icelandic pa Punjabi
bo Tibetan iw Hebrew it Italian pl Polish
br Breton ps Pashto, Pushto
ja Japanese
pt Portuguese
ca Catalan ji Yiddish ja Japanese
co Corsican jw Javanese qu Quechua
cs Czech
cy Welsh ka Georgian rm Rhaeto-Romance
kk Kazakh rn Kirundi
da Danish kl Greenlandic ro Romanian
de German km Cambodian ru Russian
dz Bhutani kn Kannada rw Kinyarwanda
ko Korean
el Greek ks Kashmiri sa Sanskrit
en English ku Kurdish sd Sindhi
eo Esperanto ky Kirghiz sg Sangro
es Spanish sh Serbo-Croatian
et Estonian la Latin si Singhalese
eu Basque ln Lingala sk Slovak
lo Laothian sl Slovenian
fa Persian lt Lithuanian sm Samoan
fi Finnish lv Latvian, Lettish sn Shona
fj Fiji so Somali
fo Faeroese sq Albanian
fr French mg Malagasy sr Serbian
fy Frisian mi Maori ss Siswati

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 59]

Internet Draft Service Location Protocol 10 June 1996

mk Macedonian st Sesotho
ga Irish ml Malayalam su Sundanese
gd Scots Gaelic mn Mongolian sv Swedish
gl Galician mo Moldavian sw Swahili

Veizades, Kaplan, Guttman, Perkins

ta Tamil ug Uigar
te Telugu uk Ukrainian
tg Tajik ur Urdu
th Thai uz Uzbek
ti Tigrinya
tk Turkmen vi Vietnamese
tl Tagalog vo Volapuk
tn Setswana
to Tonga wo Wolof
tr Turkish
ts Tsonga xh Xhosa
tt Tatar
tw Twi yi Yiddish
yo Yoruba
za Zhuang
zh Chinese
zu Zulu

B. Appendix: For Further Reading

Three related resource discovery protocols are NBP and ZIP
which are part of the AppleTalk protocol family [11], the Legato
Resource Administration Platform [18], and the Xerox Clearinghouse
system [16]. Domain names and representation of addresses are
used extensively in the Service Location Protocol. The references
for these are RFCs 1034 and 1035 [14, 15]. An example of service
discovery protocol for a specific service is Router Discovery [9].

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 60]

Internet Draft Service Location Protocol 10 June 1996

References

[1] Unicode Technical Report #4. The unicode standard, version 1.1
(volumes 1 and 2). Technical Report (ISBN 0-201-56788-1) and
(ISBN 0-201-60845-6), Unicode Consortium, 1994.

[2] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. RFC 1533, October 1993.

[3] R. Atkinson. IP Authentication Header. RFC 1826, August 1995.

[4] R. Atkinson. IP Encapsulating Security Payload. RFC 1827,
August 1995.

[5] R. Atkinson. Security Architecture for the Internet Protocol.
RFC 1825, August 1995.

[6] T. Berners-Lee and D. Connolly. Hypertext Markup Language -
2.0. RFC 1866, November 1995.

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

[8] N. Borenstein and N. Freed. MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, September
1993.

[9] Stephen E. Deering, editor. ICMP Router Discovery Messages.
RFC 1256, September 1991.

[10] Ralph Droms. Dynamic Host Configuration Protocol. RFC 1541,
October 1993.

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

[12] Geneva ISO. Code for the representation of names of languages.
ISO 639:1988 (E/F), 1988.

[13] Geneva ISO 8879. Information Processing -- Text and Office
Systems - Standard Generalized Markup Language (SGML).
<URL:http://www.iso.ch/cate/d16387.html>, 1986.

[14] P. Mockapetris. Domain Names - Concepts and Facilities. RFC
1034, November 1987.

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 39]

INTERNET-DRAFT 61]

Internet Draft Service Location Protocol March-96

ta Tamil
te Telugu
tg Tajik
th Thai
ti Tigrinya
tk Turkmen
tl Tagalog
tn Setswana
to Tonga
tr Turkish
ts Tsonga
tt Tatar
tw Twi
uk Ukrainian
ur Urdu
uz Uzbek
vi Vietnamese
vo Volapuk
wo Wolof
xh Xhosa
yo Yoruba
zh Chinese
zu Zulu

Veizades, Kaplan, Guttman, 10 June 1996

[15] P. Mockapetris. DOMAIN NAMES - IMPLEMENTATION AND
SPECIFICATION. RFC 1035, November 1987.

[16] D. Oppen and Y. Dalal. The clearinghouse: A decentralized
agent for locating named objects in a distributed environment.
Technical Report Tech. Rep. OPD-78103, Xerox Office Products
Division, 1981.

[17] X/Open Preliminary Specification. File System Safe UCS
Transformation Format (FSS_UTF). Technical Report Document
Number: P316, X/Open Company Ltd., 1994.

[18] Legato Systems. The Legato Resource Administration Platform.
Legato Systems, 1991.

Authors' Addresses

Questions about this memo can be directed to:

John Veizades Erik Guttman
@Home Network Sun Microsystems
385 Ravendale Dr. 2550 Garcia Avenue, MS PAL01-550
Mountain View, CA 94043 Mountain View, CA 94043-1100

Phone: +1 415 944 7332 Phone: +1 415 336 6697
Fax: +1 415 944 8500

Email: veizades@home.com Email: Erik.Guttman@eng.sun.com

Charles Perkins Scott Kaplan
IBM Corporation
P.O. Box 704 346 Fair Oaks St.
Yorktown Heights NY 10598 San Francisco, CA 94110

Phone: +1 914 784 7350 Phone: +1 415 285 4526
Fax: +1 914 784 6205

EMail: perk@watson.ibm.com Email: scott@catch22.com

Veizades,Guttman,Perkins,Kaplan Expires 10 December 1996 [Page 40] 62]

----