SIMPLE J. Rosenberg Internet-Draft Cisco Intended status: Standards Track J. Urpalainen Expires: December 31, 2009 Nokia June 29, 2009 An Extensible Markup Language (XML) Document Format for Indicating A Change in XML Configuration Access Protocol (XCAP) Resources draft-ietf-simple-xcap-diff-13 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 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 December 31, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Rosenberg & Urpalainen Expires December 31, 2009 [Page 1] Internet-Draft XCAP Diff Format June 2009 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format indicates the document that has changed and its former and new entity tags. It also can indicate the specific change that was made in the document, using an XML patch format. This format allows also indications of element and attribute content of an XML document. XCAP diff documents can be delivered to clients using a number of means, including a Session Initiation Protocol (SIP) event package. Rosenberg & Urpalainen Expires December 31, 2009 [Page 2] Internet-Draft XCAP Diff Format June 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Structure of an XCAP Diff Document . . . . . . . . . . . . . . 5 4. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Example Document . . . . . . . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 7.1. application/xcap-diff+xml MIME Type . . . . . . . . . . . 12 7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 13 7.3. Schema Registration . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Rosenberg & Urpalainen Expires December 31, 2009 [Page 3] Internet-Draft XCAP Diff Format June 2009 1. Introduction The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] is a protocol that allows clients to manipulate XML documents stored on a server. These XML documents serve as configuration information for application protocols. As an example, resource list [RFC4662] subscriptions (also known as presence lists) allow a client to have a single SIP subscription to a list of users, where the list is maintained on a server. The server will obtain presence for those users and report it back to the client. This application requires the server, called a Resource List Server (RLS), to have access to the list of presentities. This list needs to be manipulated by clients so they can add and remove their friends as they desire. Complexities arise when multiple clients attempt to simultaneously manipulate a document, such as a presence list. Frequently, a client will keep a copy of the current list in memory, so it can render it to users. However, if another client modifies the document, the cached version becomes stale. This modification event must be made known to all clients which have cached copies of the document, so that they can fetch the most recent one. To deal with this problem, clients can use a Session Initiation Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to change events in XCAP documents. This notification needs to indicate the specific resource that changed, and how it changed. One solution for the format of such a change notification would be a content indirection object [RFC4483]. Though content indirection can tell a client that a document has changed, it provides it with MIME Content-ID indicating the new version of the document. The MIME Content-ID is not the same as the entity tag, which is used by XCAP for document versioning. As such, a client cannot easily ascertain whether an indication of a change in a document is due to a change it just made, or due to a change another client made at around the same time. Furthermore, content indirections don't indicate how a document changed; they would only be able to indicate that it did change. To resolve these problems, this document defines a data format which can convey the fact that an XML document managed by XCAP has changed. This data format is an XML document format, called an XCAP diff document. This format can indicate that a document has changed, and provide its previous and new entity tags. It can also optionally include a set of patch operations [RFC5261], which indicate how to transform the document from the version prior to the change, to the version after it. XML element and attribute content of XCAP documents can also be delivered with this format. Rosenberg & Urpalainen Expires December 31, 2009 [Page 4] Internet-Draft XCAP Diff Format June 2009 XML documents that are equivalent for the purposes of many applications may differ in their physical representation. Similar to XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of an XML document determines the logical equivalence when this format is used to patch XML documents. 2. Terminology 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 RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. This specification also defines the following additional terms: Document: When the term document is used without the "XCAP diff" in front of it, it refers to the XCAP document resource about whom the XCAP diff document is reporting a change. XCAP diff document: The XML document defined by this specification that reports on a set of changes in an XCAP document resource. Server: Typically an XCAP server, this is a protocol entity that generates XCAP diff documents based on its knowledge of a set of XCAP documents. Client: Typically an XCAP client and SIP User Agent (UA), the client consumes XCAP diff documents in order to reconstruct the document stored on the server. 3. Structure of an XCAP Diff Document An XCAP diff document is an XML [W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying XCAP diff documents and document fragments. The namespace URI for elements defined by this specification is a URN [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is: urn:ietf:params:xml:ns:xcap-diff An XCAP diff document begins with the root element tag . This element has a single mandatory attribute, "xcap-root". The value of this attribute is the XCAP root URI for the documents in which the changes have taken place. A single XCAP diff document can Rosenberg & Urpalainen Expires December 31, 2009 [Page 5] Internet-Draft XCAP Diff Format June 2009 only represent changes in documents within the same XCAP root. The content of the element is a sequence of , and elements followed by any number of elements from other namespaces for the purposes of extensibility. Wherever the XML schema (see Section 4) allows extension elements or attributes, any such unknown content MUST be ignored by the client. Each element specifies changes in a specific document within the XCAP root. If several elements pinpoint to the same specific document, i.e. for example, the full ETag change history is indicated, the corresponding patches MUST be appliable in the given document order. The element has one mandatory attribute, "sel", and a two optional attributes, "new-etag" and "previous-etag". The "sel" attribute of the element identifies the specific document within the XCAP root for which changes are indicated. Its content MUST be a relative path reference, with the base URI being equal to the XCAP root URI. The "new-etag" attribute provides the entity tag (ETag) for the document after the application of the changes, assuming the document exists after those changes. The "previous- etag" attribute provides an identifier for the document instance prior to the change. If the change being reported is the removal of a document, the "previous-etag" MUST only be included and the "new- etag" attribute will not be present. The "new-etag" attribute MUST only exist alone when the document either exists or it was just created (no patch included). Both attributes are present when a patch (or series of XCAP operations) has been applied to the resource. Also both attributes MAY be used to indicate an ETag change without any document modifications (patches). The "previous-etag" and "new-etag" need not have been sequentially assigned ETags at the server. An XCAP diff document can indicate changes that have occurred over a series of XCAP operations. The only requirement then is that, the sequence of events, when executed serially, will result in the transformation of the document with the ETag "previous-etag" to the one whose ETag is "new-etag". Also the series of operations do not have to be the same exact series of operations that occurred at the server. Each element contains either a sequence of patching instructions or an indication that the body hasn't semantically changed. The latter means that the document has been assigned a new ETag but its content is unchanged and it is indicated by the element. Patching instructions are described by the , and elements. These elements use the corresponding add, replace and remove types defined in [RFC5261], and define a set of patch operations that can be applied to transform the Rosenberg & Urpalainen Expires December 31, 2009 [Page 6] Internet-Draft XCAP Diff Format June 2009 document. See [RFC5261] for instructions on how this transformation is effected. The element can also contain elements from other namespaces for the purposes of extensibility. The , and elements allow extension attributes from any namespace. Figure 1 shows element content and how corresponding resource or metadata changes. An external document retrieval means in practice HTTP GET requests for target resources. +-----------+----------+-----------+----------+-------------------+ | previous- | new- | | | not- | metadata change | | | | | changed> | | +-----------+----------+-----------+----------+-------------------+ | xxx | yyy | * | - | resource patched, | | | | | | patch included | +-----------+----------+-----------+----------+-------------------+ | xxx | yyy | - | - | resource patched, | | | | | | external document | | | | | | retrieval | +-----------+----------+-----------+----------+-------------------+ | xxx | yyy | - | * | only ETag changed | +-----------+----------+-----------+----------+-------------------+ | - | yyy | - | - | resource created | | | | | | or exists, | | | | | | external document | | | | | | retrieval | +-----------+----------+-----------+----------+-------------------+ | xxx | - | - | - | resource removed | +-----------+----------+-----------+----------+-------------------+ Figure 1: element content / corresponding resource changes Each element indicates the existing element content of an XCAP document. It has one mandatory attribute, "sel", and one optional attribute, "exists". The "sel" attribute of the element identifies an XML element of an XCAP document. It is a percent endoced relative URI following XCAP conventions when selecting elements. The XCAP Node Selector MUST always locate a unique node, the "exists" attribute thus shows whether an element exists or not in the XCAP document. When the "exists" attribute is absent from the element, the indicated element still exists in the XCAP document. The located result element exists as a child element of the element. It should be noted, that only the full content of an element is shown if it exists, there are no Rosenberg & Urpalainen Expires December 31, 2009 [Page 7] Internet-Draft XCAP Diff Format June 2009 conventions for patching these elements. In a corner case where the content of this element cannot be presented for some reason, although it exists in the XCAP document, the element MUST NOT have any child nodes. As the result XML element is typically namespace qualified, all needed namespace declarations MUST exist within the document. The possible local namespace declarations within the result element exist unmodified as in the source document, similar to XCAP conventions. Other namespace references MUST be resolved from the context of the or its parent elements. The prefixes of qualified names (QName) [W3C.REC-xml-names-20060816] of XML nodes also remain as they exist originally in the source XCAP document. Each element indicates the existing attribute content of an XCAP document. It has one mandatory attribute, "sel", and one optional attribute, "exists". The "sel" attribute of the element identifies an XML attribute of an XCAP document. It is a percent endoced relative URI following XCAP conventions when selecting attributes. The "exists" attribute indicates whether an attribute exists or not in the XCAP document. When the "exists" attribute is absent from the element, the indicated attribute still exists in the XCAP document. The child text node of the element indicates the value of the located attribute. Note that if the attribute is namespace qualified, the query parameter of the XCAP URI indicates the attached namespace URI and the prefix in the XCAP source document. Namespaces of the "sel" attribute of the and elements MUST also be resolved properly. The Section 6.4. of [RFC4825] describes the rules when using namespace prefixes in XCAP Node Selectors. Without a namespace prefix in an element selector, an XCAP Default Document Namespace MUST be applied. The namespace resolving rules of Patch operation elements: , and are described in Section 4.2.1 of [RFC5261]. 4. XML Schema The XML Schema for the XCAP diff format. Rosenberg & Urpalainen Expires December 31, 2009 [Page 8] Internet-Draft XCAP Diff Format June 2009 Rosenberg & Urpalainen Expires December 31, 2009 [Page 9] Internet-Draft XCAP Diff Format June 2009 Rosenberg & Urpalainen Expires December 31, 2009 [Page 10] Internet-Draft XCAP Diff Format June 2009 5. Example Document The following is an example of a document compliant to the schema. presence sip:marketing@example.com This indicates that the document with URI "http://xcap.example.com/ root/resource-lists/users/sip:joe@example.com/coworkers" has changed. Its previous entity tag is "8a77f8d" and its new one is "7ahggs" but actual changes are not shown. The element exists in the rls-services "index" document and its full content is shown. Note that the element is attached with a default namespace declaration within the original document. Similarly, a "uri" attribute content is shown from the same "index" document as an illustrative example. 6. Security Considerations XCAP diff documents can include changes from one document to another. As a consequence, if the document itself is sensitive and requires Rosenberg & Urpalainen Expires December 31, 2009 [Page 11] Internet-Draft XCAP Diff Format June 2009 confidentiality, integrity or authentication, then the same applies to the XCAP diff format. Therefore, protocols which transport XCAP diff documents must provide sufficient security capabilities for transporting the document itself. The SIP event package framework specified in RFC 3265 [RFC3265] is the most typical use-case for this format. Then in general its security considerations apply, but event packages MAY also have other specific threats which MUST be considered on an application-by- application basis. 7. IANA Considerations There are several IANA considerations associated with this specification. 7.1. application/xcap-diff+xml MIME Type MIME media type name: application MIME subtype name: xcap-diff+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 6 of RFCXXXX [[NOTE TO RFC-EDITOR/IANA: Please replace XXXX with the RFC number of this specification.]]. Interoperability considerations: none. Published specification: This document. Applications which use this media type: This document type has been used to support manipulation of resource lists [RFC4826] using XCAP. Additional Information: Rosenberg & Urpalainen Expires December 31, 2009 [Page 12] Internet-Draft XCAP Diff Format June 2009 Magic Number: None File Extension: .xdf Macintosh file type code: "TEXT" Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net Intended usage: COMMON Author/Change controller: The IETF. 7.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff This section registers a new XML namespace, as per the guidelines in [RFC3688] URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-diff. Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). XML: BEGIN XCAP Diff Namespace

