Network Working Group                                          M. Urue盿
Internet-Draft                                             D. Larrabeiti
Expires: September 15, 2004                                         UC3M
                                                          March 17, 2004


              eXtensible Service Location Protocol (XSLP)
                       <draft-uruena-xslp-00.txt>

Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

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

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

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document specifies the eXtensible Service Location Protocol
   (XSLP), a lightweight protocol that allows User Agents to obtain
   Service information from Directory Agents, even from remote domains.
   Also, XSLP allows User Agents to perform multicast queries to the
   Service Agents inside the same organization. XSLP is the main
   protocol of the eXtensible Service Discovery Framework (XSDF).









Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 1]

Internet-Draft               XSLP Protocol                    March 2004


Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1  Definitions  . . . . . . . . . . . . . . . . . . . . . . .   4
     1.2  Notation Conventions . . . . . . . . . . . . . . . . . . .   4

   2.   Messages Format  . . . . . . . . . . . . . . . . . . . . . .   5
     2.1  XSLPv1 Element . . . . . . . . . . . . . . . . . . . . . .   5
     2.2  Service Request Element  . . . . . . . . . . . . . . . . .   5
       2.2.1  Services Target Element  . . . . . . . . . . . . . . .   6
       2.2.2  Return Element . . . . . . . . . . . . . . . . . . . .   7
     2.3  Service Reply Element  . . . . . . . . . . . . . . . . . .   7
     2.4  Service Advertisement Element  . . . . . . . . . . . . . .   8
     2.5  Realm Request Element  . . . . . . . . . . . . . . . . . .   8
       2.5.1  Realm Filter Element . . . . . . . . . . . . . . . . .   9
     2.6  Realm Reply Element  . . . . . . . . . . . . . . . . . . .   9
     2.7  Service Type Request Element . . . . . . . . . . . . . . .  10
       2.7.1  Service Types Filter Element . . . . . . . . . . . . .  10
     2.8  Service Type Reply Element . . . . . . . . . . . . . . . .  10
     2.9  Redirect Element . . . . . . . . . . . . . . . . . . . . .  11
     2.10   Common Operation Parameters  . . . . . . . . . . . . . .  11
       2.10.1   Record Element . . . . . . . . . . . . . . . . . . .  12

   3.   XSLP Operation Procedures  . . . . . . . . . . . . . . . . .  13
     3.1  Service Request  . . . . . . . . . . . . . . . . . . . . .  14
     3.2  Service Advertisement  . . . . . . . . . . . . . . . . . .  15
     3.3  Realm Request  . . . . . . . . . . . . . . . . . . . . . .  16
     3.4  Service Type Request . . . . . . . . . . . . . . . . . . .  16
     3.5  Redirect Reply . . . . . . . . . . . . . . . . . . . . . .  17
     3.6  Remote Domains . . . . . . . . . . . . . . . . . . . . . .  17

   4.   Security Considerations  . . . . . . . . . . . . . . . . . .  18

   5.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . .  18

        References . . . . . . . . . . . . . . . . . . . . . . . . .  19

        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  19

   A.   XSLP Constants . . . . . . . . . . . . . . . . . . . . . . .  20
     A.1  XBE32 Elements . . . . . . . . . . . . . . . . . . . . . .  20
     A.2  Time Constants . . . . . . . . . . . . . . . . . . . . . .  20

        Intellectual Property and Copyright Statements . . . . . . .  21







Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 2]

Internet-Draft               XSLP Protocol                    March 2004


