Network Working Group M. Urueħa Internet-Draft D. Larrabeiti Expires: September 15, 2004 UC3M March 17, 2004 eXtensible Service Discovery Framework (XSDF): Common Elements and Procedures 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 defines the common Attributes and Elements employed by the eXtensible Service Discovery Framework (XSDF) protocols. It defines the data elements employed to encode Service information, as well as the common procedures and operations for all XSDF protocols. For example it includes the XSDF Agent initialization process, and details the rules for the creation, transmission, reception and processing of XSDF protocols' messages. Urueħa & Larrabeiti Expires September 15, 2004 [Page 1] Internet-Draft XSDF: Common Elements & Procedures March 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Notation Conventions . . . . . . . . . . . . . . . . . . . 5 2. User Element . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1 Description Element . . . . . . . . . . . . . . . . . . . 6 3. Service Element . . . . . . . . . . . . . . . . . . . . . . . 8 3.1 Service State Element . . . . . . . . . . . . . . . . . . 8 3.1.1 Meta-Information Element . . . . . . . . . . . . . . . 9 3.1.2 Selection State Element . . . . . . . . . . . . . . . 10 3.2 Service Main Information Element . . . . . . . . . . . . . 11 3.2.1 Service Type Element . . . . . . . . . . . . . . . . . 12 3.2.2 Selection Information Element . . . . . . . . . . . . 13 3.3 Service Location Information Element . . . . . . . . . . . 15 3.3.1 Inet Element . . . . . . . . . . . . . . . . . . . . . 15 3.3.2 Protocol Element . . . . . . . . . . . . . . . . . . . 17 3.4 Service Additional Information Element . . . . . . . . . . 18 3.4.1 Icon Element . . . . . . . . . . . . . . . . . . . . . 20 3.4.2 Naming Authority Element . . . . . . . . . . . . . . . 21 4. Messages Format . . . . . . . . . . . . . . . . . . . . . . . 22 4.1 Header Element . . . . . . . . . . . . . . . . . . . . . . 22 4.1.1 Realm Element . . . . . . . . . . . . . . . . . . . . 23 4.1.2 Endpoint Element . . . . . . . . . . . . . . . . . . . 25 4.1.3 Authentication Information Element . . . . . . . . . . 25 4.2 Error Element . . . . . . . . . . . . . . . . . . . . . . 26 4.3 Ignore Message Element . . . . . . . . . . . . . . . . . . 28 4.4 Signature Information Element . . . . . . . . . . . . . . 28 4.5 Common Operation Parameters . . . . . . . . . . . . . . . 30 4.5.1 Realm Target Element . . . . . . . . . . . . . . . . . 30 4.5.2 Services Filter Element . . . . . . . . . . . . . . . 30 4.5.3 Update Information Element . . . . . . . . . . . . . . 31 4.5.4 Cache State Element . . . . . . . . . . . . . . . . . 32 5. Common Procedures . . . . . . . . . . . . . . . . . . . . . . 33 5.1 XSDF Agent initialization . . . . . . . . . . . . . . . . 33 5.2 Message generation . . . . . . . . . . . . . . . . . . . . 34 5.2.1 Creating new messages . . . . . . . . . . . . . . . . 34 5.2.2 Replying to Request messages . . . . . . . . . . . . . 36 5.3 Message transmission . . . . . . . . . . . . . . . . . . . 36 5.3.1 Message transport over TCP/SCTP . . . . . . . . . . . 37 5.3.2 Message transport over unicast UDP . . . . . . . . . . 37 5.3.3 Message transport over multicast UDP . . . . . . . . . 38 5.4 Message reception . . . . . . . . . . . . . . . . . . . . 40 5.4.1 Ignore Message Operation . . . . . . . . . . . . . . . 42 Urueħa & Larrabeiti Expires September 15, 2004 [Page 2] Internet-Draft XSDF: Common Elements & Procedures March 2004 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 References . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 44 A. XSDF Constants . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1 XBE32 Attributes & Elements . . . . . . . . . . . . . . . 45 A.2 Timers and Constants . . . . . . . . . . . . . . . . . . . 47 Intellectual Property and Copyright Statements . . . . . . . . 48 Urueħa & Larrabeiti Expires September 15, 2004 [Page 3] Internet-Draft XSDF: Common Elements & Procedures March 2004 1. Introduction XSDF stands for eXtensible Service Discovery Framework. It defines an architecture with several entities and protocols for the management and location of Service information [12]. All XSDF protocols follow the Client-Server paradigm. One XSDF Agent acts as client, sending request operations, while the peer XSDF Agent acts as a server, processing those operations and sending replies back. Additionally, some protocols allow XSDF Agents to send unsolicited messages. XSDF operations can be classified in four groups: Requests: These operations are employed when a client XSDF Agent asks a server one for some information, as "get public Services from remote 'xyz' Domain" or to perform some action. For example: "Register a Service at local 'xyz' Scope". Replies: These operations are responses to previous request ones. They are sent by the server to the client and carry: the requested data or an acknowledge, as "Service has been successfully registered". Errors: These are reply operations returned by the server because a client has sent an invalid request. For example if someone tries to update an unknown Service. Advertisements: These operations are generated by a XSDF Agent asynchronously, without being requested by a client. Examples are XSLP Service Advertisements [13] or XSTP Service Notifications [16]. By definition, a XSDF Agent acting as a server (i.e. a DA or a SA) is itself a Service. Therefore, they should have its own Service information, in particular a Service Id. Client XSDF Agents may be also Services, though. First part of this document defines common Elements and Attributes of XSDF messages. Second part specifies the operational procedures shared by all XSDF protocols. 1.1 Definitions Domain: A Domain is a single administrative organization containing Users and Services. Urueħa & Larrabeiti Expires September 15, 2004 [Page 4] Internet-Draft XSDF: Common Elements & Procedures March 2004 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. Depending on the protocol a XSDF Agent may behave as a client or as a server (i.e. becoming itself a Service). 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ħa & Larrabeiti Expires September 15, 2004 [Page 5] Internet-Draft XSDF: Common Elements & Procedures March 2004 2. User Element This Element contains information about a XSDF User. Users, as Services, belong to a single Realm, that is, a Domain and one or more Scopes from that Domain. User Element: Element Name : user XBE32 Type : 0x0600 +---------------------------------------------------------------+ | [ Name ] | +---------------------------------------------------------------+ | [ URL #1 ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ URL #N ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ Name Attribute: Attribute Name : name XBE32 Type : 0x2861 Value Type : string Value Length : variable This Attribute contains the login name of the XSDF User. Users are identified by name, thus an User name MUST be unique inside its Domain. To obtain a globally unique name, User name MAY be appended with a "@" followed by the Domain she belongs to. URL Attribute: Attribute Name : url XBE32 Type : 0x2862 Value Type : string Value Length : variable This Attribute contain an URL pointing to additional information about this User, as her mail address or a web page. 2.1 Description Element This Element contains human readable text with additional information about the Element that contains it. As a Description Element contains text in a single language, multiple Description Elements MAY be Urueħa & Larrabeiti Expires September 15, 2004 [Page 6] Internet-Draft XSDF: Common Elements & Procedures March 2004 included with the same information in multiple languages. Description Element: Element Name : desc XBE32 Type : 0x0610 +---------------------------------------------------------------+ | Text | +---------------------------------------------------------------+ | [ Language = "en" ] | +---------------------------------------------------------------+ Text Attribute: Attribute Name : text XBE32 Type : 0x2863 Value Type : string Value Length : variable This Attribute contains the actual human-readable description text. Language Attribute: Attribute Name : lang XBE32 Type : 0x2864 Value Type : string Value Length : variable This Attribute specifies which language is employed in the previous "text" field. Languages MUST be encoded as defined in [9]. The default value of this Attribute is "en". Urueħa & Larrabeiti Expires September 15, 2004 [Page 7] Internet-Draft XSDF: Common Elements & Procedures March 2004 3. Service Element This is the most important Element of the XSDF messages, as it contains all the information about a Service. That information includes: instance identifier, its Service Type, its network location, the protocols that could be employed to access it, its state, additional human-readable data, etc. Service Element: Element Name : service XBE32 Type : 0x0100 +---------------------------------------------------------------+ | Service Identifier | +---------------------------------------------------------------+ : [ Service State Element ] : +---------------------------------------------------------------+ : [ Service Main Info Element ] : +---------------------------------------------------------------+ : [ Service Location Info Element ] : +---------------------------------------------------------------+ : [ Service Additional Info Element ] : +---------------------------------------------------------------+ Service Identifier Attribute: Attribute Name : id XBE32 Type : 0x3511 Value Type : opaque16 Value Length : 128 bits This mandatory Attribute contains a single 16 octet value that uniquely identifies this Service instance. The following Service identifiers are reserved by the IETF and SHOULD NOT be employed to identify any Service: Reserved Values Description ------------------------------------ ------------------ 00000000-0000-0000-0000-000000000000 Unknown XSDF Agent ffffffff-ffff-ffff-ffff-ffffffffffff All XSDF Agents 3.1 Service State Element This Element contains all the volatile information of a Service. Urueħa & Larrabeiti Expires September 15, 2004 [Page 8] Internet-Draft XSDF: Common Elements & Procedures March 2004 Service State Element: Element Name : serviceState XBE32 Type : 0x0110 +---------------------------------------------------------------+ : Meta-Information Element : +---------------------------------------------------------------+ : [ Selection State Element ] : +---------------------------------------------------------------+ 3.1.1 Meta-Information Element This Element contains the version information about all the Service information Elements, including Service State itself. By comparing two "metaInfo" Elements from the same Service, a XSDF Agent is able to know which Service information is newer and which Service Elements have been modified. Meta-Information Element: Element Name : metaInfo XBE32 Type : 0x0111 +---------------------------------------------------------------+ | State Timestamp | +---------------------------------------------------------------+ | [ Main Info Sequence Number = 0 ] | +---------------------------------------------------------------+ | [ Location Info Sequence Number = 0 ] | +---------------------------------------------------------------+ | [ Additional Info Sequence Number = 0 ] | +---------------------------------------------------------------+ State Timestamp Attribute: Attribute Name : stateTimestamp XBE32 Type : 0x331a Value Type : int64 Value Length : 64 bits This is the timestamp when Service State Element was generated. This timestamp could be obtained from a real clock or a logical one. The only requisite is that a newer state MUST have a greater timestamp value than an old one. Urueħa & Larrabeiti Expires September 15, 2004 [Page 9] Internet-Draft XSDF: Common Elements & Procedures March 2004 Main Info Sequence Number Attribute: Attribute Name : mainInfoSeqNum XBE32 Type : 0x321b Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceMainInfo" Element. Default value is "0", meaning initial version. Location Info Sequence Number Attribute: Attribute Name : locationInfoSeqNum XBE32 Type : 0x321c Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceLocationInfo" Element. Default value is "0", meaning initial version. Additional Info Sequence Number Attribute: Attribute Name : addInfoSeqNum XBE32 Type : 0x321d Value Type : int32 Value Length : 32 bits Whenever a Service information Element is modified, its associated counter MUST be increased by one. This Attribute contains the sequence value associated to current "serviceAddInfo" Element. Default value is "0", meaning initial version. 3.1.2 Selection State Element This Element contains all the volatile information required by a selection algorithm (i.e. Least Used/Most Resources) to evaluate the "goodness" of the associated Service. In order to perform an accurate selection, these values SHOULD have been recently measured. Selection State Element: Element Name : selectState XBE32 Type : 0x0311 +---------------------------------------------------------------+ | [ Resources ] | +---------------------------------------------------------------+ | [ Workload ] | Urueħa & Larrabeiti Expires September 15, 2004 [Page 10] Internet-Draft XSDF: Common Elements & Procedures March 2004 +---------------------------------------------------------------+ Resources Attribute: Attribute Name : resources XBE32 Type : 0x3231 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the number of resources available to the users of this Service. It MUST be a non-negative value. "Most Resources" Selection policy chooses the Service with the greatest "resources" value. Services with a zero "resources" value are temporary unavailable, no matter which Selection policy is in use, and SHOULD NOT be accessed by Users. Workload Attribute: Attribute Name : workload XBE32 Type : 0x3232 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the number of resources consumed by current users accessing to the associated Service. It MUST be a non-negative value. Lower the value, greater the capacity to be allocated to new users. "Least Used" selection policy prefers Services with lower workload. Each Service MAY define its own workload metric. By default, the workload of a Service equals to the workload of the server where Service is executing. 3.2 Service Main Information Element This Element specifies the Type of this Service instance. It MAY also contain a human-readable name for this Service, along with the Selection policy that SHOULD be employed to choose between Services with the same Type. Service Main Information Element: Element Name : serviceMainInfo XBE32 Type : 0x0120 +---------------------------------------------------------------+ : Service Type Element : +---------------------------------------------------------------+ | [ Alias ] | +---------------------------------------------------------------+ : [ Selection Information Element ] : +---------------------------------------------------------------+ Urueħa & Larrabeiti Expires September 15, 2004 [Page 11] Internet-Draft XSDF: Common Elements & Procedures March 2004 Alias Attribute: Attribute Name : alias XBE32 Type : 0x2814 Value Type : string Value Length : variable This optional Attribute ease human selection of Services by naming a Service with an name better than with its numeric id. 3.2.1 Service Type Element This Element identifies the Type of this Service instance. If a Service could be distributed among several servers, this Element also identifies which parts of such Service are provided by this instance. Service Type Element: Element Name : serviceType XBE32 Type : 0x0121 +---------------------------------------------------------------+ | Type | +---------------------------------------------------------------+ | [ Path #1 = "/" ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ Path #N ] | +---------------------------------------------------------------+ Type Attribute: Attribute Name : type XBE32 Type : 0x2812 Value Type : string Value Length : variable This Attribute identifies which kind of Service is provided by this server. Examples of Service types could be "printer" or "xsdf:da". Path Attribute: Attribute Name : path XBE32 Type : 0x2813 Value Type : string Value Length : variable If this Service Type could provide resources arranged in some kind of hierarchical structure (i.e. a file server), these Attributes specify which branches of the resource tree are provided by this particular Service instance. The default value for this field is "/", that is, the root of resource tree. Urueħa & Larrabeiti Expires September 15, 2004 [Page 12] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.2.2 Selection Information Element This Element contains all the pseudo-static information required by a selection algorithm to evaluate the "goodness" of the associated Service. Selection Information Element: Element Name : selectInfo XBE32 Type : 0x0321 +---------------------------------------------------------------+ | Policies | +---------------------------------------------------------------+ | [ Priority = 0 ] | +---------------------------------------------------------------+ | [ Weight ] | +---------------------------------------------------------------+ Policies Attribute: Attribute Name : policies XBE32 Type : 0x3133 Value Type : opaque2 Value Length : variable This Attribute contains a list of Selection policies that may be applied to choose between Services with the same Type as the associated one. If multiple Selection policies are specified, they MUST be sorted by preference. Policies with greater preference MUST be placed at the beginning. Selection algorithms defined in this document are: Value Selection Policy ------ -------------------- 0x0000 None 0x0001 Round Robin 0x0002 Least Used 0x0003 Most Resources 0x0004 Closest Each Service Type MAY define its own Selection Policy and related metric Attributes. However, all XSDF implementations MUST support the following selection policies: None This value does not specifies any selection algorithm but tells that all Services SHOULD be returned. Urueħa & Larrabeiti Expires September 15, 2004 [Page 13] Internet-Draft XSDF: Common Elements & Procedures March 2004 Round Robin Service selection probability SHOULD be distributed among all Services proportionally to its "weight" value. Thus, Service instances with greater "weight" SHOULD be accessed proportionality more times than servers with lower "weight" values. Least Used Selection process SHOULD choose the Service with the lowest "workload" Service State Attribute. As this value may change continuously, XSDF Agents SHOULD obtain/refresh it if stalled. Most Resources Selection process SHOULD choose the Service with the greatest "resurces" Service State Attribute. As the "Least Used" policy, if greatest "resources" value is shared by several Services, next Selection policy (or Round Robin, if none is specified) SHOULD be used to choose the best one among them. As "workload" attribute, "resorces" value SHOULD be refreshed if Service information have been stalled (i.e. has zero ttl). Closest This Selection policy does not have any associated metric attribute, but Selection process SHOULD choose the server with lower latency from its point of view. This document does not define how to measure such "latency". Priority Attribute: Attribute Name : priority XBE32 Type : 0x3234 Value Type : int32 Value Length : 32 bits This optional Attribute contains the priority of this Service instance. Selection algorithm SHOULD always choose among services with the greatest priority (note that priority value MAY be negative). This selection mechanism is useful to deploy services with an active/backup access policy. The default value for this field is 0. Weight Attribute: Attribute Name : weight XBE32 Type : 0x3235 Value Type : int32 Value Length : 32 bits This optional Attribute specifies the relative performance of this service instance compared to other services of the same Type. It MUST be a positive value. This field is employed by the Round Robin mechanism (a.k.a. Weighted Round Robin) in order to load balance among several servers with different processing power. Services with Urueħa & Larrabeiti Expires September 15, 2004 [Page 14] Internet-Draft XSDF: Common Elements & Procedures March 2004 an unspecified "weight" value SHOULD have the same value as the lowest specified one. 3.3 Service Location Information Element This Element contains all the information required to contact with the process running at the specified Server, which provides the associated Service. Service Location Information Element: Element Name : serviceLocationInfo XBE32 Type : 0x0130 +---------------------------------------------------------------+ : Inet Element : +---------------------------------------------------------------+ : Protocol Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : Protocol Element #N : +---------------------------------------------------------------+ 3.3.1 Inet Element This Element contains the network location of the Server, as well as additional capabilities of the network layer. This document only specifies IP related information. XSDF MAY be extended to support other network technologies. Inet Element: Element Name : inet XBE32 Type : 0x0131 +---------------------------------------------------------------+ | [ IPv4 Addresses ] | +---------------------------------------------------------------+ | [ IPv6 Addresses ] | +---------------------------------------------------------------+ | [ Hostname #1 ] | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | [ Hostname #N ] | +---------------------------------------------------------------+ | [ Capabilities16 ] | +---------------------------------------------------------------+ Urueħa & Larrabeiti Expires September 15, 2004 [Page 15] Internet-Draft XSDF: Common Elements & Procedures March 2004 IPv4 Addresses Attribute: Attribute Name : ipv4Addrs XBE32 Type : 0x3215 Value Type : opaque4 Value Length : variable This Attribute contains the list of IPv4 addresses of the Server providing this Service. IPv6 Addresses Attribute: Attribute Name : ipv6Addrs XBE32 Type : 0x3516 Value Type : opaque16 Value Length : variable This Attribute contains the list of IPv6 addresses of the Server providing this Service. Hostname Attribute: Attribute Name : hostname XBE32 Type : 0x2817 Value Type : string Value Length : variable This Attribute contains the DNS name of the Server providing this Service. If no domain name is present, but just the Server hostname (i.e. no dots), the fully qualified name can be obtained by appending the Domain that this Service belongs to. Capabilities16 Attribute: Attribute Name : capabilities16 XBE32 Type : 0x3118 Value Type : opaque2 Value Length : variable This optional Attribute contains the list of additional capabilities of the IP stack of the Server providing this Service, which are currently enabled. Capabilities are encoded as 2 octet values (See IANA Assigned Protocol Numbers): Value Inet Capability ------ --------------- 0x3200 Encap Security Payload for IPv6 [RFC2402] 0x3300 Authentication Header for IPv6 [RFC2406] Urueħa & Larrabeiti Expires September 15, 2004 [Page 16] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.3.2 Protocol Element This Element identifies a protocol that could be employed to access this Service. It includes transport port numbers and additional protocol capabilities. Protocol Element: Element Name : protocol XBE32 Type : 0x0132 +---------------------------------------------------------------+ | Name | +---------------------------------------------------------------+ | Transport Protocols & Ports | +---------------------------------------------------------------+ | [ Capabilities16 ] | +---------------------------------------------------------------+ Capabilities16 Attribute is defined in Section 3.3.1. Name Attribute is defined in Section 2 Protocols are identified by its name, for example "pop3". Protocol name is carried as a string inside the Protocol's Name Attribute. Transport Protocols & Ports Attribute: Attribute Name : transPorts XBE32 Type : 0x321a Value Type : opaque4 Value Length : variable This Attribute contains a list of the preferred port numbers (and its Transport Protocol) where Service process is listening for requests. Last 2 octets encode the port number, while first 2 octets encode the Transport Protocol (See IANA Assigned Protocol Numbers): Value Transport Protocol ------ ------------------------------------------- 0x0006 Transmission Control Protocol (TCP) [RFC793] 0x0011 User Datagram Protocol (UDP) [RFC768] 0x0084 Stream Control Transmission Protocol (SCTP) [RFC2960] The Capabilites16 is an optional Attribute that contains the list of additional capabilities of this protocol. Capabilities are encoded as 2 octet values and each protocol MAY define the values for its own Capabilities set. XBE32 based protocols MAY advertise additional operations, by including its Operation Element TLV 2 octet Type as a capability. Urueħa & Larrabeiti Expires September 15, 2004 [Page 17] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.4 Service Additional Information Element This Element contains additional management information about the Service. Service Additional Information Element: Element Name : serviceAddInfo XBE32 Type : 0x0140 +---------------------------------------------------------------+ | [ Vendor ] | +---------------------------------------------------------------+ | [ VendorURL ] | +---------------------------------------------------------------+ | [ Model ] | +---------------------------------------------------------------+ | [ ModelURL ] | +---------------------------------------------------------------+ | [ Version ] | +---------------------------------------------------------------+ | [ URL ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ : [ Icon Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Icon Element #N ] : +---------------------------------------------------------------+ : [ Operator Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Operator Element #N ] : +---------------------------------------------------------------+ : [ Naming Authority Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Naming Authority Element #N ] : +---------------------------------------------------------------+ User, Description Elements and URL Attribute are defined in Section 2. Vendor Attribute: Attribute Name : vendor XBE32 Type : 0x2865 Value Type : string Value Length : variable Urueħa & Larrabeiti Expires September 15, 2004 [Page 18] Internet-Draft XSDF: Common Elements & Procedures March 2004 This optional Attribute defines the vendor of this Service. Vendor URL Attribute: Attribute Name : vendorURL XBE32 Type : 0x2866 Value Type : string Value Length : variable This optional Attribute contains an URL pointing to more information about this Service's vendor. Model Attribute: Attribute Name : model XBE32 Type : 0x2867 Value Type : string Value Length : variable This optional Attribute defines the name of the HW/SW model providing this Service. Model URL Attribute: Attribute Name : modelURL XBE32 Type : 0x2868 Value Type : string Value Length : variable This optional Attribute contains an URL pointing to more information about this model. Version Attribute: Attribute Name : version XBE32 Type : 0x2869 Value Type : string Value Length : variable This optional Attribute contains the version info of the model that provides this Service. The URL Attribute contains an URL pointing to additional information about this Service. The Description Element contains some textual information about this Service. The Operator Element is an User Element which contains some information about the User responsible of this Service. Urueħa & Larrabeiti Expires September 15, 2004 [Page 19] Internet-Draft XSDF: Common Elements & Procedures March 2004 3.4.1 Icon Element This Element contains graphical information about a Service. The only mandatory data is an URL pointing to the image file. Icon Element: Element Name : icon XBE32 Type : 0x0620 +---------------------------------------------------------------+ | URL | +---------------------------------------------------------------+ | [ mimeType ] | +---------------------------------------------------------------+ | [ width ] | +---------------------------------------------------------------+ | [ height ] | +---------------------------------------------------------------+ | [ depth ] | +---------------------------------------------------------------+ URL Attribute is defined in Section 2. MIME Type Attribute: Attribute Name : mimeType XBE32 Type : 0x286a Value Type : string Value Length : variable This optional Attribute defines which is the MIME Type of the image file pointed by the icon URL. For example "image/png". Width Attribute: Attribute Name : width XBE32 Type : 0x326b Value Type : int32 Value Length : 32 bits This optional Attribute defines the width, in pixels, of the above image. Height Attribute: Attribute Name : height XBE32 Type : 0x326c Value Type : int32 Value Length : 32 bits This optional Attribute defines the height, in pixels, of the above Urueħa & Larrabeiti Expires September 15, 2004 [Page 20] Internet-Draft XSDF: Common Elements & Procedures March 2004 image. Depth Attribute: Attribute Name : depth XBE32 Type : 0x326d Value Type : int32 Value Length : 32 bits This optional Attribute defines the pixel's color depth of the above image. 3.4.2 Naming Authority Element This Element allows Service Agents to include vendor specific Service information. Such Elements and Attributes are named with a vendor prefix followed by a colon (":"). This Element points to the template describing those additional Elements and Attributes. Naming Authority Element: Element Name : namingAuth XBE32 Type : 0x0710 +---------------------------------------------------------------+ | Prefix | +---------------------------------------------------------------+ | Template | +---------------------------------------------------------------+ Prefix Attribute: Attribute Name : prefix XBE32 Type : 0x2873 Value Type : string Value Length : variable This Attribute contains the name prefix (without colon) for the Attributes and Elements defined by this Naming Authority (i.e. "acme"). Template Attribute: Attribute Name : template XBE32 Type : 0x2874 Value Type : string Value Length : variable This Attribute carries an URL pointing to the template which defines the additional elements employed in this Service information. Urueħa & Larrabeiti Expires September 15, 2004 [Page 21] Internet-Draft XSDF: Common Elements & Procedures March 2004 4. Messages Format All XSDF messages are encoded inside a single XBE32 Element. This Element's Type identifies the protocol version. All XSDFv1 protocols share the same message format: a Header Element followed by one or more protocol operation Elements. XSDF Message Element: +---------------------------------------------------------------+ : Header Element : +---------------------------------------------------------------+ : XSDF Operation Element #1 : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : XSDF Operation Element #N : +---------------------------------------------------------------+ : [ Signature Information Element ] : +---------------------------------------------------------------+ 4.1 Header Element This Element defines the common header for all XSDF messages. It identifies both peers of a XSDF transaction. When replying to a message, Source and Destination Elements are interchanged. Header Element: Element Name : header XBE32 Type : 0x0810 +---------------------------------------------------------------+ | Transaction Identifier | +---------------------------------------------------------------+ : Realm Element : +---------------------------------------------------------------+ : Source Endpoint Element : +---------------------------------------------------------------+ : Destination Endpoint Element : +---------------------------------------------------------------+ : [ Authentication Information Element ] : +---------------------------------------------------------------+ Urueħa & Larrabeiti Expires September 15, 2004 [Page 22] Internet-Draft XSDF: Common Elements & Procedures March 2004 Transaction Identifier Attribute: Attribute Name : xid XBE32 Type : 0x3281 Value Type : opaque4 Value Length : variable This Attribute contains an unique identifier for this XSDF transaction. It is randomly generated by the client XSDF Agent and returned in the response message by the server one. This field allows clients to correlate outstanding requests with its responses. It MAY be employed by the server to quickly reply to retransmissions. Source Endpoint Element: Element Name : source XBE32 Type : 0x0811 This Attribute identifies the XSDF Agent (UA, SA or DA) and/or User that has generated this message. Source Service Id value MUST NOT be a reserved one (i.e. "Unknown XSDF Agent" or "All XSDF Agents"). In that case, message MUST be silently dropped. Destination Endpoint Element: Element Name : destination XBE32 Type : 0x0812 This Attribute identifies the XSDF Agent (UA, SA or DA) and/or User that this message is sent to. A XSDF agent MUST check that the destination service id of any received XSDF message equals: its own id, the "Unknown XSDF Agent" id, or the "All XSDF Agents" id. Otherwise, it SHOULD skip this message and return an UNKNOWN_SERVICE_ID error. 4.1.1 Realm Element The Realm Element identifies the Domain and Scopes that XSDF operations should be applied at. A XSDF agent MUST check that the specified Realm, from the received XSDF message is compatible with its own Realm. Otherwise it SHOULD drop this message and return an UNKNOWN_REALM error. Urueħa & Larrabeiti Expires September 15, 2004 [Page 23] Internet-Draft XSDF: Common Elements & Procedures March 2004 Realm Element: Element Name : realm XBE32 Type : 0x0700 +---------------------------------------------------------------+ | [ Domain ] | +---------------------------------------------------------------+ | Scope #1 | +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ | Scope #N | +---------------------------------------------------------------+ Domain Attribute: Attribute Name : domain XBE32 Type : 0x2871 Value Type : string Value Length : variable This Attribute contains a hierarchical identifier of the organization providing one or more Services. Employing a DNS full qualified Domain name allows UAs to found remote DAs by DNS queries. Organizations MAY advertise its public DAs encoded in DNS SRV Resource Records. See XSLP [13] for details. Scope Attribute: Attribute Name : scope XBE32 Type : 0x2872 Value Type : string Value Length : variable This Attribute contains the name of the Scope, that belongs to the specified Domain, if any. Scope namespace is flat and allow organizations to aggregate Users and Services in different administrative groups. This document defines the following Scopes: DEFAULT: XSDF Agents that are not configured with a Realm belong to the "DEFAULT" Scope and have no domain. LOCAL: This Scope is reserved to Services referred to the server itself. Services from this Scope MUST NOT belong to any other Scope. DAs MUST NOT manage Services from this Scope. Thus, SAs MUST NOT register them. Multicast requests MUST NOT refer to the "LOCAL" Scope. SAs and DAs SHOULD reply just to unicast queries of Services from this Scope. Urueħa & Larrabeiti Expires September 15, 2004 [Page 24] Internet-Draft XSDF: Common Elements & Procedures March 2004 PUBLIC: Public services from remote Domains MUST belong to the the Realm with the specified Domain and a "PUBLIC" Scope. 4.1.2 Endpoint Element This Element identifies one of the peers of a XSDF transaction. Endpoint Element: +---------------------------------------------------------------+ : [ Service Element ] : +---------------------------------------------------------------+ : [ User Element ] : +---------------------------------------------------------------+ Service Element is defined in Section 3. User Element is specified in Section 2 Service Element identifies the source/destination XSDF Agent of this message. However, it MAY not appear as UAs are not required to have associated Service information. Service Element MUST contain the Service Identifier, and MAY also include its Service State. Other Service information is optional and SHOULD NOT appear. User Element contains information about the User responsible of the source/destination XSDF Agent. This field MAY identify the public key employed to sign this message. See Section 4.4 for details. 4.1.3 Authentication Information Element This optional Element MAY be employed by XSDF Agents to provide some security when lower layers do not provide such mechanisms. Authentication Information Element: Element Name : authInfo XBE32 Type : 0x0813 +---------------------------------------------------------------+ | [ Cookie ] | +---------------------------------------------------------------+ | [ EAP Information ] | +---------------------------------------------------------------+ Urueħa & Larrabeiti Expires September 15, 2004 [Page 25] Internet-Draft XSDF: Common Elements & Procedures March 2004 Cookie Attribute: Attribute Name : cookie XBE32 Type : 0x2184 Value Type : opaque Value Length : variable This Attribute contains an opaque binary value. XSDF Server Agents MAY reject a Request message and set a Cookie. The client MUST reissue the Request message including this value in the Header's Authentication Information. EAP Information Attribute: Attribute Name : eapInfo XBE32 Type : 0x2185 Value Type : opaque Value Length : variable This Element contains an EAP packet as defined in [5]. An XSDF Server Agent MAY reject a Request message due Scope Authorization issues. In that case, it will generate an EAP-Request and sent it back to the client. Then, the client will generate a new XSDF message with the EAP-Response value. 4.2 Error Element Each XSDF protocol defines its own set of errors associated with its protocol operations. However, all kinds of XSDF protocol errors are encoded using the same Error Element format. Also, there are some common errors that MAY appear at all XSDF protocols. This section specifies both, the XSDF Error Element and the list of common XSDF errors. Error Element: Element Name : error XBE32 Type : 0x08F1 +---------------------------------------------------------------+ | Code | +---------------------------------------------------------------+ | [ Name ] | +---------------------------------------------------------------+ : [ Description Element #1 ] : +¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸¸+ : [ Description Element #N ] : +---------------------------------------------------------------+ Description Element is specified in Section 2.1. Urueħa & Larrabeiti Expires September 15, 2004 [Page 26] Internet-Draft XSDF: Common Elements & Procedures March 2004 Code Attribute: Attribute Name : code XBE32 Type : 0x3283 Value Type : opaque4 Value Length : 32 bits This Attribute contains the code number of this kind of error. Name Attribute: Attribute Name : name XBE32 Type : 0x2861 Value Type : string Value Length : variable This Attribute is optional, and contains the name of this kind of error. The Description Elements contain a full description of this error. Multiple descriptions are allowed to carry error messages in several languages. This is the list of all the common XSDF errors: Error Code Error Name Cause ---------- --------------------- ----------------------------------- 0x00000001 XBE32_ERROR Invalid XBE32 encoded message 0x00000002 UNKNOWN_XBE32_ELEMENT Unknown XBE32 Element found 0x00000003 PARSING_ERROR Invalid XSDF message 0x00000004 OVERFLOW_ERROR Message size limit reached 0x00000005 UNKNOWN_REALM Incompatible Header's Realm 0x00000006 UNKNOWN_SERVICE_ID Incompatible Header's Destination 0x00000007 AUTHENTICATION_ERROR Authentication required 0x00000008 BUSY_NOW_ERROR Server is busy with other requests, retry later 0x00000009 INTERNAL_ERROR Other errors An Error Element MAY carry additional Elements and Attributes with relevant information in order to pinpoint the cause of the error. XSDF implementations MUST be able to receive messages containing XBE32 Elements not defined neither here nor in companion documents. In that case, it MUST follow the rules specified in XBE32 [11] to notify an unknown Element inside an UNKNOWN_XBE32_ERROR Error. This Element SHOULD contain the Ids and/or the Names of unknown XBE32 Errors found. Such data is encoded inside the Element Id and Element Name TLVs defined in XBE32 [11]. UNKNOWN_REALM Error Element SHOULD contain the incompatible Realm Urueħa & Larrabeiti Expires September 15, 2004 [Page 27] Internet-Draft XSDF: Common Elements & Procedures March 2004 Element of the received request message's Header. The reply message's Header itself SHOULD contain an empty Realm. UNKNOWN_SERVICE_ID Error SHOULD contain the Service Element from the received request message's Destination Endpoint. That Service Element MUST contain the unknown Id. Other Service information is optional and SHOULD NOT appear. AUTHENTICATION_ERROR Error Element SHOULD contain a Cookie Attribute, an Authorization Information Element or both. See Section 5 for a description of the procedures involving this Error. 4.3 Ignore Message Element This operation MAY be employed by XSDF Agents to prevent other ones to process the message that includes it. Any XSDF Agent MUST check if its id is listed in the "serviceIds" attribute. In that case it SHOULD stop processing this message. Ignore Message Element: Element Name : ignoreMessage XBE32 Type : 0x0830 +---------------------------------------------------------------+ | Service Ids | +---------------------------------------------------------------+ Service Ids Attribute: Attribute Name : serviceIds XBE32 Type : 0x3582 Value Type : opaque16 Value Length : variable This Attribute contains a list of Service Identifiers. They identify XSDF Agents that MUST avoid processing this message. 4.4 Signature Information Element This Element MAY be included in XSDF messages to provide both message integrity and source authentication. Source endpoint signs with its public key the digest value of the whole message but the Signature Value Attribute. Keys are assigned to User names. In order to identify which key has been employed to sign this message, Source Endpoint Element MUST include an User Element. Urueħa & Larrabeiti Expires September 15, 2004 [Page 28] Internet-Draft XSDF: Common Elements & Procedures March 2004 Signature Information Element: Element Name : signatureInfo XBE32 Type : 0x08e1 +---------------------------------------------------------------+ | Digest Method | +---------------------------------------------------------------+ | Signature Method | +---------------------------------------------------------------+ | Signature Value | +---------------------------------------------------------------+ Digest Method Attribute: Attribute Name : digestMethod XBE32 Type : 0x3286 Value Type : opaque4 Value Length : 32 bits This Attribute identifies which kind of algorithm has been employed in order to obtain a digest of the whole XSDF message, but the Signature Value Attribute. Digest Method is encoded as a 4 octet value (See IANA Assigned IKE Numbers): Value Hash Algorithm ---------- -------------- 0x00000001 MD5 [RFC1321] 0x00000002 SHA FIPS 180-1 Signature Method Attribute: Attribute Name : signatureMethod XBE32 Type : 0x3287 Value Type : opaque4 Value Length : 32 bits This Attribute identifies which kind of algorithm has been employed to encrypt the digest of the XSDF message. Signature Method is encoded as a 4 octet value (See IANA Assigned IKE Numbers): Value Encryption Algorithm ---------- ------------------------- 0x00000001 DES-CBC [RFC2405] 0x00000002 IDEA-CBC [RFC2409] 0x00000003 Blowfish-CBC [RFC2409] 0x00000004 RC5-R16-B64-CBC [RFC2409] 0x00000005 3DES-CBC [RFC2409] 0x00000006 CAST-CBC [RFC2409] Urueħa & Larrabeiti Expires September 15, 2004 [Page 29] Internet-Draft XSDF: Common Elements & Procedures March 2004 Signature Value Attribute: Attribute Name : signatureValue XBE32 Type : 0x2188 Value Type : opaque Value Length : variable This Attribute contains the encrypted digest value of this whole message but this Attribute itself. In order to check if the message has been modified, receiver should perform the same digest process and compare it with the decrypted signature. If they are not equal, message MUST be silently dropped and MUST NOT be processed. 4.5 Common Operation Parameters Each XSDF protocol defines its own set of operation Elements. However, many protocol operations share common parameters. This sections defines those common Elements. 4.5.1 Realm Target Element Any operation containing a Realm Target parameter SHOULD be applied to all the Scopes from the specified Realm subset. Target Element: Element Name : target XBE32 Type : 0x0821 +---------------------------------------------------------------+ : [ Realm Element ] : +---------------------------------------------------------------+ Realm Element is specified in Section 4.1.1. Realm Element MUST be a subset of message Header's one, that is, do not specify another Domain and contain Scopes that have been already listed at message's Header. Otherwise, message processing SHOULD be silently aborted. If no Realm is specified, this target applies to all the Scopes specified in message Header's. 4.5.2 Services Filter Element Any request operation containing a Filter Element SHOULD remove the services listed in the "serviceIds" attribute from response message. Urueħa & Larrabeiti Expires September 15, 2004 [Page 30] Internet-Draft XSDF: Common Elements & Procedures March 2004 Services Filter Element: Element Name : filter XBE32 Type : 0x0822 +---------------------------------------------------------------+ | [ Service Ids ] | +---------------------------------------------------------------+ Service Ids Attribute is defined in Section 4.3. Service Id Attribute contains a sorted list of Service Identifiers. List MUST be sorted in order to ease Service Id search. 4.5.3 Update Information Element This Element is included in reply and advertisement operations and allows server XSDF Agent to control the refresh rate of Service Registrations or Subscriptions from client XSDF Agents. It may be also included in the requests to suggest XSDF Server Agents which is the better update interval. Update Information Element: Element Name: updateInfo XBE32 Type: 0x0521 +---------------------------------------------------------------+ | Minimum Life | +---------------------------------------------------------------+ | Maximum Life | +---------------------------------------------------------------+ Minimum Life Attribute: Attribute Name : minLife XBE32 Type : 0x3253 Value Type : int32 Value Length : 32 bits This Attribute indicates that associated information SHOULD NOT be refreshed until this time has elapsed. Time is measured in milliseconds. Maximum Life Attribute: Attribute Name : maxLife XBE32 Type : 0x3254 Value Type : int32 Value Length : 32 bits Urueħa & Larrabeiti Expires September 15, 2004 [Page 31] Internet-Draft XSDF: Common Elements & Procedures March 2004 This Attribute contains the maximum time in milliseconds that associated information is going to remain registered. An Update request SHOULD be issued before this time expires, or the associated registration/subscription will be deleted. 4.5.4 Cache State Element This Element contains how much time the associated Service information has been cached, and the validity time left. Cache State Element: Element Name : cacheState XBE32 Type : 0x0211 +---------------------------------------------------------------+ | Age | +---------------------------------------------------------------+ | Time to Live | +---------------------------------------------------------------+ Age Attribute: Attribute Name : age XBE32 Type : 0x3221 Value Type : int32 Value Length : 32 bits This Attribute contains the Age of this Service, that is, the time passed since cached Service information was last updated. It is measured in milliseconds. Time to Live Attribute: Attribute Name : ttl XBE32 Type : 0x3222 Value Type : int32 Value Length : 32 bits This Attribute contains the expected amount of time in milliseconds that Service data is expected to keep being valid. Urueħa & Larrabeiti Expires September 15, 2004 [Page 32] Internet-Draft XSDF: Common Elements & Procedures March 2004 5. Common Procedures This section defines operational procedures common to all XSDF protocols. In particular this section covers XSDF Agent initialization and XSDF message creation, transmission and reception, including common operation processing. Unless explicitly said, all XSDF protocols MUST adhere to the procedures described here. 5.1 XSDF Agent initialization XSDF Agents MUST belong to a Realm. They MAY obtain such information from several ways (sorted by preference): 1. Static configuration. XSDF Agents MUST be able to read its Realm from a configuration file. 2. Dynamic configuration via DHCP [2]. Realm MAY be built from the Domain name [3] and the SLP Scope List [8] DHCP Options. 3. Dynamic configuration from DAs via XSLP. If DA addresses are pre-configured (or obtained via DHCP), an UA or SA MAY query those DAs to obtain their Realms via "realmRequest" operations. See [13] for details. 4. Use of the "DEFAULT" Realm. If all the above mechanisms fail, UAs and SAs MUST set its Realm to the empty Domain and one Scope called "DEFAULT". The behavior of XSDF Agents changes whether a Scope is managed or not by DAs. Therefore, XSDF Agents MUST be able to know if a Realm is managed by DAs and, in that case, obtain the Service information about those DAs, at least their IP addresses. UAs and SAs MAY obtain such information from several ways (sorted by preference): 1. Static configuration. A XSDF Agent MUST be able to read the Service information about DAs managing its Realm Scopes from a configuration file. 2. Dynamic configuration via DHCP [2]. XSDF Agents MAY obtain the address of DAs via the SLP Directory Agent DHCP Option [8]. 3. Dynamic configuration via XSLP. XSDF Agents MAY obtain DA Service information by performing Active Service Discovery for the "xsdf:da" Service Type, or by receiving DA Service Advertisements (a.k.a. Passive Service Discovery). See [13] for details. 4. Stand-Alone state. If all the above mechanisms fail, XSDF Agent MUST consider that there are no DAs in that Scope (unless the Urueħa & Larrabeiti Expires September 15, 2004 [Page 33] Internet-Draft XSDF: Common Elements & Procedures March 2004 XSDF Agent is itself a DA, of course) and behave as in its Stand-Alone state. The common initialization phase of a XSDF Agent ends when it knows the Realm it belongs to, and the DAs, if any, managing those Scopes. A Scope not managed by any DAs is called unmanaged Scope. 5.2 Message generation All XSDF protocols share a common message format. A XSDF message is included inside a single Element. That Element is defined by each protocol and allows protocol versioning. However, that Element always have the same structure, a Header Element, followed by one or more operation Elements and an ending optional Signature Element. Each protocol defines its own set of operations, but the other elements are common for all XSDF protocols. In particular, this section focus on how Header Element should be created. 5.2.1 Creating new messages This subsection refers to request and advertisement message creation. Refer to next subsection for generation of reply messages. When a XSDF Agent wants to create a new message that is not a reply to another message, it MUST build a Header Element following these steps: 1. Generate a new transaction identifier (XID). It SHOULD be unique in order to identify the XSDF message. Uniqueness MUST be granted for message validity time. A simple XID counter with a random initial number should be enough. 2. Realm Element SHOULD contain the common known Realm between source and destination XSDF Agents. That is, the same Domain, if any, and the subset of common Scopes. If the destination Realm is unknown (i.e. multicast message), Realm Element SHOULD contain the full Realm of the source XSDF Agent. If unknown, Realm Element MAY be empty but only during the initialization phase. See [13] for details. 3. As SAs and DAs are Services themselves, when creating a message, they MUST build an Source Endpoint Element containing at least a Service Element with its Id. Other Service information is optional and MAY NOT appear. An UA MAY NOT have a Service Id, therefore it MUST build a Source Endpoint Element but it MAY NOT contain a Service Element. 4. Destination Endpoint Element MUST contain a Service Element with Urueħa & Larrabeiti Expires September 15, 2004 [Page 34] Internet-Draft XSDF: Common Elements & Procedures March 2004 the Service Id of the remote XSDF Agent. Other Service information is optional and SHOULD NOT appear. However, if the Service Id of the remote peer is unknown, the Service Id MUST be set to the "Unknown XSDF Agent" reserved value. The above description only applies to unicast messages. Multicast messages MUST have the Destination Service Id set to the "All XSDF Agents" reserved value. 5. If a previous request message was rejected due to an AUTHENTICATION_ERROR including a Cookie Element. A new request message SHOULD be generated containing exactly the same operations, but including an Authentication Element in its Header. This Element MUST carry the Cookie Element returned in the error reply. 6. A request message MAY be also rejected because it was not authenticated and contained a restricted Realm. In that case, Error Element SHOULD carry an EAP Request message. As above, a new message SHOULD be generated with the same operations and an Authentication Element. This Element MUST contain the appropriate EAP response message by performing the specified authentication method. Please refer to Section 4.1 for a detailed description of the Header Element. In order to provide message integrity and authentication (when not provided by lower layers), XSDF Agents MAY include a Signature Element at the end of a XSDF message. In order to generate such Element, XSDF Agents MUST perform the following steps: 1. Set the Signature Method Attribute with the encryption algorithm associated with its Public/Private Key pair. 2. Choose a supported digest algorithm and fill the Digest Method Attribute with its identifier. 3. Employ the above algorithm to obtain the hash value of the whole message, including its Header, Operations and Signature Element but its last Signature Attribute. 4. Encrypt the digest value with the Private Key and set the result in the Signature Value Attribute. Please refer to Section 4.4 for a detailed description of the Signature Element. Urueħa & Larrabeiti Expires September 15, 2004 [Page 35] Internet-Draft XSDF: Common Elements & Procedures March 2004 5.2.2 Replying to Request messages After a message containing operation requests is processed, a reply message SHOULD be sent back with operation replies and/or errors. However, XSDF Agents MUST NOT send Errors as replies to multicast requests in any case. Also, XSDF Agents MUST always reply to unicast addresses. When a XSDF Agent wants to create a reply message to a previously received valid one, it MUST build a Header Element following these steps: 1. Transaction identifier (XID) MUST be copied from previous request message. 2. Realm Element SHOULD contain the common known Realm between source and destination XSDF Agents. If the Realm Element at request message's Header contains unknown Scopes, reply message SHOULD list just the subset of common Scopes, if any. If Realms are incompatible, reply message SHOULD contain an empty Realm. 3. Replying XSDF Agent MUST build a Source Endpoint Element containing at least a Service Element with its own Service Id. Other Service information is optional and MAY NOT appear. 4. Unless Source Service Element in request message was empty, Destination Endpoint Element MUST contain, at least, a Service Element with the same Id as in previous message's Source one. Other Service information is optional and SHOULD NOT appear. Please refer to Section 4.1 for a detailed description of the Header Element. 5.3 Message transmission XSDF has been designed to allow protocol messages to be transmitted over several transport protocols. XSDF Agents SHOULD support UDP and TCP transport protocols and MAY support SCTP. Each XSDF protocol defines the subset of transport protocols that could be employed for message transmission. XSDF employs XBE32 [11] to encode all its messages. In XBE32, complex Elements could be delimited by length or with an End-of-data TLV. However, this latter mechanims SHOULD NOT be employed in UDP tranmission and is restricted to TCP and SCTP transport protocols. All XSDF messages MUST be transmitted in network byte order (a.k.a. Big Endian, i.e., the most significant byte first), no matter which Urueħa & Larrabeiti Expires September 15, 2004 [Page 36] Internet-Draft XSDF: Common Elements & Procedures March 2004 transport protocol is employed. Each XSDF protocol defines its own default Server port. However, as any other Service, XSDF Agents MAY advertise other ports in its Service information. The only exception is XSLP that MUST employ UDP/ 727 port number. Clients MAY employ any ephemeral port to send request messages. Servers MUST reply from the same port number where previous message was received. When the same Realm is handled by several DAs, those DAs exchange registered Service information among them, thus providing an unified view of the common Realm. Therefore, XSDF operations aiming to that Realm could be issued to any of the DAs that manage such Realm. In particular, XSDF Agents SHOULD follow the Selection policy advertised by DAs to choose the better one to send XSDF operations to. 5.3.1 Message transport over TCP/SCTP When a client XSDF Agent wants to communicate with a server one over TCP or SCTP, client MUST initiate the TCP/SCTP connection. Once such connection is established, both, request and reply messages of the transaction are exchanged. A single connection MAY be employed for multiple XSDF transactions. The initiating XSDF Agent SHOULD close the connection. However, the server peer SHOULD close the connection when it has been idle for MAX_IDLE_CONN_TIME. Whenever a XSDF request message is sent, source XSDF Agent SHOULD set an REPLY_TIMER. If the timer expires before a response (i.e. containing reply operations or errors) has been received, message transmission to destination XSDF Agent MUST be skipped. In that case, its Service information SHOULD be flushed from cache and next XSDF Agent SHOULD be chosen. If there are no XSDF Agents left, message transmission MUST be aborted and upper layer SHOULD be notified with an error message. 5.3.2 Message transport over unicast UDP As UDP does not provide a reliable, ordered-delivery mechanism to transport messages. XSDF Agent SHOULD implement additional procedures when transmitting messages over UDP. Some kind of ordered delivery could be achieved by the Header's XID Attribute. When there are multiple outstanding requests, client MAY employ XID to correlate received replies with request messages. Notice that this mechanism does not ensure that request messages are received nor processed in the same order as sent. However, XSDF Agents MUST process request operations from the same message in the same order as received. Thus, XSDF Agents SHOULD NOT issue requests Urueħa & Larrabeiti Expires September 15, 2004 [Page 37] Internet-Draft XSDF: Common Elements & Procedures March 2004 in multiple, concurrent UDP messages when there are order constrains between them. XSDF messages SHOULD be restricted to 1232 octets when sent over UDP datagrams. When a XSDF reply message does not fit, it SHOULD be truncated removing the last reply operations and an OVERFLOW_ERROR Element SHOULD be appended. In that case, XSDF message, including the ending Error Element SHOULD also adhere to the size limit. Each UDP datagram MUST contain a single XSDF message, although such message MAY include several operations. Whenever a XSDF request message is sent, source XSDF Agent SHOULD set an UDP_REPLY_TIMER. If the timer expires before a response (i.e. containing reply operations or errors) has been received, the outstanding message SHOULD be retransmitted again, up to UDP_MAX_RETRIES. The initial retransmission MUST occur after INITIAL_RETRY_TIME. Next retransmissions MUST wait an exponentially increased delay, by doubling the time, or the range of the random interval, each time. Retransmitted messages MUST be identical to the initial one, including the XID. Whenever a new message is generated, a new XID MUST be generated. XSDF Agents MAY briefly cache reply messages in order to quickly respond to retransmitted requests (i.e. if first reply message get lost). If the transport layer returns an error from remote peer, or the MAX_RETRIES limit is reached, request message transmission to that XSDF Agent MUST be skipped. In that case, its Service information SHOULD be flushed from cache and next XSDF Agent SHOULD be chosen. If there are no XSDF Agents left, message transmission MUST be aborted and upper layer SHOULD be notified with an error message. 5.3.3 Message transport over multicast UDP Multicast transmission MAY be employed by the XSLP and XSTP protocols. Other XSDF protocols (i.e. XSRP and XSSP) MUST employ only unicast transmission. In IPv4 networks, all XSDF multicast messages MUST be sent to the administratively scoped SLP multicast [6] address (239.255.255.253). In isolated networks, XSDF Agents MAY be configured to employ the all hosts broadcast address (255.255.255.255). In both cases the default TTL is 255. In IPv6 networks there are not broadcast addresses, but there is enough space for several multicast ranges in every scope. XSDF uses the same multicast group-id assignments as SLPv2 [10]: Urueħa & Larrabeiti Expires September 15, 2004 [Page 38] Internet-Draft XSDF: Common Elements & Procedures March 2004 FF0X:0:0:0:0:0:0:116 All XSDF Agents FF0X:0:0:0:0:0:0:123 All XSDF Directory Agents FF0X:0:0:0:0:0:1:1000 XSDF Agents with hash(Service Type) == 1 ... FF0X:0:0:0:0:0:1:13FF XSDF Agents with hash(Service Type) == 1023 The FF0X prefix refers to the appropriate multicast scope between FF01 - FF05, as defined in [7]. XSDF Agents MUST NOT send or join to multicast groups which have a greater scope than the unicast scopes of the associated interface. For example if an interface has only a link local address, the XSDF Agent should join just to the multicast groups in scopes FF01 and FF02. For each scope there are 1023 multicast addresses reserved for SLP, XSLP Service Requests should be sent to the multicast address that is generated as a hash of the specified Service Type. The hash algorithm is defined in SLPv1 [4] as follows: An unsigned 32 bit value V is initialized to 0. Each byte of the Service Type UTF-8 encoded string value is considered consecutively. The current value V is multiplied by 33, then the value of the current string byte is added. Each byte in the Service Type string is processed in this manner. The result is contained in the low order 10 bits of V. For example, the following code implements this algorithm: unsigned long slp_hash(const char *pc, unsigned int len) { unsigned long h = 0; while (len-- != 0) { h *= 33; h += *pc++; } return (0x3FF & h); /* round to a range of 0-1023 */ } There is only one exception to this mapping between Service Types and IPv6 multicast groups. Queries for the "xsdf:da" Service Type MUST be sent to the "All XSDF Directory Agents" (FF0X:0:0:0:0:0:0:123) multicast groups. DAs MUST join to the appropriate "All XSDF Directory Agents" multicast groups. Note that this algorithm is to be applied only to IPv6 multicast groups. In IPv4, all Service Types are mapped to the single SLP multicast group (239.255.255.253). Unless specifically configured not to do so, XSDF Agents MUST be able to receive Service Advertisements to discover new DAs from its Realm. Therefore, IPv6 XSDF Agents MUST join to the "All XSDF Agents" Urueħa & Larrabeiti Expires September 15, 2004 [Page 39] Internet-Draft XSDF: Common Elements & Procedures March 2004 multicast group in all the appropriate IPv6 scopes. Also, IPv4 XSDF Agents MUST join to the SLP multicast group (239.255.255.253) and be able to receive broadcast messages (255.255.255.255). When transmitting a request message to a multicast group, XSDF Agents follow some rules very similar to ones described in previous section. In particular, XSDF messages MUST NOT be larger than 1232 octets and retransmitted messages MUST be identical to the initial one, including its XID value. When sending a multicast request (i.e. not multicast Advertisements), XSDF Agents MAY send up to MC_MAX_RETRIES additional messages. Second message MUST NOT be sent before INITIAL_RETRY_TIME has passed. Further messages MUST follow an exponential backoff by doubling the wait interval each time. Those "messages" could be retransmissions or reissued requests: o Whenever a request message is sent to a multicast group, source XSDF Agent SHOULD set an UDP_REPLY_TIMER. If no reply message is received before it expires, initial request SHOULD be retransmitted. Retransmitted messages MUST be identical to the original one, including its XID field. o Once one or more replies have been received, source XSDF Agent MAY reissue the same request in order to obtain even more Service information. In order to reissue a request, Source XSDF Agent MUST create a new message with a different XID containing the request operations. Also, XSDF Agent MUST include after the message's Header an "ignoreMessage" operation. This Element SHOULD contain the Service Id of all the XSDF Agents that have replied to the request since it was sent in the first time. Request MAY be reissued until no more reply messages are received or until the MC_MAX_RETRIES limit is reached. Initial request message, plus retransmissions, plus reissued requests MUST NOT be in any case greater than the MC_MAX_RETRIES value. 5.4 Message reception All XSDF messages MUST follow the XBE32 [11] encoding rules. Otherwise, message processing MUST be aborted an a XBE32_ERROR Error Element MUST be created. When the message is properly encoded but an unknown Element or Attribute is found, receiving XSDF Agent MUST check the first two bits of the Element type as described in [11]. o If unknown XBE32 Element is mandatory, message processing MUST be aborted. Otherwise, that element MUST be skipped and message processing SHOULD continue. Urueħa & Larrabeiti Expires September 15, 2004 [Page 40] Internet-Draft XSDF: Common Elements & Procedures March 2004 o Unknown XBE32 Element MAY be reported back inside an UNKNOWN_XBE32_ELEMENT Error Element. It is RECOMMENDED that all unknown Elements found were reported inside a single Error Element. When a XSDF message is received by a XSDF Agent, it SHOULD follow these steps in order to check the Header Element: 1. Realm Element SHOULD contain a Compatible Realm with receiving XSDF Agent one. If Domain Attributes do not match or all listed Scopes are unknown, message processing SHOULD be aborted and an UNKNOWN_REALM Error SHOULD be generated. Realm Element MAY be empty, but in that case the message SHOULD contain a "realmRequest" operation. See [13] for details. 2. Unless received from an UA, Source Endpoint Element MUST contain a Service Element with the Id of the source XSDF Agent. Such Id value MUST NOT be a reserved one (i.e. Unknown XSDF Agent or All XSDF Agents). In that case, message MUST be silently dropped. 3. Multicast/broadcast requests MUST contain an "All XSDF Agents" Service Id value in the Destination Endpoint Element. Otherwise, message MUST be silently dropped. 4. Destination Endpoint Element of any unicast messages, unless received from an UA, MUST contain a Service Element with the Id of the receiving XSDF Agent, or the "Unknown XSDF Agent" value. Otherwise, message processing MUST be aborted and an UNKNOWN_SERVICE_ID Error Element MUST be created. 5. XSDF messages MAY include an Authentication Element in its Header. In that case, XSDF Agent MUST check if it contains a valid Cookie Element and/or an EAP Element that authenticates the peer Agent. XSDF Agent MUST ensure that User is authorized to access to the specified Realm. Whenever a received message does not adhere to the XSDF syntax, message processing MUST be aborted and a PARSING_ERROR Error Element MUST be created. When message processing has been aborted and an Error Element has been created, a reply MUST be sent back. Refer to Section 5.2.2 for reply message generation. However, the above rule only applies to unicast request messages. When a reply or a multicast message generates an error, receiving XSDF Agent MUST NOT reply back, and they MUST silently discard such invalid message. A XSDF Agent MAY reject a XSDF message without a valid Cookie Element Urueħa & Larrabeiti Expires September 15, 2004 [Page 41] Internet-Draft XSDF: Common Elements & Procedures March 2004 or from an unauthenticated peer willing to access a restricted Realm. In that case, it MUST generate a reply message containing an AUTHENTICATION_ERROR Error. This Element SHOULD contain the appropriate Elements: a Cookie or an EAP request message to authenticate the peer. Protocol operations SHOULD be skipped until a new request message containing the appropriate Authentication Elements is received. After Header Element has been validated, XSDF Agent begins processing message operations sequentially. Following subsection describe processing of common XSDF operations. 5.4.1 Ignore Message Operation When an Ignore Message Element is found, XSDF Agent MUST search for its own Service Id inside the Service Ids list. If found, message processing MUST be aborted. Otherwise, message operation processing MUST continue. In both cases, this operation does not generate any reply Element. A detailed description of the Ignore Message Element can be found at Section 4.3. Please note that XSDF Agent MUST find exactly its own Service Id. Special values as "Unknown XSDF Agent" or "All XSDF Agents" Ids MUST be skipped. 6. Acknowledgements The Service model defined by XSDF was heavily influenced by the Service Templates defined for SLPv2, the Parameters of the ASAP and ENRP Rserpool protocols, and specially, by Erik Guttman's "serviceid" draft, which details the problems derived from the usage of an URL to identify a Service. Also, most of the protocol procedures detailed in this document are borrowed from the SLP specifications. Urueħa & Larrabeiti Expires September 15, 2004 [Page 42] Internet-Draft XSDF: Common Elements & Procedures March 2004 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [3] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997. [4] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan, "Service Location Protocol", RFC 2165, June 1997. [5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. [6] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998. [7] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998. [8] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999. [9] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [10] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001. [11] Urueħa, M. and D. Larrabeiti, "eXtensible Binary Encoding (XBE32)", draft-uruena-xbe32-00 (work in progress), March 2004. [12] Urueħa, M. and D. Larrabeiti, "Overview of the eXtensible Service Discovery Framework (XSDF)", draft-uruena-xsdf-overview-00 (work in progress), March 2004. [13] Urueħa, M. and D. Larrabeiti, "eXtensible Service Location Protocol (XSLP)", draft-uruena-xslp-00 (work in progress), March 2004. [14] Urueħa, M. and D. Larrabeiti, "eXtensible Service Registration Protocol (XSRP)", draft-uruena-xsrp-00 (work in progress), March 2004. [15] Urueħa, M. and D. Larrabeiti, "eXtensible Service Subscription Urueħa & Larrabeiti Expires September 15, 2004 [Page 43] Internet-Draft XSDF: Common Elements & Procedures March 2004 Protocol (XSSP)", draft-uruena-xssp-00 (work in progress), March 2004. [16] Urueħa, M. and D. Larrabeiti, "eXtensible Service Transfer Protocol (XSTP)", draft-uruena-xstp-00 (work in progress), 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 44] Internet-Draft XSDF: Common Elements & Procedures March 2004 Appendix A. XSDF Constants A.1 XBE32 Attributes & Elements Element Name XBE32 Type ------------ ---------- service 0x0100 serviceState 0x0110 metaInfo 0x0111 serviceMainInfo 0x0120 serviceType 0x0121 serviceLocationInfo 0x0130 inet 0x0131 protocol 0x0132 serviceAddInfo 0x0140 cacheState 0x0211 selectState 0x0311 selectInfo 0x0321 updateInfo 0x0521 user 0x0600 desc 0x0610 icon 0x0620 realm 0x0700 namingAuth 0x0710 header 0x0810 source 0x0811 destination 0x0812 authInfo 0x0813 target 0x0821 filter 0x0822 ignoreMessage 0x0830 signatureInfo 0x08e1 error 0x08f1 Urueħa & Larrabeiti Expires September 15, 2004 [Page 45] Internet-Draft XSDF: Common Elements & Procedures March 2004 Attribute Name XBE32 Type Value Type Value Length -------------- ---------- ---------- ------------ id 0x3511 opaque16 128 bits type 0x2812 string variable path 0x2813 string variable alias 0x2814 string variable ipv4Addrs 0x3215 opaque4 variable ipv6Addrs 0x3516 opaque16 variable hostname 0x2817 string variable capabilities16 0x3118 opaque2 variable transPorts 0x3219 opaque4 variable stateTimestamp 0x331a int64 64 bits mainInfoSeqNum 0x321b int32 32 bits locationInfoSeqNum 0x321c int32 32 bits addInfoSeqNum 0x321d int32 32 bits age 0x3221 int32 32 bits ttl 0x3222 int32 32 bits lifetime 0x3223 int32 32 bits resources 0x3231 int32 32 bits workload 0x3232 int32 32 bits policies 0x3133 opaque2 variable priority 0x3234 int32 32 bits weight 0x3235 int32 32 bits minLife 0x3253 int32 32 bits maxLife 0x3254 int32 32 bits name 0x2861 string variable url 0x2862 string variable text 0x2863 string variable lang 0x2864 string variable vendor 0x2865 string variable vendorURL 0x2866 string variable model 0x2867 string variable modelURL 0x2868 string variable version 0x2869 string variable mimeType 0x286a string variable width 0x326b int32 32 bits height 0x326c int32 32 bits depth 0x326d int32 32 bits domain 0x2871 string variable scope 0x2872 string variable prefix 0x2873 string variable template 0x2874 string variable xid 0x3281 opaque4 variable serviceIds 0x3582 opaque16 variable code 0x3283 opaque4 32 bits cookie 0x2184 opaque variable eapInfo 0x2185 opaque variable digestMethod 0x3286 opaque4 32 bits Urueħa & Larrabeiti Expires September 15, 2004 [Page 46] Internet-Draft XSDF: Common Elements & Procedures March 2004 signatureMethod 0x3287 opaque4 32 bits signatureValue 0x2188 opaque variable A.2 Timers and Constants Timer name Description --------------- ---------------------------------------------- REPLY_TIMER Timeout for TCP/SCTP replies UDP_REPLY_TIMER Timeout for UDP request message retransmission Constant name Default Value Description ---------------------- ------------- ----------------------------- MAX_IDLE_CONN_TIME 5 minutes Lifetime of idle connections UDP_INITIAL_RETRY_TIME 2 seconds First retransmission delay UDP_MAX_RETRIES 3 times Max number of request message retransmissions over UDP MC_MAX_RETRIES 3 times Max number of additional multicast request messages Urueħa & Larrabeiti Expires September 15, 2004 [Page 47] Internet-Draft XSDF: Common Elements & Procedures 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 48] Internet-Draft XSDF: Common Elements & Procedures 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 49]