[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 05 06 07 08 09 10 11 12 13 14 15 16 RFC 2165

draft-ietf-srvloc-protocol-07.txt                         John Veizades
INTERNET-DRAFT                                                TGV, Inc.
                                                           Scott Kaplan
                                                           Erik Guttman
                                                       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

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 April 24, 1996                                         [Page 1]

INTERNET-DRAFT            Service Location Protocol          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................................................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..................................7
        5.4.1  Version...............................................7
        5.4.2  Functions.............................................7
        5.4.3  Length................................................7
        5.4.4  Error Codes...........................................8
        5.4.5  Transaction Identifier (XID)..........................8
        5.4.6  Flags.................................................8
        5.4.7  Time To Live..........................................8
        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.............................11
    5.8 Get Attributes Request......................................12
    5.9 Service Discovery Request...................................13
6.0 Directory Agents................................................14
    6.1 Introduction................................................14
    6.2 Directory Agent Discovery...................................15
    6.3 Service Registration........................................15
    6.4 Service Unregister..........................................17
    6.5 SCOPE Discovery and Use.....................................18
7.0 Server Location Connections.....................................19
8.0 Security Considerations.........................................20
9.0 Multicast vs. Broadcast.........................................20
    9.1 Non-interneted networks.....................................20
    9.2 Interneted site.............................................20
    9.3 Service Multicast 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          October-95

12.0 Interesting Constants..........................................28
13.0 Acknowledgments................................................29
14.0 References.....................................................29
15.0 Author's Addresses.............................................30
16.0 Document Expiration............................................30
Appendix A - Technical contents of ISO 639:1988.....................31

3.0 Notation Conventions

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

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

Service Agent (SA)       A process working on the behalf of one or more
                         services to advertise service attributes and

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

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 advertise service
                         information for a collection of service

Service                  The service is a process or system providing a
                         facility to the network.  The goal of service
                         location is to provide sufficient information
                         to the user, via the User Agent, to find the
                         service.  The service itself is out of band
                         of the service location protocol.

Directory Agent (DA)     A process which collects information from

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
                         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 which defines
                         the type of service.  Each type of service has
                         a unique Distinguished Attribute.  This is 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
                         four types: integer, string, boolean and
                         opaque.  The service information advertised
                         by a Service Agent may include more than one
                         value per class.

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

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

Agent's Internet         All the hosts accessible within the 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 radius are considered "outside
                         of the user's internet."

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 Internet.  The User Agent, an end
system, does not need any configuration to begin network interaction.
The User Agent builds on the information it retrieves in earlier
network requests to find the Service Agents advertising service
information, then finds the terms used to describe services that it
is interested in.  The 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.

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

If the User Agent does not have knowledge of a Directory Agent or if
there are no Directory Agents available on the User Agent's internet,
a second mode of discovery is used.  The User Agent multicasts a
request to the service multicast address, which the service it wishes
to locate will respond to.  All the Service Agents which are listening
to this multicast address will respond, provided they can satisfy the
User Agent's request.  Service Agents which have no information for the
User Agent DO NOT respond.  This will cause an 'implosion' of
responses.  The most important case of discovery is that of locating
a Directory Agent.

In the case where the User Agent wishes to obtain a complete answer,
an enumeration of ALL services which satisfy the query, there is a
retransmission/convergence algorithm.  The User Agent resends the
request, together with a list of previous responders.  Only those
Service Agents which are not on the list respond.  Once there are no
new responses to the request the accumulation of responses is deemed

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

A service is advertised by an application which registers the service
information with a Directory Agent.  This Directory Agent will resolve
requests from User Agents as described above.  This means that a
Directory Agent must first be discovered, using the multicast mechanism
described above.   If the service is to become unavailable, it must be
unregistered with the Directory Agent.  The Directory Agent responds
with an acknowledgment to either a registration or unregistration.

The Service Agent or Application must register with an available
Directory Agent.  The Service Agent must additionally listen for
multicast requests on the service specific multicast address.
Service Applications will fail in an internet where there are no
Directory Agents.  Service Applications are present in this protocol
to provide a lightweight service registration mechanism.

5.2 Service and Predicate Representation

Service information is represented in a text format.  The goal is that

Veizades, Kaplan, Guttman                                      [Page 5]

INTERNET-DRAFT            Service Location Protocol          October-95

the 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 datagram headers are in an
encoded form which is not human readable.

5.3 Additional Notes

5.3.1 Interpretation Service Location Replies

Replies should be considered to be valid at the time of delivery.  The
service may, however, fail or change between the time of the reply and
the moment an application seeks to make use of the service.  The end
system making use of service location must be prepared for the
possibility that the service information provided is either stale or
incomplete.  In the case where the service information provided does
not allow an end system to connect to a service as desired, the request
must be resubmitted.

5.3.2 Use of TCP and Multicast in Service Location

The service location protocol requires the implementation of a
connectionless and a 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 limitations detailed in section 9.0.

5.3.3 Linguistic Localization

All Service Registrations and Unregistrations are localized with codes
which declare in which language strings in the Service attributes are
written.  For each language the Service advertises, a separate
registration takes place.  The Service needs to be unregistered
only once, since the Service Instance information associated with it
will be unique (i.e. there can only be one service of a given type at a
given URL location, even if it is registered in multiple languages.)

All Service Requests include a language identifier.  The Directory
Agent or Service Agent will respond in the same language as the
request, if it has a registration in the same language as the request.
If the 'monolingual bit' is not set, and the request is in an
unsupported language, a reply can be sent in the default language
(which is English.)  This is only possible when there are no language
specific attributes in the 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 6]