1. Introduction

   XSDF [4] is a framework for Service Discovery. It allows Users to
   dynamically find available network Services and choose the better
   ones following certain selection policies. In XSDF, User Agents (UAs)
   may issue multicast Service requests directly to Service Agents
   (SAs). In bigger networks, UAs request Service information to a
   central repository managed by the so-called Directory Agents (DAs).

   XSLP is the protocol employed by UAs to obtain Service information
   from SAs and/or DAs. Such information contains the location of the
   Service, the expected validity time and some selection data to choose
   the best Service instance, if multiple ones have been discovered.
   This mechanism allows end hosts, with little or no configuration, to
   dynamically find the best available network Services.

   In networks where no DAs have been deployed, as unmanaged LANs, UAs
   directly query SAs for Services. Such XSLP request messages are sent
   to SAs in multicast (or broadcast if multicast is not available). SAs
   with Services that match with such request return these Services to
   the UA  in unicast replies.

                       Multicast XSLP Request   +----+
               +----+  ----------------------> +----+|
               | UA |                          | SA |+
               +----+ <----------------------  +----+
                        Unicast XSLP Replies

   As multicast requests have scalability issues, larger networks will
   deploy one or more DAs. Those DAs centralize all Service information
   from one or more Scopes of a Domain. SAs register the Services from
   those Scopes at any of these DAs employing XSRP. Then, XSLP messages
   can be directly issued in unicast to any of these DAs.

                       Unicast XSLP Request
               +----+  --------------------> +----+
               | UA |                        | DA |
               +----+ <--------------------  +----+
                        Unicast XSLP Reply

   Of course, UAs first need to find the appropriate DAs. As DAs are
   Services by themselves, when they have no DAs configured, they can
   bootstrap by querying for DA agents in multicast as if they were any
   other Service. Once one or more DAs serving a Scope are discovered,
   all location requests/registrations for Services at those Scopes
   should be issued in unicast to any of those DAs.

   As each Scope should be treated as a different environment, both



Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 3]

Internet-Draft               XSLP Protocol                    March 2004


   modes of operation may coexist in a single network. If DAs are
   deployed, but they do not manage all the Scopes at the Domain, an UA
   may issue both, unicast requests to DAs, and multicast requests to
   SAs from unmanaged Scopes.

1.1 Definitions

   Domain: A Domain is a single administrative organization containing
      Users and Services.

   Scope: A Scope is a subset of Users and Services from a Domain,
      typically making a logical administrative group.

   Realm: A Realm is a combination of a Domain and one or more Scopes
      from such Domain, if any.

   Service: A Service is any process attached to a network that provides
      some kind of functionality to Users or other Services. A Service
      belongs to a single Realm.

   User Agent (UA): A process working on the User's (or other process)
      behalf to discover Services, and select the best available one.
      UAs obtain Service information from Directory Agents and Service
      Agents via XSLP.

   Service Agent (SA): A Service Agent is itself a Service that
      advertise Service information on behalf other processes. SAs are
      queried by User Agents for Services via XSLP, and/or register
      Service information in Directory Agents employing XSRP.

   Directory Agent (DA): A Directory Agent is a Service that, when
      deployed, acts as a central repository of all Service information
      from a Realm. Service Agents register its Services in a DA
      employing the XSRP protocol. Then, User Agents are able to query
      that information with XSLP. An Scope can be served by multiple DAs
      that coordinate themselves via XSSP & XSTP protocols.

   XSDF Agent: Any process that employs any XSDF protocol to interact
      with other XSDF Agents. All XSDF Agents must implement the XSLP
      protocol. UAs behave as clients while SAs and DAs are servers.


1.2 Notation Conventions

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL, when
   they appear in this document, are to be interpreted as described in
   RFC2119 [1].



Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 4]

Internet-Draft               XSLP Protocol                    March 2004


2. Messages Format

   This section defines the format of all XSLP messages. These messages
   are exchanged between an User Agent and, a Directory Agent or several
   Service Agents.

   XSDF protocol messages are encoded employing XBE32 [3]. Definitions
   for common XSDF Elements and Attributes can be found at [5]

2.1 XSLPv1 Element

   All XSDF messages have a common format: a single XBE32 Element
   containing a Header, and one or more protocol Operations. XSLP
   messages are encoded inside a XSLPv1 Element.

   XSLPv1 Element:
     Element Name : xslpv1
     XBE32 Type   : 0x0901

   +---------------------------------------------------------------+
   :                        Header Element                         :
   +---------------------------------------------------------------+
   :                   XSLP Operation Element #1                   :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                   XSLP Operation Element #N                   :
   +---------------------------------------------------------------+
   :               [ Signature Information Element ]               :
   +---------------------------------------------------------------+

   Header and Signature Information Elements are defined in [5]. Next
   subsections describe XSLP Operation Elements.

2.2 Service Request Element

   UAs send this operation request to DAs or SAs in order to obtain the
   specified Service information from their common Realm.















Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 5]

