WDIFF

draft-ietf-svrloc-protocol-06.txt --> draft-ietf-svrloc-protocol-07.txt

draft-ietf-svrloc-protocol-06.txt

draft-ietf-srvloc-protocol-07.txt John Veizades
INTERNET-DRAFT TGV, Inc.
Scott Kaplan
CoroNet Systems Inc.
Erik Guttman
Peerlogic, Inc.
July 6,
October 24, 1995

Service Location Protocol

1.0 Status of this memo

This draft document is a product of the IETF Service Location Working
Group; it will be submitted to the RFC editor as a standards document.
Please respond with comments to the srvloc@tgv.com mailing list.

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 may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet-Drafts as
reference material or to cite them other than as a "working draft" or
"work in progress."

To learn the current status of any Internet-Draft, please check the
1id-abstracts.txt listing contained in the Internet-Drafts Shadow
Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
munnari.oz.au.

2.0 Abstract

The service location protocol provides a 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 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 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
Expires January 6, April 24, 1996 [Page 1]

INTERNET-DRAFT Service Location Protocol July-95 October-95

Table of Contents

1.0 Status of this memo..............................................1
2.0 Abstract.........................................................1
3.0 Notation Conventions.............................................3
4.0 Terminology......................................................3
5.0 Protocol Overview................................................5 Overview................................................4
5.1 Protocol Transactions........................................4
5.2 Service and Predicate Representation.........................5
5.3 Additional Notes.............................................6
5.3.1 Interpretation Service Location Replies...............6
5.3.2 Use of TCP and Multicast in Service Location..........6
5.3.3 Linguistic Localization...............................6
5.3.4 Standard Attribute Definitions........................7
5.4 Service Location PDU header..................................6
5.1.1 Version...............................................6
5.1.2 Functions.............................................6
5.1.3 header..................................7
5.4.1 Version...............................................7
5.4.2 Functions.............................................7
5.4.3 Length................................................7
5.1.4
5.4.4 Error Codes...........................................7
5.1.5 XID...................................................7
5.1.6 Locale................................................7
5.1.7 Flags.................................................7
5.1.8 Codes...........................................8
5.4.5 Transaction Identifier (XID)..........................8
5.4.6 Flags.................................................8
5.4.7 Time To Live..........................................8
5.2
5.4.8 Character Encoding....................................8
5.5 Service Request and Reply....................................8
5.6 Directory Agent Discovery Request...........................10
5.7 Distinguished Attribute Request..............................8
5.3 Request.............................11
5.8 Get Attributes Request and Reply.............................9
5.4 Service Request and Reply...................................10
5.5 Request......................................12
5.9 Service Attributes Request and Reply........................12 Discovery Request...................................13
6.0 Directory Agents................................................12 Agents................................................14
6.1 Introduction................................................12 Introduction................................................14
6.2 Directory Agent Discovery...................................13 Discovery...................................15
6.3 Service Registration........................................14 Registration........................................15
6.4 Service Unregister..........................................14 Unregister..........................................17
6.5 SCOPE Discovery and Use.....................................15
6.6 SCOPE Propogation...........................................17 Use.....................................18
7.0 Service Information Versions....................................17
7.1 Information Versions........................................18
7.2 User Agents.................................................18
7.3 Directory Agents............................................19
7.4 Service Agents..............................................19
8.0 Server Location Connections.....................................19
8.0 Security Considerations.........................................20
9.0 Special Data Types..............................................20
9.1 Function Resolution.........................................20
9.2 Opaque......................................................20
10.0 Authentication.................................................21
11.0 Multicast vs. Broadcast........................................21
11.1 Broadcast.........................................20
9.1 Non-interneted networks...................................21
11.2 networks.....................................20
9.2 Interneted site...........................................21
11.3 site.............................................20
9.3 Service Multicast Address.................................21
12.0 Data Element Formats...........................................22
12.1 Attributes................................................22
12.2 Service Instance..........................................23
12.3 Addresses.................................................24
12.4 Predicate.................................................24
13.0 Predicate Language.............................................25 Address...................................20
10.0 Protocol Formats...............................................21
10.1 Fields Used in Service Location Packets....................21
10.1.1 Previous Responder's URL............................21
10.1.2 Service Request Predicate...........................21
10.1.3 Reply...............................................23
10.1.4 Service Registration Information....................24
10.1.5 Service Unregister Information......................24
10.1.6 Attribute List......................................25
10.1.7 Language of Reply...................................25
10.1.8 Service Scheme......................................25
10.2 URLs in Service Location...................................25
10.3 Attribute Value encoding rules.............................25
11.0 Implementation Requirements....................................27

Veizades, Kaplan, Guttman [Page 2]

INTERNET-DRAFT Service Location Protocol July-95

14.0 October-95

12.0 Interesting Constants..........................................27 Constants..........................................28
13.0 Acknowledgments................................................29
14.0 References.....................................................29
15.0 Acknowledgments................................................28
16.0 References.....................................................28
17.0 Author's Address...............................................29
18.0 Addresses.............................................30
16.0 Document Expiration............................................29 Expiration............................................30
Appendix A - Technical contents of ISO 639:1988 (E/F)...............30 639:1988.....................31

3.0 Notation Conventions

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

In General, all definitions of items in packets are described in
section 12.0. 10.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 User Agent retrieves service information
from the service agents. Service Agents.

Service Agent (SA) A process working on the behalf of one or more
services to advertise service attributes and
configuration. There can only be

Service Application A process working on behalf of one or more
services to advertise service attributes and
configuration. Unlike an SA per a
given host. the application
will not directly respond to service queries
and will merely register with Directory Agents.

Service Instance The address (service access point) of one
service, together with service specific
configuration information.

Service Information A collection of attributes and configuration
information associated with a single service.
The service agents 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 goal of service
location is to provide sufficient information
to the user, via the user agent, User Agent, to find the
service. The service itself is out of band
of the service location protocol.

Directory Agent (DA) A process which collects information from
service agents

Veizades, Kaplan, Guttman [Page 3]

INTERNET-DRAFT Service Location Protocol October-95

Service Agents to provide a single repository
of service information in order to centralize

Veizades, Kaplan, Guttman [Page 3]

INTERNET-DRAFT Service Location Protocol July-95
it for efficient access by User Agents. There
can only be one DA present per given host.

Distinguished Attribute A special attribute at the top level of the
service location naming taxonomy. The
Distinguished Attribute has "DIST ATTR" as its
class name, a 32 bit value describing taxonomy which defines
the type of service. Each type of service and has
a text string as its value.
The 32 bit quantity unique Distinguished Attribute. This is registered with IANA. also
referred to as 'SCHEME' in what follows.

Attribute A {class, value} pair describing a
characteristic of a service. Note that a
class is a string and the value can be of
five
four types: integer, string, boolean, function
(see section 9.0), boolean and
opaque. The service information advertised
by a Service Agent may include more than one
value per class.

Standard Attribute An attribute whose class name and values have
a standard interpretation. These should be
clearly defined and registered with a
standards organization.

Predicate A boolean expression of attributes, relations

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

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 of networks, hosts
and related network infrastructure that is
grouped together for geographical or political
reasons.

Agent's Internet All the hosts accessible within the agent's Agent's
multicast radius. If the network does not
support multicast, the agent's internet is
defined by its broadcast radius. The
discovery method used by the service location
protocol requires these techniques to start up
and provide stable operation. Servers outside
of the agent's Agent's radius are considered "outside
of the user's internet."

Veizades, Kaplan, Guttman [Page 4]

INTERNET-DRAFT Service Location Protocol July-95

5.0 Protocol Overview

5.1 Protocol Transactions

The following describes the operations an end system needs to perform
to find services on the attached network. Internet. The user agent, User Agent, an end
system, does not need any configuration to begin network interaction.
The user
agent User Agent builds on the information it retrieves in earlier
network requests to find the service agents Service Agents advertising service
information, then finds the terms used to describe services that it
is interested in. The user agent User Agent can use this information to send

Veizades, Kaplan, Guttman [Page 4]

INTERNET-DRAFT Service Location Protocol October-95

out predicates which describe the services that match the user's needs.

The service location protocol requires

A User Agent will operate two ways: If the implementation User Agent has already
obtained the location of a
connectionless and Directory Agent, the User Agent will unicast
a connection oriented transport protocols, this
would be UDP and TCP request to it, in the Internet protocol suite. These protocols
should be supported over order to resolve a network protocol layer that supports
internetwork wide multicast. particular request. The protocol
Directory Agent will operate in unicast a broadcast
enviroment with the limitations outlined in section 11.

Note: When implementing this protocol over IP version 4 reply to the following
must be observed.

1. The constants specified in Section 14 must be used.

2. User Agent. The address format for describing IP addresses specified in section
12.3 must be used.

3. ICMP error messages should not be sent in response User Agent
will retry a request to multicast
datagrams.

The service location protocol uses a multicast request/unicast Directory Agent till it gets a reply, so if
the Directory Agent cannot service the request (say it has no
information) it must return an response
interaction. Since with zero values, possibly with
an error code set.

If the requester User Agent does not know the number have knowledge of
responders to a request, the request may generate more responses than Directory Agent or if
there are no Directory Agents available on the requester User Agent's internet,
a second mode of discovery is able used. The User Agent multicasts a
request to handle. Therefore the requester sends a series
of requests. Each request contains service multicast address, which the information learned in service it wishes
to locate will respond to. All the
previous requests. The protocol requires responders Service Agents which are listening
to scan this list
and respond only if multicast address will respond, provided they can satisfy the
User Agent's request. Service Agents which have no information not in for the list.