INTERNET-DRAFT            Service Location Protocol          October-95

5.3.4 Standard Attribute Definitions

Service schemes registered with the IANA for use with the service
location protocol must have an accompanying document which describes
the following:

Scheme of the service
Mutlicast address
Attributes (Tag and values)
Attribute Descriptions and interpretations

Service schemes can be defined out of this standardization process
through the use of experimental multicast addresses.

5.4 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               |
|        Time to Live           |O|M|  flags    | char encoding |

5.4.1 Version

This protocol document defines version 1 of the service location

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

5.4.3 Length

The length is the number of bytes after the Service Location PDU

Veizades, Kaplan, Guttman                                      [Page 7]

INTERNET-DRAFT            Service Location Protocol          October-95

5.4.4 Error Codes

Errors are only valid in reply and service acknowledgment datagrams.
Replies that completed successfully should have a zero value for the
error code.

5.4.5 Transaction Identifier (XID)

The XID (transaction ID) field allows the requester to match replies
to individual requests.  A Service Reply will contain the same XID as
the Service Request.  A Service Acknowledge will contain the same XID
as the Service Register or Unregister.

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

5.4.6 Flags

The flags field is a bit field.  Bit 0 is the 'Overflow bit.'  See
Section 7.0 for a complete description for the use of this field.  Bit
1 is the 'Monolingual bit.'  Requests with this bit set indicate that
the end system will only accept responses in the language that is
indicated Service or Attribute Request.  Replies in other languages
should not be sent for this request.  All other bits must be set to

5.4.7 Time to Live

The TTL field is set to the number of minutes the reply can 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 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 and a Predicate in a specific
language.  The general form of a Service Request is shown below:


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
be sure that responses from other sources are not drowned out. The
request is multicast repeatedly (with a 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 = SrvRqst)          |
|number of previous responders  |  <Previous Responders URLs>   |
|                                                               |
\                    <Previous Responders URLs>                 \
|                                                               |
|                                                               |
\                   <Service Request Predicate>                 \
|                                                               |

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

INTERNET-DRAFT            Service Location Protocol          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 = SrvRply)         |
|   number of replies returned  |           <Reply 1>           |
|                        <Reply 1> (cont.)                      |
|                              .                                |
\                              .                                \
|                              .                                |
|                           <Reply N>                           |

                          Service Reply

5.6 Directory Agent Discovery Request

This request is generated by the User Agent or Service Agent or Service
Application in order to discover a Directory Agent.  The query is of
the form:


This query is to the Directory Agent multicast address. The scheme of
a Directory Agent is 'DIRECTORY AGENT' hence it is the scheme used in
the 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 any.  The where clause is empty in the query, so
all Directory Agents will match the request.  English is used as the
locale for this example.  Typically the language of 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

The replies will arrive from different sources.  They will be similar

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

If the goal is 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 Distinguished Attribute Request to find all the
types of services that are available on a network.
Like most service location PDUs, a client can issue more than one
request to insure that all replies have been received.  In each
subsequent request, a User Agent adds the list of Distinguished
Attributes (schemes) that it is aware of.

The format of the Distinguished Attribute Request is special in that it
specifies no 'Scheme' for the service type.  Instead a '*' is used to
denote a 'wild card.'  The request may be sent to any Directory Agent.
This will return all the service types that it knows about.  The
request may also be sent to the General Multicast Address, in order to
find out all service available on the User Agent's internet (which are
advertised by Directory Agents and Service Agents.)


* is the wildcard scheme.  There is no scope specified in this example,
as the scope is unrestricted.  The select clause is empty, as no
attribute 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 by Service Agents.  These
replies take the form:

    printer/     <- these multicast addresses are
    http/         examples only.  The actual official
    nntp/         numbers have not been assigned!

The scheme defines the type of service, the distinguished attribute.
The address to the right of it defines the multicast address which can
be used to send queries to Service Agents.  No other information is
returned in the replies, since the select-clause of the request was
NULL.  All schemes were returned since the where-clause was NULL.

If the User Agent is already aware of certain Distinguished Attributes,
as in the 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 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.

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 union of all attributes returned by all service
Agents.  The Attribute information will be used to form Service

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 = AttrRqst)         |
|number of previous responders  |  <Previous Responders URLs>   |
|                                                               |
\                    <Previous Responders URLs>                 \
|                                                               |
|           Reserved            |     <Language of Reply>       |
|                                                               |
\                         <Service Scheme>                      \
|                                                               |

                          Attribute Request

If sent to a Directory Agent, the 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 Request.  The
Language field determines the language in which the attribute tags and
string values should be returned in.  The Service Scheme is the service
to get attributes for.

Veizades, Kaplan, Guttman                                     [Page 12]

INTERNET-DRAFT            Service 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 = AttrRply)         |
|           Reserved            |      <Language of reply>      |
|                                                               |
\                        <Attribute List>                       \
|                                                               |

The attribute list has the same form as the attribute list at the end
of a reply.

For example, say I issue an Attribute Request for "printer".  I might
receive the following reply (the language field is set to 'en'):

    (PAGES PER MINUTE=1,3,12),
    (LOCATION=12'th floor,outside deb's cube)

5.9 Service Discovery Request

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

This query is sent directly to a Directory Agent.  Following the
example of the last section, say I wanted a printer that is on the
12th floor which prints 12 pages per minute.  I know there is a 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 responds with a
Service Reply with 0 in the number of responses and no reply values.

The User Agent then tries a less restrictive query to find a printer,
using the 12th floor as "where" criteria, but selecting the PAGES PER
MINUTE attribute, to find out how slow it will be:

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

Veizades, Kaplan, Guttman                                     [Page 13]

INTERNET-DRAFT            Service Location Protocol          October-95

In this case, we get one reply:

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

The URL for the printer here, igore.wco.ftp.com:515 is the location of
the printer.  You can spool to that port on that host and print.

In the absence of a Directory Agent, the request above could be
multicast.  In this case it would be sent to the printer Multicast
Address and not to the 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 assumes there are no such printers.

One final note:  The select field of the query is used to control how
much information is returned by the Directory Agent or Service Agent.
As described in full in Section 10.1.2, there are 3 different
selections possible.  A NULL selection will return no attribute
information, merely a 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 proxy for many Service Agents and Service
Applications.  It acquires information from them and acts as a single
point of contact to supply that information to User Agents.

The queries that a User Agent multicasts to Service Agents (in an
environment without a Directory Agent) are the same queries that the
User Agent unicasts to a Directory Agent.  A User Agent may cache
information about the presence of other Directory Agents to use as fall
back Directory Agents in case a selected Directory Agent fails.