Internet-Draft               XSLP Protocol                    March 2004


   Service Request Element:
     Element Name : serviceRequest
     XBE32 Type   : 0x0930

   +---------------------------------------------------------------+
   :                   Services Target Element                     :
   +---------------------------------------------------------------+
   :                 [ Services Filter Element ]                   :
   +---------------------------------------------------------------+
   :                       Return Element                          :
   +---------------------------------------------------------------+

   Services Filter Element is defined in [5].

   All Services specified by the Target but the ones with Ids listed in
   the Filter Element SHOULD be included in the reply operation. The
   Return Element defines which information Elements SHOULD be returned
   in such reply.

2.2.1 Services Target Element

   UA specifies in this Element the Type of the Service it is interested
   in, for example "printer". It MAY also specify the exact Id of the
   requested Services, but in any case the Service Type MUST be
   included.

   Target Element:
     Element Name : target
     XBE32 Type   : 0x0821

   +---------------------------------------------------------------+
   :                     Service Type Element                      :
   +---------------------------------------------------------------+
   |                       [ Service Ids ]                         |
   +---------------------------------------------------------------+

   Service Ids Attribute and Service Type Element are defined in [5].

   All Service Request operations MUST contain the Type of the Services
   being requested. If the Type Element contains any Path Element, the
   returned elements MUST provide the requested resources. That is,
   their Path Elements MUST fully contain, at least, one of the
   requested Paths ("/" includes "/store/index.html". Although "/s" does
   not include "/store/index.html", but "/s/all"). If no Path attribute
   is included, all elements SHOULD be returned, no matter which
   resources they are providing.

   When included, the Service Ids Attribute indicates which Services



Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 6]

Internet-Draft               XSLP Protocol                    March 2004


   should be returned. XSDF Server Agent SHOULD NOT return information
   about other Services but the ones listed here. When the list does
   contain unknown Services, those Ids SHOULD be silently skipped.

2.2.2 Return Element

   In this Element, UA indicates which information of the selected
   Services should be returned. An empty "return" Element will generate
   a reply containing just the Service Ids found. If a "serviceState"
   Element is specified, Services will carry the Element information of
   the same name, and so on.

   Return Element:
     Element Name : return
     XBE32 Type   : 0x0841

   +---------------------------------------------------------------+
   |                      [ Service State ]                        |
   +---------------------------------------------------------------+
   |                  [ Service Main Information ]                 |
   +---------------------------------------------------------------+
   |                [ Service Location Information ]               |
   +---------------------------------------------------------------+
   |               [ Service Additional Information ]              |
   +---------------------------------------------------------------+

   When "return" Element contains the Service State empty Element,
   Services in the reply MUST contain their Service State Elements.

   When "return" Element contains the Service Main Information empty
   Element, Services in the reply MUST contain their Service Main
   Information Elements.

   When "return" Element contains the Service Location Information empty
   Element, Services in the reply MUST contain their Service Location
   Information Elements.

   When "return" Element contains the Service Additional Information
   empty Element, Services in the reply MUST contain their Service
   Additional Information Elements.

2.3 Service Reply Element

   This reply operation is sent back to the UA as a response to a
   previous "serviceRequest" operation. It contains all the selected
   Service information and its validity time.





Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 7]

Internet-Draft               XSLP Protocol                    March 2004


   Service Reply Element:
     Element Name : serviceReply
     XBE32 Type   : 0x0941

   +---------------------------------------------------------------+
   :                    [ Record Element #1 ]                      :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                    [ Record Element #N ]                      :
   +---------------------------------------------------------------+

   Record Element is defined in Section 2.10.1.

   Each Record Element contains information about a single Service that
   matches with a previous "serviceRequest". If no Service Records are
   included, source XSDF Agent does not known any Service that matches.
   However, empty "serviceReply" operations MUST NOT be sent as a
   response to multicast queries.

2.4 Service Advertisement Element

   Service Advertisements MAY be sent by DAs and SAs containing Service
   information they known. In the so-called Passive DA Discovery
   process, DAs send multicast messages to all XSDF Agents from the same
   Realm to advertise its own Service information. Also, Service
   Advertisements MAY be employed by XSSP [7] as a notification
   mechanism.

   Service Advertisement Element:
     Element Name : serviceAdvert
     XBE32 Type   : 0x0921

   +---------------------------------------------------------------+
   :                      Record Element #1                        :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                      Record Element #N                        :
   +---------------------------------------------------------------+

   Record Element is defined in Section 2.10.1.

   Service Elements inside Record Elements MUST include Service Id, Main
   and Location Elements. Other Service information is optional and
   SHOULD NOT appear.

2.5 Realm Request Element

   This Element defines an optional operation. It requests the Realm of
   the destination XSDF Agent.




Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 8]