Namespace for XCAP Diff

urn:ietf:params:xml:ns:xcap-diff

See RFCXXXX[[NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.]].

END Rosenberg & Urpalainen Expires December 31, 2009 [Page 13] Internet-Draft XCAP Diff Format June 2009 7.3. Schema Registration This section registers a new XML schema per the procedures in [RFC3688]. URI: urn:ietf:params:xml:schema:xcap-diff Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net). The XML for this schema can be found as the sole content of Section 4. 8. Acknowledgments The authors would like to thank Pavel Dostal, Jeroen van Bemmel, Martin Hynar, Anders Lindgren, Mary Barnes and Ben Campbell for their valuable comments. 9. References 9.1. Normative References [W3C.REC-xml-20060816] Maler, E., Paoli, J., Bray, T., Yergeau, F., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium Recommendation REC-xml-20060816, August 2006, . [W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, . [W3C.REC-xml-names-20060816] Hollander, D., Bray, T., Layman, A., and R. Tobin, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium Recommendation REC-xml-names-20060816, August 2006, . [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Rosenberg & Urpalainen Expires December 31, 2009 [Page 14] Internet-Draft XCAP Diff Format June 2009 Types", RFC 3023, January 2001. [RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999. [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007. [RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008. 9.2. Informative References [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006. [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007. [RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. Rosenberg & Urpalainen Expires December 31, 2009 [Page 15] Internet-Draft XCAP Diff Format June 2009 Authors' Addresses Jonathan Rosenberg Cisco Edison, NJ US Email: jdrosen@cisco.com URI: http://www.jdrosen.net Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland Phone: +358 7180 37686 Email: jari.urpalainen@nokia.com Rosenberg & Urpalainen Expires December 31, 2009 [Page 16]