Movatterモバイル変換
[0]ホーム
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 locally cached 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 the corresponding resource or metadata changes. In practice, an external document retrieval means HTTP GET requests for target resources. The asterisk character '*' means that a element has child element(s):,, or, or alternatively only a element. The hyphen character '-' means that the corresponding content (attribute or element) doesn't exist in a element. The 'xxx' and 'yyy' are values of entity tags (ETag) of an XCAP document.Rosenberg & Urpalainen Standards Track [Page 6] RFC 5874 XCAP Diff Format May 2010 +-----------+----------+-----------+----------+-------------------+ | previous- | new- | | | not- | XCAP resource/ | | | | | changed> | metadata change | +-----------+----------+-----------+----------+-------------------+ | 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 optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the element identifies an XML element of an XCAP document. It is a percent-encoded 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 element exists as a child element of the element. In a corner case where the content of this element cannot be presented for some reason (e.g., the payload is too large) although it exists in the XCAP document, the element MUST NOT have any child nodes. As the located XML element is typically namespace qualified, all needed namespace declarations MUST exist within the document. The possible local namespace declarations within the located 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. TheRosenberg & Urpalainen Standards Track [Page 7] RFC 5874 XCAP Diff Format May 2010 prefixes of qualified names (QNames) [W3C.REC-xml-names-20060816] of XML nodes also remain as they originally exist in the source XCAP document. Each element indicates the existing attribute content of an XCAP document. It has one mandatory attribute, "sel", and optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the element identifies an XML attribute of an XCAP document. It is a percent-encoded relative URI following XCAP conventions when selecting attributes. The "exists" attribute indicates whether or not an attribute exists 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. 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 Standards Track [Page 8] RFC 5874 XCAP Diff Format May 2010Rosenberg & Urpalainen Standards Track [Page 9] RFC 5874 XCAP Diff Format May 2010Rosenberg & Urpalainen Standards Track [Page 10] RFC 5874 XCAP Diff Format May 20105. Example Document The following is an example of a document compliant to the schema.
presencesip:marketing@example.com This indicates that the document with the 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, "uri" attribute content is shown from the same "index" document as an illustrative example.6. Basic Requirements for a System Exchanging XCAP Diff Documents Documents at an XCAP server are identified by URIs, and updated by XCAP clients with HTTP (PUT and DELETE) methods. The XCAP server assigns a new entity tag value for each document version. An entity tag value is defined by Section 3.11 of RFC 2616 [RFC2616]: "AnRosenberg & Urpalainen Standards Track [Page 11] RFC 5874 XCAP Diff Format May 2010 entity tag MUST be unique across all versions of all entities associated with a particular resource". These entity tags are used to protect requests from making overriding changes when multiple XCAP clients update the same XCAP document. An entity tag value can be interpreted as a unique identifier to a specific version of an XCAP document in its change history. The entity tag values of XCAP resources also enable a reliable way to update the locally cached XCAP resource copies in an XCAP diff implementation. When a diff client applies XCAP diff document changes, it MUST apply a resource state change only if entity tag values match with octet-by-octet equivalence according to the table defined in Figure 1. If a diff client notices inconsistencies and/or errors when it applies reported resource changes, it SHOULD tear down the session. State changes of an XCAP document MUST be delivered reliably from a diff notifier to a diff client, and a diff client MUST be able to apply all changes of an XCAP document in the same chronological order that occurred at an XCAP server. When using an unreliable transport with retransmissions, the application protocol used with the XCAP diff MUST ensure that duplicates are dropped. If an XCAP diff delivery is lost, the diff session MUST be torn down. Note that a diff notifier can easily notice a lost notification when a diff client must respond to each XCAP diff delivery. A diff notifier doesn't necessarily report all of these XCAP document updates with ETags; it MAY skip over some intermediate version of a document, for example, with rapidly changing resources. However, it MUST always report changes consistently to a diff client so that it can properly update the latest state (content and ETag) of its locally cached resources. As an example, an XCAP document is updated by different 'a', 'b', and 'c' versions identified with the same corresponding ETag values in a relatively short period. The first reported notification contains the 'a' "new-tag" information (no "previous- etag" attribute), and the diff notifier decides to skip the update notification identified by the 'b' ETag value. The second notification to a diff client MUST then contain the 'a' "previous- etag" and 'c' "new-etag" values with optional corresponding content changes (from version 'a' to 'c'). Since XCAP documents are typically confidential, diff notifiers MUST obey the XCAP authorization rules. In practice, this means following the read privilege rules of XCAP resources when notifying the authenticated diff clients of changes. Transport SHOULD be secured by encryption.Rosenberg & Urpalainen Standards Track [Page 12] RFC 5874 XCAP Diff Format May 2010 Note: This format specification doesn't define how to select the resources whose differences a diff notifier should report. It also doesn't define whether actual content changes should be reported. Typically, however, a diff client starts a session by sending a resource listing request. Then it compares the remote resource listings with locally cached ones, and probably downloads those resources that aren't locally cached or whose entity tags differ. When a diff client receives an XCAP diff with a "previous-etag" value that matches its current cached copy of a document, it can apply the diffs to the cached copy. As it takes some time to download reference documents, and diff notifications appear after actual resource state changes, several round trips may be needed before a full synchronization is achieved, especially with rapidly changing resources.7. Security Considerations XCAP diff documents can include changes from one version of a document to another version. As a consequence, if the document itself is sensitive and requires confidentiality, integrity, or authentication, then the same applies to the XCAP diff format. Therefore, protocols that transport XCAP diff documents must provide sufficient security capabilities for transporting the document itself. Confidential XCAP documents are typically transported using TLS-encrypted (Transport Layer Security) [RFC5246] communication; see RFC 4825 [RFC4825] for further security details. When this format is used to report content changes of XCAP documents, all security considerations of RFC 5261 [RFC5261] apply. Very frequent updates of XCAP documents and/or many diff clients per subscribed resource impose a Denial-of-Service attack possibility to the servers processing XCAP diff documents. An efficient patch processing and throttling can, however, decrease the required overall processings and transactions. The SIP event package framework specified in RFC 3265 [RFC3265] is the most typical use-case for this format. Then, an end-to-end SIP encryption mechanism, such as Secure/Multipurpose Internet Mail Extensions (S/MIME) described in Section 26.2.4 of RFC 3261 [RFC3261], SHOULD be used. If that is not available, it is RECOMMENDED that TLS [RFC5246] be used between elements to provide hop-by-hop authentication and encryption mechanisms as described in Section 26.2.2 ("SIPS URI Scheme") and Section 26.3.2.2 ("Interdomain Requests") of RFC 3261 [RFC3261]. Event packages MAY also have other specific threats that MUST be considered on an application-by- application basis.Rosenberg & Urpalainen Standards Track [Page 13] RFC 5874 XCAP Diff Format May 20108. IANA Considerations There are several IANA considerations associated with this specification.8.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 the charset parameter application/xml as specified in RFC 3023 [RFC3023]. Encoding considerations: Same as the encoding considerations of application/xml as specified in RFC 3023 [RFC3023]. Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 7 of RFC 5874. Interoperability considerations: none. Published specification: This document. Applications that use this media type: This document type has been used to support manipulation of resource lists [RFC4826] using XCAP. Additional Information: 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.Rosenberg & Urpalainen Standards Track [Page 14] RFC 5874 XCAP Diff Format May 20108.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: BEGINXCAP Diff NamespaceNamespace for XCAP Diff
urn:ietf:params:xml:ns:xcap-diff
SeeRFC5874.
[8]ページ先頭