Internet-Draft               XSLP Protocol                    March 2004


   Realm Request Element:
     Element Name : realmRequest
     XBE32 Type   : 0xC940

   +---------------------------------------------------------------+
   :                  [ Realm Filter Element ]                     :
   +---------------------------------------------------------------+


2.5.1 Realm Filter Element

   When this optional Element is included, the "realmReply" response
   SHOULD NOT include the Scopes listed in this field.

   Realm Filter Element:
     Element Name : filter
     XBE32 Type   : 0x0841

   +---------------------------------------------------------------+
   :                        Realm Element                          :
   +---------------------------------------------------------------+

   Realm Element is defined in [5].

   This Element contains a sorted list of Scopes that SHOULD NOT be
   included in the "realmReply" response. List MUST be sorted in order
   to ease Scope search.

2.6 Realm Reply Element

   This reply operation is sent back to the UA as a response to a
   previous "realmRequest" operation. It contains the full Realm of the
   source XSDF Agent but the filtered Scopes.

   Realm Reply Element:
     Element Name : realmReply
     XBE32 Type   : 0xC941

   +---------------------------------------------------------------+
   :                         Realm Element                         :
   +---------------------------------------------------------------+

   Realm Element is defined in [5].

   Returned Realm Element MUST contain the Realm, source XSDF Agent
   belongs to. Scopes included in the request Filter parameter SHOULD
   NOT be included.




Urue盿 & Larrabeiti    Expires September 15, 2004               [Page 9]

Internet-Draft               XSLP Protocol                    March 2004


2.7 Service Type Request Element

   This Element defines an optional operation. It requests the list of
   Service Types, of all the Services known by the destination XSDF
   agent.

   Service Type Request Element:
     Element Name : serviceTypeRequest
     XBE32 Type   : 0xC950

   +---------------------------------------------------------------+
   :                    Realm Target Element                       :
   +---------------------------------------------------------------+
   :               [ Service Types Filter Element ]                :
   +---------------------------------------------------------------+

   Realm Target Element is defined in [5].

   The Realm Target Element MAY contain the subset of Header's Realm
   Scopes to request Service Types from. If Realm Target is empty,
   Service Types, from all the Scopes specified in message Header, are
   requested.

2.7.1 Service Types Filter Element

   When this Element is included, the reply "serviceTypeReply" message
   SHOULD NOT include the Service Types listed in this field.

   Service Types Filter Element:
     Element Name : filter
     XBE32 Type   : 0x0841

   +---------------------------------------------------------------+
   :                   [ Service Type Element #1 ]                 :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                   [ Service Type Element #N ]                 :
   +---------------------------------------------------------------+

   Service Type Element is defined in [5].

   This Element contains a sorted list of Service Types that SHOULD NOT
   be included in the "serviceTypeReply" response. List MUST be sorted
   by the Type Attribute in order to ease Service Type search.

2.8 Service Type Reply Element

   This reply operation is sent back to the UA as a response to a
   previous "serviceTypeRequest" operation. It contains the list of all



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 10]

