[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-svrloc-protocol-11.txt                         John Veizades
INTERNET-DRAFT                                                TGV, Inc.
                                                           Scott Kaplan
                                                           Erik Guttman
                                                        Charles Perkins
                                                           IBM Research
                                                      February 21, 1996

                       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

   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.isi.edu 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 August 21, 1996                                        [Page 1]

INTERNET-DRAFT            Service Location Protocol         February-96

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
    5.1 Protocol Transactions........................................5
    5.2 Service and Predicate Representation.........................7
    5.3 Additional Notes.............................................7
        5.3.1  Interpretation of Service Location Replies............7
        5.3.2  Use of TCP and Multicast in Service Location..........7
        5.3.3  Multilingual Support..................................7
        5.3.4  Standard Attribute Definitions........................8
        5.3.5  Naming Authority......................................8
        5.3.6  No Synchronous Assumption.............................8
    5.4 Service Location PDU header..................................8
        5.4.1  Version...............................................9
        5.4.2  Functions.............................................9
        5.4.3  Length................................................9
        5.4.4  Error Codes...........................................9
        5.4.5  Transaction Identifier (XID)..........................9
        5.4.6  Flags................................................10
        5.4.7  Time To Live.........................................10
        5.4.8  Character Encoding...................................10
        5.4.9  Language Code........................................10
    5.5 Service Request and Reply...................................10
    5.6 Directory Agent Discovery Request...........................13
    5.7 Scheme Request..............................................14
    5.8 Attribute Request and Attribute Reply.......................15
    5.9 Service Discovery Request...................................17
6.0 Directory Agents................................................18
    6.1 Introduction................................................18
    6.2 Directory Agent Discovery...................................18
    6.3 Service Registration........................................20
    6.4 Service Unregister..........................................22
    6.5 SCOPE Discovery and Use.....................................23
    6.6 Service Location Scaling and Operating Modes................24
7.0 Service Location Connections....................................25
8.0 Security Considerations.........................................26
9.0 Multicast vs. Broadcast.........................................26
    9.1 Single Subnet...............................................26
    9.2 Multiple Subnets............................................26
    9.3 Service Multicast Address...................................26
10.0 Service Location in the Internet...............................27
11.0 Protocol Formats...............................................27
    11.1 Fields Used in Service Location Packets....................27
         11.1.1 Previous Responders' Address Specification..........27
         11.1.2 Service Request Predicate...........................28
         11.1.3 Reply...............................................31
         11.1.4 Service Registration Information....................31
         11.1.5 Service Unregister Information......................31
         11.1.6 Attribute List......................................31
         11.1.7 Service Scheme......................................32

Veizades, Kaplan, Guttman, Perkins                             [Page 2]

INTERNET-DRAFT            Service Location Protocol         February-96

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

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

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

4.0 Terminology

   User Agent (UA)       A process working on the user's behalf to
                         acquire service attributes and configuration.
                         The User Agent retrieves service information
                         from the Service Agents or Directory 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 Information   A collection of attributes and configuration
                         information associated with a single service.
                         The Service Agents advertise service
                         information for a collection of service

Veizades, Kaplan, Guttman, Perkins                             [Page 3]

INTERNET-DRAFT            Service Location Protocol         February-96

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

   Directory Agent (DA)  A process which collects information from
                         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.

   Scheme                Each type of service has a unique scheme. The
                         Scheme defines a template including expected
                         attributes, values and protocol behavior.
                         Well known Schemes are registered with the
                         IANA and templates are available as RFCs.
                         Private Schemes may also be supported.

   Naming Authority      The agency or group which catalogues
                         given Schemes and Attributes.  The default
                         Naming Authority is IANA.  Otherwise the
                         scheme of the service has the Naming Authority
                         appended to the end, following a '.'

   Attribute             A {class, value} pair describing a
                         characteristic of a service.  Note that a
                         class is a string.  Values are optional.
                         An attribute without a value is a keyword.
                         A value is a string which may be interpreted
                         as a string, or as a boolean, integer or
                         opaque value if the value string takes
                         specific forms (see section 11.3.)  The
                         service information advertised by a Service
                         Agent may include more than one value per

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

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

   Campus                A campus is a collection of networks, hosts
                         and related network infrastructure that is
                         grouped together for geographical or political

Veizades, Kaplan, Guttman, Perkins                             [Page 4]

INTERNET-DRAFT            Service Location Protocol         February-96

   Agent's Internet      All the hosts accessible within the Agent's
                         multicast radius which defaults to the Agent's
                         site (see section 13.0.)  If the network does
                         not support multicast, the agent's internet is
                         defined by its broadcast radius.  The
                         discovery method 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."

   Address Specification This is the network layer protocol dependent
                         mechanism for specifing an User Agent.  For
                         Internet systems this is a URL (Universal
                         Resource Locator see RFC 1738).

5.0 Protocol Overview

5.1 Protocol Transactions

   The diagram below illustrates the relationships described below:

      +---------------+   we want this info:     +-----------+
      |  Application  | - - - - - - - - - - - -> |  Service  |
      +---------------+                          +-----------+
           /|\                                      |     |
            |                         +-------------+     |
            |                         |                   |
           \|/                       \|/                 \|/
      +---------------+          +-----------+      +-------------+
      |   User Agent  |<-------->|  Service  |      |   Service   |
      +---------------+          |   Agent   |      | Application |
            |                    +-----------+      +-------------+
            |                         |                   |
            |                        \|/                  |
            |                   +-------------+           |
            +------------------>|  Directory  |<----------+
                                |    Agent    |
                                +-------------+      ___________
                                     /|\            / Many other\
                                      +------------>|   SA's    |

   The following describes the operations a User Agent employs to find
   services on the attached Internet.  The User Agent does not need any
   configuration to begin network interaction.  The User Agent may
   build on the information received in earlier network requests to

   find the Service Agents advertising service information, and
   subsequently the terms used to describe services that it is
   interested in.  The User Agent can use this information to construct
   predicates which describe the services that match the user's needs.

Veizades, Kaplan, Guttman, Perkins                             [Page 5]

INTERNET-DRAFT            Service Location Protocol         February-96

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

   If the User Agent does not have knowledge of a Directory Agent or
   if there are no Directory Agents available on the 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.

   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
   complete.  Depending on the length of the request, around 60
   previous responders may be listed in a single datagram (without
   exceding the size of a single datagram and requiring fragmentation.)
   If there are more responders than this, the scaling mechanisms
   described in section 6.6 should be used.

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

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

Veizades, Kaplan, Guttman, Perkins                             [Page 6]

INTERNET-DRAFT            Service Location Protocol         February-96

5.2 Service and Predicate Representation

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

5.3 Additional Notes

5.3.1 Interpretation of 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 andthe moment an application seeks to make use of the service.
   The application 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 a User Agent to connect to a service as
   desired, the request may be resubmitted.

5.3.2 Use of TCP and Multicast in Service Location

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

   The 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 Multilingual Support

   All Service Registrations declare the language in which the strings
   in the service attributes are written by specifying the appropriate
   code in the packet header.  For each language the Service advertises
   a separate registration takes place.  The Service needs to be
   unregistered only once since the information associated with it will
   be unique.There can only be one service of a given type at a given
   URL reference, even if it is registered in multiple languages.

   All Service Requests specify a requested language in the packet
   header.  The Directory Agent or Service Agent will respond in the
   same language as the request, if it has a registration in the same
   language as the request.  If this language is not supported, a reply
   can be sent in the default language (which is English.)  If the
   'monolingual bit' flag in the header is set and the requested
   language is not supported, a SrvRply is not returned:  Instead
   return a SrvAck with the error field set to LANGUAGE_NOT_SUPPORTED.

Veizades, Kaplan, Guttman, Perkins                             [Page 7]

INTERNET-DRAFT            Service Location Protocol         February-96

5.3.4 Standard Attribute Definitions

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

      Scheme of the service
      Multicast address, if used
      Attributes (Tag and values)
      Attribute Descriptions and interpretations

   Service schemes defined outside of the IANA standardization process
   will use their own Naming Authority string and, possibly, a
   multicast address from the unassigned range.  If a scheme does not
   define its own multicast address, the Service Location General
   Multicast address is used, as the default.

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

   Scheme names which begin with 'x-' are guaranteed not to conflict
   with any officially registered scheme names.  It is suggested that
   this prefix be used for experimental or private scheme names.

5.3.5 Naming Authority

   The Naming Authority of a service defines the semantic meaning of
   the scheme and attributes registered with and provided by Service
   Location.  The Naming Authority itself is a string which uniquely
   identifies an  organization.  If no string is provided IANA is the

   Naming Authorities may define Service schemes which are
   experimental, proprietary or for private use.  The procedure to use
   is to create a 'unique' Naming Authority string and then specify the
   Standard Attribute Definitions as described above.  This Naming
   Authority will accompany registration and queries, as described

5.3.6 No Synchronous Assumption

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

5.4 Service Location PDU header

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

Veizades, Kaplan, Guttman, Perkins                             [Page 8]

INTERNET-DRAFT            Service Location Protocol         February-96

   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   |O|M|  flags    |          char encoding        |
   |        Time to Live           |              XID              |
   |       Language Code           |  Reserved (Language Dialect)  |

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

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

Veizades, Kaplan, Guttman, Perkins                             [Page 9]

INTERNET-DRAFT            Service Location Protocol         February-96

   makes.  The XIDs will eventually wrap back to zero and continue
   incrementing from there.

   If a Service Agent or Application detects a change in the XID in an
   unsolicited advertisement of a Directory Agent, it can assume that
   the Directory Agent has rebooted and has reset its state.  The
   Service must reregister at this time.

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
   the User Agent will only accept responses in the language that is
   indicated by the Service or Attribute Request.  Replies in other
   languages should not 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 number of minutes the reply can be
   cached by any intermediary service.  A value of 0 means the
   information must not be cached.  User Agents must not cache
   Service information.  Requests by a User Agent must be issued
   directly onto the network.

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.  Values for character encoding can be found in the Internet
   Assigned Numbers Authority's (IANA) database
   http://www.isi.edu/in-notes/iana/assignments/character-sets and have
   the values refered by the MIBEnum value.

5.4.9 Language Code

   The language code (see Appendix A) is encoded in this field.  ALL
   strings within the packet which follows are to be interpreted in
   this language.

   Some strings, such as scheme names, have standard definitions.
   These strings should be considered as tokens and not as words in a
   language to be translated.  This will be noted where appropriate
   throughout this document.

   The language dialect field is reserved for future use.

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

Veizades, Kaplan, Guttman, Perkins                            [Page 10]

INTERNET-DRAFT            Service Location Protocol         February-96

   are four ways the Service Query may be used:  a Directory Agent
   Discovery Request, a Scheme Request, a Services Discovery Request
   and a Service Attributes Request.  These are described in the
   sections which follow.

   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 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 NAMING AUTHORITY determines the semantic interpretation of the
   SCHEME and the attributes used in the SELECT and WHERE CLAUSE. The
   SCOPE is used for range of the query (SCOPEs are determined
   administratively, not by network topology as will be described
   later.)  The SELECT CLAUSE lists which attributes to return with the
   reply.  The WHERE CLAUSE contains the attributes which determine the
   instances of the service (identified by the SCHEME) which match the

   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.

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

      (1).  The result must have the same scheme as in the request.
      (2).  It must have the same Naming Authority.
      (3).  It must have the same Scope.
      (4).  The conditions specified in the WHERE CLAUSE must match
            the attributes and keywords registered for the service.

Veizades, Kaplan, Guttman, Perkins                            [Page 11]

INTERNET-DRAFT            Service Location Protocol         February-96

   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 Addr Spec>|
   |                                                               |
   \                  <Previous Responders Addr Spec>              \
   |                                                               |
   |                                                               |
   \                   <Service Request Predicate>                 \
   |                                                               |

                             Service Request

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

   The general form of an individual reply is as follows:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |    Length of URL string       |         <URL String>          |
   |                                                               |
   \                       <URL String>, Continued.                \
   |                                                               |
   |  Length of Attributes String  |      <Attributes String>      |
   |                                                               |
   \                   <Attributes String>, Continued.             \
   |                                                               |

   The URL string conforms to RFC 1738.  If the service scheme does not
   have a standardized representation, the minimal requirement is:


   The reply will always contain the Scheme and the ADDRESS

   The Keywords and Attributes String may not be included, if there
   were no attributes returned as the result of the query.  Attributes
   are included in the reply depending on the "select clause" of the
   query.   A NULL "SELECT CLAUSE" will not include any attribute

Veizades, Kaplan, Guttman, Perkins                            [Page 12]

INTERNET-DRAFT            Service Location Protocol         February-96

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

   If attributes are returned the string takes the form (with
   arbitrarily many attributes and values):

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

   TTLs are not returned in Service Replies.

   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

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

   This request is generated by the User Agent or Service Agent or
   Service Application in order to discover a Directory Agent.  This is
   a normal Service Request.  The Service Request predicate used for
   Directory Agent Discovery takes 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.  No Naming Authority is included, so
   'IANA' is assumed.  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.

Veizades, Kaplan, Guttman, Perkins                            [Page 13]

INTERNET-DRAFT            Service Location Protocol         February-96

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

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

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

   If the goal is merely to discover any Directory Agent, the first
   reply will do.  If the goal, however, is to discover all reachable
   DAs, the request must be retransmitted after an interval (the
   recommended time is 3 seconds.)  This retransmitted request will
   include a list of DAs which have already responded.  This list
   takes the same form as the list of DAs above:  a series of


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

5.7 Scheme Request

   The User Agent may use the Scheme Request to find all the types of
   services that are available on a network.

   The format of the Scheme 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 schemes that it knows about.

   The request may also be sent to the General Multicast Address, in
   to find out all services available on the User Agent's internet
   (which are advertised by Directory Agents and Service Agents.)  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 schemes that it is aware of.  When no new replies arrive
   from a request, the User Agent can presume that it has acquired a
   complete set of available service types.

      *://SA Multicast Address//

   * is the wildcard scheme.  The Naming Authority is not included so
   'IANA' is assumed.  There is no scope specified in this example, as
   the scope is GLOBAL (ie. all Service Agents will respond.)  The
   SELECT CLAUSE requests that the SA Multicast Address be returned.
   This will allow multicast queries in the future.  Finally, the
   WHERE CLAUSE is empty so the request will match all services.

   Replies are sent by Directory Agents (and Service Agents, in the
   case where the request is multicast.)  These replies take the form:

Veizades, Kaplan, Guttman, Perkins                            [Page 14]

INTERNET-DRAFT            Service Location Protocol         February-96

       URL returned:       printer://
       Attributes returned: (SA Multicast Address=
       URL returned:       http://
       Attributes returned: (SA Multicast Address=
       URL returned:       nfs-server://
       Attributes returned: (SA Multicast Address=

   NOTE: These multicast addresses are examples only, the official
   numbers have not yet been assigned at this time.

   The scheme defines the type of service.  The SA Multicast Address
   attribute defines the multicast address which can be used to send
   queries to Service Agents which advertise the scheme.  Only the
   SA Multicast address is returned, since only that was selected.
   All schemes were returned since the where-clause was NULL.

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

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

   Only Directory Agents or Service Agents which have services other
   than these four types will respond to the request.  The Naming
   Authority is implicitly 'IANA' as none was specified, so only
   services registered under this Naming Authority will have their
   information returned.

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

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

5.8 Attribute Request and Attribute Reply

   Once a User Agent selects a single scheme, it may issue a "get
   attributes request" to find all the attributes associated with that
   scheme.  Since different instatiations of a given service can, and
   very likely will, have different values for the attributes defined
   by the scheme, the User Agent must form a union of all attributes
   returned by all service Agents.  The Attribute information will be
   used to form Service Queries.

Veizades, Kaplan, Guttman, Perkins                            [Page 15]

INTERNET-DRAFT            Service Location Protocol         February-96

   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 Addr Spec>|
   |                                                               |
   \         <Previous Responders Addr Spec>, continued            \
   |                                                               |
   |                                                               |
   \                         <Service Scheme>                      \
   |                                                               |

                             Attribute Request

   If sent to a Directory Agent, the number of previous responders is
   zero and there are no Previous Responder Address Specification.
   These fields are only used for repeated multicasting, exactly as
   for the Service Request.

   The replies take the form:

   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)         |
   |                                                               |
   \                        <Attribute List>                       \
   |                                                               |

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

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

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

Veizades, Kaplan, Guttman, Perkins                            [Page 16]

INTERNET-DRAFT            Service Location Protocol         February-96

5.9 Service Discovery Request

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

   This query is sent directly to a Directory Agent.  Following the
   example of the last section, suppose a printer is needed on the 12th
   floor which has UNRESTRICTED_ACCESS and prints 12 pages per minute.
   The response shown above from the Get Attribute Request indicates
   that there is a printer on the 12th floor and that there is one that
   prints 12 pages per minute, and one that is UNRESTRICTED.  To check
   whether they are one and the same printer, issue the following

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

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

   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 and
   whether it has UNRESTRICTED_ACCESS:

                (LOCATION==12th floor)/

   In this case, there is now only one reply:

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

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

   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, 3 seconds apart).
   If no response comes, the User Agent gives up and assumes there are
   no such printers.

Veizades, Kaplan, Guttman, Perkins                            [Page 17]

INTERNET-DRAFT            Service Location Protocol         February-96

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

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

   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 11.1.2, there are 3 ]
   different selections possible.  A NULL selection will return no
   attribute information, merely a scheme, the Address Specification.
   A LIST selection specifies which attributes should be returned.
   Finally, a WILD selection can be sent, which will return all
   attributes/values.  This WILD selection 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 on behalf of 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 alternate Directory Agents to use
   in case a selected Directory Agent fails.

   When 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 more Directory Agents are needed.
   Multiple Directory Agents are supported within the framework of this

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

   Directory Agents, in the future, may use mechanisms outside of this
   protocol to coordinate the maintenance of a distributed database of
   service location information, and thus scale to enterprise networks
   or larger administrative domains.

6.2 Directory Agent Discovery

   A User or Service Agent or Service Application may be statically
   configured to use a particular DA.  This is discouraged unless the
   application resides on a network where any form of multicast or

Veizades, Kaplan, Guttman, Perkins                            [Page 18]

INTERNET-DRAFT            Service Location Protocol         February-96

   broadcast is impossible.

   Alternatively, a host which uses DHCP may use it to obtain a
   Directory Agent's address.  A DHCP option will be assigned for
   this purpose.  It has not yet been, at the time this document was

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

   Lastly, the agent may be informed passively as follows:

   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.  The class for this attribute is 'SCOPE'.

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

   When a Directory Agent first comes up it begins with 0 as its XID,
   and increments this by one each time it sends an unsolicited reply.
   When the counter wraps, it should go from 0xFFFF to 0x0100, not 0.
   If the Directory Agent has stored all of the service information
   in a nonvolitile store, it should initially set the XID to 256, as
   it is not coming up 'stateless.'

   All Service Agents and Service Applications which receive the
   unsolicited reply should examine its XID.  If the Directory Agent
   has never before been heard from or if the XID is less than it was
   previously and less than 256, the Service Agent or Service
   Application should register all service information with the
   Directory Agent, after waiting a random interval of between 0 and
   3 seconds.

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

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

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

   When a Service Agent or Application, or User Agent first comes
   on-line it may 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.  Services may be registered with DAs

Veizades, Kaplan, Guttman, Perkins                            [Page 19]

INTERNET-DRAFT            Service Location Protocol         February-96

   which have no scope.

   Note that while it is very highly recommended that all services are
   registered with all unscoped DAs and with all DAs which have a
   certain (set of) SCOPE values, it is not strictly required.  If a
   service isn't registered this way, the availability of the service
   advertisement will be limited and possibly inconsistent between DAs.
   This situation may be acceptable if UAs are preconfigured
   (statically or by DHCP) to only use one particular DA in all
   situations.  This approach leaves open the chance of failure if the
   preconfigured DA is not available.

   Once a User Agent becomes aware of a Directory Agent it will unicast
   its queries there.  In the event that more than one Directory Agent
   is 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.

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

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.

   The format of a Service Registration is:

   0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   |           Service location header (function = SrvReg)         |
   |     Length of URL String      |          <URL String>         |
   |                                                               |
   \                          <URL String>                         \
   |                                                               |
   |  Length of Attr List String   |       <Attribute String>      |
   |                                                               |
   \                 <Attribute List>, Continued.                  \
   |                                                               |

                          Service Registration

Veizades, Kaplan, Guttman, Perkins                            [Page 20]

INTERNET-DRAFT            Service Location Protocol         February-96

   Service registration may use a connectionless protocol (e.g. UDP),
   or a connection oriented protocol (e.g. TCP).  The registration
   operation may contain more information than can be sent 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:

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

   An example of a service registration is as follows:

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

   The same registration could be done again, in German (note that
   'printer' the scheme and SCOPE are IANA terms and will remain in the
   language they were originally registered with IANA, i.e. English):

      URL:        printer://igore.wco.ftp.com:515
      Attributes: (SCOPE=ENTWICKLUNG),
                  (STANDORT=11 Etage),

   Registrations must contain an Attribute of SCOPE unless they are
   unscoped and then they must be registered with all directory agents.
   In the example above, the SCOPE is set to DEVELOPMENT (in English)
   and ENTWICKLUNG (in German.)  Recall that all strings in a packet
   must be in one language, which is specified in the header.

   The Directory Agent may return a server error in the acknowledgment.
   This error is carried in the Error Codes field of the service
   location packet header.  A Directory Agent may decline to register a
   service if it is specified with an unsupported SCOPE.  In this case
   a SCOPE_NOT_SUPPORTED error is returned in the SrvAck.

Veizades, Kaplan, Guttman, Perkins                            [Page 21]

INTERNET-DRAFT            Service Location Protocol         February-96

   An unscoped service registration will match all requests.  A request
   which specifies a certain scope will therefore return services which
   have that scope and services which are unscoped.  It is strongly
   suggested that one should use scopes in all registrations or none.
   See Section 6.5 and Sections 6.6 for details.

   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

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

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 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 location header (function = SrvUnreg)       |
   |                                                               |
   \              <URL String of Service to Unregister>            \
   |                                                               |

                           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:


Veizades, Kaplan, Guttman, Perkins                            [Page 22]

INTERNET-DRAFT            Service Location Protocol         February-96

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


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.  The values of SCOPE should be configurable, so the system
   administrator can set its value. The SCOPE "LOCAL" is reserved and
   must not be used, use of this reserved value may be defined in a
   future protocol document.

   Services with the attribute SCOPE should only be registered with
   DAs which support the same scope or DAs which have no SCOPE.

   Directory Agents advertise the list of all scopes that are
   available.  A Service Agent or Service Application may then choose
   at least one scope in which to be registered, and should register
   with all Directory Agents in that scope, as well as all DAs which
   have no scope.  Failure to be comprehensive in registration
   according to this rule will mean that the service advertisement may
   not be discoverable by all User Agents.

   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 should always select that SCOPE
   information be returned.  Note that the directory-agent scheme is
   registered with the IANA naming authority (which is automatically
   selected by leaving the Naming Authority field empty.)

   The query:


   Could receive the following reply:

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

Veizades, Kaplan, Guttman, Perkins                            [Page 23]

INTERNET-DRAFT            Service Location Protocol         February-96

   The same Directory Agent if it had no SCOPE value would reply:

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

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

      Returned URL:        directory-agent://
      Returned Attributes: (SCOPE=ADMIN,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:


   Here the SCOPE field of the request is left blank, but the WHERE
   clause of the request is filled in with a list of the scopes which
   can be used to satisfy the request.  Normally a single SCOPE would
   be filled in for a query, in the SCOPE field, but in the special
   case of a DA query this is not done.

   A DA which has no scope will reply to any Directory Agent Discovery

   Being a member of a scope means that an agent may use a specific set
   of Directory Agents that support its 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.

6.6 Service Location Scaling and Operating Modes

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

   In a larger but still administratively simple network, a single DA
   may suffice.  In this network, the DA will not have any SCOPE.  DAs
   that are discovered will return no list of SCOPES.  Service Agents
   and Service Applications should register with this DA even if they
   are configured to specifically register with DAs which have a
   specific scope or set of scopes.  User Agents will query DAs without
   scopes, even if they are configured to use DAs with a certain scope.
   This is because when a DA with no SCOPE is discovered, it will have
   all the available service information and no scoped DAs will exist.

Veizades, Kaplan, Guttman, Perkins                            [Page 24]

INTERNET-DRAFT            Service Location Protocol         February-96

   In a large campus or organization several DAs will be used in order
   to divide the load of maintaining service information and to
   orgainize which services should be used by which community.  In this
   case ALL DAs SHOULD HAVE A SCOPE.  All Service Registrations that
   have a scope should be registered with all DAs of that scope which
   have been or are subsequently discovered.  Unscoped services should
   be registered with all DAs as they are implicitely GLOBAL in scope.
   User Agents make requests of DAs which whose SCOPE they are
   configured to use.

   In each case where 'should' is used above, one should keep in mind
   that if the rule is not followed the availability of the service
   information may be limited or inconsistent across the service
   location system.

   There are thus 3 distinct operating modes.  The first requires no
   administrative intervention.  The second requires only that a DA be
   run.  The last requires that all DAs be configured to have SCOPE and
   that a coherent strategy of assigning SCOPES to services be
   followed.  Users must be instructed which SCOPES are appropriate for
   them to use.  This administrative cost will allow users and
   applications to dynamically discover services without assistance.

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

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

   When a request results in overflowed data that cannot be correctly
   parsed (say, because of duplicate or dropped IP packets), a User
   Agent that wishes to reliably obtain the overflowed data 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

Veizades, Kaplan, Guttman, Perkins                            [Page 25]

INTERNET-DRAFT            Service Location Protocol         February-96

   A connection initiated by an Agent may be used for a single
   transaction.  It may also be used for multiple transactions.  Since
   there are length fields in the packet headers, the Agents may send
   multiple requestsalong a connection and read the return stream for
   acknowledgments and replies.  The Agent is responsible for closing
   the TCP connection.  The DA should wait at least 30 seconds before
   closing an idle connection.

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.  An Agent may choose to
   ignore a transaction based on security information supplied by
   other (underlying) services.  As in the absense of Service Location,
   end-to-end authentication should be used between clients and

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 Agents using DHCP or staticly configured, but Agents
   will not be able to discover DAs on non-bridged subnets.

   As dynamic discovery is not feasible in a broadcast environment and
   manual configuration is difficult, multiple DAs in a broadcast
   environment may be difficult to deploy.

9.3 Service Multicast Address

   Each service MAY have a unique multicast address to which it belongs
   to.  This multicast address may be obtained from IANA.  This
   mechanism is used so that the number of datagrams any one service
   receives is minimized.  The Service Location General Multicast
   Address may be used to query for any service, though one should use

Veizades, Kaplan, Guttman, Perkins                            [Page 26]

INTERNET-DRAFT            Service Location Protocol         February-96

   the service-specific multicast address if it exists.

   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.  If the underlying hardware will not
   support the number of need multicast addresses all services can use
   the general service location multicast address.

10.0 Service Location in the Internet

   A subsequent protocol document will describe mechanism for
   supporting a service discovery protocol in a global Internet.

11.0 Protocol Formats

11.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
               -----------------------------------     -------------
      11.1.1   <Previous Responders' Addr Spec>        SrvRqst
      11.1.2   <Service Request Predicate>             SrvRqst
      11.1.3   <Reply>                                 SrvRply
      11.1.4   <Service Registration Information>      SrvReg
      11.1.5   <Service Unregister Information>        SrvUnReg
      11.1.6   <Attribute List>                        AttrRply
      11.1.7   <Service Scheme>                        AttrRqst

11.1.1 Previous Responders' Address Specification

   The previous responders' Address Specification is specified as

      <Previous Responders' Address Specification>
         ::= <Address Specification>, |
             <Address Specification>,
                <Previous Responders' Address Specification>

   ie. a list separated and terminated by commas with no intervening
   white space.  The Address Specification is the address of the
   Directory Agent or Service Agent which supplied the previous
   response.  The format for Address Specifications in Service Location
   is defined in 11.2.



Veizades, Kaplan, Guttman, Perkins                            [Page 27]

INTERNET-DRAFT            Service Location Protocol         February-96

11.1.2 Service Request Predicate

   The following grammar expresses the form of a Service Request

    <predicate>   ::= <scheme>[.<name auth>]:/<scope>/<select>/<where>/
    <scheme>      ::= string representing type of service.  Only
                      'a' to 'z', '+' and '-' are allowed.
    <name auth>   ::= string representing the Naming Authority.
                      Only characters from 'a' to 'z', '+' and '-'
                      are allowed. If this field is omitted 'IANA'
                      is assumed.
    <scope>       ::= string representing the directory agent scope.
                      '/' and ':' are not allowed in this string.
                      The scopes 'LOCAL' and 'REMOTE' are reserved.

    <select>      ::= <select-list>                     |
                      <select-all>                      |
    <select-list> ::= <select-item>                     |
                      <select-item>, <select-list>
    <select-item> ::= <keyword>  |  <attr-tag>  |  <partial-attr-tag>*
    <attr-tag>       ::= class name of an attribute of a given scheme
                         This tag cannot include the following
                         characters: '(', ')', ',', '=', '!', '>',
                         '<', '/', '*'
    <keyword>        ::= a class name of an attribute which will have
                         no values.  This string has the same limits
                         as the <attr-tag>.  In addition white space
                         internal to the keyword is illegal.
    <partial-tag>    ::= the partial class name of an attribute
                         followed by an '*' matches all class names
                         which begin with the characters preceding
                         the '*'
    <select-all>     ::= *
    <select-none>    ::=
                         That is NOTHING or white space.

    <where>          ::= <where-any>                       |
                         <where-list>                      |
    <where-any>      ::=
                         That is NOTHING or white space.
    <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>) |
    <query-join>     ::= <join-item>                       |
                         <join-item>, <query-join>

Veizades, Kaplan, Guttman, Perkins                            [Page 28]

INTERNET-DRAFT            Service Location Protocol         February-96

    <join-item>      ::= <attr-tag>                        |
                         <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

       If this is absent in a Service Request, the request will match
       any service regardless of scope.  If it is present, only
       services registered under that scope will match the request.

       This determines what information to return.  There are 3 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
                of values.  The list contains a set of class names.
                Elements in the list can be partial names, as 'INT*'
                will match 'INTERFACE 1' and 'INTERNAL'.

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

       The where-list is a logical expression.  It can be a single

Veizades, Kaplan, Guttman, Perkins                            [Page 29]

INTERNET-DRAFT            Service Location Protocol         February-96

       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 OR list matches. A conjunction matches
       only if all elements in the AND list match.

       Note that there is no logical negation operator:  This is
       because there is no notion of returning "everything except" what
       matches a 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.

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

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

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

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

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

       is equivalent to the where-list:

       (& (attr1=value1) keyword1 keyword2 (attr2>=34))

       The query-join cannot be mixed with a where-list.  It is provided
       as a convenient mechanism to provide a statement of necessary
       conditions without building a logical expression.

Veizades, Kaplan, Guttman, Perkins                            [Page 30]

INTERNET-DRAFT            Service Location Protocol         February-96

11.1.3 Reply

   Service Replies have two fields, a URL String and an attribute list.
   URL Strings are as per RFC 1738.  They should contain at least:


   SCHEME is a string.  Schemes may be standardized by developing a
        specification for the "scheme specific" part and registering
        them with the IANA.

   ADDRESS SPECIFICATION is the service access point of the service.
        It is the network address or domain name where the service
        can be accessed.

   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>) | <keyword>
   <attr-val-list> ::=  <attr-val>   |   <attr-val>, <attr-val-list>

   An attribute with only an attr-tag and no values is a keyword.

   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.