Character strings are represented as a {type, length, value} tuple.
Implementers
User Agent DO NOT respond. This will cause an 'implosion' of this specification are strongly encouraged to be able to
send and receive Unicode [15] as one
responses. The most important case of discovery is that of locating
a Directory Agent.

In the string data types.

Replies should be considered to be valid at case where the time User Agent wishes to obtain a complete answer,
an enumeration of delivery. ALL services which satisfy the query, there is a
retransmission/convergence algorithm. The
service may, however, fail or change between User Agent resends the time
request, together with a list of previous responders. Only those
Service Agents which are not on the reply and
the moment an application seeks list respond. Once there are no
new responses to make use of the service. The end
system making use request the accumulation of service location must be prepared responses is deemed
complete.

It is important to stress that while the multicast/convergence model
is important for discovering services (such as Directory Agents) it
is the
possibility that 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.

A service information provided is either stale or
incomplete. In the case where advertised by an application which registers the service
information provided does not
allow an end system to connect to with a service Directory Agent. This Directory Agent will resolve
requests from User Agents as desired, the request must
be resent.

Veizades, Kaplan, Guttman [Page 5]

INTERNET-DRAFT Service Location Protocol July-95

5.1 Service Location PDU header

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| version = 1 | function | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code | XID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Locale |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|M| flags |
+-+-+-+-+-+-+-+-+

5.1.1 Version described above. This protocol document defines version 1 of means that a
Directory Agent must first be discovered, using the multicast mechanism
described above. If the service location
protocol.

5.1.2 Functions

Service location datagrams can be identified as is to their operation by become unavailable, it must be
unregistered with the function field. Directory Agent. The Directory Agent responds
with an acknowledgment to either a registration or unregistration.

The following are the defined operations:

Packet Types Abbreviation Function Value

Distinguished Attribute Request DistAttrRqst 1
Distinguished Attribute Reply DistAttrRply 2
Attribute Class Request AttrRqst 3
Attribute Class Reply AttrRply 4 Service Request SrvRqst 5 Agent or Application must register with an available
Directory Agent. The Service Reply SrvRply 6 Agent must additionally listen for
multicast requests on the service specific multicast address.
Service Registration SrvReg 7 Applications will fail in an internet where there are no
Directory Agents. Service Unregister SrvUnreg 8 Applications are present in this protocol
to provide a lightweight service registration mechanism.

5.2 Service Acknowledge SrvAck 9 and Predicate Representation

Service Attributes Request SrvAttrRqst 10
Version Request VerRqst 11
Version Reply VerRply 12
Function Resolve Request FuncReslvRqst 13
Function Resolve Reply FuncReslvRply 14
Scope Request ScopeRqst 15
Scope Reply ScopeRply 16 information is represented in a text format. The goal is that

Veizades, Kaplan, Guttman [Page 6] 5]

INTERNET-DRAFT Service Location Protocol July-95

5.1.3 Length

The length is October-95

the number of bytes after format be human readable and transmittable via email. The location
of network services is encoded in a URL like format which is also
comprehensible and well known. Only the Service Location PDU
Header.

5.1.4 Error Codes

Errors datagram headers are only valid in reply and service acknowledgement datagrams. an
encoded form which is not human readable.

5.3 Additional Notes

5.3.1 Interpretation Service Location Replies

Replies that completed successfully should have a zero value for be considered to be valid at the
error code.

5.1.5 Transaction Identifier (XID) time of delivery. The XID (transaction ID) field allows
service may, however, fail or change between the requester to match replies
to individual requests. Retransmission time of the same service location
datagram should not contain an updated XID. The requester creates reply and
the
XID from moment an initial random seed and increments it by one for each
request it makes. The XIDs will eventually wrap back application seeks to zero and
continue incrementing from there. make use of the service. The responder copies end
system making use of service location must be prepared for the XID from
possibility that the request into its reply.

5.1.6 Locale

All service location requests and responses contain information provided is either stale or
incomplete. In the "locale" field.
This allows clients case where the service information provided does
not allow an end system to advertise their preference as connect to a service as desired, the language
in which responses should request
must be returned. The locale field is comprised
of four 8 bit values using the lower case ASCII representation resubmitted.

5.3.2 Use of the
symbols defined in ISO 639 (reprinted TCP and Multicast in Appendix A). Service Location

The first two
bytes should be left zeroed (0x0) for further expansion. Services
should have service location protocol requires the implementation of a default locale. If they are able to respond in
connectionless and a
language that corresponds with the client's requested locale they
should, otherwise they should respond connection oriented transport protocols. The
latter is used for bulk transfer, only when necessary.

The Service Location discovery mechanisms use internetwork wide
multicast. The protocol will operate in a broadcast environment
with data limitations detailed in their default
locale section 9.0.

5.3.3 Linguistic Localization

All Service Registrations and set the locale code to Unregistrations are localized with codes
which declare in which language strings in the default locale.

5.1.7 Flags

The flags field is a bit field. Bit 0 is Service attributes are
written. For each language the 'Overflow bit.' See
section 8.0 for Service advertises, a complete description for separate
registration takes place. The Service needs to be unregistered
only once, since the use Service Instance information associated with it
will be unique (i.e. there can only be one service of this field. Bit
1 a given type at a
given URL location, even if it is the 'Monolingual bit.' registered in multiple languages.)

All Service Requests with this bit set indicate that
the end system include a language identifier. The Directory
Agent or Service Agent will only accept responses respond in the same language that is
indicated as the
request, if it has a registration in the locale field of same language as the header. Replies in other
languages should not be sent for this request. All other bits must be
set to zero.

5.1.8 Time to Live

The TTL field is set to
If the number of seconds 'monolingual bit' is not set, and the request is in an
unsupported language, a reply can be cached
by any intermediary service. A value of 0 means sent in the information must
not be cached.

NOTE: The preceding header default language
(which is used English.) This is only possible when there are no language
specific attributes in all of the packet discriptions
below and is abbreviated by using "Sevice location header" followed by request.

For example one which includes attributes tags in the request
predicate. The class names of the attributes will be incomprehensible
except where the language is supported. A Directory Agent will reply
with zero values and the error code set to LANGUAGE_NOT_SUPPORTED.
Service Agents will not reply.

Veizades, Kaplan, Guttman [Page 7] 6]

INTERNET-DRAFT Service Location Protocol July-95

the function being used.

5.2 Distinguished Attribute Request

The client uses the Distinguished October-95

5.3.4 Standard Attribute Request to find all the
types of services that are available on a network. Definitions

Service agents
respond schemes registered with a list of Distinguished Attributes that they support.
Like most the IANA for use with the service
location PDUs, a client can issue more than one
request to insure that all replies protocol must have been received. In each
subsequent request, a user agent adds the list of distinguished
attributes that it is aware of to an accompanying document which describes
the "distinguished attributes"
field following:

Scheme of the datagram. The "Num Dist Attrs found" indicates how many
"previously found" Distinguished service
Mutlicast address
Attributes will follow. (Tag and values)
Attribute Descriptions and interpretations

Service agents look for distinguished attributes that they support but
are not in the list. If any such distinguished attributes exist, the
service agent replies with these distinguished attributes. The number schemes can be defined out of distinguished attributes the service agent returns is in the
datagram as "Num Dist Attrs found".

The service agent's reply is sent to this standardization process
through the unicast address use of the sender.

The service agent should wait before responding. The wait time should
be a random interval between experimental multicast addresses.

5.4 Service Location PDU header

0 and 2 seconds.

User agent requests that are generated by a genesis event, i.e., the
rebooting of a system, loading of the network kernel, etc. should be
sent after a random interval between 0 and 5 seconds.

A distinguished attribute defines a class of objects of a particular
type, i.e., printers, modems, file servers, etc. These attributes are
registered through the Internet Numbering Authority (IANA). Examples are
"DIST ATTR" as the class and "PRINTER" as the value, or "NFS FILE SERVER"
as the value. Since the class "DIST ATTR" is standardized, this class
name should not be used in any other attribute.

Distinguished Attributes Request

Veizades, Kaplan, Guttman [Page 8]

INTERNET-DRAFT Service Location Protocol July-95

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0

5.4.1 Version

This protocol document defines version 1 2 3 4 5 6 7 8 9 0 of the service location
protocol.

5.4.2 Functions

Service location datagrams can be identified as to their operation by
the function field. The following are 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 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = DistAttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Num

5.4.3 Length

The length is the number of Dist Attrs returned | <Distinguished Attribute> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Distinguished Attribute> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Distinguished Attributes Reply

5.3 Get Attributes Request bytes after the Service Location PDU
Header.

Veizades, Kaplan, Guttman [Page 7]

INTERNET-DRAFT Service Location Protocol October-95

5.4.4 Error Codes

Errors are only valid in reply and Reply

Once a user agent selects service acknowledgment datagrams.
Replies that completed successfully should have a single distinguished attribute, it sends a
"get attributes request" to find all zero value for the attributes associated with
that distinguished attribute. Since different services with a
particular distinguished attribute can have different attributes,
error code.

5.4.5 Transaction Identifier (XID)

The XID (transaction ID) field allows the requester to
find all match replies
to individual requests. A Service Reply will contain the attributes associated with a distinguished attribute, same XID as
the
user agent must form a union of all attributes returned by all service
agents.

If a user agent is unable to process all Service Request. A Service Acknowledge will contain the replies from same XID
as the service
agents it may reissue Service Register or Unregister.