Internet-Draft               XSLP Protocol                    March 2004


   the Service Types from specified Scopes.

   Service Type Reply Element:
     Element Name : serviceTypeReply
     XBE32 Type   : 0xC951

   +---------------------------------------------------------------+
   :                   [ Service Type Element #1 ]                 :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                   [ Service Type Element #N ]                 :
   +---------------------------------------------------------------+

   Service Type Element is defined in [5].

   Returned Service Type Elements contains information about
   non-filtered Service Types from specified Scopes. If no Service Types
   are included, no Services are registered at specified Scopes or all
   Service Types have been filtered. However, empty "serviceTypeReply"
   operations MUST NOT be sent as a response to multicast queries.

2.9 Redirect Element

   This reply operation indicates UA that it SHOULD resent the request
   to the specified XSDF Agents from the same Realm.

   Redirect Element:
     Element Name : redirect
     XBE32 Type   : 0x0911

   +---------------------------------------------------------------+
   :                      Service Element #1                       :
   +父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父父�+
   :                      Service Element #N                       :
   +---------------------------------------------------------------+

   Service Element is defined in [5].

   As the UA receiving this response SHOULD forward its XSLP request to
   the specified Services, all the listed Services MUST refer to XSDF DA
   or SA agents. Each Service Element MUST contain Service Id, Main and
   Location Elements. Other Service information is optional and SHOULD
   NOT appear.

2.10 Common Operation Parameters

   When an UA requests Service information, SAs and DAs return such
   information inside a Record Element, that also contains for how long
   this data is expected to remain valid. This section describes in



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 11]

Internet-Draft               XSLP Protocol                    March 2004


   detail the "record" Element.

2.10.1 Record Element

   This is the main parameter of the "serviceReply" and "serviceAdvert"
   operations. It contains the advertised Service or the information
   requested by an UA.

   Record Element:
     Element Name : record
     XBE32 Type   : 0x0200

   +---------------------------------------------------------------+
   :                        Service Element                        :
   +---------------------------------------------------------------+
   :                      Record State Element                     :
   +---------------------------------------------------------------+

   Service Element is defined in [5].

2.10.1.1 Record State Element

   This Element contains meta-information about the associated Service
   carried inside the Record Element.

   Record State Element:
     Element Name : recordState
     XBE32 Type   : 0x0210

   +---------------------------------------------------------------+
   :                     Cache State Element                       :
   +---------------------------------------------------------------+

   Cache State Element is defined in [5].

   Cache State Element contains two Attributes about the associated
   Service, its Age and the remaining TTL. UA SHOULD flush the Service
   information from its cache when its TTL value is zero.













Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 12]

Internet-Draft               XSLP Protocol                    March 2004


3. XSLP Operation Procedures

   All XSDF Agents MUST follow the common procedures for XSDF Agent
   initialization, message generation, transmission and processing
   defined in [5]. This section specifies additional procedures for the
   XSLP protocol.

   XSLP is a Client-Server protocol. UAs act as Clients sending
   operation requests while SAs and DAs act as Servers processing those
   requests and sending replies back.

   All XSLP Agents MUST support the UDP transport protocol and MAY also
   support TCP and SCTP. The port number for all these transport
   protocols MUST be 727.

   When a Scope is managed by one or more active DAs, UAs MUST employ
   unicast transmission to obtain Services from the DAs that manage that
   Scope. In that case, the UA SHOULD choose the better DA (that
   supports the "xslp" protocol) as advertised by their Service
   information. Once a XSLP message with  the appropriate operations has
   been generated, it is sent to the selected DA. If message can not be
   delivered, next DA from the same Realm SHOULD be chosen. If there are
   no DAs left, Scope is marked as "unmanaged" and search process MAY
   follow as defined below.

   In unmanaged Scopes from local Domain, UAs SHOULD employ multicast
   XSLP messages in order to reach all the SAs of those Scopes as
   defined in [5]. However, if a new DA managing a previously unmanaged
   Scope is discovered, the Scope becomes "managed" and UAs MUST employ
   unicast XSLP messages as defined above.

   Service Types have associated IPv6 multicast groups. Thus, multicast
   queries by Service Type MUST be sent to those groups. For XSLP
   operations that have no associated Service Type, the IPv6 multicast
   group derived from the "xsdf:sa" Service Type (FE0X:0:0:0:0:0:1:1216)
   SHOULD be employed in order to reach all the SAs at unmanaged Scopes.

   When in an "unmanaged" Scope, SAs MUST reply to multicast queries
   with unicast messages. However, if the reply operation is empty, SAs
   MUST NOT respond, exactly the same as if an error has occurred. This
   rule only applies to multicast queries, for unicast ones, SAs MUST
   return the empty reply operation.

   An UA MAY belong to multiple Scopes, some could be managed by DAs
   while others remain unmanaged. Thus, UAs SHOULD be able to perform
   both kinds of searches, unicast messages to a single DA and multicast
   messages to several SAs. While DA MUST support unicast queries, SAs
   SHOULD support both, unicast and multicast queries from UAs.



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 13]