11.1.4 Service Registration Information

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

11.1.5 Service Unregister Information

   The Service Unregister Information takes the form:


      SCHEME and ADDRESS SPECIFICATION are described above.

11.1.6 Attribute List

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

Veizades, Kaplan, Guttman, Perkins                            [Page 31]

INTERNET-DRAFT            Service Location Protocol         February-96

11.1.7 Service Scheme

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

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

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

11.2 ADDRESS SPECIFICATIONs in Service Location

   The address specification as described in RFC 1738 is:


   It is preferable to use a fully qualified domain name wherever
   possible as renumbering of host addresses will make ip addresses
   invalid over time.  When no Domain Name Server is available SAs
   and DAs must use dotted decimal conventions for IP addresses.

   Generally just the host domain name (or address) is sufficent to
   return.  When there is a non-standard port for the protocol, that
   should be returned as well.  Some applications may make use of
   the <user>:<password>@ syntax, but its use is discouraged in this
   context as information registered in Service Location is so easily

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

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

Veizades, Kaplan, Guttman, Perkins                            [Page 32]

INTERNET-DRAFT            Service Location Protocol         February-96

   - 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

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

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

12.0 Implementation Requirements

A User Agent MAY:
  - Provide a way for the application to configure the default DA, so
    that it can be used without needing to find it each initially.
  - Be able to request the address of a DA from DHCP, if configured to
    do so.