Retransmission of the request. It can get same service location datagram should not contain
an updated XID. The requester creates the attributes XID from
these service agents an initial random
seed and increments it by reissuing the request. one for each request it makes. The user agent places XIDs will
eventually wrap back to zero and continue incrementing from there.

5.4.6 Flags

The flags field is a bit field. Bit 0 is the addresses 'Overflow bit.' See
Section 7.0 for a complete description for the use of this field. Bit
1 is the service agents 'Monolingual bit.' Requests with this bit set indicate that it already has replies from
in
the "service addresses" field of end system will only accept responses in the request. language that is
indicated Service agents or Attribute Request. Replies in other languages
should
only reply if they are not on be sent for this request. All other bits must be set to
zero.

5.4.7 Time to Live

The TTL field is set to the "service addresses" list number of minutes the
request. With a packet length of 1500 bytes, this protocol reply can support

~200 IPv4 respondents. Networks be cached
by any intermediary service. A value of 0 means the information must
not be cached.

5.4.8 Character Encoding

The encoding will determine the interpretation of all character data
which follows. There is no way to mix ASCII and UNICODE, for example.
See the list of interesting constants for a list of supported character
set encodings. This list is by no means complete and can be added to.

NOTE: The preceding header is used in all of the packet descriptions
below and is abbreviated by using "Service location header" followed by
the function being used.

5.5 Service Request and Reply

The Service Request is used to obtain nearly all information in the
Service Location Protocol. It is a general mechanism for delivering
a query to a Directory Agent or Service Agents. Depending on the
format of the query, different information can be obtained. There are
four general types of query: Directory Agent Discovery Request,
Distinguished Attributes, Services Discovery and Service Attributes.
These are described in the sections which follow.

Veizades, Kaplan, Guttman [Page 8]

INTERNET-DRAFT Service Location Protocol October-95

There is an additional mechanism for determining the range of service
attributes. This is the Attribute Request. It is used to obtain the
tags and values of attributes which will be used to formulate Service
Discovery Requests. The Attribute Request and Attribute Reply will
be described later.

While all of these types of queries may be useful, the only one which
is essential is the Service Discovery Request. If a User Agent has
enough a priori knowledge of what it is looking for it can simply
issue a Service Discovery Request and be done with greater than 200 it. The point of
the other requests is to allow a User Agent to formulate a query when
it has limited or no a priori knowledge of the services available and
their attributes.

The Service Request allows the User Agent to specify the Distinguished
Attribute or Scheme of the service agents
need and a Predicate in a specific
language. The general form of a Service Request is shown below:

SCHEME/SCOPE/LANGUAGE/SELECT CLAUSE/WHERE CLAUSE

Briefly, the SCHEME of the service is a unique service type name. The
SCOPE is used for range of the query (SCOPEs are determined
administratively, not by network topology
as will be described later.) The LANGUAGE is a 2 letter code which
defines which language the attributes will be transmitted in (See
Appendix A for a complete list of values). The SELECT CLAUSE
determines what attribute information to return with the reply.
The WHERE CLAUSE determines which services fit 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 install
be sure that responses from other sources are not drowned out. The
request is multicast repeatedly (with a directory agent (see Section 6.0). recommended wait interval of
a second) until there are no new responses, or a certain time has
elapsed. The User Agent may configure a certain 'time out' duration
for example, with the Service Location implementation or in the case
where the User Agent doesn't need ALL the replies, as when any one
service will do.

Veizades, Kaplan, Guttman [Page 9]

INTERNET-DRAFT Service Location Protocol October-95

The format of the Service Request 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = AttrRqst) SrvRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number of services agents found| <Dist Attr> previous responders | <Previous Responders URLs> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Dist. Attr> (cont.) <Previous Responders URLs> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Addresses> Request Predicate> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attributes

Service Request

The reply has the following fields: Distinguished Attribute or Scheme
of the service, the URL of the service (this is the
location that will be used by the User Agent to bind to the service),
a language is included to designate what language was used in the
strings in the reply, and lastly, a list of attributes (tags and
values) which are returned as per the selection in the query.

The general form of an individual reply is as follows:

SCHEME / URL / LANGUAGE / [(ATTR1 = VAL), (ATTR2 = VAL1, VAL2)] /

The reply will always contain the Scheme and the URL. The TTL in the
header should be set to a value no greater than the shortest TTL of the
list of services in the reply. The language is only required if
attributes are returned. Attributes are included in the reply
depending on the "select clause" of the query.

A NULL selection will not include any attribute 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.)

Veizades, Kaplan, Guttman [Page 9] 10]

INTERNET-DRAFT Service Location Protocol July-95 October-95

The format of a Service Reply 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 = AttrRply) SrvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of Attrs replies returned | <Attribute <Reply 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute <Reply 1> (cont.) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute <Reply N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attributes Reply

5.4

Service Request and Reply

Having obtained

5.6 Directory Agent Discovery Request

This request is generated by the entire list User Agent or Service Agent or Service
Application in order to discover a Directory Agent. The query is of attributes which
the service agent
uses form:

DIRECTORY AGENT//en/SCOPE/()

This query is to describe services, the user agent can build Directory Agent multicast address. The scheme of
a query predicate
that describes Directory Agent is 'DIRECTORY AGENT' hence it is the service needs of scheme used in
the user. request. No scope is included in the request, since the query is
GLOBAL in scope. We want to reach all the available directory agents.
The query selects "SCOPE", so SCOPE attribute information will be
returned, if there is a predicate
based on any. The where clause is empty in the list query, so
all Directory Agents will match the request. English is used as the
locale for this example. Typically the language of attributes received. the system or the
user would be used. If no responses are received in the language
specified the system should use the default language, which is English
(en).

The query replies will arrive from different sources. They will be similar
to:

DIRECTORY AGENT/srvloc-resolver.catch22.com/en/(SCOPE=Accounting)/
DIRECTORY AGENT/204.182.15.66/en/(SCOPE=Janitorial Services)/

If the goal is multicast to discover all reachable Directory Agents, the request
must be resent after an interval (recommended time is one second.) This
resent request will include a list of DAs which have already responded.
This list takes the same form as the list of DAs above: Simply a
series of "DIRECTORY AGENT/URL///" strings. Directory Agents which
receive Directory Agent requests will only respond if they are not on
this list. After there are no new replies, the series of requests has
discovered all Directory Agents.

Veizades, Kaplan, Guttman [Page 10]

INTERNET-DRAFT Service Location Protocol October-95

5.7 Distinguished Attribute Request

The User Agent uses the multicast address of Distinguished Attribute Request to find all the distinguished attribute
types of the services that are available on a network.
Like most service
which is being queried for or unicast location PDUs, a client can issue more than one
request to service agents that support
the indicated distinguished attribute. Service agents insure that can satisfy
the predicate reply with all replies have been received. In each
subsequent request, a User Agent adds the attributes list of Distinguished
Attributes (schemes) that they used to satisfy the
predicate. it is aware of.

The reply contains the set format of all attributes which satisfy
the predicate. The reply is unicast to the sender. One reply packet Distinguished Attribute Request is returned for each service that the the service agent finds which
will fulfill the requested predicate.

As special in the case of the Get Attributes Request, that it
specifies no 'Scheme' for the service reply must be
localized type. Instead a '*' is used to
denote a single language. 'wild card.' The locale field of the Service
Reply's header must request may be set sent to any Directory Agent.
This will return all the language of the reply. service types that it knows about. The
request
predicate can only may also be satisfied sent to the General Multicast Address, in order to
find out all service available on the context of User Agent's internet (which are
advertised by Directory Agents and Service Agents.)

*//en//()

* is the language wildcard scheme. There is no scope specified in which this example,
as the scope is unrestricted. The select clause is empty, as no
attribute classes information will be returned. Finally, the where clause is
empty so the request will match all services.

Replies are sent by each Directory Agent and values by Service Agents. These
replies take the form:

printer/224.0.3.10/// <- these multicast addresses are stated in.
http/224.0.3.24/en// examples only. The actual official
nntp/224.0.3.85/en// numbers have not been assigned!
nfs/224.0.3.115///

The Service Reply
contains scheme defines the address type of service, the agent which fulfilled distinguished attribute.
The address to the request. This right of it defines the multicast address should which can
be used in future requests for to send queries to Service Agents. No other information about the
service. The specific service may not be using is
returned in the service locaton
protocol and replies, since the agent is acting on behalf select-clause of this service, so service
location the request must be sent to was
NULL. All schemes were returned since the agent specified by this address. where-clause was NULL.

If the Service Information Addess User Agent is zero already aware of certain Distinguished Attributes,
as in the agent case where it has already received several replies, but wants
to be sure that all Distinguished Attributes are discovered, another
request is multicast, with a selection specifying which Distinguished
Attribute information it is NOT interested in, as:

*//en//(& (SCHEME != PRINTER)
(SCHEME != HTTP)
(SCHEME != NNTP)
(SCHEME != NFS))

Only Directory Agents and Service Agents which have services other than
these four types will respond to the request. When no new replies
arrive from a request, the User Agent has acquired a complete set of
available service types.

Veizades, Kaplan, Guttman [Page 11]

INTERNET-DRAFT Service Location Protocol October-95

User Agent requests that are
collocated. If generated by a server contains more than one instance genesis event, i.e., the
rebooting of a system, loading of the network kernel, etc. should be
sent after a random interval between 0 and 5 seconds.

5.8 Attribute Request and Attribute Reply

Once a User Agent selects a single distinguished attribute, it may
issue a "get attributes request" to find all the attributes associated
with that distinguished attribute. Since different services with a
particular distinguished attribute can have different attributes, to
find all the attributes associated with a distinguished attribute, the
User Agent must form a
particular type union of service all these services maybe attributes returned in a
single datagram.