In scaling service location systems to the size of a campus a central
repository is added to limit the amount of general queries in the
network infrastructure.  A site may also grow to such a size that it is
not feasible to maintain only one central repository of service
information. In this case another Directory Agent is needed. Multiple
Directory Agents are supported within the framework of this protocol.
Each Service Agent or application registers with each DA and hosts may
either use each DA in a round robin fashion or may pick which DA to use
in a nondeterministic fashion.

Directory Agents, in the future, may use mechanisms outside of this
protocol to scale to larger global Internets.

Veizades, Kaplan, Guttman                                     [Page 14]

INTERNET-DRAFT            Service Location Protocol          October-95

6.2 Directory Agent Discovery

When a Directory Agent first comes on-line it sends an unsolicited
Service 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 a random interval of between 0 and
10 seconds and then begin registration of each of the services they

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

    directory agent/srvloc-resolver.catch22.com/en/(SCOPE=ADMIN)/

This directory agent can be reached at the URL specified, and supports
the SCOPE called 'ADMIN'.

When a 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 above two events take
place.  When scopes are being used on a campus a Service Agent or
Application may choose a set of scopes to be advertised in and need
only register with Directory Agents that support the scopes in which
they wish to be registered.

Once a User Agent becomes aware of a Directory Agent it will unicast
its queries there.  In the event that more than one Directory Agents
are detected, it will select one to communicate with.  When scopes are
supported, the User Agent will direct its queries to different
Directory Agents depending on which scopes are appropriate domains for
the query to be answered in.

A Directory Agent's unsolicited Service Reply to the General Multicast
address should always be treated as a situation where the DA has become
available for the first time.  A Service Agent or Application should
register services with it even if it had done so previously.

6.3 Service Registration

After a Service Agent has found a Directory Agent, it begins to
register its advertised services one at a time.  A Service Agent must
wait for some random interval between 0 and 3 seconds between each
registration.  Registration is done using the Service Registration
packet specifying all attributes for a service.  A Directory Agent must
acknowledge each service registration request.

Veizades, Kaplan, Guttman                                     [Page 15]

INTERNET-DRAFT            Service Location Protocol          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 = SrvReg)         |
|                              .                                |
\               <Service Registration Information>              \
|                              .                                |

                       Service Registration

Service registration may use a connectionless protocol (e.g. UDP), or a
connection oriented protocol (e.g. TCP).  The registration operation
may contain more information than can be sent in one datagram.  In this
case the Service Agent or Application must use a connection oriented
protocol to register itself with the DA.  When a Service Agent or
Application registers the same attribute class more than once for a
service instance, the Directory Agent overwrites the all the values
associated with that attribute class.  Separate registrations must be
made for each language that the service is to be advertised 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 registration is as follows:

                                    (PAPER COLOR=WHITE),
                                    (PAPER SIZE=LETTER),
                                    (LANGUAGE=POSTSCRIPT, HPGCL),
                                    (LOCATION=12th Floor))/

The same registration could be done again, in German (note that
'printer' the scheme, is an IANA term, so it will remain in the
language it was originally registered in with IANA, i.e. in English):

                                    (STELLE=12te Etage) /

Registrations must contain an Attribute of SCOPE unless they are
unscoped and then they must be registered with all directory agents.
See example above.

The Directory Agent may return a server error in the acknowledgment,
if for instance, a registered service lacks an address.  This error is
carried in the Error Codes field of the service location packet header.

Veizades, Kaplan, Guttman                                     [Page 16]

INTERNET-DRAFT            Service Location Protocol          October-95

A non-error acknowledgment must have the error code set to zero.
Once a DA acknowledges a service registration it makes the 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 Applications should start the registration process
before the TTL they used for registration expires if they want to
continue to be advertised.

6.4 Service Unregister

When a service is no longer available for use, the Service Agent or
Application must unregister itself from Directory Agents that it has
been registered with.  A service uses the following PDU to unregister

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)       |
|                                                               |
\                <Service Unregister Information>               \
|                                                               |

                        Service Unregister