A User Agent SHOULD:
  - 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

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

A User Agent MUST:
  - Be able to unicast requests and receive replies from a DA.
    Transactions should be made reliable by using retransmission of
    the request if the reply does not arrive within a timeout interval.
  - Be able to detect DAs using a Directory Agent Discovery request
    issued when the UA starts up.
  - Be able to send requests to a multicast address.  If the
    multicast address is not known, the UA must be able to use a
    Scheme query to obtain the multicast address for the scheme of the
  - Be able to handle numerous replies after a multicast request.  The
    implementation may be configurable so it will either return the
    first reply, all replies until a timeout or keep trying till the

Veizades, Kaplan, Guttman, Perkins                            [Page 33]

INTERNET-DRAFT            Service Location Protocol         February-96

    results converge.

A Service Application and Service Agent MAY be able to:
  - Get the address of a local Directory Agent by way of DHCP.

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 SHOULD be registered with the DA.  See Section 6.2.
  - Unicast registrations and unregistrations to a DA.  Transactions
    should be made reliable by using retransmission of the request
    if the reply does not arrive within a timeout interval.
  - Be able to detect DAs using a Directory Agent Discovery request
    issued when the Service Application starts up.

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 SHOULD be registered with the DA.  See Section 6.2.
  - Unicast registrations and unregistrations to a DA.  Transactions
    should be made reliable by using retransmission of the request if
    the reply does not arrive within a timeout interval.
  - Listen to the multicast address of the service it is advertising.
    The incoming requests should be filtered:  If the Address
    Specification of the SA is in the Previous Responders Address
    Specification list, the SA should not respond.  Otherwise, a
    response to the multicast query should be unicast to the UA
    which sent the request.
  - Listen for broadcast requests and TCP connection requests, to
    the Service Location port.
  - 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 'Scheme' requests this way.
  - Be able to detect DAs using a Directory Agent Discovery request
    issued when the SA starts up.