Veizades, Kaplan, Guttman [Page 10]

INTERNET-DRAFT by all service
Agents. The Attribute information will be used to form Service Location Protocol July-95
Queries.

It 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 = SrvRqst) AttrRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|number of services agents found| <Predicate> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Predicate> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Addresses> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Request

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Version |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Information Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Services | <Service Instance> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> (cont) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of Attributes | <Attribute 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ previous responders | <Attribute 1> (cont.) <Previous Responders URLs> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ . <Previous Responders URLs> \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| <Attribute N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Reply

Veizades, Kaplan, Guttman [Page 11]

INTERNET-DRAFT Service Location Protocol July-95

5.5 Service Attributes Request and Reply

After a user agent has received a response to its Service Request it
will know the address of one or more services, as well as the attribute
values used to satisfy the query. That gives the user agent sufficient
information to know that a service is useful and how to access it. The
user agent may desire further information, however. The Service
Attributes Request returns all the advertised attributes and their
range of values for a given service instance. The user agent can then
provide a complete profile of a given service, which might be
| Reserved | <Language of
interest Reply> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Scheme> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Attribute Request

If sent to a user.

The service request contains Directory Agent, the service instance number of previous responders is zero
and there are no Previous Responder URLs. These fields are used for
repeated multicasting, exactly as for the service in
question. This request should be unicast to the service agent or Service Request. The
Language field determines the
directory agent language in which provided the user agent with the attribute tags and
string values should be returned in. The Service Reply
from which Scheme is the Service Instance information was extracted. The
response service
to this request should be sent in a get attributes for.

Veizades, Kaplan, Guttman [Page 12]

INTERNET-DRAFT Service Reply packet. Location Protocol October-95

The replies take the 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 = SrvAttrRqst) AttrRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | <Language of reply> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Instance> <Attribute List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Attributes Request

6.0 Directory Agents

6.1 Introduction

A directory agent acts as a proxy for many service agents. It
acquires information from service agents and acts as a single point
of contact to supply that information. A service agent registers
information with the directory agent so it can reply to service
location requests the way that the service agent would.

The directory
agent should be able to respond in a timely fashion to user agent
requests and return accurate information about attribute list has the services that are
being exported by same form as the service agent.

The queries that attribute list at the end
of a user agent sends to service agents (i.e. reply.

For example, say I issue an
environment without a directory agent) are the same queries that Attribute Request for "printer". I might
receive the
user agent unicasts to a directory agent. A user agent may cache
information about following reply (the language field is set to 'en'):

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

5.9 Service Discovery Request

Having obtained the presence entire list of other directory agents attributes used to use as fall
back directory agents in case describe a selected directory agent fails.

In scaling
particular kind of service location systems to the size from a Get Attributes Request, (or using
a priori knowledge of a campus service's attributes,) the User Agent can build
a central

Veizades, Kaplan, Guttman [Page 12]

INTERNET-DRAFT Service Location Protocol July-95

repository query predicate that describes the service needs of the user.

This query is added sent directly to limit a Directory Agent. Following the amount
example of general queries in the
network infrastructure. A site may also grow to such last section, say I wanted a size printer that it is
not feasible to maintain only one central repository of service
information. In this case another directory agent is instanciated.
Multiple directory agents are supported within on the framework of this
protocol. Each SA registers with each DA and hosts may either use each
DA in a round robin fashion or may pick
12th floor which DA to use in prints 12 pages per minute. I know there is a
nondeterministic fashion.

6.2 printer
on the 12th floor and that there is one that prints 12 pages per minute
from the response I got from my Get Attribute Request. I am hopeful
that they are one and the same printer. Therefore I issue the
following request:

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

Now, there is no such printer. The Directory Agent Discovery

When responds with a directory agent first comes on line it sends an unsolicited
Attributes
Service Reply to with 0 in the general service location multicast address. If number of responses and no reply values.

The User Agent then tries a DA supports less restrictive query to find a particular scope or set of scopes these are placed in printer,
using the reply 12th floor as an attribute value of "where" criteria, but selecting the service. The class for this
attribute is "SCOPE". PAGES PER
MINUTE attribute, to find out how slow it will be:

printer//en/PAGES PER MINUTE/(LOCATION==12th floor)

Veizades, Kaplan, Guttman [Page 13]

INTERNET-DRAFT Service agents upon receiving Location Protocol October-95

In this reply must
wait case, we get one reply:

printer/igore.wco.ftp.com:515/en/(PAGES PER MINUTE = 3)/

The URL for a random interval of between 0 and 10 seconds and then begin
registration of each the printer here, igore.wco.ftp.com:515 is the location of
the services printer. You can spool to that port on that host and print.

In the service agent advertises.

When a service agent or user agent first comes on-line it issues absence of a
service Directory Agent, the request for above could be
multicast. In this case it would be sent to the distinguished attribute "DIR AGENT"; directory
agents reply printer Multicast
Address and not to this query. A service agent may examine the enclosed
authorization information Directory Agent address above. Service Agents
that can satisfy the predicate will reply. Service Agents which cannot
satisfy the reply do not send any reply at all. The only way a User
Agent can be sure there are no services which match the query is by
retrying the request (say 3 times, 15 seconds apart). If no response
comes, the User Agent gives up and determine if assumes there are no such printers.

One final note: The select field of the directory agent query is an
authorized agent.

A service agent registers used to control how
much information with all directory agents when
either of is returned by the above two events take place. When scopes Directory Agent or Service Agent.
As described in full in Section 10.1.2, there are being used
on 3 different
selections possible. A NULL selection will return no attribute
information, merely a campus scheme, the URL. 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 may
produce a large reply, so a TCP connection may need to be established.
Refer to Section 7.0 for details.

6.0 Directory Agents

6.1 Introduction

A Directory Agent acts as a service agent may choose proxy for many Service Agents and Service
Applications. It acquires information from them and acts as a set single
point of scopes contact to be advertised in
and need only register with directory agents supply that support the scopes in
which they wish information to be registered.

Once a user agent becomes aware of a directory agent it will unicast
its User Agents.

The queries to it. In the event that more than one directory agents
are detected, it will select one a User Agent multicasts to communicate with. When scopes Service Agents (in an
environment without a Directory Agent) are
supported, the user agent will direct its same queries to different
directory agents depending on which scopes are appropriate domains for that the query
User Agent unicasts to be answered in. a Directory Agent. A directory agent continues to send User Agent may cache
information about the above reply at a period presence of 5
minutes. SAs that fail other Directory Agents to detect this heart beat from the DA use as fall
back Directory Agents in
which they are registered with should check case a selected Directory Agent fails.

In scaling service location systems to see if the DA is still
alive. The SA should send size of a Version Request (see section 7.2) campus a central
repository is added to
determine if the DA still has limit the most recent version amount of general queries in the service
information
network infrastructure. A site may also grow to such a size that the SA had previously registered with the DA. If it
fails is
not feasible to respond, the SA should mark the registration as inactive.
When the DA appears again maintain only one central repository of service
information. In this case another Directory Agent is needed. Multiple
Directory Agents are supported within the SA reregisters framework of this protocol.
Each Service Agent or application registers with the DA. If the each DA and hosts may
either use each DA
responds incorrectly, the SA should reregister with it. If all the
DAs in a scope are inactive the SA should reregister in another scope
for it round robin fashion or may pick which DA to be made available.

After a service agent has found use
in a directory agent, it begins nondeterministic fashion.

Directory Agents, in the future, may use mechanisms outside of this
protocol to
register its advertised services one at a time. A service agent must scale to larger global Internets.

Veizades, Kaplan, Guttman [Page 13] 14]

INTERNET-DRAFT Service Location Protocol July-95

6.3 October-95

6.2 Directory Agent Discovery

When a Directory Agent first comes on-line it sends an unsolicited
Service Registration Reply to the general service location multicast address. If a
DA supports a particular scope or set of scopes these are placed in the
reply as an attribute value of the service. The class for this
attribute is "SCOPE". Service Agents and Service Applications will,
upon receiving this reply, wait for some a random interval of between 0 and 3
10 seconds between and then begin registration of each
registration. Registration is done using the Service Registration
packet specifying all attributes for a service. A Service Registration
Packet has the same format as a Service Reply packet, except for of the
function type. They are different in order to avoid ambiguities. A services they
advertise.

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

directory agent must acknowledge each service registration request.

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 agent/srvloc-resolver.catch22.com/en/(SCOPE=ADMIN)/

This directory agent can be sent in one datagram. In this
case reached at the service agent must use a connection oriented protocol to
register itself with URL specified, and supports
the DA. SCOPE called 'ADMIN'.

When a service agent Service Agent or Application, or User Agent first comes on-line
it issues a Directory Agent Discovery Request, as defined in 5.6 above.

A Service Agent or Application registers information with ALL newly
discovered Directory Agents when either of the
same attribute class more than once for above two events take
place. When scopes are being used on a service instance, the
directory agent overwrites the all the values associated with that

attribute class. Separate registrations must campus a Service Agent or
Application may choose a set of scopes to be made for each locale advertised in and need
only register with Directory Agents that support the service is scopes in which
they wish to be advertised in.

If a subsequent registration has registered.

Once a different version number (see
section 7.0) from User Agent becomes aware of a prior one, for the same service, the new packet Directory Agent it will be taken as an update. The version number of unicast
its queries there. In the service event that more than one Directory Agents
are detected, it will be
changed select one to communicate with. When scopes are
supported, the most recent version number in User Agent will direct its queries to different
Directory Agents depending on which scopes are appropriate domains for
the query to be answered in.

