SIMPLE WG M. Thomson Internet-Draft Andrew Expires: June 16, 2006 December 13, 2005 A Document Format for Expressing XML Support (EXS) draft-thomson-simple-expressing-xml-support-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 June 16, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document defines a simple XML format for expressing support for, or understanding of sections of XML documents. This format is designed for use in negotiating a common level of support in protocols. XPath expressions are used to define which XML nodes within any particular instance document are understood. Thomson Expires June 16, 2006 [Page 1] Internet-Draft Expressing XML Support December 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 5 3. Feature Model . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Document Format . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Establishing a Common Schema Definition . . . . . . . . . 7 4.2. Indicating Support for an Entire Namespace . . . . . . . . 8 4.2.1. Specifying Schema Definitions for Namespaces . . . . . 8 4.3. Indicating Support for Individual Nodes . . . . . . . . . 9 4.3.1. Excluding Node Descendants . . . . . . . . . . . . . . 9 4.4. Establishing Contexts . . . . . . . . . . . . . . . . . . 10 4.5. Excluding Specific Nodes . . . . . . . . . . . . . . . . . 11 4.6. Excluded Node Types . . . . . . . . . . . . . . . . . . . 11 5. Simplified XPath Profile . . . . . . . . . . . . . . . . . . . 13 5.1. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Limitations . . . . . . . . . . . . . . . . . . . . . . . 14 6. Testing for Support . . . . . . . . . . . . . . . . . . . . . 15 7. Expression of XML Support Schema . . . . . . . . . . . . . . . 16 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 10.1. MIME Type registration . . . . . . . . . . . . . . . . . . 22 10.2. URN Sub-Namespace Registration . . . . . . . . . . . . . . 23 10.3. XML Schema Registration . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11.1. Normative References . . . . . . . . . . . . . . . . . . . 24 11.2. Informative References . . . . . . . . . . . . . . . . . . 24 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Thomson Expires June 16, 2006 [Page 2] Internet-Draft Expressing XML Support December 2005 1. Introduction Extensible Markup Language (XML) documents are widely used to express data of all forms. One highly desirable feature of XML is that documents are extensible, that is, additional functionality can be added to a base document. For specifications, extensibility enables a basic specification to address an existing need without constraining the future use of the document and its future usage. Similarly, a specification can define a framework upon which other specifications may build solutions through extensibility, for example [I-D.ietf-geopriv-common-policy]. Extensibility therefore offers a great deal of flexibility in specification. However, extensibility can lead to arbitrary levels of complexity, which could lead to interoperability issues. A document created by one system can only be understood in its entirety by another if the target system supports all the features used in the document. In extreme cases, if a single fragment is not understood, the entire document could be unusable. To address this problem, interoperating systems need a method for negotiating a common level of support. Negotiating support for entire document formats can already be accomplished through the use of MIME and protocol headers, such as the "Accept" header in HTTP and SIP. However, a MIME type alone cannot express the rich set of features that could be combined within an XML document, nor do MIME types allow for expressing support for parts of a document. This document defines an expression of XML support (EXS) document format. An EXS document is created so that document generators can determine if a generated document can be understood. An EXS document is an XML document that specifies what features are understood by a particular processor. An EXS document can also be used to indicate to individual users the level of service that they are permitted to access. This goes beyond an expression about what a service can provide and provides information on user permission. EXS is based on the XPath grammar [W3C.REC-xpath-19991116], which is a very rich and flexible tool for selecting XML nodes. In order to simplify implementation, this document also defines a basic profile of XPath that removes predicates and limits the axes that may be used. This document does not define methods for sharing or publishing EXS documents. Different applications and protocols are responsible for defining how this information is shared and any negotiation Thomson Expires June 16, 2006 [Page 3] Internet-Draft Expressing XML Support December 2005 completed. Thomson Expires June 16, 2006 [Page 4] Internet-Draft Expressing XML Support December 2005 2. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Terminology from the XPath specification [W3C.REC-xpath-19991116] is used extensively in this document. This includes the following terms: document, node, node-set, part, child, parent, descendant, axis, document order. Thomson Expires June 16, 2006 [Page 5] Internet-Draft Expressing XML Support December 2005 3. Feature Model XML documents model data of varying complexity. A _feature_ is an abstraction that refers to the capacity of a document to convey a particular unit of data. Since the concept of a feature is abstract, they are not necessarily discrete; that is, features can compose other features or overlap with other features. For example, an element and its children could be characterized as a single feature; or each child element could each be characterized as a single feature; alternatively, a feature could also be a collection of attributes distributed throughout a document. This document defines a simplified feature model where individual features can be reduced to a node-set. A feature is expressed as a single node or node-set. Typically, this a set of elements, attributes and text nodes. This model is chosen because the nature of XML is such that elements and attributes are the usual points where extensibility is used. The simple model presented in this document is not intended to be exhaustively capable of specifying capabilities. The degree to which this model is applicable depends on the application and the subset of XPath that is used. Thomson Expires June 16, 2006 [Page 6] Internet-Draft Expressing XML Support December 2005 4. Document Format An expression of XML support is made so that document generators can determine if a generated document can be understood. An EXS document is intended to be evaluated against a target document. 4.1. Establishing a Common Schema Definition The EXS document format described in the following sections relies on having a shared definition of XML document structure. This is achieved primarily through the use of XML Schema definitions [W3C.REC-xmlschema-1-20041028], although other schema definition languages MAY be used. A shared schema definition cannot be guaranteed by using the namespace URI only. It is uncommon to have different schema definitions sharing a namespace, therefore the schema definitions MAY be omitted from an EXS document. However, the namespace alone cannot be used to ensure a shared schema definition. Aside from the case where two applications have different schema definitions, XML Schema defines a "redefine" element that can be used to alter the definitions for particular schema. The "structure" element contains arbitrary content that is used to define the schema used in the document. It is RECOMMENDED that this section is included and that it contain a "schema" element from [W3C.REC-xmlschema-1-20041028] that imports all necessary schema documents. Alternatively a common schema definition MAY be indicated through the use of the "ns" attribute on the "namespace" element. This is described in more detail in Section 4.2. Schemas that are referenced by an EXS document and not included directly within the "structure" element SHOULD be retrieved, even if the schema for the given namespace is already known. For example, the following EXS fragment defines document structure by referencing an external schema document. Note that schema definitions for published RFCs are not usually Thomson Expires June 16, 2006 [Page 7] Internet-Draft Expressing XML Support December 2005 published to a fixed location. For these schema, it is not necessary to provide a schema definition, providing that the schema from the published RFC is used. Schema URNs that are registered with IANA SHOULD NOT be used in place of URLs. 4.2. Indicating Support for an Entire Namespace Support for all nodes from a namespace is indicated by using the "namespace" element. The namespace is indicated by the "ns" attribute. This statement indicates that all nodes that belong to given namespace are supported. From the perspective of the XPath data model, a node is supported if the namespace URI in the expanded-name of the node matches the value of the namespace. For example, the following minimal EXS document that indicates support for an entire namespace: The XPath data model states that attributes with no prefix do not have a namespace URI in their expanded name. Similarly, text nodes do not have an expanded name. For the purposes of testing for support, all text children and attribute children that have no namespace prefix belong to the same namespace as their parent element. For example, when the following document is evaluated against the above statement, this selects the "yes:supported" element and its text content, the "param" attribute and the "yes:info" attribute. text content This document format SHOULD only be used where namespaces in XML are employed. 4.2.1. Specifying Schema Definitions for Namespaces The "namespace" element also allows for references to schema definitions, which may be used in place of the "structure" element. Thomson Expires June 16, 2006 [Page 8] Internet-Draft Expressing XML Support December 2005 The "schemaLocation" attribute indicates the location of the schema definition for the given namespace. It is RECOMMENDED that this attribute be included where possible to avoid any potential miscommunication. A "namespace" element MAY occur with the same namespace multiple times within an EXS document, however the value of the "schemaLocation" attribute MUST not have multiple different values within the same document. An omitted "schemaLocation" attribute indicates that the value is the same as an included "schemaLocation" attribute for the same namespace. Schema definitions MAY be included in the document through the use of the "structure" element. In this case, the "schemaLocation" attribute SHOULD be omitted, or it should contain a fragment URI referring to the schema definition. The following EXS fragment refers to the location of the schema for a supported namespace: 4.3. Indicating Support for Individual Nodes Support for individual nodes is indicated by using the "node" element. The "path" attribute of this element includes an XPath expression that selects a node-set from the target document. For example, the following EXS document indicates that the entirety of the "app:supported" element is supported as a child of the current context: Node expressions are evaluated in the current context, see Section 4.4 for details. If the "app:supported" element is suported in all contexts, then a value of "//app:supported" might be a better expression. 4.3.1. Excluding Node Descendants Unless otherwise specified, selecting a node using the "node" element also selects all of its descendants. The "descendants" attribute specifies the types of descendants are included. The value is a list that MAY include any of the following values: "elements" (element descendants are included), "attributes" (attribute descendants are Thomson Expires June 16, 2006 [Page 9] Internet-Draft Expressing XML Support December 2005 included) and "text" (text descendants are included). Unless the value "elements" is included, only the immediate child attribute and text nodes are included. Two special values are also defined for convenience: "##all" indicates that all descendants are included, and "##none" indicates that no descendants are included. "##all" is the default value, which is equivalent to "elements attributes text". For example, the following EXS document indicates that the entirety of the "app:supported" element and its attributes is understood. Text and element descendants of these nodes are not supported. The "descendants" attribute is particularly useful when an element could contain any content. For instance, this is allowed by the "any" or "anyAttribute" in XML Schema [W3C.REC-xmlschema-1-20041028]. Since the content model of the "ruleset" element (through its descendants, see [I-D.ietf-geopriv-common-policy]) could include arbitrary content, this statement constitutes an unlimited promise of support. Where any content is allowed, this expression is NOT RECOMMENDED, instead it SHOULD be limited by using the "descendants" attribute. 4.4. Establishing Contexts For the purposes of simplification of grouping the "context" enables the selection of a document subset. The "path" attribute of this element is an XPath expression that selects a node-set. Elements that are nested within the "context" element are evaluated once for each node in the context node-set. Contexts MAY be nested within other contexts, in which case the path expression for the context is evaluated within the context of each node of the enclosing context node-set. Within a context, a "namespace" element can only select descendants of the context node, including the context node itself. Note that a "node" element can select any node from the document, however it is RECOMMENDED that nodes are only selected from the descendants of the context node. Thomson Expires June 16, 2006 [Page 10] Internet-Draft Expressing XML Support December 2005 Since the "context" element selects a node-set that could contain any number of nodes, it is RECOMMENDED that the node-set is restricted sufficiently to limit the performance impact of evaluating nested statements. If nested "context" statements are used, it is RECOMMENDED that the node-set be restricted to a single node. For example, the following EXS document indicates that the "http://example.com/ns/app" namespace is understood within the "enclosing" element only. 4.5. Excluding Specific Nodes The "except" element MAY be included as a child of either the "namespace" or "node" elements to indicate nodes that are excluded. Similar to "node", the "except" element selects all descendants unless the "descendants" attribute is used. When nested with a "node" element, the "except" element is evaluated as if the "node" element had established a context. That is. For example, the following EXS fragment indicates support for the "app:supported" element and all its contents, except for the "app:exception" element (when it is a child of "app:supported"). 4.6. Excluded Node Types The EXS document format is aimed at the three primary XML node types: elements, attributes and text. Support for other node types is limited. Namespace prefix declarations ("xmlns" attributes) MUST always be supported, regardless of any statements to the contrary. "except" elements MUST NOT select namespace prefix declarations. Comment nodes SHOULD NOT be the subject of expressions of support. Declarations that indicate support for comments SHOULD be ignored. Note however, that comment nodes affect the XPath content model, Thomson Expires June 16, 2006 [Page 11] Internet-Draft Expressing XML Support December 2005 specifically text nodes; therefore, where text nodes are selected, expressions might need to compensate for comment nodes. Processing instructions SHOULD automatically be considered as unsupported. Thomson Expires June 16, 2006 [Page 12] Internet-Draft Expressing XML Support December 2005 5. Simplified XPath Profile This section defines a simplified profile of XPath that MAY be required by protocols. This profile retains only the parts of the XPath grammar that enable the selection of elements and attributes. Protocols MAY use this profile, or define any other profile that most suits the application. However, protocols that use this specification MUST specify which XPath profile is required. 5.1. Grammar This profile defines a simple XPath grammar that prohibits the use of axes, except for the special axes "child", "self", "descendent-or-self" and "attribute". These axes MUST be specified using their abbreviated syntax only; they cannot be used with the double-colon ("::") notation. Note that the parent axis ("..") is not allowed by this profile. Predicates are excluded from this grammar, as are operators and all functions except the "node()" and "text()" functions. This grammar excludes support for selecting comments and processing instructions. The following ABNF grammar [RFC4234] describes this XPath profile. LocationPath = RelativeLocationPath / AbsoluteLocationPath AbsoluteLocationPath = "/" RelativeLocationPath? / AbbreviatedAbsoluteLocationPath RelativeLocationPath = Step / (RelativeLocationPath "/" Step) / AbbreviatedRelativeLocationPath Step = NodeTest / AbbreviatedStep NodeTest = ([AttributeSpecifier] NameTest) / (NodeType "()") AbbreviatedAbsoluteLocationPath = "//" RelativeLocationPath AbbreviatedRelativeLocationPath = RelativeLocationPath "//" Step AbbreviatedStep = "." / ".." AttributeSpecifier = "@" NameTest = "*" / (NCName ":*") / QName NodeType = %x74.65.78.74 / %x6E.6F.64.65 ; case-sensitive: "text" / "node" Definitions for "NCName" and "QName" can be found in [W3C.REC-xml- 20040204]. These restrictions reduce the complexity of a processor and mean that a processor only needs to provide support for node-set results. Since the included axes are all evaluated in document order and no predicates are allowed, this profile also grants significant scope Thomson Expires June 16, 2006 [Page 13] Internet-Draft Expressing XML Support December 2005 for optimization. 5.2. Limitations In order to use this simplified XPath profile, features MUST be able to be described as a set of elements and attributes only. This simplified XPath profile is limited in its capability to deal with loosely structured documents. In terms of expressing the context where a node is supported, this grammar only allows the parents of a node to be indicated. For instance, indicating support for an element that is dependent on the value of an attribute requires the use of predicates. Thomson Expires June 16, 2006 [Page 14] Internet-Draft Expressing XML Support December 2005 6. Testing for Support An application can test if a document that it generates conforms to a particular EXS document by applying the following procedure: 1. Search for the context node-set. The initial node set consists of the document root (the parent of the document element) only. 2. For each node in that node-set: A. Find all "namespace" and "node" elements within the current context. B. Conditionally mark the nodes that match the each statement: + For the "namespace" element, this includes all nodes that are in the current context and the specified namespace. All direct descendants of these nodes that are either attributes with the null namespace or text nodes are also included. + For the "node" element, this includes all nodes in the node-set specified. All descendants of those nodes are also marked based on the value of the "descendants" attribute. C. If the support statement has "except" children, evaluate each and remove any conditional marks from the node-set result. Similar to the "node" element, descendants of excluded nodes are also excluded based on the value of the "descendants" attribute. D. Mark all remaining conditionally marked nodes as supported. E. Find all "context" element children of the current context node. F. Recurse: evaluate step 1. for each context child. 3. Mark all namespace prefix declarations and comments as supported. 4. If any nodes are not marked, the document is considered as not supported and this procedure terminates. 5. The document is validated against the specified schema, taking into account any schemas that are indicated. Only valid documents are considered supported. Thomson Expires June 16, 2006 [Page 15] Internet-Draft Expressing XML Support December 2005 7. Expression of XML Support Schema Thomson Expires June 16, 2006 [Page 16] Internet-Draft Expressing XML Support December 2005 Thomson Expires June 16, 2006 [Page 17] Internet-Draft Expressing XML Support December 2005 For formatting purposes, the EXS schema contains extra line-breaks in the XPath pattern. These must be removed to use this schema - the actual value does not contain spaces or newline characters. Thomson Expires June 16, 2006 [Page 18] Internet-Draft Expressing XML Support December 2005 8. Example Thomson Expires June 16, 2006 [Page 19] Internet-Draft Expressing XML Support December 2005 Thomson Expires June 16, 2006 [Page 20] Internet-Draft Expressing XML Support December 2005 9. Security Considerations In general, the purpose for which EXS documents are used will determine what security constraints apply. This section provides some guidance on the types of security considerations that SHOULD be made when using this specification. An expression of XML support document could reveal capability information about a service. This information could be used for competitive analysis, or as input to an attack that focusses on unsupported values or border cases. Where the EXS document is widely published, there are often many legitimate means for obtaining this sort of information, so encryption of this information is not especially important. EXS documents can be used to indicate the service level offered to a individual users of a service. This information is sensitive to that user and therefore users SHOULD be authenticated and EXS documents SHOULD be encrypted where information applies to individuals users. If an EXS document is alterable, an attacker could use it to make promises of support that cannot be satisfied. Conversely, a forged EXS could be used to limit the features used by a user. Protocols that provide message integrity SHOULD be used to prevent alterations. Services that provide EXS documents out-of-band to protocols that use the information SHOULD be authenticated by their clients. Thomson Expires June 16, 2006 [Page 21] Internet-Draft Expressing XML Support December 2005 10. IANA Considerations 10.1. MIME Type registration This specification requests the registration of a new MIME type according to the procedures of [RFC2048] and guidelines in [RFC3023]. MIME media type name: application MIME subtype name: exs+xml Mandatory parameters: none Optional parameters: Same as charset parameter application/xml as specified in RFC 3023[RFC3023]. Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023]. Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 9 of RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification]]. Interoperability considerations: none. Published specification: RFC XXXX [[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification]] Applications which use this media type: This document type is used to express application support for XML features within documents. This has general application for a range of applications. Additional Information: Magic Number: None File Extension: .exs Macintosh file type code: "TEXT" Personal and email address for further information: Martin Thomson, martin.thomson@andrew.com Intended usage: COMMON Author/Change controller: The IETF. Thomson Expires June 16, 2006 [Page 22] Internet-Draft Expressing XML Support December 2005 10.2. URN Sub-Namespace Registration This section registers a new XML namespace, "urn:ietf:params:xml:ns:exs" as per the guidelines in [RFC3688]. URI: urn:ietf:params:xml:ns:exs Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Martin Thomson (martin.thomson@andrew.com). XML: BEGIN Expression of XML Support