A Directory Agent MUST be able to:
  - Send an unsolicited Directory Agent Discovery reply to the
    Service Location General Multicast address on startup and repeat
    it periodically.   This reply has a unique XID for the life of the
    DA; this XID changes on each reboot (see Section 6.2).
  - Listen on the Directory Agent Multicast Address for Directory
    agent discovery requests.  Filter these requests if the Previous
    Responder Address Specification list includes the DA's Address
  - Listen for broadcast requests to the Service Location port.
  - Listen on the TCP and UDP Service Location 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.

Veizades, Kaplan, Guttman, Perkins                            [Page 34]

INTERNET-DRAFT            Service Location Protocol         February-96

  - 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

13.0 Configuration Parameters and Defaults

13.1 Multicast vs. Broadcast

   All Service Location entities must use multicast by default.
   The ability to use broadcast messages must be configurable.
   Broadcast messages are to be used in environments where not all
   Service Location entities have hardware or software which supports

13.2 Multicast Radius

   Multicast requests should be sent to all subnets in a site.  The
   default multicast radius for a site is 32.  This value must be
   configurable.  The value for the site's multicast TTL may be
   obtained from DHCP.  The DHCP option has not yet been assigned.

13.3 Directory Agent Address

   The Directory Agent address discovery mechanism must be
   configurable.  There are three possibilities for this configuration:
   A default address, no default address and the use of DHCP to locate
   a DA as described in section 6.2.  The default value should be "no
   default address."  In this case the UA or SA must do a Directory
   Agent Discovery query.