A Directory Agent's
service information cache.

The DA must send a service acknowledgment for every registration.

The directory agent may return a server error in unsolicited Service Reply to the acknowledgment,
if for instance, General Multicast
address should always be treated as a registered service lacks an addresss. This error is
carried in situation where the Error Codes field of DA has become
available for the service location packet header. first time. A non-error acknowledgement must have the error code set to zero.
Once Service Agent or Application should
register services with it even if it had done so previously.

6.3 Service Registration

After a DA acknowledges Service Agent has found a service registration Directory Agent, it makes the information
available begins to 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
register its advertised services one at a time. A Service Agent must
wait for some random interval between 0 1 2 and 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = SrvAck) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Acknowledgment

6.4 Service Unregister

When a service seconds between each
registration. Registration is no longer available for use, done using the service must
unregister itself from directory agents that it has been registered
with. Service Registration
packet specifying all attributes for a service. A Directory Agent must
acknowledge each service uses the following PDU to unregister itself. registration request.

Veizades, Kaplan, Guttman [Page 14] 15]

INTERNET-DRAFT Service Location Protocol July-95 October-95

The format of a Service Reply 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 = SrvUnreg) SrvReg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . |
\ <Service Instance> Registration Information> \
| . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Unregister Registration

Service registration may use a connectionless protocol (e.g. UDP), or a
connection oriented protocol (e.g. TCP). The service agent should retry this registration operation if there is no response
from the directory agent. The directory agent acknowledges
may contain more information than can be sent in one datagram. In this
operation
case the Service Agent or Application must use a connection oriented
protocol to register itself with the DA. When a service acknowledgment. Once Service Agent or
Application registers the same attribute class more than once for a
service agent
receives this acknowledgment, it can assume 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 no
longer to be advertised by the directory agent.

6.5 SCOPE Discovery and Use

The scope mechanism in.

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

SCHEME / URL / LOC / (ATTR1 = VALUE), (ATTR2 = VAL1, VAL2) /

An example of a service location protocol registration is an important
feature to enhance its scalability. as follows:

printer/igore.wco.ftp.com:515/en/(SCOPE=DEVELOPMENT),
(PAPER COLOR=WHITE),
(PAPER SIZE=LETTER),
(LANGUAGE=POSTSCRIPT, HPGCL),
(LOCATION=12th Floor))/

The primary use of scopes same registration could be done again, in German (note that
'printer' the scheme, is to
provide an IANA term, so it will remain in the capability to organize a campus along conceptual lines. A
set
language it was originally registered in with IANA, i.e. in English):

printer/igore.wco.ftp.com:515/de/(SCOPE=ENTWICKLUNG),
(PAPIERFARBE=WEISS),
(PAPIERFORMAT=BRIEF),
(DRUECKERSPRACHE=POSTSCRIPT,HPGCL),
(STELLE=12te Etage) /

Registrations must contain an Attribute of services can SCOPE unless they are
unscoped and then they must be assigned to a given department of an
organization, to registered with all directory agents.
See example above.

The Directory Agent may return a certain building or geographical area or server error in the acknowledgment,
if for instance, a
certain purpose. The users registered service lacks an address. This error is
carried in the Error Codes field of the system can be presented with these
organizational elements as a top level selection, before services
within this domain are sought. service location packet header.

Veizades, Kaplan, Guttman [Page 16]

INTERNET-DRAFT Service Location Protocol October-95

A campus that has grown beyond a size that can be reasonably serviced
by a few DAs can use the SCOPE mechanism. DAs non-error acknowledgment must have the attribute class
"SCOPE". The values for this attribute are error code set to zero.
Once a list of strings that
represent DA acknowledges a service registration it makes the administrative areas for which this directory agent is an
authority. The semantics information
available to 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 location header (function = SrvAck) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Acknowledgment

Service Agents and language of Applications should start the strings registration process
before the TTL they used for registration expires if they want to describe
the SCOPE are entirely the choice of the administrative entity of the
particular domain in which these SCOPEs exist. Directory agents
advertise the list of all scopes that are available. A service agent
chooses at least one scope in which
continue to be registered. A advertised.

6.4 Service Unregister

When a service agent is no longer available for use, the Service Agent or
Application must register with all directory agents in that scope.

Being a member of a scope means that you use a specific set of
directory agents unregister itself from Directory Agents that support your scope. User agents send all
requests to DAs which support it has
been registered with. A service uses the indicated scope. following PDU to unregister
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
register with location header (function = SrvUnreg) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Unregister Information> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Service Unregister

The Service Agent should retry this operation if there is no response
from the DA(s) in their scope. For a UA to find Directory Agent. The Directory Agent acknowledges this
operation with a service acknowledgment. Once the Service Agent
receives this acknowledgment, it can assume that is registered in a particular scope they must contact a DA which
supports the indicated scope. There service is no limitation on scope
membership built into
longer advertised by the protocol; that is Directory Agent.

The Service Unregister Information sent to say, a user agent or the Directory Agent has
the following form:

SCHEME / URL / LOC / [(Attr1), ... ,(AttrN)]/

This will unregister the service agent may from the Directory Agent in every
language it was registered in. To unregister the printer above, use:

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

If attributes are included in the unregistration, the attributes
will be a member of more than one scope. Membership unregistered, but not the entire service. That is
open to say
that the class Attr1 and all agents, unless some authorization mechanism is added to
limit access. its values will no longer be advertised

Veizades, Kaplan, Guttman [Page 15] 17]

INTERNET-DRAFT Service Location Protocol July-95

An end system finds October-95

for the scopes given service. Notice that are available in a campus the language for the attributes
must be included. An example of unregistering the PAPER SIZE
attribute would be:

printer/igore.wco.ftp.com:515/en/(SCOPE=DEVELOPMENT),(PAPER SIZE)/
printer/igore.wco.ftp.com:515/de/(SCOPE=ENTWICKLUNG),(PAPIERFORMAT)/

Two unregistrations would have to be sent; one for English and one
for German.

More than one attribute can be unregistered, by
multicasting inserting a DA discovery request to all directory agents. list, i.e.

nfs/23.34.45.11/en/(DESCRIPTION),(MOUNT POINTS)/

6.5 SCOPE Discovery and Use

The
discovery message contains the scope or scopes, if known, that are
being used, as part mechanism in the service location protocol is an important
feature to enhance its scalability. The primary use of the attribute request. Directory Agents that
support the scope(s) in question return reply. If no scope scopes is
specified, all directory agents respond to this request. This exchange
will give
provide the end system capability to organize a list campus along administrative lines.
A set of all scopes that it services can use for scope
membership but this may not be the list of all scopes available on the
users internet. Some scopes may be shielded from registration
and queries using an access control system as described above.

A SA may not register with scopes outside assigned to a given department of the SA's internet.

After an end system has picked a scope
organization, to use as its default scope it
may ask a directory agent certain building or geographical area or for the list a
certain purpose. The users of all available scopes known to the DA, including those that are not system can be presented with these
organizational elements as a top level selection, before services
within the user agent's internet.

To get this list the user agent sends a scope list request to the
directory agent.

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 = ScopeRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Scope List Request

The directory agent responds with domain are sought.

A campus that has grown beyond a scope list reply. Every scope size that is available for can be reasonably serviced
by a few DAs can use to the user agent is listed in the reply.
In addition to the list of all scopes the directory agent also
returns SCOPE mechanism. DAs have the attribute class
"SCOPE". The values for this attribute are a list of scopes strings that are outside of the boundaries of
the user agents internet. For each foreign scope the directory agent
returns
represent the scope name administrative areas for which this Directory Agent is an
authority. The semantics and language of the hosting directory agents' service
instances. Foreign directory agents and scopes maybe strings used to support
name spaces that are outside of the autonomous domain describe
the user agent
belongs to. Resources within those foreign networks can be found
using SCOPE are entirely the normal service location queries. The propogation choice of foreign
scopes to directory agents in the user agents multicast perimeter is
outside the scope of this document though global directory services
may provide this service.

Veizades, Kaplan, Guttman [Page 16]