The Service Agent should retry this operation if there is no response
from the Directory Agent.  The Directory Agent acknowledges this
operation with a service acknowledgment.  Once the Service Agent
receives this acknowledgment, it can assume that the service is no
longer advertised by the Directory Agent.

The Service Unregister Information sent to the Directory Agent has
the following form:

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

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


If attributes are included in the unregistration, the attributes
will be unregistered, but not the entire service.  That is to say
that the class Attr1 and all its values will no longer be advertised

Veizades, Kaplan, Guttman                                     [Page 17]

INTERNET-DRAFT            Service Location Protocol          October-95

for the given service.  Notice that 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)/

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

More than one attribute can be unregistered, by inserting a list, i.e.

    nfs/,(MOUNT POINTS)/

6.5 SCOPE Discovery and Use

The scope mechanism in the service location protocol is an important
feature to enhance its scalability.  The primary use of scopes is to
provide the capability to organize a campus along administrative lines.
A set of services can be assigned to a given department of an
organization, to a certain building or geographical area or for a
certain purpose.  The users of the system can be presented with these
organizational elements as a top level selection, before services
within this domain are sought.

A campus that has grown beyond a size that can be reasonably serviced
by a few DAs can use the SCOPE mechanism.  DAs have the attribute class
"SCOPE".  The values for this attribute are a list of strings that
represent the administrative areas for which this Directory Agent is an
authority.  The semantics and language of the strings used 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
or Service Application chooses at least one scope in which to be
registered, and must 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 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 scope it would reply as:

    directory agent/,DEV,SALES)/

Normally all Directory Agents respond to 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 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 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 scope.
Membership is open to all, unless some external authorization mechanism
is added to limit access.

7.0 Service Location Connections

When a Service Location Request results in a reply from a Service or
Directory Agent that will overflow a datagram, the User Agent can open
a connection to the Agent and reissue the request over the connection.

The reply will be returned with the 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 route, assume that a maximum
packet size is 1460.

A User Agent that wishes to obtain the overflowed data must establish
a connection with the Directory Agent or Service Agent with the data.
The 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 registration over the 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 size of the replies.

Veizades, Kaplan, Guttman                                     [Page 19]

INTERNET-DRAFT            Service Location Protocol          October-95

8.0 Security Considerations

There are no provisions in this protocol to insure data integrity, data
authority or data confidentiality.  Mechanisms in the underlying
network layer protocol or at the service access point may be used to
provide these functions.

9.0 Multicast vs. Broadcast

The service location protocol was designed for use in networks where
multicast at the 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 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 network is designed so that a 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

9.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
is used so that the number of datagrams any one service receives is

When undirected queries are made concerning this type of service, the
query should be sent to the matching multicast address.  If the subnet
does not support multicast then the query should be broadcast to the
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 all protocol
elements introduced in the 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 Reply>                     AttrRqst & AttrRply
  10.1.8   <Service Scheme>                        AttrRqst

10.1.1 Previous Responders URL

The previous responder's URL is specified as

    <Previous Responder's URL> ::= URL, |
                                   URL,<Previous Responder's URL>

followed by a comma with no white space.  The URL is the address of the
Directory Agent or Service Agent which supplied the previous response.
The format for URLs in Service Location is defined in 12.2.



10.1.2 Service Request Predicate

The following grammar expresses the form of a Service Request

    <predicate>      ::= <scheme>/<scope>/<lang>/<select>/<where>
    <scheme>         ::= string representing type of service.
                         '/' is not allowed in this string.
    <scope>          ::= string representing the directory agent scope.
                         '/', ':' are not allowed in this string.  The
                         scope 'LOCAL' and 'REMOTE' are reserved.

    <lang>           ::= 2 letter code, as described in Appendix A.

    <select>         ::= <select-list>                     |
                         <select-all>                      |
    <select-list>    ::= <select-item>                     |
                         <select-item>, <select-list>
    <select-item>    ::= <attr-tag>

