Network Working Group M. Urue±a Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 Overview of the eXtensible Service Discovery Framework (XSDF) 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 provides an overview of the eXtensible Service Discovery Framework (XSDF). It defines a collection of extensible protocols and agents for the dynamic location of network services. XSDF Service Discovery Framework is scalable and can be deployed from unmanaged LANs up to Internet-wide Service Location. XSDF also provides several mechanisms to select among the available services discovered. This allows service providers to implement load sharing or active/backup policies among multiple servers providing the same service. Urue±a & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSDF Overview March 2004 1. Introduction Service Discovery term refers to the process that allows an User to find a Service. In particular, the main information to be discovered for network Services is its location, that is, the combination of network addresses of the server which is running that Service instance, and a transport protocol port where the Service process is listening. Until the day in which Service Discovery Frameworks will be widely deployed, clients need to known just the hostname of the server providing such Service, as most Services employ well-known ports. This situation requires User's workstation to be pre-configured with the name of the servers providing network Services. This approach lead to high administrative costs, specially when adding new Services to the network. When clients are mobile and connect to several networks, manual configuration becomes a real issue. That is the rationale behind the development of Service Discovery Frameworks. This document provides an overview of the eXtensible Service Discovery Framework. XSDF defines a collection of application protocols and entities, aimed to manage information about network Services as its existence, location, and management data. XSDF is an evolution of the Service Location Protocol (SLP) [1]. It also tries to be compliant with the requirements [4] defined by the Reliable Server Pooling (Rserpool) Working Group. The main features of XSDF and its differences with SLP are: Enhanced Service Model: SLP describes a Service with an URL and a set of attribute-value pairs. Also, SLP services are identified by its URL, which is known to be the source of some problems [5]. In XSDF, services are identified by an UUID [6] and could be defined by employing an extensible hierarchical representation data model. Internet-wide location: SLP was designed for Service Discovery in Local Area Networks inside a single administrative domain. XSDF has been designed to allow Service Discovery from remote sites by querying public Service Directory Agents advertised in DNS SRV Resource Records [3]. Load balancing: Although Service selection is an important step in the Service Discovery process, SLP does not provide a standard mechanism to choose the best service located. XSDF includes the service selection model of Rserpool thus enabling common selection mechanisms as load balancing or primary/backup servers. Such selection process can be done both, by the end hosts and by the XSDF Directory Agents. As XSDF Agents are themselves Services, Urue±a & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSDF Overview March 2004 they can employ the XSDF Framework to discover other low loaded XSDF Agents. End-to-End solution: As end clients are aware of the different servers from a pool, they can connect directly to the chosen one. Therefore there is not need of stateful middleware, as in other solutions like L4/L7 switches. High Availability: Once deployed, Service Discovery may became a critical component of the Network. XSDF defines the XSTP/XSSP protocols to provide a scalable and highly available Service repository distributed among multiple DAs sharing a common Realm. Zero Configuration: As in SLP, neither UAs nor SAs need to be configured with the location of DAs. XSDF may also bootstrap by employing multicast searches and DA advertisements. However, as DAs are Services themselves, XSDF does not require special messages for DA Discovery. In a XSDF capable network, a client does not need to know any Service but IP connectivity (via DHCP or IPv6 autoconf.). Then, it may be able to obtain any kind of Service information, for example the local DNS server. As in SLP, XSLP only handles Service Discovery (and additionally Service selection). Once an UA choose one Service, it will employ any other protocol outside of the scope of XSDF (unless it was also a XSDF Service, of course). XSDF will just provide the location and protocol information to begin further Service communication. This document does not contain the specification of XSDF protocols but an overview of the XSDF Framework. XSDF protocols are defined in separate documents. See [8] for a detailed description of common XSDF procedures and data structures. 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. Urue±a & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSDF Overview March 2004 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. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). Urue±a & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSDF Overview March 2004 2. Architecture A XSDF Framework is formed by multiple XSDF Agents and several protocols to communicate them. Each of these protocols deals with a different part of the Service Discovery process. The XSDF protocols are: eXtensible Service Location Protocol (XSLP): User Agents employ this protocol to get Service information from Service Agents and/or Directory Agents. Please note that a SA or a DA can behave as an UA and query other SAs/DAs for XSDF Service information. XSLP protocol specification can be found at [9]. eXtensible Service Register Protocol (XSRP): When a Scope is served by one or more Directory Agents, Service Agents register Service information in such DAs, thus aggregating all Services of the Scope in a central cache. XSRP is the protocol employed by SAs to register Service information in a DA. XSRP protocol specification can be found at [10]. eXtensible Service Subscription Protocol (XSSP): This protocol allows a XSDF Agent to subscribe itself to any changes made to Service information by registering a notification channel. All changes affecting the specified subscription are sent through that channel. Directory Agents with common Scopes employ this protocol to be subscribed to Service registration operations from those Scopes. XSSP protocol specification can be found at [11]. eXtensible Service Transfer Protocol (XSTP): In order to achieve high availability or just scalability, a single Scope can be served by several Directory Agents. Those DAs employ the XSTP protocol to obtain the Services known by the other DAs, and to notify subscribed Services with XSRP operations affecting Service information registered in the common Scope. XSTP protocol specification can be found at [12]. All XSDF protocols are quite simple client-server ones. That allows UAs, and specially SAs, to be implemented in embedded platforms with low processing power. XSDF messages may be encoded with any suitable encoding mechanism for hierarchical structured data, as XML does. However, XBE32 [7] binary encoding is preferred as it is more compact, and can be more easily parsed than plain XML. Urue±a & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSDF Overview March 2004 This figure provides an overview of the XSDF architecture and its protocols: +----+ XSLP +----+ XSTP +----+ XSRP +----+ | UA | ----> | DA | <----> | DA | <---- | SA | +----+ XSSP +----+ XSSP +----+ +----+ | ^ | XSLP | +----------------------------------------+ The main objective of the XSDF Framework is that User Agents were able to obtain information about available Services. Such information is maintained by the Service Agents. In small scenarios, UAs are able to query SAs for the services via XSLP multicast queries. In bigger networks, there is an intermediate Service information broker called Directory Agent. A DA does not generate Service information but only acts as a central cache of Service information. SAs periodically refresh Service information in DAs via XSRP, in order that UAs ask them for such information via unicast XSLP. When multiple DAs handle the same collection of Services, all DAs need to have the same information in order to provide the same view to UAs. In that case, DAs employ: XSTP to acquire Service information from other DAs, and XSSP to be subscribed to changes in other DA's Services in order to quickly apply those changes to its own Service cache. 2.1 Realm Model As SLP, XSDF employs the Scope mechanism to aggregate Services and Users in administrative groups. Therefore, User searches are restricted to Services from its own group. XSDF adds the "Domain" object to allow remote Service Discovery. A Realm is a combination of a domain (if any) and one or more Scopes. XSDF Agents must be configured with a Realm, although UAs may search for Services in other Realms, that is, from remote Domains. Each organization will define Scopes tailored to its needs. However, the XSDF Framework defines three default Scopes: DEFAULT: By default all Services belong to the "DEFAULT" Scope and have no Domain. This well-known Scope is useful for unmanaged networks. Urue±a & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSDF Overview March 2004 LOCAL: Services that belong to this Scope, are only meaningfully to the local server. For example managing Services as SNMP or SSH/ Telnet. PUBLIC: Public services from remote domains belong to the Realm with the specified DNS domain and a "PUBLIC" Scope. In order to simplify SA and UA implementation, DAs of the same Scope behave as a single repository, thus a Service can be registered in a single DA but be available by querying any other DAs of the same Scope. Please notice that, this description only applies to XSDF Agents in the same Scope. As a XSDF Agent may belong to several Scopes, it should handle each Scope as a separate environment. A XSLP +----+ XSRP +---------------> | DA | <---------------+ | +----+ | | B B | +----+ XSLP +----+ XSTP +----+ XSRP +----+ A,B,C | UA | ----> | DA | <----> | DA | <---- | SA | A,B,C +----+ +----+ XSSP +----+ +----+ | ^ | XSLP | +----------------------------------------+ For example, in the above figure, the SA has Services from 3 different Scopes (A, B, C). It should register Services from the first one at the single DA that manages that Scope. Services from Scope B could be registered at any of the two DAs which serve Scope B. Finally, SA should reply to direct UA requests from the last Scope as there is no DA managing that Scope. The same applies to XSLP queries from UAs. If an UA wants to fetch Services from all the Scopes, it will need to send unicast requests to DAs managing those Scopes and a Multicast request to query SAs from the unmanaged C Scope. Also, only the two DAs sharing the B Scope will employ XSTP/ XSSP to keep Service information in sync. 2.2 Service Model In SLP, a Service is defined by an URL and a set of attribute-value pairs. In Rserpool, Service information carries one or more transport protocol identifiers, that is, a port and one or more IP address per transport protocol, along with selection policy information. XSDF Service model mix both approaches with a single extensible representation. Service information is divided in four parts: Urue±a & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSDF Overview March 2004 Service Identifier: All Services are identified by a single UUID, which is unique inside a Domain. Service State: This refers to the volatile information about the Service that cannot be cached for long time. A good example of State information is the workload of the server. Also, Service State includes version information of other Service information. Service Main Information: This information defines the Type of the Service, its selection policy, and other important Service-dependent information. Service Location Information: In order to establish a connection with a network Service, clients need to known its attachment point to the network and the available protocols to access to the Service. Location information specifies data such as its IP addresses, transport ports and configured application protocols. Service Additional Information: While previous information allows automatic Service Discovery, the so called Additional Information contains data intended for human consumption as a textual description of the Service or the mail address of the Service administrator. When requesting Service information, an UA may specify which kind of information it is interested in. This allows automatic UAs to download just Service State, Main and Location Information to choose a Service, and later just check the State to see if Service information need to be updated. All without downloading the Additional information that may be quite long as it is very verbose for human consumption. 2.3 Cache Model In the XSDF Framework, Service information can be stored in multiple places. That information is generated and maintained by Service Agents and no other XSDF Agent but the home SA should modify Service Information. Thus, the only authoritative source of information about a Service instance is the home SA. Then, to improve network performance, that information may be cached by the other two XSDF Agents: UAs and DAs. Service Agents assigns a lifetime to its Service information. This lifetime specifies the amount of time that Service data is expected to remain valid. Therefore, Service information may be cached by UAs only until the lifetime period expires. A Directory Agent is just a central cache for Service information. Urue±a & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSDF Overview March 2004 When a SA registers a Service in the DA via XSRP, it specifies the expected Lifetime of that information. When an UA requests Service information to the DA via XSLP, DA reply also contains the Age an the Time To Live of that information. Age is the amount of time Service information has been cached in the DA before the reply was generated. Time To Live is the amount of time left that Service information can be cached in the client. That is, time to live equals the lifetime of the Service minus its DA cache age. Whenever a SA refresh Service information cached in the DA, age is set to zero and time to live is set to the specified lifetime value. Lifetime value configures the UA cache behavior. However, Service information cached in DAs may be flushed before its lifetime expires if not refreshed by the home SA. When a Service registration/update is acknowledged, DA specifies the "minLife" and "maxLife" values for next update. SAs should update Service information before "maxLife" time expires but after "minLife". This mechanism has been designed to avoid Service update storms from SAs to DAs. It also allows DAs to cache, for "maxLife" milliseconds, Service information with zero lifetime, that is, that should not be cached by UAs. lifetime +----+ age/ttl +----+ <-------- +----+ | UA | <-------- | DA | XSRP | SA | +----+ XSLP +----+ --------> +----+ min/maxLife XSSP subscriptions follow the same minLife-maxLife mechanism to "cache" subscription information. If a subscription is not refreshed before maxLife, that subscription is deleted and further notifications are not sent to subscription's notification channel. 2.4 Selection Model When an UA requests Service information via XSLP, it can found several Service instances that fit its needs. In that case, some kind of selection process should happen. For example, a list of all Services (for example printers) could be shown to the user who chooses one of them. For Services that allows automatic selection, XSDF provides a version of the selection model from Rserpool. Each Service Type may have an associated selection policy. Also, each Service instance may provide some kind of metric about the "goodness" of the Service. XSDF allows each Service Type to define its own selection policy and Urue±a & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSDF Overview March 2004 related metrics. But defines the following selection policies that must be supported by all XSDF implementations: Round Robin: This policy states that each time a client wants to access a Service, it chooses a different one. Services may have an associated "weight" information, thus Service instances with greater "weight" should be accessed proportionality more times than servers with lower "weight" values. Least Used: Services with this policy indicate that clients should access to servers with the lowest "workload" state value. Most Resources: Services with this policy tell clients that they should access to servers with the greatest "resources" state value. Closest: Services with this policy tell clients that they should access to servers with the lowest latency from its point of view. Of course, if the selected Service is offline or has zero "resources" left, clients should try the next discovered one, sorted by the selection policy in use. Along with the "weight", "workload" and "resources" values, XSDF defines a fourth selection metric that is applied to before other selection policies: "priority". When two Services of the same type have different "priority" value, clients should access to the Service with the greatest one. Only if the Service with the greatest priority is offline, clients are able to access the next Service with greater priority. When two or more Services have the same priority, one of them is chosen following the associated selection policy. Unlike ASAP, where selection process is always performed in the client side, in XSDF selection process could be done by the UA, the DA or both. SAs may include selection information inside the Service information in order that UAs choose the best discovered Service. Also SAs may specify in the XSRP Service registration, Selection information for the DA. In that case, DA sorts the registered Services from the same Type and, when an UA requests Service information, the DA may provide just the better Services. A SA may provide the first, second or both kinds of selection data, which also can be different. Urue±a & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSDF Overview March 2004 3. Applicability Statement XSDF could be deployed in a broad set of scenarios, from unmanaged LANs to big Enterprise Networks and even in Internet. As each network has its own requirements, each scenario will need to deploy all kind of XSDF agents and protocols or just a subset of them. 3.1 Unmanaged Networks The first scenario is a single LAN that has little or no server infrastructure (i.e. no DNS server), for example a SOHO were there are only only client stations, or home appliances. Scopes: DEFAULT DEFAULT DEFAULT +----+ +----+ +----+ | UA | | SA | ... | SA | +----+ +----+ +----+ | ^ ^ | XSLP | | +-------------+----------+ In this scenario, XSDF Service Discovery can be achieved just by deploying User Agents and Service Agents at the same "DEFAULT" scope. Then, XSLP protocol is employed to perform multicast/broadcast searches. If multiple Services are found, selection process will be performed by UAs. 3.2 Small Network The second scenario is a network with multiple LANs where multicast searches are too inefficient. In that case, a Directory Agent should be deployed. Therefore Service Agents should employ XSRP to register its Services in the DA. Scopes: A A A XSLP +----+ XSRP +----+ +-------> | DA | <---- | SA | +----+ +----+ +----+ | UA | +----+ +----+ +----+ +-------> | DA | <---- | SA | XSLP +----+ XSRP +----+ Scopes: B B B If the number of Services and Users is small, all XSDF agents may belong to the same Scope. Otherwise, multiple Scopes could be defined. Those Scopes could be managed by a single DA or by several ones but each DA only handles one Scope. As UAs ask DAs for Services, Urue±a & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSDF Overview March 2004 selection process could be done at the DA. Thus, DA may reply to the UA with the Service list ordered by server workload. 3.3 Enterprise Network The last scenario is an Enterprise network were there are many subgroups of Users and Services and also critical Services rely on XSDF Service Discovery. Therefore, both scalability and high availability of the XSDF Service is required. Scopes: AB AB AC AC +----+ XSLP +----+ XSTP +----+ XSRP +----+ | UA | ----> | DA | <----> | DA | <---- | SA | +----+ XSSP +----+ XSSP +----+ +----+ In an Enterprise network, there will be multiple Scopes, and Scopes with critical Services will be handled by two or more DAs. In that case all XSDF protocols will be deployed. XSTP and XSSP will allow DAs with common Scopes to share its Service information and provide a common view to UAs and SAs. Selection process could not only be done in the DAs, but also in the UAs in order to quickly react to server failures. 3.4 Internet XSDF can be also employed to advertise public Services in Internet. For example a pool of Web servers may employ XSDF to achieve load balancing. This could be done by deploying public available DAs managing the pool Services with "PUBLIC" Scope, and advertising such DAs in the DNS server of the organization. 1. SRV RR? +-----+ Server +------------------>| DNS | Pool | +-----+ +----+ | +----+| +----+ 2. XSLP +----+ XSTP +----+ XSRP +----+|+ | UA | -------> | DA | <----> | DA | <---- | SA |+ +----+ +----+ XSSP +----+ +----+ Scopes: PUBLIC PUBLIC PUBLIC In this scenario, an UA willing to contact a Service from the "example.com" Domain first will ask for the "_xslp._udp.example.com" DNS SRV Resource Record. This record will contain a list of the preferred public DAs. Then, the UA is able to ask, via XSLP, for the desired Service (i.e. www) in the "PUBLIC" Scope. At last, the DA will reply with the least-loaded, available servers. Urue±a & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSDF Overview March 2004 4. Security considerations XSDF security model is based on the Realm concept. Services and Users belong to Realms. Therefore an User (i.e. an UA) should access only to Service information from its own Realm. The same applies to other XSDF Agents, SAs should register Services only at DAs from compatible Realms. These authorization relationships are defined by each protocol. For example, an User from a Realm should access via XSLP to Service information from that Realm, however he must not be able to deregister those Services via XSRP. Some Scopes may be public, and any User from other domains may be able to obtain information via XSLP. However, others Scopes could be restricted and must require authorization in order to grant access. In that case, XSDF Agents should be authenticated in order to check their access rights. XSDF relies on IPSec and TLS to provide authenticated and secure protocol message exchange among XSDF Agents. However, XSDF has some security mechanisms that should be employed when not provided by lower layers (i.e. SCTP already provides a Cookie mechanism). 4.1 Cookie mechanism XSDF provides a simple Cookie mechanism to reduce the risk of Denial of Service (DoS) attacks. A XSDF server Agent may reject any request message without processing it with a reply error message that carries a Cookie value. In that case, the client should reissue the same message but including this Cookie value. Once a valid Cookie is received by the XSDF server, it may process the included operations. This mechanism does not prevent DoS attacks but made it harder to perform attacks with spoofed IP addresses. 4.2 EAP Authentication XSDF provides two kinds of authentication, first one is suitable for User authentication while the other one allows Server messages to be authenticated. Users may be authenticated employing EAP [2] messages. The process is very similar to the Cookie mechanism. When an unauthenticated user wishes to request a message from a restricted Scope, the XSDF server Agent may reject that message without processing it. The reply error message will carry an EAP request message, for example a MD5-Challenge. Then, the client will employ the requested authentication mechanism and return the EAP response along with the original XSDF requests. Urue±a & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSDF Overview March 2004 Once properly authorized, XSDF server Agent would perform the requested operations. 4.3 Public Key Signature The above mechanism may be suitable for, shared secret based, user authentication. However, in order to provide server message authentication (i.e. DA advertisement), public key signatures are a better mechanism. XSDF messages may contain a Signature Information Element. That element contains a digest of the message, encrypted with the XSDF Agent private key. Therefore, any XSDF Agent with the public key of the source one may check if the message is valid and has been generated by the claimed XSDF Agent. When XSDF is deployed in insecure environments, all User Agents must know (or obtain via other mechanisms) the public keys of the Directory Agents from its Realm, in order to validate DA Advertisements. Otherwise, is very easy to advertise a rogue DA and compromise the security of, not only XSDF, but other types of Services obtained via XSDF. For example, a rogue DA may carry out a DoS attack by answering to all XSLP request with an empty Service list. Even worse, it may reply with rogue Services that perform man-in-the-middle attacks to Users and real Services. 5. Acknowledgements The eXtensible Service Discovery Framework is an evolution of the one defined by the Service Location Protocol, and owes many of the ideas discussed at the Srvloc Working Group. Besides, XSDF tries to cover some of the requisites defined by the Rserpool Working Group, thus it has also benefited from their efforts. Therefore, we wish to thank all the RFC and draft authors from both communities, including Erik Guttman, Weibin Zhao, James Kempf, John Loughney, Maureen Stillman, Quiaobing Xie, Randall Stewart, Michael Tuexen, and many others. Urue±a & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSDF Overview March 2004 References [1] Guttman, E., Perkins, C., Veizades, J. and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [2] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [3] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [4] Tuexen, M., Xie, Q., Stewart, R., Shore, M., Ong, L., Loughney, J. and M. Stillman, "Requirements for Reliable Server Pooling", RFC 3237, January 2002. [5] Guttman, E., "The serviceid: URI Scheme for Service Location", draft-guttman-svrloc-serviceid-02 (work in progress), August 2002. [6] Mealling, M., "A UUID URN Namespace", draft-mealling-uuid-urn-03 (work in progress), March 2004. [7] Urue±a, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [8] Urue±a, M. and D. Larrabeiti, "eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures", draft-uruena-xsdf-common-00 (work in progress), March 2004. [9] Urue±a, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [10] Urue±a, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [11] Urue±a, M. and D. Larrabeiti, "eXtensible Service Subscription Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. [12] Urue±a, M. and D. Larrabeiti, "eXtensible Service Transfer Protocol (XSTP)", draft-uruena-xstp-00 (work in progress), March 2004. Urue±a & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSDF Overview March 2004 Authors' Addresses Manuel Urue±a Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 87 95 EMail: muruenya@it.uc3m.es David Larrabeiti Universidad Carlos III de Madrid Av. Universidad 30 Legan‰s, Madrid 28911 ES Phone: +34 91 624 99 53 EMail: dlarra@it.uc3m.es Urue±a & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSDF Overview March 2004 Appendix A. Example of a 'printer' Service A.1 XML Encoding 8e9d7823-d5ac-497c-91d0-fb07ea0c3fb2 f85444f4eb 0 printer Alice's printer Least Used (0x0002) 14 false true 169.254.85.139 fe80::202:b3ff:fe3c:da7a ipp tcp/631, sctp/631 lpr tcp/515, sctp/515 Acme Laser Printer 2000 http://www.acme.com/printers/lp200.html Urue±a & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSDF Overview March 2004 A.2 XBE32 Encoding 01000284 35110014 8e9d7823 d5ac497c ....5... ...#..I| 91d0fb07 ea0c3fb2 01100020 0111000f ......?. ... .... 331a000c 000000f8 5444f4eb 0311000c 3....... TD...... 32320008 00000000 0120006c 0121000f 22...... . .l.!.. 2812000b 7072696e 74657200 28140013 (...prin ter.(... 416c6963 65277320 7072696e 74657200 Alice's printer. 03210014 31330008 00020000 32350008 .!..13.. ....25.. 0000000d 10000018 20020009 636f6c6f ........ ...colo 72000000 30020005 00000000 10000018 r...0... ........ 2002000a 6475706c 65780000 30020005 ...dupl ex..0... ff000000 01300054 01310020 32150008 .....0.T .1. 2... a9fe558b 35160014 fe800000 00000000 ..U.5... ........ 0202b3ff fe3cda7a 01320018 28610007 .....>.z .2..(a.. 69707000 321a000c 00060277 00840277 ipp.2... ...w...w 01320018 28610007 6c707200 321a000c .2..(a.. lpr.2... 00060203 00840203 0140008c 2867001b ........ ....(g.. 41636d65 204c6173 65722050 72696e74 Acme Las er Print 65722032 30303000 2868002c 68747470 er 2000. (h.,http 3a2f2f77 77772eb1 636d652e 636f6d2f ://www.a cme.com/ 7072696e 74657273 2f6c7032 3030302e printers /lp2000. 68746d6c html Urue±a & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSDF Overview 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±a & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSDF Overview 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±a & Larrabeiti Expires September 15, 2004 [Page 20]