INTERNET-DRAFT Service Location Protocol July-95

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 = ScopeRply) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| number of local scopes | number of foreign scopes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Local Scope List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Foreign Scope List> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Scope List Reply

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Scope Name (Typed String) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| num administrative entity of supporting DAs | Service Instance List |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Instance List(cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Foreign Scope

6.6 SCOPE Propagation

User the
particular domain in which these SCOPEs exist. Directory Agents contact their DA for
advertise the list of all known scopes both
foreign that are available. A Service Agent
or Service Application chooses at least one scope in which to be
registered, and local. To build this list of scopes, DAs must propagate
this register with all Directory Agents in that scope.

A Directory Agent which has a SCOPE will send replies to Directory
Agent Discovery requests with the scope information from included. Note
that Directory Agent Requests MUST ALWAYS select that SCOPE
information be returned.

The query:

directory agent//en/SCOPE/()

Could receive the following reply:

directory agent/diragent.void.com/en/(SCOPE=ADMINISTRATION)/

The same Directory Agent which does not support any scopes would reply:

directory agent/diragent.void.com/en//

Veizades, Kaplan, Guttman [Page 18]

INTERNET-DRAFT Service Location Protocol October-95

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

directory agent/123.12.34.56/en/(SCOPE=ADMIN,DEV,SALES)/

Normally all Directory Agents respond to another. DAs a Directory Agent Request. If
only Directory Agents of a particular set of scopes are desired, issue
a query like the following:

directory agent/ADMIN,SALES/en//()

Here the SCOPE field of the request is filled in with a list of the
scopes which can be used to satisfy the request.

Being a member of a scope means that you use a multicast address specific set of
Directory Agents that support your scope. User Agents send all
requests to DAs which support the indicated scope. Services are
registered with the DA(s) in their scope. For a UA to propagate this information from find a service
that is registered in a particular scope they must send requests to a
DA which supports the indicated scope. There is no limitation on scope
membership built into the protocol; that is to say, a User Agent or
Service Agent or Application may be a member of more than one DA scope.
Membership is open to all, unless some external authorization mechanism
is added to another. limit access.

7.0 Service Location Connections

When a new DA comes online it sends Service Location Request results in a DA scope list request to the DA
multicast address. Other DAs respond using reply from a Service or
Directory Agent that will overflow a datagram, the Scope List Reply with
all User Agent can open
a connection to the scopes they support both locale Agent and foreign. At reissue the end of
this interaction request over the DA connection.

The reply will know about all available scopes and DAs
which support them.

7.0 Service Information Versions

Service location information can live in three locations: at the
service agent, be returned with the directory agent and/or overflow bit set (see section 5.4.6)
The reply will contain data, as much as will fit into a single packet.
If no MTU information is available for the user agent. route, assume that a maximum
packet size is 1460.

A service
agent has User Agent that wishes to obtain the authoritative version of overflowed data must establish
a connection with the service information. Directory Agent or Service Agent with the data.
The
directory agents request is simply sent again (with a new XID, however.) The reply
is returned over the connection stream.

A Service registration which exceeds one packet in length should be
made by establishing a connection with a Directory Agent and sending
the user agents have copies of registration over the service agent's
information. The "information version" provides an indication connection stream.

Directory Agents and Service Agents must respond to connection requests
and Services whose registration can exceed a packet in length must be
able to connect and send. User Agents should be able to make requests
over a connection. 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
user and directory agents that the copies that they hold are out size of
sync with the authoritative database in the service agent. In addition
to the information version a time to live is set with each reply packet replies.

Veizades, Kaplan, Guttman [Page 17] 19]

INTERNET-DRAFT Service Location Protocol July-95 October-95

8.0 Security Considerations

There are no provisions in this value protocol to insure data integrity, data
authority or data confidentiality. Mechanisms in seconds is the maximum time a value maybe cached
reguardless of underlying
network layer protocol or at the information version. A value of 0 indicated that
information service access point may not be cached.

7.1 Information Versions

For every used to
provide these functions.

9.0 Multicast vs. Broadcast

The service instance advertisement, location protocol was designed for use in networks where
multicast at the service agent attaches network layer is supported; in some instances
multicast may not be supported. To support this protocol in networks
where multicast is not supported the following modifications are made
to support the protocol in an
information version environment where network layer broadcast
is supported.

9.1 Single Subnet

If a network is not connected 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 advertisement. This version number network is designed so that a way Directory Agent
address is statically configured with each User Agent, the directory
Agent will act as a bridge for information that resides on different
subnets. The Directory Agent address can be dynamically configured with
end systems using a protocol like the IP Dynamic Host Configuration
Protocol.

9.3 Service Multicast Address

Each service agent must have a unique multicast address to tag the current state of which it belongs
to. This multicast address is obtained from the information that
it IANA. This mechanism
is advertising. When this information changes, used so that the number of datagrams any one service agent
increments the version. Agents that receives is
minimized.

When undirected queries are caching made concerning this information can
ask the service agent for the version type of service, the current service
information.

For very volatile information, which must
query should be gathered each time a
request is made, the service agent implements the value as a
'function'. This means that on replying sent to each request, the service
agent or directory agent must resolve matching multicast address. If the function. The version number subnet
does not need support multicast then the query should be broadcast to change when the function's resolution value does.
This mechanism allows caching of service information and version state,
even
Service Location port.

Veizades, Kaplan, Guttman [Page 20]

INTERNET-DRAFT Service Location Protocol October-95

10.0 Protocol Formats

10.1 Fields Used in Service Location Packets

The following section supplies formal definitions for very volatile information or information which may depend on all protocol
elements introduced in the state sections above.

Protocol Element Used in
----------------------------------- -------------
10.1.1 <Previous Responder's URL> SrvRqst
10.1.2 <Service Request Predicate> SrvRqst
10.1.3 <Reply> SrvRply
10.1.4 <Service Registration Information> SrvReg
10.1.5 <Service Unregister Information> SrvUnReg
10.1.6 <Attribute List> AttrRply
10.1.7 <Language of transactions within Reply> AttrRqst & AttrRply
10.1.8 <Service Scheme> AttrRqst

10.1.1 Previous Responders URL

The previous responder's URL is specified as

followed by a distributed system. (See section
9.0 for details on function resolution.) SAs may not respond to UAs comma with unresolved function values. no white space. The information contained in such
replies URL is very volitile and should not be cached the information
version is set to zero and these replies may not be cached.

7.2 User Agents

When a user agent caches information that it has received from a
service agent address of the
Directory Agent or directory agent it should verify Service Agent which supplied the previous response.
The format for URLs in Service Location is defined in 12.2.

Example:

some.corp.com,128.127.203.63,

10.1.2 Service Request Predicate

The following grammar expresses the version number form of a Service Request
Predicate:

<predicate> ::= <scheme>/<scope>/<lang>/<select>/<where>
<scheme> ::= string representing type of service.
'/' is
still valid. It can do not allowed in this by requesting the service instance's
current version number from the source of string.
<scope> ::= string representing the cached information.

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 directory agent scope.
'/', ':' are not allowed in this string. The
scope 'LOCAL' and 'REMOTE' are reserved.

<lang> ::= 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service location header (function = VerRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| letter code, as described in Appendix A.

<select> ::= <select-list> |
\ <Service Instance> \
<select-all> |
<select-none>
<select-list> ::= <select-item> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version Request
<select-item>, <select-list>
<select-item> ::= <attr-tag>

Veizades, Kaplan, Guttman [Page 18] 21]

INTERNET-DRAFT Service Location Protocol July-95

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ October-95

<attr-tag> ::= class name of an attribute of a given scheme
This tag cannot have include the following
characters: '(', ')', ',', '=', '!', '>',
'<', '/'
<select-all> ::= *
<select-none> ::=
That is NOTHING or white space.

<where> ::= <where-any> | Service location header (function = VerRply)
<where-list>
<where-any> ::= ()
<where-list> ::= (& <query-item> <query-list>) |
(| <query-item> <query-list>) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<query-item>
<query-list> ::= <where-list> | Information Version
<query-item> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Version Reply

The information may be invalid
<query-item> <query-list>
<query-item> ::= (<attr-tag> <comp-op> <attr-val>) |
<where-list>
<comp-op> ::= != | == | < | <= | > | >=
<attr-val> ::= any string (see Section 10.3 for several reasons. The service agent
may not exist, the service instance may no longer exist or the end
system ways
in which attr-vals are interpreted.)

Value strings may not contain '/', ','
'=', '<', '>'. '(' and ')' can only be authorized to use the service. Error values are
returned used
for all the above reasons. When an error is received purpose of encoding a user
agent must invalidate the cached information. A user agent binary values.
Binary encodings (See Section 10.3) may try to
revalidate the information, unicasting
include the original predicate above reserved characters.

Note on string matches: All strings are case insensitive, with respect
to the
service agent string matching on queries. All preceding or may try trailing blanks should
not be considered for a match, but blanks internal to reacquire a service provider multicasting
the original predicate.

7.3 Directory Agents

Directory agents must return correct information since they string are acting
relevant. For example " Some String " matches "SOME STRING" but not
"some string".

A predicate has a simple structure, which depends on behalf of service agents. Service agents must update directory
agents when their databases change. The service agent must unregister
any service instance before any information about the service is
changed. This limits parentheses,
commas and slashes to delimit the availability elements. Examples of any incorrect or transient
false advertisements. As soon as proper usage
have been given throughout the service agent has document. The terms used above are
described below:

predicate:
Placed in a new set of
service information to advertise, it reregisters it with the Directory
Agent.

A Service Request, this is interpreted by a Service
Agent or Directory Agent will still need to verify that the information it is
caching is accurate, as a service agent might have gone down. It can
do this by periodically sending version number requests of services
that it has determine what information cached about. These requests are sent to the
service agent that registered the information.

7.4 Service Agents

Service agents advertise
return.

select-clause:
This determines what information that they authoritatively own.
When a service agent advertises information, it also indicates the to return. There are 4 types
of select-clause: NULL, ANY and LIST.
NULL: The reply returns no attribute information version. When the service agent registers with a directory
agent, the service agent is responsible for invalidating the directory
agent's cached state before the information changes at
PARTICULAR services which satisfy the service
agent. where-clause.
ANY: The service agent must then reregister reply returns all attribute information, as above.
LIST: The reply returns the new attribute information with for the Directory Agent.

8.0 Service Location Connections

When a service location request results in a reply from a service or
directory agent
attributes whose class names are listed, as above.
Recall that will overflow a datagram, the user agent can open an attribute has a connection to the agent class name and reissue the request over the connection. a set

Veizades, Kaplan, Guttman [Page 19] 22]

INTERNET-DRAFT Service Location Protocol July-95 October-95

of values. The response list contains a set of class names.

where-clause:
This determines which services the request matches. An empty
where-clause will match all services. The request will be received over
limited to services which have the same connection. A directory or
service agent indicates an overflow via Scheme which was defined
prior to the overflow flag predicate, so the where-clause
is not the sole factor in picking out which services match the
service location packet header.
request.