Veizades, Kaplan, Guttman                                     [Page 21]

INTERNET-DRAFT            Service Location Protocol          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>                       |
    <where-any>      ::= ()
    <where-list>     ::= (& <query-item> <query-list>)     |
                         (| <query-item> <query-list>)     |
    <query-list>     ::= <where-list>                      |
                         <query-item>                      |
                         <query-item> <query-list>
    <query-item>     ::= (<attr-tag> <comp-op> <attr-val>) |
    <comp-op>        ::=  !=  |  == |  <  |  <=  |  >  |  >=
    <attr-val>       ::= any string (see Section 10.3 for the ways
                         in which attr-vals are interpreted.)

                         Value strings may not contain '/', ','
                         '=', '<', '>'.  '(' and ')' can only be used
                         for the purpose of encoding a binary values.
                         Binary encodings (See Section 10.3) may
                         include the above reserved characters.

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

A predicate has a simple structure, which depends on the parentheses,
commas and slashes to delimit the elements.  Examples of proper usage
have been given throughout the document.  The terms used above are
described below:

       Placed in a Service Request, this is interpreted by a  Service
       Agent or Directory Agent to determine what information to

       This determines what information to return.  There are 4 types
       of select-clause:  NULL, ANY and LIST.
       NULL:    The reply returns no attribute information for the
                PARTICULAR services which satisfy the where-clause.
       ANY:     The reply returns all attribute information, as above.
       LIST:    The reply returns the attribute information for the
                attributes whose class names are listed, as above.
                Recall that an attribute has a class name and a set

Veizades, Kaplan, Guttman                                     [Page 22]

INTERNET-DRAFT            Service Location Protocol          October-95

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

       This determines which services the request matches.  An empty
       where-clause will match all services.  The request will be
       limited to services which have the Scheme which was defined
       prior to the predicate, so the where-clause
       is not the sole factor in picking out which services match the

       The where-list is a logical expression.  It can be a single
       expression, a disjunction or a conjunction.  A single expression
       must apply for the where-clause to match.  A disjunction matches
       if any expression in the disjunctive list matches.  A
       conjunction matches only if all elements in the conjunction

       Note that there is no logical negation operator:  This is
       because there is no notion of returning "everything except" what
       matches a given criteria.

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

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

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

       Examples of this would be:
       (QUEUE LENGTH <= 234)

10.1.3 Reply

Service Replies have the following form:

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

    SCHEME is a string.  Schemes are standardized by registering them
           with the IANA.
    URL is the service access point of the service.  It is the network
           address or domain name where the service 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 a two letter
           code listed in Appendix A.
    The <attr-list> is returned if the 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 attr-val, as the comma is used as the
multiple value delimiter.  Examples of an attr-list are:


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

10.1.4 Service Registration Information

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

10.1.5 Service Unregister Information

The Service Unregister Information takes the form:

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

    SCHEME, URL, and LANGUAGE are described above.

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

    Examples of tags:

If there are no tags included in the unregistration, the entire
service, in each language which it was registered, is removed from the
storage of a 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

Veizades, Kaplan, Guttman                                     [Page 24]

INTERNET-DRAFT            Service Location Protocol          October-95

A separate Service Unregister must be done for each language in which
the service was registered, providing a list of tags in the language
in question.  Example (unregistering 2 attributes in English, German
and French):

    service/, (SIZE)/
    service/, (GROESSE)/
    service/, (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 language in which the attributes of
the service 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 can have the form:


PROTOCOL is 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) 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