Internet-Draft               XSLP Protocol                    March 2004


   As"LOCAL" Scope only contains Services related to the local Server,
   it has its own rules. Multicast queries MUST NOT refer to the "LOCAL"
   scope. Also, "LOCAL" Services SHOULD NOT be included in Service
   advertisements. In order to obtain Service information from this
   Scope, an UA MUST employ just unicast messages targeted to the
   particular XSDF Agent.

   Service information can be obtained from several Sources and
   mechanisms, thus multiple versions MAY be returned. However, as
   Service information SHOULD be the same across all its Scopes, all
   version MUST be considered as a Single Service where newer
   information replaces older one.

3.1 Service Request

   The so-called Active Service Discovery mechanism, allows an UA to
   obtain information about Services at a specified Realm. UAs will send
   "serviceRequest" operations, while DAs or SAs will respond with
   "serviceReply" carrying the matching Services they known. Refer to
   Section 2.2 and Section 2.3 for a detailed description of
   "serviceRequest" and "serviceReply" operations.

   When a SA or a DA receives a valid XSLP message with an authorized
   "serviceRequest" operation, it MUST follow these steps to process
   such operation:

   1.  Obtain the list of Scopes to query Services from the message's
       Header.

   2.  Obtain all the Services with the specified Type that belong to
       the above Scope list. If Service Type Element contains some Path
       Elements, Services not providing any of the specified resources
       SHOULD be dropped.

   3.  If the Target parameter specifies the Ids of the requested
       Services, XSDF Agent SHOULD find those Services and check that
       they belong to the specified Realms and have the specified
       Service Type.

   4.  If the request operation contains a Filter parameter, specified
       Services SHOULD be removed from the reply.

   5.  Once the list of Services that match has been obtained, reply
       operation MUST generate a Record Element for each one.
       LAST_UPDATE_TIMESTAMP associated to the Service registration MUST
       be employed to calculate the Age of the record (by subtracting it
       from current time). Remaining TTL is calculated as the associated
       SERVICE_LIFETIME variable minus its Age. Both registration



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 14]

Internet-Draft               XSLP Protocol                    March 2004


       variables are defined in [6].

   6.  Record's Service Element MUST include the Service Identifier,
       other information is optional and SHOULD appear if listed in the
       Return parameter of the "serviceRequest" operation.

   If specified Service Type has an associated Selection Policy, DA MAY
   sort/filter returned Services according to that policy. Therefore, if
   UAs does not have additional Service information they SHOULD try to
   access the discovered Services in the specified order.

   A XSDF Agent MAY employ XSLP itself in its initialization phase to
   discover DAs from a Realm. As the UA does not know any DA from the
   Realm, all the Scopes are considered to be "unmanaged" and
   "serviceRequest" operation MUST be sent in a multicast message. In
   that case, the Service Type to be included in the request MUST be
   "xsdf:da". XSDF Agents MUST wait for some time, distributed between 0
   and INIT_FIND_DELAY, before trying to obtain DA Service information
   via this mechanism. Also, XSDF Agents MAY employ this mechanism
   periodically in order to discover new DAs from unmanaged Scopes.
   Consecutive queries MUST be spaced at least by a RETRY_FIND_DELAY
   interval.

3.2 Service Advertisement

   UAs MAY also obtain Service information by the Passive Service
   Discovery mechanism. In this process UAs do not request Services but
   DAs and SAs do sent multicast messages advertising Service
   information inside "serviceAdvert" Elements. Refer to Section 2.4 for
   a detailed description of the "serviceAdvert" operation.

   Directory Agents MUST periodically advertise its own Service
   information inside Service Advertisement messages. Those DA
   Advertisement messages MUST be sent to the "All XSDF Agents"
   multicast group as defined in [5]. Consecutive advertisements MUST be
   spaced at least by a DA_ADVERT_DELAY interval.

   SAs MAY also employ this mechanism to advertise Services in unmanaged
   Scopes. However, a SA MUST NOT advertise any Service belonging to a
   Realm fully managed by one or more active DAs.

   Service Advertisement messages MAY be also employed to notify
   modification Events. See XSSP [7] for a complete description of this
   mechanism.

   As described in [7], a service becoming unavailable MAY be advertised
   within a Service Advertisement message with a zero TTL. Directory
   Agents SHOULD notify that are to become unavailable with this



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 15]