where-list:
The operations that where-list is a logical expression. It can overflow are be a single
expression, a disjunction or a conjunction. A single expression
must apply for the attribute reply, where-clause to match. A disjunction matches
if any expression in the service reply and service register. This
operation requires disjunctive list matches. A
conjunction matches only if all elements in the implementation conjunction
match.

Note that there is no logical negation operator: This is
because there is no notion of returning "everything except" what
matches a reliable byte stream
protocol, like TCP, by the user, service, given criteria.

A where-list can be nested and directory agents.

9.0 Special Data Types

9.1 Function Resolution

The attribute value of an attribute 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 a function. 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 the where-clause.

query-item:
A function query item has the form:
(<attr-tag> <comp-op> <attr-val>)

Examples of this would be:
(SOME ATTRIBUTE == SOME VALUE)
(STATUS != RESERVED)
(QUEUE LENGTH <= 234)

10.1.3 Reply

Service Replies have the following form:

SCHEME / URL / LANGUAGE / [ <attr-list> ] /

SCHEME is a
handle for a rapidly changing attribute value that must be resolved at string. Schemes are standardized by registering them
with the IANA.
URL is the service agent (e.g. a piece access point of code that the service. It is the network
address or domain name where the service agent runs to
determine an attribute like whether a can be accessed.

Veizades, Kaplan, Guttman [Page 23]

INTERNET-DRAFT Service Location Protocol October-95

LANGUAGE codifies the language in which the attributes of the
service have been registered. The language is on-line). a two letter
code listed in Appendix A.
The
function data that <attr-list> is passed to returned if the service agent select-clause of the query is
not NULL.

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

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

(SCOPE=ADMINISTRATION)
(COLOR=RED, WHITE, BLUE)
(DELAY=10 Minutes),(MOST RECENT BUILD=10-5-95),(PRIORITY=LOW,HIGH)

The third example has three attributes in the service agent to identify list. Color can take
on the method to determine values red, white and blue. There are several other examples
of replies throughout the
attribute's value. document.

10.1.4 Service Registration Information

The type of any value that is returned in Service Registration Information has the same form as a Function Resolve Reply
in the section above. The attribute list must be a basic type: string, integer, boolean or opaque. A function
resolve reply cannot return another function value. A Function Resolve
Reply must have a TTL of zero.

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

10.1.5 Service location header (function = FuncReslvRqst) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function Resolution Opaque Value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Function Resolve Request

0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unregister Information

SCHEME / URL / LANGUAGE / [ <tags> ] /

SCHEME, URL, and LANGUAGE are described above.

<tags> ::= <tag-list>
<tag-list> ::= (<attr-tag>) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Function Resolve Reply

9.2 Opaque

The Opaque data type allows for (<attr-tag>), <tag-list>

Examples of tags:
(COLOR)
(COLOR), (STATUS), (PRIORITY)

If there are no tags included in the unregistration, the entire
service, in each language which it was registered, is removed from the inclusion
storage of vendor defined data
types. When this data type cannot be resolved by a user agent it Directory Agent. If tags are included, each tag in the
list is used to find the attribute for the service specified. In the
first example, the COLOR attribute and all its values are
unregistered. In the second example, COLOR, STATUS and PRIORITY are
unregistered.

Veizades, Kaplan, Guttman [Page 20] 24]

INTERNET-DRAFT Service Location Protocol July-95

should October-95

A separate Service Unregister must be ignored. Directory agents should store and pass these
values on unintrepreted. Opaque types are uniquely identified by their
TAG under done for each language in which
the service was registered, providing a given standarization authority.

10.0 Authentication

There are no provisions list of tags in this protocol to insure data integrity, data
authority or data confidentiality. Mechanisms the language
in question. Example (unregistering 2 attributes in English, German
and French):

service/12.34.56.78/en/(COLOR), (SIZE)/
service/12.34.56.78/de/(FARBE), (GROESSE)/
service/12.34.56.78/fr/(COLEUR), (TAILLE)/

10.1.6 Attribute List

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

10.1.7 Language of Reply

The language of reply codifies the underlying network
layer protocol or at language in which the attributes of
the service access point may be used to provide
these functions.

11.0 Multicast vs. Broadcast have been registered. The language is a two letter code,
listed in Appendix A.

10.1.8 Service Scheme

The Service Scheme is a string describing the type of service. These
strings are registered with IANA. They may not include '/' or ','.

10.2 URLs in Service Location

A URL in the context of service location protocol was designed for use in networks where
multicast at can have the network layer form:

[(PROTOCOL)] URL

PROTOCOL is supported; in some instances
multicast may optional. If it is omitted, IPv4 is assumed. Other values
have not yet been determined.

The representation of the URL depends on the PROTOCOL. In the case of
IPv4:

(IPv4) URL ::= <address> [:<portnum>]
<address> ::= <dns-name> | <dotted number>
<dns-name> ::= A qualified domain name, as 'cs.stanford.edu'
<dotted number> ::= An a.b.c.d representation of a 32 bit IP
address.

10.3 Attribute Value encoding rules

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

Attribute values can have be supported. To support this protocol any string with the exception of '(', ')',
'=', '>', '<', '/' and ',' (the comma) except in networks the case described
below where multicast opaque values are encoded.

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

Veizades, Kaplan, Guttman [Page 25]

INTERNET-DRAFT Service Location Protocol October-95

- Boolean values are either TRUE or FALSE. This is not supported the following modifications are made
to support case
irrespective of the protocol language (i.e. in an environment where network layer broadcast French or Tegulu, Boolean TRUE
is supported.

11.1 Single Subnet

If 'TRUE', as well as in English.) Boolean attributes can take only
one value.

- Integer values are expressed as a network sequence of numbers. The range of
allowable values, for this 32 bit quantity, is not connected -2147483648 to any other networks simple network
layer broadcasts will work
2147483647.

- Opaque values (i.e. binary values) are expressed in place of multicast.

11.2 Multiple Subnets radix-64
notation. The directory agent provides a central clearing house syntax is:

<opaque-val> ::= (<len>:<radix-64-data>)
<len> ::= integer length of information
for user agents. If the network is designed so that a directory agent
address is statically configured with each user agent, original binary data
<radix-64-data> ::= An encoding of the directory
agent will act as binary data into a bridge new
format, see below for information that resides on different
subnets. The directory agent address can be dynamically configured with
end systems using a protocol like the IP Dynamic Host Configuration
Protocol.

11.3 Service Multicast Address

Each service must have a unique multicast address to which it belongs
to. This multicast address is obtained from the IANA. This mechanism algorithm:

Radix-64 encodes every 3 bytes of binary data into 4 bytes of ASCII
data which is used so that in the number range of datagrams any one service receives is
minimized.

When undirected queries characters which are made concerning this type fully printable.
The range of service, characters is from '0' through 'o'. This is the
query should be sent same
technique used by the uuencode program.

To encode binary to radix-64:

Take the matching multicast address. binary data input in sets of 3 bytes, call them B1, B2 and
B3. If the subnet
does buffer has a number of bytes not support multicast then the query should be broadcast divisible by three,
pad it with NULL bytes to be divisible by three. Initialize the
Service Location port.

Veizades, Kaplan, Guttman [Page 21]

INTERNET-DRAFT Service Location Protocol July-95

12.0 Data Element Formats

12.1 Attributes
0 1 2 3
0 1 2 3
target array of 4 5 6 7 8 9 0 1 2 3 bytes b1, b2, b3 and b4 to 0x30. Add to this:

b1 += (B1 & 0xFC) >> 2;
b2 += (B1 & 0x03) << 4 5 6 7 8 9 0 1 + (B2 & 0xF0) >> 4;
b3 += (B2 & 0x0F) << 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length |S| Std. Auth. | num values |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute Class> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Attribute Value> \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Length The number + (B3 & 0xC0) >> 6;
b4 += (B3 & 0x3F);

To decode radix-64 to binary:

Subtract 48 (that is 0x30) from each of bytes b1, b2, b3 and b4.
Initialize an array in the attribute,
including the length field

S bit set if the attribute is a standard
attribute

Standardization Authority A number assigned to an organization
which defines semantics for attributes.
(Registered with IANA)

Number size of Values The the number of values returned bytes given in the
attribute value field.

Attribute Class <typed string>

Attributes are {class, value} pairs that define a characteristic of a
service. There are three classes
length field of attributes: distinguished
attributes, standard attributes and regular attributes.

A standard attribute is indicated by setting the standard attribute
bit. Standard attributes have a well defined interpretation within
a given standardization authority. Distinguished attributes <opaque-val>. Then decode every three values:

B1 = (b1) << 2 + (b2 & 0x30) >> 4;
B2 = (b2 & 0x0F) << 4 + (b3 & 0x3C) >> 2;
B3 = (b3 & 0x03) << 6 + (b4);

Examples:

(5:00000000) encodes 5 NULLs.
(6:00000000) encodes 6 NULLs. They are
standard attributes in all standardization authorities. A the same due to the padding.
(6:J6E\K6lQ00) endodes "hello!"

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

Veizades, Kaplan, Guttman [Page 22] 26]

INTERNET-DRAFT Service Location Protocol July-95

distinguished attribute is denoted by a standard attribute whose October-95

- Keywords may be expressed as an attribute class is "DIST ATTR". that has no values:

(power pc enabled=)
or
(official use only=)

11.0 Implementation Requirements

