Internet Engineering Task Force (IETF) J. Urpalainen
Request for Comments: 5875 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems LLC
May 2010
Internet Engineering Task Force (IETF) J. Urpalainen
Request for Comments: 5875 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems LLC
May 2010
An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package
可扩展标记语言（XML）配置访问协议（XCAP）Diff事件包
Abstract
摘要
This document describes an "xcap-diff" SIP (Session Initiation Protocol) event package for the SIP Event Notification Framework, which clients can use to receive notifications of changes to Extensible Markup Language (XML) Configuration Access Protocol (XCAP) resources. The initial synchronization information exchange and document updates are based on the XCAP Diff format.
本文档描述了SIP事件通知框架的“xcap diff”SIP（会话启动协议）事件包，客户端可使用该事件包接收对可扩展标记语言（XML）配置访问协议（xcap）资源的更改通知。初始同步信息交换和文档更新基于XCAP Diff格式。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5875.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5875.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
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.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XCAP Diff Event Package . . . . . . . . . . . . . . . . . . . 4
4.1. Overview of Operation with Basic Requirements . . . . . . 4
4.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
4.3. 'diff-processing' Event Package Parameter . . . . . . . . 5
4.4. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 8
4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 13
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 13
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 13
5. An Initial Example NOTIFY Document . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 18
A.1. Initial Documents on an XCAP Server . . . . . . . . . . . 18
A.2. An Initial Subscription . . . . . . . . . . . . . . . . . 18
A.3. A Document Addition into a Collection . . . . . . . . . . 19
A.4. A Series of XCAP Component Modifications . . . . . . . . . 20
A.5. An XCAP Component Subscription . . . . . . . . . . . . . . 23
A.6. A Conditional Subscription . . . . . . . . . . . . . . . . 26
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. XCAP Diff Event Package . . . . . . . . . . . . . . . . . . . 4
4.1. Overview of Operation with Basic Requirements . . . . . . 4
4.2. Event Package Name . . . . . . . . . . . . . . . . . . . . 5
4.3. 'diff-processing' Event Package Parameter . . . . . . . . 5
4.4. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 6
4.5. Subscription Duration . . . . . . . . . . . . . . . . . . 8
4.6. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
4.7. Notifier Generation of NOTIFY Requests . . . . . . . . . . 8
4.8. Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
4.9. Handling of Forked Requests . . . . . . . . . . . . . . . 13
4.10. Rate of Notifications . . . . . . . . . . . . . . . . . . 13
4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 13
5. An Initial Example NOTIFY Document . . . . . . . . . . . . . . 13
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 17
Appendix A. Informative Examples . . . . . . . . . . . . . . . . 18
A.1. Initial Documents on an XCAP Server . . . . . . . . . . . 18
A.2. An Initial Subscription . . . . . . . . . . . . . . . . . 18
A.3. A Document Addition into a Collection . . . . . . . . . . 19
A.4. A Series of XCAP Component Modifications . . . . . . . . . 20
A.5. An XCAP Component Subscription . . . . . . . . . . . . . . 23
A.6. A Conditional Subscription . . . . . . . . . . . . . . . . 26
The SIP events framework [RFC3265] describes subscription and notification conventions for the Session Initiation Protocol (SIP) [RFC3261]. The Extensible Markup Language (XML) [W3C.REC-xml-20060816] Configuration Access Protocol (XCAP) [RFC4825] allows a client to read, write, and modify XML-formatted application usage data stored on an XCAP server.
SIP事件框架[RFC3265]描述了会话启动协议（SIP）[RFC3261]的订阅和通知约定。可扩展标记语言（XML）[W3C.REC-XML-20060816]配置访问协议（XCAP）[RFC4825]允许客户端读取、写入和修改存储在XCAP服务器上的XML格式的应用程序使用数据。
While XCAP allows authorized users or devices to modify the same XML document, XCAP does not provide an effective mechanism (beyond polling) to keep resources synchronized between a server and a client. This memo defines an "xcap-diff" event package that, together with the SIP event notification framework [RFC3265] and the XCAP diff format [RFC5874], allows a user to subscribe to changes in an XML document, and to receive notifications whenever the XML document changes.
虽然XCAP允许授权用户或设备修改相同的XML文档，但XCAP没有提供有效的机制（除了轮询）来保持服务器和客户端之间的资源同步。此备忘录定义了一个“xcap diff”事件包，它与SIP事件通知框架[RFC3265]和xcap diff格式[RFC5874]一起，允许用户订阅XML文档中的更改，并在XML文档更改时接收通知。
There are three basic features that this event package enables:
此事件包支持三个基本功能：
First, a client can subscribe to a list of XCAP documents' URLs in a collection located on an XCAP server. This allows a subscriber to compare server resources with its local resources using the URLs and the strong entity tag (ETag) values of XCAP documents, which are shown in the XCAP diff format, and to synchronize them.
首先，客户机可以订阅位于XCAP服务器上的集合中的XCAP文档URL列表。这允许订阅者使用XCAP文档的URL和强实体标记（ETag）值（以XCAP diff格式显示）将服务器资源与其本地资源进行比较，并同步它们。
Second, this event package can signal a change in those documents in one of three ways. The first mode only indicates the event type and does not include document contents, so the subscriber uses HTTP [RFC2616] to retrieve the updated document. The second mode includes document content changes in notification messages, using the XML-Patch-Ops [RFC5261] format with minimal notification size. The third mode also includes document content changes in notification messages with the same XML-Patch-Ops format, but is more verbose, and shows the full HTTP version history.
第二，此事件包可以通过以下三种方式之一表示这些文档中的更改。第一种模式仅指示事件类型，不包括文档内容，因此订阅者使用HTTP[RFC2616]检索更新的文档。第二种模式包括通知消息中的文档内容更改，使用最小通知大小的XML修补程序Ops[RFC5261]格式。第三种模式还包括通知消息中的文档内容更改，这些更改具有相同的XML修补程序Ops格式，但更详细，并显示完整的HTTP版本历史记录。
Third, the client can subscribe to specific XML elements or attributes (XCAP components) showing their existing contents in the resulting XCAP diff format notification messages. If the requested component does not exist but is later created, the notifier sends a notification with the component's content. The notifier also sends notifications when the subscribed XCAP components are removed, for example, after a successful HTTP DELETE request.
第三，客户机可以订阅特定的XML元素或属性（XCAP组件），在生成的XCAP diff格式通知消息中显示它们的现有内容。如果请求的组件不存在，但后来创建了该组件，则通知程序将发送包含该组件内容的通知。当订阅的XCAP组件被删除时（例如，在HTTP删除请求成功后），通知程序也会发送通知。
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, BCP 14 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119、BCP 14[RFC2119]中的描述进行解释，并指出合规实施的要求级别。
The following terms are used in this document:
本文件中使用了以下术语：
XCAP component: An XML element or an attribute, which can be updated, removed, or retrieved with XCAP.
XCAP组件：可以使用XCAP更新、删除或检索的XML元素或属性。
Aggregating: An XCAP client can update only a single XCAP component at a time using HTTP. However, a notifier may be able to aggregate a series of these modifications into a single notification using XML-Patch-Ops semantics encoded in the XCAP diff format.
聚合：XCAP客户端一次只能使用HTTP更新单个XCAP组件。但是，通知程序可以使用XCAP diff格式编码的XML修补程序Ops语义将一系列修改聚合为单个通知。
This document reuses terminology mostly defined in XCAP [RFC4825] and some in WebDAV [RFC4918].
本文档重用了XCAP[RFC4825]和WebDAV[RFC4918]中定义的术语。
To receive "xcap-diff" event package features, the subscriber indicates its interest in certain resources by including a URI list in the subscription body to the notifier. Each URL in this list MUST be an HTTP URL that identifies a collection, an XCAP document, or an XCAP component. Collection URLs MUST have a trailing forward slash "/", following the conventions of WebDAV [RFC4918]. A collection selection includes all documents in that collection and recursively all documents in sub-collections. The URL of an XCAP component consists of the document URL with the XCAP Node Selector added. Although the XCAP Node Selector allows all in-scope namespaces of an element to be requested, the client MUST NOT subscribe to namespaces.
要接收“xcap diff”事件包功能，订阅者通过在订阅主体中向通知程序包含URI列表来表示其对某些资源的兴趣。此列表中的每个URL必须是标识集合、XCAP文档或XCAP组件的HTTP URL。集合URL必须具有尾随的正斜杠“/”，遵循WebDAV[RFC4918]的约定。集合选择包括该集合中的所有文档以及子集合中的所有文档。XCAP组件的URL由添加了XCAP节点选择器的文档URL组成。尽管XCAP节点选择器允许请求元素的所有作用域内名称空间，但客户端不得订阅名称空间。
The notifier MUST support XCAP component subscriptions. The notifier sends the first notification in response to the subscription, and this first notification MUST contain the URLs of the documents and XCAP component contents that are part of the subscription. The subsequent notifications MAY contain patches to these documents. The subscriber can specify how the notifier will signal the changes of documents by using the 'diff-processing' event package parameter, covered in Section 4.3. Note that the existence of the "diff-
通知程序必须支持XCAP组件订阅。通知程序发送第一个通知以响应订阅，此第一个通知必须包含作为订阅一部分的文档和XCAP组件内容的URL。后续通知可能包含这些文档的修补程序。订阅者可以通过使用第4.3节所述的“差异处理”事件包参数，指定通知者将如何发出文件更改的信号。请注意，“diff”的存在-
processing" parameter or its value has no influence on XCAP component subscriptions.
“处理”参数或其值对XCAP组件订阅没有影响。
The name of this event package is "xcap-diff". As specified in [RFC3265], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests.
此事件包的名称为“xcap diff”。如[RFC3265]中所述，此值出现在订阅和通知请求中的事件头字段中。
With the aid of the optional "diff-processing" Event header field parameter, the subscriber indicates a preference as to how the notifier SHOULD indicate change notifications of documents. The possible values are "no-patching", "xcap-patching", and "aggregate". All three modes provide information that allows the subscriber to synchronize its local cache, but only the "xcap-patching" mode provides intermediate states of the version history. The notifier SHOULD use the indicated mode if it understands it (as doing so optimizes network traffic within the capabilities of the receiver).
借助可选的“diff processing”（差异处理）事件标题字段参数，订阅者指示通知者应如何指示文档更改通知的首选项。可能的值为“无修补”、“xcap修补”和“聚合”。这三种模式都提供了允许订阅服务器同步其本地缓存的信息，但只有“xcap修补”模式提供版本历史的中间状态。通知程序应使用指示模式（因为这样做可以在接收器的能力范围内优化网络流量）。
The "no-patching" value means that the notifier indicates only the document and the event type (creation, modification, and removal) in the notification. The notification does not necessarily indicate the full HTTP ETag change history. Notifiers MUST support the "no-patching" mode as a base-line for interoperability. The other, more complex modes are optional.
“无修补”值表示通知程序仅指示通知中的文档和事件类型（创建、修改和删除）。通知不一定表示完整的HTTP ETag更改历史记录。通知程序必须支持“无修补”模式作为互操作性的基线。另一种更复杂的模式是可选的。
The "xcap-patching" value means that the notifier includes all updated XCAP component contents and entity tag (ETag) changes made by XCAP clients (via HTTP). The client receives the full (HTTP) ETag change history of a document.
“xcap patching”值表示通知程序包括所有更新的xcap组件内容和xcap客户端（通过HTTP）所做的实体标记（ETag）更改。客户端接收文档的完整（HTTP）ETag更改历史记录。
The "aggregate" value means that the notifier MAY aggregate several individual XCAP component updates into a single XCAP diff <document> element. The policy for determining whether or not to apply aggregation or to determine how many updates to aggregate is locally determined.
“聚合”值意味着通知程序可以将几个单独的XCAP组件更新聚合到单个XCAP diff<document>元素中。用于确定是否应用聚合或确定聚合的更新次数的策略是本地确定的。
The notifier SHOULD support the "xcap-patching" and "aggregate" modes, and thus implement XML-Patch-Ops [RFC5261] diff-generation, because this can greatly reduce the required number of notifications and overall transmissions.
通知程序应该支持“xcap修补”和“聚合”模式，从而实现XML修补操作[RFC5261]差异生成，因为这可以大大减少所需的通知数量和整体传输。
If the subscription does not contain the "diff-processing" header field parameter, the notifier MUST default to the "no-patching" mode.
如果订阅不包含“差异处理”标题字段参数，通知程序必须默认为“无修补”模式。
Note: To see the difference between "xcap-patching" and "aggregate" modes, consider a document that has versions "a", "b", and "c" with corresponding ETag values "1", "2", and "3". The "xcap-patching" mode will include first the change from version "a" to "b" with the versions' corresponding "1" and "2" ETags and then the change from version "b" to "c" with their "2" and "3" ETags. The "aggregate" mode optimizes the change and indicates only a single aggregated change from "a" to "c" with the old "1" and new "3" ETags. If these changes are closely related, that is, the same element has been updated many times, the bandwidth savings are larger.
注意：为了查看“XCAP修补”和“聚合”模式之间的差异，考虑一个具有对应的ETAG值“1”、“2”和“3”的版本“A”、“B”和“C”的文档。“xcap修补”模式将首先包括从版本“a”到版本“b”的更改，以及相应的“1”和“2”ETAG，然后从版本“b”到版本“c”的更改，以及相应的“2”和“3”ETAG。“聚合”模式优化了更改，并仅指示使用旧的“1”和新的“3”ETag从“a”到“c”的单个聚合更改。如果这些更改密切相关，即同一元素已更新多次，则节省的带宽会更大。
This "diff-processing" parameter is a subscriber hint to the notifier. The notifier may respond using a simpler mode, but not a more complex one. Notifier selection of a mode is covered in Section 4.7. During re-subscriptions, the subscriber MAY change the diff-processing parameter.
此“diff processing”参数是通知程序的订户提示。通知程序可以使用更简单的模式进行响应，但不能使用更复杂的模式。第4.7节介绍了通知程序对模式的选择。在重新订阅期间，订户可以更改差异处理参数。
The formal grammar [RFC5234] of the "diff-processing" parameter is:
“diff processing”参数的形式语法[RFC5234]为：
diff-processing = "diff-processing" EQUAL ( "no-patching" / "xcap-patching" / "aggregate" / token )
diff processing=“diff processing”等于（“无修补”/“xcap修补”/“聚合”/令牌）
where EQUAL and token are defined in RFC 3261 [RFC3261].
其中，RFC 3261[RFC3261]中定义了EQUAL和token。
The URI list is described by the XCAP resource list format [RFC4826], and is included as a body of the initial SUBSCRIBE request. Only a simple subset of that format is required, a flat list of XCAP request URIs. The "uri" attribute of the <entry> element contains these URI values. The subscriber MUST NOT use hierarchical lists or <entry-ref> references, etc. (though in the future, semantics may be expanded thanks to the functionality in the resource list format). In subsequent SUBSCRIBE requests, such as those used for refreshing the expiration timer, the subscribed URI list MAY change, in which case the notifier MUST use the new list.
URI列表由XCAP资源列表格式[RFC4826]描述，并作为初始订阅请求的主体包含。只需要该格式的一个简单子集，即XCAP请求uri的平面列表。<entry>元素的“uri”属性包含这些uri值。订阅者不得使用分层列表或<entry ref>引用等（尽管在将来，由于资源列表格式中的功能，语义可能会扩展）。在后续的订阅请求中，例如那些用于刷新过期计时器的请求，订阅的URI列表可能会更改，在这种情况下，通知程序必须使用新的列表。
The SUBSCRIBE request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/ xcap-diff+xml". If the header field is present, it MUST include "application/xcap-diff+xml", and MAY include any other types.
订阅请求可能包含接受标头字段。如果不存在这样的头字段，则其默认值为“application/xcap diff+xml”。如果存在标题字段，则它必须包括“application/xcap diff+xml”，并且可以包括任何其他类型。
The SUBSCRIBE request MAY contain the Suppress-If-Match header field [RFC5839], which directs the notifier to suppress either the body of a subsequent notification or the entire notification if the ETag value matches.
SUBSCRIBE请求可能包含Suppress If Match标头字段[RFC5839]，该字段指示通知程序在ETag值匹配时抑制后续通知的正文或整个通知。
If the SUBSCRIBE body contains elements or attributes that the notifier doesn't understand, the notifier MUST ignore them.
如果订阅正文包含通知程序不理解的元素或属性，则通知程序必须忽略它们。
Subscribers need to appropriately populate the Request-URI of the SUBSCRIBE request, typically set to the URI of the notifier. This document does not constrain that URI. It is assumed that the subscriber is provisioned with or has learned the URI of the notifier of this event package.
订阅者需要适当地填充订阅请求的请求URI，通常设置为通知程序的URI。此文档不约束该URI。假定订阅服务器已配置或已学习此事件包的通知程序的URI。
The XCAP server will usually be co-located with the SIP notifier, so the subscriber MAY use relative XCAP Request-URIs. Because relative Request-URIs are allowed, the notifier MUST know how to resolve these against the correct XCAP Root URI value.
XCAP服务器通常与SIP通知程序位于同一位置，因此订户可以使用相对的XCAP请求URI。由于允许使用相对请求URI，通知程序必须知道如何根据正确的XCAP根URI值解析这些URI。
Figure 1 shows a SUBSCRIBE request and body covering several XCAP resources: a "resource-list" document, a specific element (XCAP component) in a "rls-services" document, and a collection in "pidf-manipulation" application usage. The "Content-Type" header of this SUBSCRIBE request is "application/resource-lists+xml".
图1显示了一个SUBSCRIBE请求和主体，它涵盖了几个XCAP资源：“资源列表”文档、“rls服务”文档中的一个特定元素（XCAP组件），以及“pidf操纵”应用程序用法中的一个集合。此订阅请求的“内容类型”标题为“应用程序/资源列表+xml”。
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
Expires: 4200
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
Expires: 4200
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="resource-lists/users/sip:joe@example.com/index"/>
<entry uri="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"/>
<entry uri="pidf-manipulation/"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="resource-lists/users/sip:joe@example.com/index"/>
<entry uri="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"/>
<entry uri="pidf-manipulation/"/>
</list>
</resource-lists>
Figure 1: Example subscription body
图1：示例订阅主体
When subscribing to XCAP components, namespace prefixes of XCAP Node Selectors MUST be properly resolved to namespace URIs. Section 6.4 of RFC 4825 [RFC4825] describes the conventions when using prefixes
订阅XCAP组件时，必须将XCAP节点选择器的命名空间前缀正确解析为命名空间URI。RFC 4825[RFC4825]第6.4节描述了使用前缀时的约定
in XCAP Node Selectors. If only XCAP Default Document Namespace is used, just like in the previous example (where a <service> element is selected), the query component of the "uri" value is not required.
在XCAP节点选择器中。如果只使用XCAP默认文档名称空间，就像前面的示例（其中选择了<service>元素），则不需要“uri”值的查询组件。
The default expiration time for subscriptions within this package is 3600 seconds. As per RFC 3265 [RFC3265], the subscriber MAY specify an alternative expiration timer in the Expires header field.
此包中订阅的默认过期时间为3600秒。根据RFC 3265[RFC3265]，订阅者可以在Expires报头字段中指定替代过期计时器。
The format of the NOTIFY message body either is the default of "application/xcap-diff+xml" or is a format listed in the Accept header field of the SUBSCRIBE.
NOTIFY消息正文的格式要么是默认的“application/xcap diff+xml”，要么是订阅的Accept header字段中列出的格式。
In this event package, notification messages contain an XCAP diff document [RFC5874].
在此事件包中，通知消息包含XCAP diff文档[RFC5874]。
The XCAP diff format [RFC5874] can include the subscribed XCAP component contents. For documents, the format can also include corresponding URIs, ETag values, and patching instructions from version "a" to "b". Removal events (of documents, elements, or attributes) can be identified too. Except for collection selections, the "sel" selector values of the XCAP diff format MUST be octet-by-octet equivalent to the relevant "uri" parameter values of the <entry> element of the "resource-list" document.
XCAP diff格式[RFC5874]可以包括订阅的XCAP组件内容。对于文档，格式还可以包括相应的URI、ETag值以及从版本“a”到“b”的修补说明。也可以识别删除事件（文档、元素或属性）。除集合选择外，XCAP diff格式的“sel”选择器值必须是八位字节，相当于“资源列表”文档的<entry>元素的相关“uri”参数值。
With XCAP component subscriptions, XCAP Node Selectors can contain namespace prefixes. A notifier MUST then resolve these prefixes to namespace URIs according to RFC 4825 [RFC4825] conventions. In other words, notifiers MUST be aware of XCAP Default Document Namespaces for Application Usages when they locate unprefixed qualified XCAP elements. Note that the namespace resolving rules of Patch operation elements <add>, <replace>, and <remove> are described in Section 4.2.1 of [RFC5261].
对于XCAP组件订阅，XCAP节点选择器可以包含名称空间前缀。然后，通知程序必须根据RFC 4825[RFC4825]约定将这些前缀解析为命名空间URI。换句话说，通知程序在定位未固定的限定XCAP元素时，必须知道应用程序使用的XCAP默认文档名称空间。请注意，[RFC5261]的第4.2.1节描述了补丁操作元素<add>、<replace>和<remove>的名称空间解析规则。
During the initial subscription, or if the URI list changes in SUBSCRIBE refresh requests, the notifier MUST resolve the requested XCAP resources and their privileges. If there are superfluous resource selections in the requested URI list, the notifier SHOULD NOT provide overlapping similar responses for these resources. A resource for which an authenticated user does not have a read privilege MUST NOT be included in the XCAP diff format. Note that an XCAP component that could not be located with XCAP semantics does not produce an error. Instead, the request remains in a "pending" state,
在初始订阅期间，或者如果订阅刷新请求中的URI列表发生更改，通知程序必须解析请求的XCAP资源及其权限。如果请求的URI列表中有多余的资源选择，通知程序不应为这些资源提供重叠的类似响应。已验证用户没有读取权限的资源不得包含在XCAP diff格式中。请注意，无法使用XCAP语义定位的XCAP组件不会产生错误。相反，请求仍处于“挂起”状态，
that is, waiting for this resource to be created (or read access granted if XCAP Application Usages utilize dynamic access control lists). Subscriptions to collections have a similar property: once a new document is created into the subscribed collection, the creation of a new resource is signaled with the next NOTIFY request.
也就是说，等待创建此资源（或者如果XCAP应用程序使用动态访问控制列表，则授予读取访问权）。对集合的订阅具有类似的属性：一旦在订阅的集合中创建了新文档，新资源的创建将通过下一个NOTIFY请求发出信号。
After the notifier knows the list of authorized XCAP resources, it generates the first NOTIFY, which contains URI references to all subscribed, existing documents for which the subscriber has read privileges, and typically XCAP component(s) of existing content.
通知程序知道授权的XCAP资源列表后，会生成第一个通知，其中包含对所有订阅的、订阅者具有读取权限的现有文档的URI引用，通常还包含现有内容的XCAP组件。
After sending the initial notification, the notifier selects a diff-processing mode for reporting changes. If the subscriber suggested a mode in the "diff-processing" parameter of the SUBSCRIBE, the notifier MAY use that requested mode or MAY fall back to a simpler operational mode, but the notifier MUST NOT use a more complex mode than the one chosen by the subscriber. From least to most complex, the order of the modes is the following: "no-patching", "xcap-patching", "aggregate". Thus, the notifier may respond to an "aggregate" request using any mode, but cannot reply to an "xcap-patching" subscription using the "aggregate" mode. Naturally, the notifier MUST handle a "no-patching" request with the "no-patching" mode.
发送初始通知后，通知程序选择一种差异处理模式来报告更改。如果订阅者在订阅的“diff processing”参数中建议了一种模式，则通知者可以使用该请求的模式，也可以退回到更简单的操作模式，但通知者不得使用比订阅者选择的模式更复杂的模式。从最小到最复杂，模式的顺序如下：“无修补”、“xcap修补”、“聚合”。因此，通知程序可以使用任何模式响应“聚合”请求，但不能使用“聚合”模式响应“xcap修补”订阅。当然，通知程序必须以“无修补”模式处理“无修补”请求。
In all modes, the notifier MUST maintain the chronological order of XCAP changes. If several changes to a given resource are presented in a single notification, the chronological update order MUST be preserved in the XML document order of the notification body. Chronological order is preserved to simplify the required subscriber implementation logic.
在所有模式下，通知程序都必须保持XCAP更改的时间顺序。如果在单个通知中显示对给定资源的多个更改，则按时间顺序排列的更新顺序必须保留在通知正文的XML文档顺序中。保留时间顺序以简化所需的订户实现逻辑。
While the "aggregate" mode uses bandwidth most efficiently, it introduces other challenges. The initial synchronization might fail with rapidly changing resources, because the "aggregate" mode messages might not include the full version history of a document and the base XCAP protocol does not support version history retrievals of documents. When new documents are created in subscribed collections and the notifier is aggregating patches, the same issue can occur. In a corner case (such as when the XML prolog changes), the notifier may not be able to provide patches with the XML-Patch-Ops [RFC5261] semantics.
虽然“聚合”模式最有效地使用带宽，但它带来了其他挑战。资源快速变化时，初始同步可能会失败，因为“聚合”模式消息可能不包括文档的完整版本历史记录，并且基本XCAP协议不支持文档的版本历史记录检索。当在订阅的集合中创建新文档并且通知程序正在聚合修补程序时，同样的问题也会发生。在极端情况下（例如当XML序言更改时），通知程序可能无法提供具有XML修补程序Ops[RFC5261]语义的修补程序。
If the notifier has to temporarily disable diff generation and send only the URI references of some changed documents to the subscriber, it MUST continue with the "xcap-patching" mode afterwards for these resources, if the initial subscription also started with the "xcap-patching" mode.
如果通知程序必须临时禁用diff生成并仅将某些更改文档的URI引用发送给订阅服务器，则如果初始订阅也以“xcap patching”模式启动，则随后必须继续使用这些资源的“xcap patching”模式。
Note: The diff-generation may be disabled when the NOTIFY body becomes impractically large or an intermediate error has happened. As the subscriber loses track of the patching operations, it must refresh to a "known good" state by downloading current documents. Once it has done so, it can re-subscribe, for example, with the "aggregate" mode.
注意：当NOTIFY body变得非常大或发生中间错误时，可能会禁用diff生成。由于订阅者无法跟踪修补操作，它必须通过下载当前文档刷新到“已知良好”状态。一旦这样做了，它就可以重新订阅，例如，使用“聚合”模式。
In the "aggregate" mode, the notifier chooses how long to wait for multiple patches to combine and how this combination is done.
在“聚合”模式下，通知程序选择等待多个修补程序组合的时间以及组合方式。
In the "xcap-patching" mode, the notifier MAY try to optimize the diff-generation, for example, by eliminating redundant information since some XCAP clients will probably not have completely optimized their HTTP PUT request.
在“xcap修补”模式下，通知程序可能会尝试优化差异生成，例如，通过消除冗余信息，因为某些xcap客户端可能没有完全优化其HTTP PUT请求。
Note: It is straightforward to change the XCAP client's change requests: PUT and DELETE (sent via HTTP) to use XML-Patch-Ops semantics. While XCAP does not support patching of all XML node types -- for example, namespace declarations cannot be added separately -- efficient utilization of XML-Patch-Ops can sometimes significantly reduce the bandwidth requirements at the expense of extra processing.
注意：将XCAP客户机的更改请求：PUT和DELETE（通过HTTP发送）更改为使用XML修补程序操作语义非常简单。虽然XCAP不支持对所有XML节点类型进行修补（例如，不能单独添加名称空间声明），但高效利用XML修补操作有时可以显著降低带宽需求，而牺牲额外的处理。
After the notifier has reported the existence of an XCAP component, it MUST also report its removal consistently. For example, the removal of the parent element of the subscribed element requires the same signaling since the subscribed element ceases to exist. To signal the removal of an XCAP component, the notifier sets the Boolean "exist" attribute value of the <element> or <attribute> elements to false. Even with rapidly changing resources, the notifier MUST signal only the latest state: e.g., whether or not the XCAP component exists.
通知程序报告存在XCAP组件后，还必须一致报告其删除情况。例如，由于订阅元素不再存在，移除订阅元素的父元素需要相同的信令。为了发出删除XCAP组件的信号，通知程序将<element>或<attribute>元素的布尔“exist”属性值设置为false。即使在资源快速变化的情况下，通知程序也必须仅发出最新状态的信号：例如，XCAP组件是否存在。
When the notifier receives a re-subscription, it MUST re-send the current full XML diff content unless the subscriber has requested a conditional subscription [RFC5839] by using the header field Suppress-If-Match: [ETag value]. With a conditional re-subscription, the notifier MUST also inspect the subscription body when determining the current subscription state. Since the subscription is based on a list of XCAP request URIs, it is RECOMMENDED that the notifier does not consider the order of these URIs when determining the equivalence to "stored" previous states. If a match to the previous state is not found, the NOTIFY message MUST contain the full XML diff state (similar to the initial notification). The notifiers SHOULD implement the conditional subscription handling with this event package.
当通知程序收到重新订阅时，它必须重新发送当前完整的XML diff内容，除非订阅者使用标头字段Suppress If Match:[ETag value]请求条件订阅[RFC5839]。对于有条件的重新订阅，通知程序在确定当前订阅状态时还必须检查订阅正文。由于订阅是基于XCAP请求URI的列表，建议通知器在确定等价于“存储”的先前状态时不考虑这些URI的顺序。如果未找到与前一状态的匹配项，则通知消息必须包含完整的XML差异状态（类似于初始通知）。通知程序应使用此事件包实现条件订阅处理。
During re-subscriptions, the subscriber may change the value of the diff-processing parameter. The value change influences only subsequent notifications, not the notification (if generated) followed immediately after the (re-)SUBSCRIBE request.
在重新订阅期间，订阅者可以更改diff处理参数的值。值更改仅影响后续通知，而不影响（重新）订阅请求之后紧接的通知（如果生成）。
Event packages like this require reliable transfer of NOTIFY messages. This means that all messages MUST successfully be transferred or the document will become out of sync, and then patches will most likely fail (or worse, have unintended consequences). This "xcap-diff" event package requires, similar to Partial-PIDF-Notify RFC 5263 [RFC5263], that a notifier MUST NOT send a new NOTIFY request to the same dialog unless a successful 200-response has been received for the last sent NOTIFY request. If the NOTIFY request fails due to a timeout, the notifier MUST remove the subscription.
像这样的事件包需要可靠地传输NOTIFY消息。这意味着必须成功传输所有消息，否则文档将变得不同步，然后修补程序很可能会失败（或者更糟，会产生意外后果）。与部分PIDF Notify RFC 5263[RFC5263]类似，此“xcap diff”事件包要求通知程序不得向同一对话框发送新的Notify请求，除非已收到上次发送的Notify请求的成功200响应。如果NOTIFY请求因超时而失败，则通知程序必须删除订阅。
Note: This requirement ensures that out-of-order events will not happen or that the dialog will terminate after non-resolvable NOTIFY request failures. In addition, some of the probable NOTIFY error responses (for example, 401, 407, 413) can possibly be handled gracefully without tearing down the dialog.
注意：此要求确保不会发生无序事件，或者对话框将在不可解析的NOTIFY请求失败后终止。此外，一些可能的NOTIFY错误响应（例如401407413）可以在不破坏对话框的情况下优雅地处理。
If, for example, the subscriber has selected too many elements to which to subscribe, such that the notification body would be impractically large (that is, an intermediate NOTIFY failure), the notifier MAY discard the <element> element content. The existence of elements is then indicated with an empty <element> element, and the content is not shown for those resources. In other words, the <element> element does not have a child element that would show the subscribed "full" element content.
例如，如果订阅者选择了太多要订阅的元素，使得通知主体将不切实际地大（即，中间通知失败），则通知者可以丢弃<element>元素内容。元素的存在然后用一个空的<element>元素来表示，这些资源的内容不显示。换句话说，<element>元素没有显示订阅的“完整”元素内容的子元素。
The first NOTIFY request will usually contain references to HTTP resources including their strong ETag values. If the subscriber does not have similar locally cached versions, it will typically start an unconditional HTTP GET request for those resources. During this HTTP retrieval time, the subscriber MAY also receive patches to these documents if it has requested them and if the documents are changing rapidly. It can happen that the version retrieved by HTTP is not the same than what is indicated in the initial notification. A subscriber can then chain the modification list for each document, and locate the position where the previous ETag value is equal to that retrieved via HTTP. If an ETag match is not found from the first change, a subscriber MUST omit all changes up to the point where it is the same. From that change onwards, the subscriber applies all reported patches. If the version received via HTTP is newer than any received via the notifications, the subscriber may not find an equivalent match of an ETag value from the chain of patches.
第一个NOTIFY请求通常包含对HTTP资源的引用，包括它们的强ETag值。如果订阅服务器没有类似的本地缓存版本，它通常会对这些资源启动无条件HTTP GET请求。在HTTP检索期间，如果订阅者请求了这些文档的补丁，并且文档正在快速更改，则订阅者也可能会收到这些文档的补丁。HTTP检索到的版本可能与初始通知中指示的版本不同。然后，订阅者可以链接每个文档的修改列表，并找到前一个ETag值等于通过HTTP检索到的值的位置。如果在第一次更改中未找到ETag匹配项，则订阅服务器必须忽略所有更改，直到更改相同为止。从该更改开始，订阅服务器将应用所有报告的修补程序。如果通过HTTP接收到的版本比通过通知接收到的任何版本都要新，则订阅者可能无法从补丁链中找到ETag值的等效匹配项。
This can happen since notifications are reported after HTTP changes and preferably at some minimum intervals. Also, document removals can be reported in notifications and/or HTTP retrievals may fail because of unexisting resources (rapidly changing). In any case, the subscriber can re-fetch the possible out-of-sync document, wait for subsequent notifications or refresh the subscription (with "xcap-patching"), and repeat the described "sync" algorithm until a "full" sync is achieved.
这种情况可能发生，因为通知是在HTTP更改之后报告的，最好是在一些最小的时间间隔内报告。此外，可以在通知中报告文档删除和/或HTTP检索可能因资源不可用（快速变化）而失败。在任何情况下，订户都可以重新获取可能的不同步文档，等待后续通知或刷新订阅（使用“xcap修补”），并重复所述的“同步”算法，直到实现“完全”同步。
If the notifier aggregates patches, the previous modification list may not contain the ETag value retrieved by HTTP simply because of aggregation optimizations. A similar out-of-sync cycle can happen when new (subscribed) documents are created that change rapidly. To avoid such difficulties, the subscriber MAY start the subscription with the "xcap-patching" mode, and then refresh the subscription with the "aggregate" mode after the initial sync is achieved. Naturally, the subscriber can revert back to the "xcap-patching" mode from "aggregate" at any time and vice versa.
如果通知程序聚合修补程序，则由于聚合优化，先前的修改列表可能不包含HTTP检索到的ETag值。当创建快速变化的新（订阅）文档时，也可能出现类似的不同步周期。为避免此类困难，订户可以使用“xcap补丁”模式启动订阅，然后在实现初始同步后使用“聚合”模式刷新订阅。当然，用户可以随时从“聚合”恢复到“xcap修补”模式，反之亦然。
If the subscriber has received a "full" sync and it has detected that some of the resources are being served with the "xcap-patching" mode while others are in the "aggregate" mode, it SHOULD refresh the subscription to the "aggregate" mode.
如果订阅服务器已接收到“完全”同步，并且它检测到某些资源正在以“xcap修补”模式提供服务，而其他资源则处于“聚合”模式，则它应将订阅刷新到“聚合”模式。
The notifier MAY at any time temporarily use the "no-patching" mode for some resources so that the subscriber receives only URI references of modifications. When the notifier is acting in this mode, several cycles MAY be needed before an initial "full" sync is achieved. As the notifier MAY change modes in the middle of a dialog, the subscriber is always responsible for taking appropriate actions. Also, as the last resort, the subscriber MAY always disable the usage of diff-processing by setting the "diff-processing" parameter to "no-patching".
通知程序可在任何时候临时对某些资源使用“无修补”模式，以便订户仅接收修改的URI引用。当通知程序在此模式下运行时，可能需要几个周期才能实现初始“完全”同步。当通知器可以改变对话中间的模式时，订阅者总是负责采取适当的行动。此外，作为最后的手段，订户可以通过将“diff processing”参数设置为“no patching”来禁用diff processing的使用。
If a diff format cannot be applied due to patch processing and/or programming errors (for a list, see Section 5.1 of [RFC5261]), the subscriber SHOULD refresh the subscription and disable patching by setting the "diff-processing" parameter to "no-patching". The subscriber SHOULD NOT reply with a non-200 response since the notifier cannot make corrections.
如果由于补丁处理和/或编程错误而无法应用diff格式（有关列表，请参阅[RFC5261]第5.1节），订户应刷新订阅并通过将“diff PROCESSION”参数设置为“no patching”禁用补丁。订阅者不应回复非200响应，因为通知程序无法进行更正。
During unconditional re-subscriptions, the subscriber MUST stamp the received state of all previous resources as stale. However, if a conditional [RFC5839] re-subscription is successful, the subscriber MUST preserve the current state of resources unless the subscribed URI list has changed. That is, the subscriber MUST fetch the resource's state, for example, from some local cache.
在无条件重新订阅期间，订阅服务器必须将以前所有资源的接收状态标记为过时。但是，如果有条件的[RFC5839]重新订阅成功，订阅服务器必须保留资源的当前状态，除非订阅的URI列表已更改。也就是说，订阅服务器必须获取资源的状态，例如，从某个本地缓存获取。
This specification allows only a single dialog to be constructed from an initial SUBSCRIBE request. If the subscriber receives forked responses to a SUBSCRIBE, the subscriber MUST apply the procedures in Section 4.4.9 of RFC 3265 [RFC3265] for handling non-allowed forked requests.
此规范仅允许从初始订阅请求构造单个对话框。如果订户收到对订阅的分叉响应，订户必须应用RFC 3265[RFC3265]第4.4.9节中的程序来处理不允许的分叉请求。
Notifiers of an "xcap-diff" event package SHOULD NOT generate notifications for a single subscription at a rate of more than once every five seconds.
“xcap diff”事件包的通知程序不应以每五秒钟超过一次的速率为单个订阅生成通知。
State agents play no role in this package.
州代理在此包中不起作用。
Figure 2 shows an example initial XCAP diff format document provided by the first NOTIFY request to the SUBSCRIBE example in Figure 1. The following is an example Event header field for this SUBSCRIBE request:
图2显示了一个示例初始XCAP diff格式文档，该文档由图1中的订阅示例的第一个NOTIFY请求提供。以下是此订阅请求的示例事件标头字段：
Event: xcap-diff; diff-processing=aggregate
Event: xcap-diff; diff-processing=aggregate
The subscriber requests that the notifier "aggregate" XCAP component updates and anticipates that the subsequent notifications will contain aggregated patches to these documents.
订户请求通知程序“聚合”XCAP组件更新，并预期后续通知将包含这些文档的聚合修补程序。
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns:s="urn:ietf:params:xml:ns:rls-services"
xcap-root="http://xcap.example.com/root/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xmlns:s="urn:ietf:params:xml:ns:rls-services"
xcap-root="http://xcap.example.com/root/">
<d:document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/index"/>
<d:document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/index"/>
<d:document new-etag="30376adf"
sel="pidf-manipulation/users/sip:joe@example.com/index"/>
<d:document new-etag="30376adf"
sel="pidf-manipulation/users/sip:joe@example.com/index"/>
<d:element sel="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><s:service uri="sip:marketing@example.com">
<s:list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</s:list>
<s:packages>
<s:package>presence</s:package>
</s:packages>
</s:service></d:element>
<d:element sel="rls-services/users/sip:joe@example.com/index/
~~/*/service%5b@uri='sip:marketing@example.com'%5d"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
><s:service uri="sip:marketing@example.com">
<s:list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</s:list>
<s:packages>
<s:package>presence</s:package>
</s:packages>
</s:service></d:element>
</d:xcap-diff>
</d:xcap-diff>
Figure 2: An example initial XCAP diff format document
图2：初始XCAP diff格式文档示例
Note that the resource-list "index" document included only the new ETag value, as the document existed during the subscription time. In the "pidf-manipulation" collection, there is only a single document for which the user has read privileges. The <service> element exists within the rls-services "index" document and its content is shown. Note also that the <service> element was located using the Default Document Namespace (no prefix in XCAP Node Selector value) although it has an "s" prefix in the source document.
请注意，资源列表“索引”文档仅包含新的ETag值，因为该文档在订阅期间存在。在“pidf操纵”集合中，只有一个文档用户具有读取权限。<service>元素存在于rls服务“索引”文档中，并显示其内容。还要注意，<service>元素是使用默认文档名称空间（XCAP节点选择器值中没有前缀）定位的，尽管它在源文档中有一个“s”前缀。
IANA has added a new event package to the SIP Event Types Namespace registry as follows:
IANA向SIP事件类型命名空间注册表添加了一个新的事件包，如下所示：
Package Name Type Contact Reference
------------- -------- ------- ---------
xcap-diff package IETF Real-time Applications [RFC5875]
<rai@ietf.org>
Package Name Type Contact Reference
------------- -------- ------- ---------
xcap-diff package IETF Real-time Applications [RFC5875]
<rai@ietf.org>
This document defines a new SIP event package for the SIP event notification framework specified in RFC 3265 [RFC3265]. As such, all the security considerations of RFC 3265 apply. The configuration data can contain sensitive information, and both the client and the server need to authenticate each other. The notifiers MUST authenticate the "xcap-diff" event package subscriber using the normal SIP authentication mechanisms, for example, Digest as defined in Section 22 of RFC 3261 [RFC3261]. The notifiers MUST be aware of XCAP User Identifiers (XUI) and how to map the authenticated SIP identities unambiguously with XUIs.
本文档为RFC 3265[RFC3265]中指定的SIP事件通知框架定义了一个新的SIP事件包。因此，RFC 3265的所有安全注意事项均适用。配置数据可能包含敏感信息，客户端和服务器都需要相互验证。通知程序必须使用正常的SIP身份验证机制（例如，RFC 3261[RFC3261]第22节中定义的摘要）对“xcap diff”事件包订户进行身份验证。通知程序必须知道XCAP用户标识符（XUI）以及如何将经过身份验证的SIP标识明确地映射到XUI。
Since XCAP [RFC4825] provides a basic authorization policy for resources and since notifications contain content similar to XCAP resources, the security considerations of XCAP also apply. The notifiers MUST obey the XCAP authorization rules when signalling resource changes. In practice, this means following the read privilege rules of XCAP resources.
由于XCAP[RFC4825]为资源提供了基本的授权策略，并且由于通知包含类似于XCAP资源的内容，所以XCAP的安全注意事项也适用。在发送资源更改信号时，通知程序必须遵守XCAP授权规则。实际上，这意味着遵循XCAP资源的读取权限规则。
Denial-of-service attacks against notifiers deserve special mention. The following can cause denial of service due to intensive processing: subscriptions to a long list of URIs, "pending" subscriptions to non-existent documents or XCAP components, and diff-generation algorithms that try to optimize the required bandwidth usage to extremes.
对通知程序的拒绝服务攻击值得特别提及。由于密集处理，以下情况可能会导致拒绝服务：对一长串URI的订阅、“挂起”对不存在的文档或XCAP组件的订阅，以及尝试将所需带宽使用优化到极致的差异生成算法。
The mechanism used for conveying xcap-diff event information MUST ensure integrity and SHOULD ensure confidentially of the information. An end-to-end SIP encryption mechanism, such as 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 described in Sections 26.2.2 ("SIPS URI Scheme") and 26.3.2.2 ("Interdomain Requests") of RFC 3261 [RFC3261].
用于传输xcap diff事件信息的机制必须确保完整性，并应确保信息的机密性。应使用端到端SIP加密机制，如RFC 3261[RFC3261]第26.2.4节中描述的S/MIME。如果不可用，建议在元素之间使用TLS[RFC5246]，以提供RFC 3261[RFC3261]第26.2.2节（“SIPS URI方案”）和第26.3.2.2节（“域间请求”）中描述的逐跳身份验证和加密机制。
The author would like to thank Jonathan Rosenberg for his valuable comments and for providing the initial event package, and Aki Niemi, Pekka Pessi, Miguel Garcia, Pavel Dostal, Krisztian Kiss, Anders Lindgren, Sofie Lassborn, Keith Drage, Stephen Hinton, Byron Campen, Avshalom Houri, Ben Campbell, Paul Kyzivat, Spencer Dawkins, Pasi Eronen, and Chris Newman for their valuable comments. Lisa Dusseault critiqued the document during IESG review, raising numerous issues that resulted in improved document quality. Further, technical writer A. Jean Mahoney devoted countless hours to integrating Lisa's comments and cleaning up the technical English usage.
作者要感谢乔纳森·罗森博格的宝贵评论和提供的初始活动包，以及阿基·尼米、佩卡·佩西、米格尔·加西亚、帕维尔·多斯塔、克里斯蒂安·基斯、安德斯·林格伦、索菲·拉斯伯恩、基思·德拉格、斯蒂芬·辛顿、拜伦·坎本、保罗·基齐瓦特、斯宾塞·道金斯、帕西·艾隆、，以及克里斯·纽曼的宝贵评论。Lisa Dusseault在IESG审查期间批评了该文件，提出了许多问题，从而提高了文件质量。此外，技术作家A.Jean Mahoney花了无数时间整合Lisa的评论，清理技术英语的用法。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825]Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826]Rosenberg，J.，“用于表示资源列表的可扩展标记语言（XML）格式”，RFC 4826，2007年5月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261]Urpalainen，J.，“利用XML路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 52612008年9月。
[RFC5839] Niemi, A. and D. Willis, "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.
[RFC5839]Niemi，A.和D.Willis，“用于条件事件通知的会话启动协议（SIP）事件的扩展”，RFC 5839，2010年5月。
[RFC5874] Rosenberg, J. and J. Urpalainen, "An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources", RFC 5874, May 2010.
[RFC5874]Rosenberg，J.和J.Urpalainen，“用于指示XML配置访问协议（XCAP）资源更改的可扩展标记语言（XML）文档格式”，RFC 5874，2010年5月。
[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[RFC4918]Dusseault，L.，“用于Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月。
[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008.
[RFC5263]Lonnfors，M.，Costa Requena，J.，Leppanen，E.，和H.Khartabil，“存在信息部分通知的会话启动协议（SIP）扩展”，RFC 5263，2008年9月。
[W3C.REC-xml-20060816] Paoli, J., Bray, T., Yergeau, F., Maler, E., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml-20060816, August 2006, <http://www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-xml-20060816]Paoli，J.，Bray，T.，Yergeau，F.，Maler，E.，和C.Sperberg McQueen，“可扩展标记语言（xml）1.0（第四版）”，万维网联盟第一版REC-xml-20060816，2006年8月<http://www.w3.org/TR/2006/REC-xml-20060816>.
These examples illustrate the basic features of the xcap-diff event package. Only the relevant header fields are shown. Note also that the SIP request URIs of these examples don't correspond to reality.
这些示例说明了xcap diff事件包的基本功能。仅显示相关的标题字段。还要注意，这些示例的SIP请求URI与实际情况不符。
The following documents exist on an XCAP server (xcap.example.com) with an imaginary "tests" application usage (there's no Default Document Namespace defined in this imaginary application usage).
以下文档存在于一个XCAP服务器（XCAP.example.com）上，该服务器具有一个虚构的“tests”应用程序用法（在这个虚构的应用程序用法中没有定义默认的文档命名空间）。
http://xcap.example.com/tests/users/sip:joe@example.com/index:
http://xcap.example.com/tests/users/sip:joe@example.com/index:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a sample document</note>
</doc>
and then
然后
http://xcap.example.com/tests/users/sip:john@example.com/index:
http://xcap.example.com/tests/users/sip:john@example.com/index:
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
The following demonstrates the listing of collection contents and it shows only resources where the user has read privileges. The user Joe, whose XUI is "sip:joe@example.com", sends an initial subscription:
下面演示了集合内容的列表，并仅显示用户具有读取权限的资源。用户Joe的XUI是“sip:joe@example.com“，发送初始订阅：
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
In addition to the 200 (OK) response, the notifier sends the first NOTIFY:
除了200（确定）响应外，通知程序还发送第一个通知：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>
</xcap-diff>
</xcap-diff>
The subscriber learns that the document on this "tests" application usage is equivalent to its locally cached version, so it does not act. If the local version had been different, the subscriber would most likely re-fetch the document.
订阅者了解到，此“测试”应用程序使用情况的文档与其本地缓存版本等效，因此它不会执行操作。如果本地版本不同，订阅者很可能会重新获取文档。
If the subscriber had requested the "tests/users/" collection, the notification body would have been the same since Joe has no read privileges to John's resources (XCAP default behavior).
如果订户请求了“tests/users/”集合，那么通知主体将是相同的，因为Joe对John的资源没有读取权限（XCAP默认行为）。
If the Expires header field had a value "0", the request would be similar to the PROPFIND method of WebDAV. The syntax and responses differ, however.
如果Expires头字段的值为“0”，则请求类似于WebDAV的PROPFIND方法。但是，语法和响应不同。
Let's say that Joe adds a new document to his collection, using either the same client or another client running on a different device. He does an HTTP PUT to his application usage collection:
假设Joe使用同一个客户机或运行在不同设备上的另一个客户机将一个新文档添加到他的集合中。他对其应用程序使用情况集合执行HTTP PUT：
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</doc>
This HTTP PUT request results in the XCAP client receiving a strong HTTP ETag "terteer" for this new document.
此HTTP PUT请求导致XCAP客户端接收到此新文档的强HTTP ETag“terteer”。
Then the subscriber receives a notification afterwards:
然后，订户随后收到通知：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>
</xcap-diff>
Note that the result is "additive"; it doesn't indicate the already indicated "index" document. Only the initial (or refreshed) notification contains all document URI references.
注意，结果是“加法”；它不表示已经指示的“索引”文档。只有初始（或刷新）通知包含所有文档URI引用。
If Joe's client both modifies the documents and refreshes the subscriptions, it would typically ignore this notification, since its modifications had caused the notification. If the client that received this NOTIFY hadn't submitted the document change, it would probably fetch this new document.
如果Joe的客户端同时修改文档和刷新订阅，它通常会忽略此通知，因为它的修改导致了此通知。如果收到此通知的客户端没有提交文档更改，它可能会获取此新文档。
If Joe's client refreshes the subscription with the same request body as in the initial subscription, the result will include these two documents: "index" and "another_document" with their ETags.
如果Joe的客户端使用与初始订阅中相同的请求主体刷新订阅，结果将包括这两个文档：“索引”和“另一个文档”及其ETag。
Now Joe's client uses its XCAP patching capability by doing the following:
现在，Joe的客户端通过执行以下操作来使用其XCAP修补功能：
PUT /tests/users/sip:joe@example.com/index/~~/doc/foo HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/foo HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<foo>this is a new element</foo>
<foo>this is a new element</foo>
Since the insertion of the element is successful, Joe's client receives the new HTTP ETag "fgherhryt3" of the updated "index" document.
由于元素的插入成功，Joe的客户机将收到更新的“索引”文档的新HTTP ETag“fgherhryt3”。
Immediately thereafter, Joe's client issues another HTTP request (this request could even be pipe-lined):
紧接着，Joe的客户机发出另一个HTTP请求（该请求甚至可以是管道）：
PUT /tests/users/sip:joe@example.com/index/~~/doc/bar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/bar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<bar>this is a bar element
</bar>
<bar>this is a bar element
</bar>
The reported new HTTP ETag of "index" is now "dgdgdfgrrr".
报告的“索引”的新HTTP ETag现在是“DGDFGRRR”。
And Joe's client issues yet another HTTP request:
Joe的客户端发出了另一个HTTP请求：
PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<foobar>this is a foobar element</foobar>
<foobar>this is a foobar element</foobar>
The reported new ETag of "index" is now "63hjjsll".
报告的“索引”新ETag现在是“63hjjsll”。
After awhile, Joe's client receives a notification with an embedded patch since it has requested "aggregate" diff-processing and the notifier is capable of producing them:
一段时间后，Joe的客户端收到一个带有嵌入补丁的通知，因为它已请求“聚合”差异处理，并且通知程序能够生成它们：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>
</d:xcap-diff>
</d:xcap-diff>
Joe's client applies this patch to the locally cached "index" document, detects the ETag update, and stores the last ETag value. Note how several XCAP component modifications were aggregated.
Joe的客户端将此修补程序应用于本地缓存的“索引”文档，检测ETag更新，并存储最后一个ETag值。注意几个XCAP组件修改是如何聚合的。
Note also that, if Joe's client did not have a locally cached version of the reference document, it would have needed to do an HTTP GET request after the initial notification. If the ETag of the received resource by HTTP did not match either the previous or new ETag of this aggregated patch, an out-of-sync condition would be probable. This issue is not typical, but it can happen. To resolve the issue, the client could re-fetch the "index" document and/or wait for subsequent notifications to detect a match. A better and simpler way to avoid the issue is to refresh the subscription with the "xcap-patching" mode and later refresh with the "aggregate" mode.
还要注意，如果Joe的客户机没有本地缓存版本的参考文档，那么它需要在初始通知之后执行HTTPGET请求。如果HTTP接收到的资源的ETag与此聚合修补程序的先前或新ETag不匹配，则可能出现不同步情况。这个问题并不典型，但也可能发生。要解决此问题，客户端可以重新获取“索引”文档和/或等待后续通知以检测匹配。避免此问题的更好、更简单的方法是使用“xcap修补”模式刷新订阅，然后使用“聚合”模式刷新。
Alternatively, if the notifier's operational mode been "xcap-patching", the NOTIFY could have been the following:
或者，如果通知程序的操作模式为“xcap修补”，则通知可能为以下内容：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this is a new element</foo></d:add></d:document>
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this is a new element</foo></d:add></d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this is a bar element
</bar></d:add></d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this is a bar element
</bar></d:add></d:document>
<d:document previous-etag="dgdgdfgrrr"
<d:document previous-etag="dgdgdfgrrr"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this is a foobar element</foobar></d:add></d:document>
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this is a foobar element</foobar></d:add></d:document>
</d:xcap-diff>
</d:xcap-diff>
If the client had to re-fetch the "index" document after the initial notification, it could have skipped some or all of these patches, depending on whether the HTTP ETag matched some of these ETags in the chain of patches. If the HTTP ETag did not match and the received HTTP version is a newer version indicated in later notification(s), the sync may then be achieved since the notifier provided the full change history in the "xcap-patching" mode.
如果客户端在初始通知后必须重新获取“索引”文档，则它可能跳过了部分或所有这些修补程序，这取决于HTTP ETag是否匹配修补程序链中的某些ETag。如果HTTP ETag不匹配，并且收到的HTTP版本是稍后通知中指示的较新版本，则可以实现同步，因为通知程序在“xcap修补”模式下提供了完整的更改历史记录。
Last, the notifier could (temporarily) fall back to the "no-patching" mode, which allows the notifier to keep the dialog alive when there are too many updates:
最后，通知程序可能（暂时）退回到“无修补”模式，这允许通知程序在更新过多时保持对话框处于活动状态：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll"/>
<document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll"/>
</xcap-diff>
</xcap-diff>
At any time, the notifier may fall back to the "no-patching" mode for some or all of the subscribed documents.
在任何时候，对于部分或所有订阅的文档，通知程序可能会返回到“无修补”模式。
The user Joe sends an initial subscription for the "id" attribute of a <doc> element. The "index" document exists, but the <doc> root element does not contain the "id" attribute at the time of the subscription.
用户Joe发送<doc>元素的“id”属性的初始订阅。“index”文档存在，但订阅时<doc>根元素不包含“id”属性。
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/index/~~/doc/@id"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/index/~~/doc/@id"/>
</list>
</resource-lists>
The first NOTIFY looks like the following since there is nothing to indicate:
第一个通知如下所示，因为没有任何指示：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/"/>
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/"/>
Note that if the "index" document hadn't existed, the first NOTIFY request would have been the same. The XCAP diff document format doesn't indicate reasons for non-existing resources.
请注意，如果“索引”文档不存在，则第一个通知请求将是相同的。XCAP diff文档格式没有指出不存在资源的原因。
Afterwards, Joe's client updates the whole document root element including the attribute "id" (not a typical XCAP operation or a preferred one, just an illustration here):
之后，Joe的客户机更新整个文档根元素，包括属性“id”（不是典型的XCAP操作或首选操作，这里只是一个示例）：
PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<doc id="bar">This is a new root element</doc>
<doc id="bar">This is a new root element</doc>
The new HTTP ETag of the "index" document is now "dwawrrtyy".
“索引”文档的新HTTP ETag现在是“dwawrrtyy”。
Then Joe's client gets a notification:
然后Joe的客户收到一个通知：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</attribute>
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</attribute>
</xcap-diff>
</xcap-diff>
Note that the HTTP ETag value of the new document is not shown, as it is irrelevant for this use-case.
注意，没有显示新文档的HTTPETag值，因为它与此用例无关。
Then Joe's client removes the "id" attribute:
然后Joe的客户机删除“id”属性：
DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0
DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0
And the subscriber gets a notification:
并且订户会收到一个通知：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
exists="0"/>
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
exists="0"/>
</xcap-diff>
</xcap-diff>
The notification indicates that the subscribed attribute was removed from the document. Naturally, attributes are "removed" if the element where they belong is removed, for example, by an HTTP DELETE
通知表示已从文档中删除订阅的属性。当然，如果属性所属的元素被删除（例如，通过HTTP删除），则属性被“删除”
request. The component selections indicate only the existence of attributes or elements.
要求组件选择仅指示属性或元素的存在。
The last example is a conditional subscription where a full refresh can be avoided when there are no changes in resources. Joe's client sends an initial subscription:
最后一个示例是一个条件订阅，当资源没有变化时，可以避免完全刷新。Joe的客户端发送初始订阅：
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=xcap-patching
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=xcap-patching
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
Since there are now two documents in the repository, the first NOTIFY looks like the following:
由于存储库中现在有两个文档，因此第一个通知如下所示：
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
SIP-ETag: xggfefe54
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
NOTIFY sip:joe@userhost.example.com SIP/2.0
...
Event: xcap-diff
SIP-ETag: xggfefe54
Content-Type: application/xcap-diff+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<?xml version="1.0" encoding="UTF-8"?>
<xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff"
xcap-root="http://xcap.example.com/">
<document new-etag="63hjjsll"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="63hjjsll"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
<document new-etag="terteer"
sel="tests/users/sip:joe@example.com/another_document"/>
</xcap-diff>
</xcap-diff>
Note that the NOTIFY request contains the SIP-ETag "xggfefe54". This SIP-ETag is placed in the Suppress-If-Match header field of the conditional subscription. The "diff-processing" mode also is changed
注意，NOTIFY请求包含SIP ETag“xggfe54”。此SIP ETag位于条件订阅的抑制If匹配头字段中。“差异处理”模式也发生了变化
(or is requested to change):
（或被要求更改）：
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Suppress-If-Match: xggfefe54
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
SUBSCRIBE sip:tests@xcap.example.com SIP/2.0
...
Suppress-If-Match: xggfefe54
Accept: application/xcap-diff+xml
Event: xcap-diff; diff-processing=aggregate
Content-Type: application/resource-lists+xml
Content-Length: [XXX]
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list>
<entry uri="tests/users/sip:joe@example.com/"/>
</list>
</resource-lists>
If the notifier finds a match to the previous stored state when it evaluates this request, it responds with 204 (No Notification). If there are no reportable changes as per [RFC5839], NOTIFY request generation is suppressed. When the notifier can aggregate several modifications, this re-subscription enables the processing of that mode thereafter. Indeed, the re-subscription may be quite process-intensive, especially when there are a large number of relevant reported resources.
如果通知程序在评估此请求时发现与以前存储的状态匹配，则会以204（无通知）进行响应。如果根据[RFC5839]没有可报告的更改，则禁止生成通知请求。当通知程序可以聚合多个修改时，此重新订阅将在此后启用该模式的处理。事实上，重新订阅可能需要相当多的过程，特别是在有大量相关报告资源的情况下。
Authors' Addresses
作者地址
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
芬兰赫尔辛基乌尔帕莱宁诺基亚伊塔梅伦卡图11-13 00180
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Dean Willis (editor) Softarmor Systems LLC 3100 Independence Pk #311-164 Plano, TX 75075 USA
Dean Willis（编辑）Softarmor Systems LLC 3100 Independence Pk#311-164美国德克萨斯州普莱诺市75075
Phone: +1 214 504 19876
EMail: dean.willis@softarmor.com
Phone: +1 214 504 19876
EMail: dean.willis@softarmor.com