Internet-Draft               XSLP Protocol                    March 2004


   mechanism. They MAY advertise also the service information of other
   alternative DAs, thus UAs and SAs may be able to migrate their XSDF
   operations to them without disruption.

3.3 Realm Request

   XSDF Agents that support this kind of transaction may be queried in
   order to obtain the Realm they belong to. In that case, UAs send
   "realmRequest" operations. XSDF Agents respond with "realmReply"
   operations containing their Realms. Refer to Section 2.5 and Section
   2.6 for a detailed description of "realmRequest" and "realmReply"
   operations.

   When a DA or SA receives a valid XSLP message with an authorized
   "realmRequest" operation, it MAY generate a "realmReply" response if
   it supports such operation, or reject it as unsupported
   (UNKNOWN_XBE32_ELEMENT). Response MUST contain the XSDF Agent's Realm
   but the Scopes listed in the Filter parameter, if present.

   In order that UAs and SAs know if a DA supports this operation, the
   DA MAY advertise the "RealmReply" XBE32 Type (0xC941) in the
   Capability Attribute of the "xslp" Protocol Element [5].

   UAs and SAs MAY employ this operation in the initialization phase in
   order to obtain the Realm they belong to. In that case, they MAY
   collect the Realms of pre-configured DAs. Its Realm will be generated
   as the common Domain, and all the discovered Scopes.

3.4 Service Type Request

   When XSDF Agents support these optional operations, an UA is able to
   obtain all the Service Types from a Realm. UAs send
   "serviceTypeRequest" operations while DAs and SAs answer with
   "serviceTypeReply" operations. Refer to Section 2.7 and Section 2.8
   for a detailed description of "serviceTypeRequest" and
   "serviceTypeReply" operations.

   When a SA or a DA receives a valid XSLP message with an authorized
   "realmRequest" operation, it MAY generate a "serviceTypeReply"
   response if it supports such operation or reject it as unsupported
   (UNKNOWN_XBE32_ELEMENT). Response MUST contain the list of all the
   known Service Types from specified Realm, but the ones listed in the
   Filter parameter, if present.

   In order that UAs and SAs know if a DA supports this operation, the
   DA MAY advertise the "ServiceTypeReply" XBE32 Type (0xC951) in the
   Capability Attribute of the "xslp" Protocol Element [5].




Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 16]

Internet-Draft               XSLP Protocol                    March 2004


3.5 Redirect Reply

   A XSDF Agent MAY reply to a XSLP request message with a "redirect"
   operation. In that case, it has not processed any of the requested
   operations but indicates that the specified XSDF Agents are better
   suited to perform such request. Refer to Section 2.9 for a detailed
   description of the "redirect" operation.

   When an UA receives a valid "redirect" operation as a response for a
   request message, it SHOULD generate a new request message with the
   same operations as the previous one. That message SHOULD be sent to
   the XSDF Agents included in the "redirect" operation. If Selection
   information is included, best one SHOULD be chosen. Otherwise, first
   one SHOULD be selected.  If message can not be delivered, next DA
   SHOULD be chosen until message gets delivered or there are no XSDF
   Agents left.

3.6 Remote Domains

   Previous sections refer only to XSLP operations in the local domain.
   However, XSLP allows Service Discovery in both, remote and local
   sites. Therefore, when an UA is requested to obtain some Service
   information form a Realm, it MUST compare the specified Realm's
   Domain with its own, if any. If both Domains match, Local Service
   Discovery is requested and the above rules apply.

   If Domains do not match, a Remote Service Discovery procedure is
   required. This procedure is exactly the same as the local one when
   DAs are deployed, but the mechanism to locate the DAs of the remote
   Domain. Multicast requests MUST NOT be employed to locate DAs from
   non-local Domains.

   Instead of pre-configured DAs or multicast queries as in the local
   case, remote DAs could be located by querying the DNS. DAs managing
   the Services from the "PUBLIC" Scope MAY be advertised in DNS SRV
   Resource Records [2] of the remote DNS Domain. Those Resource Records
   MUST have the following name: "_xslp._udp." plus the remote Domain
   name. For example, DAs managing "PUBLIC" Services from "example.com"
   Domain could be located by obtaining the "_xslp._udp.example.com" DNS
   SRV RR.

   Once the public DAs from remote Domain have been discovered
   (including its weight value), UAs SHOULD follow the same procedures
   already defined to query local DAs.







Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 17]