13.4 Directory Agent Scope Assignment

   The scope or scopes of a DA must be configurable.  The default value
   for a DA is to have no scope if not otherwise configured.

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

Veizades, Kaplan, Guttman, Perkins                            [Page 35]

INTERNET-DRAFT            Service Location Protocol         February-96

  Error Codes

    No Error                 0

15.0 Acknowledgments

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

16.0 References

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

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

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

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

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

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

Veizades, Kaplan, Guttman, Perkins                            [Page 36]

INTERNET-DRAFT            Service Location Protocol         February-96

[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

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

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

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

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

[18] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
Extensions". RFC 1533, NIC 1993.

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

Veizades, Kaplan, Guttman, Perkins                            [Page 37]

INTERNET-DRAFT            Service Location Protocol         February-96

17.0 Author's Addresses

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

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

   Email: veizades@tgv.com

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

   Phone: +1 415 285 4526

   Email: scott@catch22.com

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

   Phone: +1 415 336 6697

   Email: Erik.Guttman@eng.sun.com

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

   Phone: +1 914 784 7350

   EMail: perk@watson.ibm.com

18.0 Document Expiration

This document expires August 21, 1996

Veizades, Kaplan, Guttman, Perkins                            [Page 38]

INTERNET-DRAFT            Service Location Protocol         February-96

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, Perkins                            [Page 39]

INTERNET-DRAFT            Service Location Protocol         February-96

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

Veizades, Kaplan, Guttman, Perkins                            [Page 40]

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