A distinguished attribute is
always User Agent MAY:
- Listen on the 32 bit multicast Service Location General Multicast address assigned by IANA followed by a
typed string giving the ASCII representation of for
unsolicited Directory Agent Replies. This will increase the distinguished
attribute.

12.2 Service Instance

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 | Num set of Addrs. | Addr 1 Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr 1 length | <Address 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Address 1> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Srv Info Length | <Service Info for Address 1> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Info for Address 1> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Addr N Type | Addr N length | <Address N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Address N> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Srv Info Length | <Service Info
Directory Agents available to it for Address N> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Service Info making replies. See Section
6.2.
- Provide a way for Address N> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Instance

A service instance is the application to configure the default DA, so
that this one can be used without needing to find it each
initially.
- Be able to multicast requests to a multicast address. If the
multicast address of the service in question, the port
of is not known, the service access point and any additional service specific
information needed UA must be able to make use a
Distinguished Attributes query to obtain the service connection. A service multicast address
is typed
for the scheme of the request.
- Be able to support a variety handle an implosion of network protocols. replies after a multicast
request. The service
specific information implementation may be service layer protocol specific information
that facilitates configurable so it will either
return the service rendezvous. When more than one network
interface first reply, all replies until a timeout or protocol is used keep trying
till the results converge.

A User Agent MUST:
- Be able to support unicast requests and receive replies reliably from a service on an end system,
multiple addresses can DA.

A Service Application MUST be added able to:
- Listen to a service instance using the number
of addresses field.

Veizades, Kaplan, Guttman [Page 23]

INTERNET-DRAFT Service Location Protocol July-95

12.3 Addresses

The General Multicast address types for
unsolicited Directory Agent Replies. If one is detected, and the
DA has the right scope, all services which are specified in currently being
advertised must be registered with the assigned numbers RFC. Address
representation will vary from one network protocol DA. See Section 6.2.
- Unicast registrations and unregistrations reliably to another.

An IPv4 a DA.

A Service Agent MUST be able to:
- Listen to the Service Location General Multicast address for
unsolicited Directory Agent Replies. If one is represented as follows:

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Port | Protocol Bit Array |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where detected, and the
DA has the right scope, all services which are currently being
advertised must be registered with the port DA. See Section 6.2.
- Unicast registrations and unregistrations reliably to a DA.
- Listen to the multicast address of the service it is advertising.
The incoming requests should be filtered: If the redevous port for URL of the protocol SA is
in question
and the protocol is Previous Responders URL list, the SA should not respond.
Otherwise, a bit map of response to the multicast query should be unicast to
the UA which protocols are supported for
connections. When bit 1 (LSB) is set UDP is supported and when bit
two is set TCP is supported.

12.4 Predicate

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Predicate length | <Predicate> |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
\ <Predicate> (cont.) \
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Predicate

Veizades, Kaplan, Guttman [Page 24]

INTERNET-DRAFT sent the request.
- Listen to the Service Location Protocol July-95

13.0 Predicate Language

All values are represented in network byte order.

<relational op> ::= '==' | '!=' | '<'
'>' | '>=' | '<='

<boolean op> ::= '&' (logical AND) | '|' (logical OR)

<integer> ::= 'I' <int val>
<int val> ::= 4 byte signed quantity
<typed string> ::= 'S' <string type> <len> <string bytes>
<string type> ::= 1 byte value, see 'String Types' below
<len> ::= 2 byte value, counts number of string bytes
<string bytes> ::= If ASCII typed, there is <len> number General Multicast address for
queries of
characters. any type. If ISO646 or Unicode string
type, then there are half of <len> in 2
byte characters in the string bytes.

<function> ::= 'F' <resolution>
<resolution> ::= 4 byte unsigned quantity

<boolean> ::= 'B' <bool val>
<bool val> ::= 1 byte quantity, only query can be replied to by the first bit in
Service Agent, the
field is read. 0 = FALSE, nonzero = TRUE

<opaque> ::= 'O' <len> <opaque val>
<opaque val> ::= a vendor intrepreted sequence Service Agent must do so. It must check first
to make sure it is not on the list of bytes

<distinguished attribute> ::= 'D' <unsigned int> <typed string>
<unsigned int> ::= 4 byte unsigned integer 'previous responders.'
It will receive 'Distinguished Attribute' requests this way.

A Directory Agent MUST be able to:
- Send an unsolicited Directory Agent Discovery reply to the

Veizades, Kaplan, Guttman [Page 25] 27]

INTERNET-DRAFT Service Location Protocol July-95

Example:

The predicate language is expressed in reverse polish notation. A
predicate query reqeusting all printers October-95

Service Location General Multicast address on startup. See
Section 6.2.
- Listen on the 12'th floor would read
as follows (all quoted characters are ASCII representations of Directory Agent Multicast Address for Directory
agent discovery requests. Filter these requests if the Previous
Responder URL list includes the DA's URL.
- Listen on the TCP and UDP ports for unicast requests,
registrations and unregistrations and service them.
- Provide a
one byte value. Otherwise all bytes are to way in which SCOPE information can be taken as a literal
decimal values). The example uses 239.56.125.101 as used to configure
the multicast
address for printers, Directory Agent.
- Age out the services which have been registered so that when the
service registration's TTL expires, the service advertisement is invalid.

Byte boundary

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|'&'|'='|'='|'D'|239| 56|125|101|'S'| 1 | 0 | 9 |'D'|'I'|'S'|'T'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|' '|'A'|'T'|'T'|'R'|'S'| 1 | 0 | 7 |'P'|'R'|'I'|'N'|'T'|'E'|'R'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|'='|'='|'S'| 1 | 0 | 8 |'L'|'O'|'C'|'A'|'T'|'I'|'O'|'N'|'S'| 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 0 | 11|'1'|'2'|'''|'T'|'H'|' '|'F'|'L'|'O'|'O'|'R'|
+---+---+---+---+---+---+---+---+---+---+---+---+---+

14.0
withdrawn.

NOTE: Service Applications, Service Agents and User Agents use
ephemeral ports for transmitting information to the service location
port.

12.0 Interesting Constants

IP Port number for unicast requests to Directory Agents:

UDP and TCP Port Number: 427

Multicast Addresses

General Multicast Address: 224.0.1.22
Directory Agent Multicast Address: 224.0.1.35

String

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

Character Encoding Types

ASCII 1
ISO646 2
Unicode 3
JIS 4
SJIS 5
EUC 6

Error Codes

No Error 0
Other Error 255
LANGUAGE_NOT_SUPPORTED 1
AUTHORITY_NOT_SUPPORTED 2
PROTOCOL_PARSE_ERROR 3
INVALID_REGISTRATION 4

Veizades, Kaplan, Guttman [Page 26] 28]

INTERNET-DRAFT Service Location Protocol July-95

15.0 October-95

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

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

14.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 of the
5th ACM Symposium on Principles of Distributed Computing, pp. 1-10,
1986.

[11] D. Cheriton and T. Mann, "Uniform Access to Distributed Name
Interpretations in the V-system".

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

[13] P. Mockapetris. "Domain Names - Implementation and Specification".
RFC 1035, NIC. November 1987

Veizades, Kaplan, Guttman [Page 27] 29]

INTERNET-DRAFT Service Location Protocol July-95 October-95

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

[15] The Unicode Standard Version 1.0 Volume 1, Addison-Wesley
Publishing (ISBN 0-201-56788-1). October 1991.

[16] ISO 639:1988 (E/F) "Code for the representation of names of
languages"; ISO, Geneve, 1988.

[17] K. Lunde, "Understanding Japanese Information Processing,"
O'Reilly & Associates, Inc. 1993

17.0

15.0 Author's Addresses

John Veizades
TGV, Inc.
101 Cooper St
Santa Cruz, CA 95060

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

Email: veizades@tgv.com

Scott Kaplan
CoroNet Systems Inc.
5150 El Camino Real, Suite C-22
Los Altos,
346 Fair Oaks St.
San Francisco, CA 94022 94110

Phone: +1 415 960 3255 x 216
Fax: +1 415 960 3288 285 4526

Email: scott@coronet.com scott@catch22.com

Erik Guttman
PeerLogic, Inc.
555 De Haro
1920 Sacramento St., Suite 300 #8
San Francisco, CA 94107 94109

Phone: +1 415 626 4545 921 6570

Email: guttman@cs.stanford.edu

18.0

16.0 Document Expiration

This document expires January 6, April 24, 1996

Veizades, Kaplan, Guttman [Page 28] 30]

INTERNET-DRAFT Service Location Protocol July-95 October-95

Appendix A - Technical contents of ISO 639:1988 (E/F)

"Code for the representation of names of languages".
Two-letter lower-case symbols are used.
The Registration Authority for ISO 639 is Infoterm,Osterreiches
Normungsinstitut (ON), Postfach 130, A-1021 Vienna, Austria.

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
as Assamese hr Croatian na Nauru
ay Aymara hu Hungarian ne Nepali
az Azerbaijani hy Armenian nl Dutch
no Norwegian
ba Bashkir ia Interlingua
be Byelorussian ie Interlingue oc Occitan
bg Bulgarian ik Inupiak om (Afan) Oromo
bh Bihari in Indonesian or Oriya
bi Bislama is Icelandic
bn Bengali; Bangla it Italian pa Punjabi
bo Tibetan iw Hebrew pl Polish
br Breton ps Pashto, Pushto
ja Japanese pt Portuguese
ca Catalan ji Yiddish
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
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 [Page 29] 31]

INTERNET-DRAFT Service Location Protocol July-95 October-95

ta Tamil
te Tegulu
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 [Page 30] 32]

----