Internet-Draft               XSLP Protocol                    March 2004


4. Security Considerations

   XSDF Service Discovery Framework relies on security procedures
   provided by lower layers, as TLS or IPSec ones. However, it defines
   some authentication mechanisms that SHOULD be employed when similar
   ones are not being provided by the layers below. See [5] for a
   detailed description of these mechanisms.

   XSLP over TLS is named "xslp/tls" and its default port number for the
   TCP and SCTP transport protocols is 728.

   In insecure environments, XSDF Agents receiving Service Advertisement
   messages or "redirect" operations SHOULD carefully check if they came
   from a trusted XSDF Agent. In order to provide message authentication
   and integrity, SAs and DAs SHOULD append a Signature Element to
   messages containing Service Advertisements and Redirect Replies.

5. Acknowledgements

   XSLP protocol was designed as an evolution of the SLPv2 one and its
   extensions. It also also includes many ideas borrowed from Rserpool's
   ASAP. Therefore, we wish to thank the authors of both specifications,
   as well as Weibin Zhao, Henning Schulzrinne, Erik Guttman, Chatschik
   Bisdikan and William F. Jerome. They are the authors of the SLP
   Remote Discovery draft, which is the foundation of the Remote Domains
   section of this document.

























Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 18]

Internet-Draft               XSLP Protocol                    March 2004


References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
        specifying the location of services (DNS SRV)", RFC 2782,
        February 2000.

   [3]  Urue盿, M. and D. Larrabeiti, "eXtensible Binary Encoding
        (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004.

   [4]  Urue盿, M. and D. Larrabeiti, "Overview of the eXtensible
        Service Discovery Framework (XSDF)",
        draft-uruena-xsdf-overview-00 (work in progress), March 2004.

   [5]  Urue盿, M. and D. Larrabeiti, "eXtensible Service Discovery
        Framework (XSDF):  Common Elements and Procedures",
        draft-uruena-xsdf-common-00 (work in progress), March 2004.

   [6]  Urue盿, M. and D. Larrabeiti, "eXtensible Service Registration
        Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March
        2004.

   [7]  Urue盿, M. and D. Larrabeiti, "eXtensible Service Subscription
        Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March
        2004.


Authors' Addresses

   Manuel Urue盿
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Legan塻, Madrid  28911
   ES

   Phone: +34 91 624 87 95
   EMail: muruenya@it.uc3m.es












Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 19]

Internet-Draft               XSLP Protocol                    March 2004


   David Larrabeiti
   Universidad Carlos III de Madrid
   Av. Universidad 30
   Legan塻, Madrid  28911
   ES

   Phone: +34 91 624 99 53
   EMail: dlarra@it.uc3m.es

Appendix A. XSLP Constants

A.1 XBE32 Elements

   Element Name         XBE32 Type
   ------------         ----------
   xslpv1               0x0901
   redirect             0x0911
   serviceAdvert        0x0921
   serviceRequest       0x0930
   serviceReply         0x0931
   realmRequest         0xC940
   realmReply           0xC941
   serviceTypeRequest   0xC950
   serviceTypeReply     0xC951
   filter               0x0841
   return               0x0851
   record               0x0200
   recordState          0x0210


A.2 Time Constants

   Constant name       Default Value  Description
   ------------------  -------------  -----------------------------------
   INIT_FIND_DELAY         5 seconds  Max delay before obtaining Realm or
                                      DAs info via XSLP
   RETRY_FIND_DELAY           1 hour  Min delay before repeating XSLP DA
                                      Discovery
   DA_ADVERT_DELAY        30 minutes  Min delay between DA Advertisements












Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 20]

Internet-Draft               XSLP Protocol                    March 2004


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.


Full Copyright Statement

   Copyright (C) The Internet Society (2004). All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION



Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 21]

Internet-Draft               XSLP Protocol                    March 2004


   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.











































Urue盿 & Larrabeiti    Expires September 15, 2004              [Page 22]