10.3 Attribute Value encoding rules

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

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

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 the case
   irrespective of the language (i.e. in French or Tegulu, Boolean TRUE
   is 'TRUE', as well as in English.)  Boolean attributes can take only
   one value.

 - Integer values are expressed as a sequence of numbers.  The range of
   allowable values, for this 32 bit quantity, is -2147483648 to

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

     <opaque-val>    ::=  (<len>:<radix-64-data>)
     <len>           ::=  integer length of the original binary data
     <radix-64-data> ::=  An encoding of the binary data into a new
                          format, see below for the algorithm:

   Radix-64 encodes every 3 bytes of binary data into 4 bytes of ASCII
   data which is in the range of characters which are fully printable.
   The range of characters is from '0' through 'o'.  This is the same
   technique used by the uuencode program.

   To encode binary to radix-64:

   Take the binary data input in sets of 3 bytes, call them B1, B2 and
   B3.  If the buffer has a number of bytes not divisible by three,
   pad it with NULL bytes to be divisible by three.  Initialize the
   target array of 4 bytes b1, b2, b3 and b4 to 0x30.  Add to this:

        b1 += (B1 & 0xFC) >> 2;
        b2 += (B1 & 0x03) << 4 + (B2 & 0xF0) >> 4;
        b3 += (B2 & 0x0F) << 2 + (B3 & 0xC0) >> 6;
        b4 += (B3 & 0x3F);

   To decode radix-64 to binary:

   Subtract 48 (that is 0x30) from each of b1, b2, b3 and b4.
   Initialize an array in the size of the number of bytes given in the
   length field of the <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);


   (5:00000000) encodes 5 NULLs.
   (6:00000000) encodes 6 NULLs.  They are 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 26]

INTERNET-DRAFT            Service Location Protocol          October-95

 - Keywords may be expressed as an attribute that has no values:

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

11.0 Implementation Requirements

A User Agent MAY:
  - Listen on the Service Location General Multicast address for
    unsolicited Directory Agent Replies.  This will increase the set of
    Directory Agents available to it for making replies. See Section
  - Provide a way for the application to configure the default DA, so
    that this one can be used without needing to find it each
  - Be able to multicast requests to a multicast address.  If the
    multicast address is not known, the UA must be able to use a
    Distinguished Attributes query to obtain the multicast address
    for the scheme of the request.
  - Be able to handle an implosion of replies after a multicast
    request.  The implementation may be configurable so it will either
    return the first reply, all replies until a timeout or keep trying
    till the results converge.

A User Agent MUST:
  - Be able to unicast requests and receive replies reliably from a DA.

A Service Application MUST be able to:
  - Listen to the Service Location General Multicast address for
    unsolicited Directory Agent Replies.  If one is detected, and the
    DA has the right scope, all services which are currently being
    advertised must be registered with the DA.  See Section 6.2.
  - Unicast registrations and unregistrations reliably to 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 detected, and the
    DA has the right scope, all services which are currently being
    advertised must be registered with the 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 URL of the SA is
    in the Previous Responders URL list, the SA should not respond.
    Otherwise, a response to the multicast query should be unicast to
    the UA which sent the request.
  - Listen to the Service Location General Multicast address for
    queries of any type.  If the query can be replied to by the
    Service Agent, the Service Agent must do so.  It must check first
    to make sure it is not on the list of '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 27]

INTERNET-DRAFT            Service Location Protocol          October-95

    Service Location General Multicast address on startup.   See
    Section 6.2.
  - Listen on the 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 way in which SCOPE information can be used to configure
    the Directory Agent.
  - Age out the services which have been registered so that when the
    service registration's TTL expires, the service advertisement is

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

12.0 Interesting Constants

  IP Port number for unicast requests to Directory Agents:

    UDP and TCP Port Number: 427

  Multicast Addresses

    General Multicast Address:
    Directory Agent Multicast Address:

    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

Veizades, Kaplan, Guttman                                     [Page 28]

INTERNET-DRAFT            Service Location Protocol          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.  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

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

[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 29]

INTERNET-DRAFT            Service Location Protocol          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

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
   346 Fair Oaks St.
   San Francisco, CA 94110

   Phone: +1 415 285 4526

   Email: scott@catch22.com

   Erik Guttman
   1920 Sacramento St., #8
   San Francisco, CA 94109

   Phone: +1 415 921 6570

   Email: guttman@cs.stanford.edu

16.0 Document Expiration

This document expires April 24, 1996

Veizades, Kaplan, Guttman                                     [Page 30]

INTERNET-DRAFT            Service Location Protocol          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 31]

INTERNET-DRAFT            Service Location Protocol          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 32]

Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/