Namespace for Expression of XML Support

urn:ietf:params:xml:ns:exs

[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX with the RFC number for this specification.]]

See RFCXXXX.

END 10.3. XML Schema Registration This section registers an XML schema as per the procedures in [RFC3688]. URI: urn:ietf:params:xml:schema:exs Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Martin Thomson (martin.thomson@andrew.com). The XML for this schema can be found in Section 7 of this document between lines starting with "", inclusive. Thomson Expires June 16, 2006 [Page 23] Internet-Draft Expressing XML Support December 2005 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC2048] Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001. [W3C.REC-xpath-19991116] DeRose, S. and J. Clark, "XML Path Language (XPath) Version 1.0", W3C REC REC-xpath-19991116, November 1999. [W3C.REC-xml-20040204] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004. 11.2. Informative References [RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [I-D.ietf-geopriv-common-policy] Schulzrinne, H., "A Document Format for Expressing Privacy Preferences", draft-ietf-geopriv-common-policy-06 (work in progress), October 2005. [W3C.REC-xmlschema-1-20041028] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004. Thomson Expires June 16, 2006 [Page 24] Internet-Draft Expressing XML Support December 2005 Appendix A. Acknowledgements The author would like to recognize the work of Jonathon Rosenberg for his work in defining a document format for policy capabilities. Security considerations are largely based on that work. Thomson Expires June 16, 2006 [Page 25] Internet-Draft Expressing XML Support December 2005 Author's Address Martin Thomson Andrew PO Box U40 Wollongong University Campus, NSW 2500 AU Phone: +61 2 4221 2915 Email: martin.thomson@andrew.com URI: http://www.andrew.com/ Thomson Expires June 16, 2006 [Page 26] Internet-Draft Expressing XML Support December 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Thomson Expires June 16, 2006 [Page 27]