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




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.

この文書では、クライアントが拡張マークアップ言語(XML)設定アクセスプロトコル(XCAP)リソースへの変更の通知を受信するために使用できるSIPイベント通知フレームワークのための「XCAP-diffの」SIP(セッション開始プロトコル)イベントパッケージについて説明します。初期同期の情報交換や文書の更新が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


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 ( 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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.


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
1. はじめに

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.


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.


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.


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.

第二に、このイベントパッケージは、次の3つの方法でそれらの文書の変更を通知することができます。最初のモードは、イベントの種類を示し、文書の内容が含まれていませんので、加入者は、更新された文書を取得するために、HTTP [RFC2616]を使用しています。第2のモードは、最小限の通知サイズの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.

第三に、クライアントは、得られたXCAP diff形式の通知メッセージで、既存の内容を示す特定のXML要素または属性に(XCAPコンポーネント)を購読することができます。要求されたコンポーネントが存在していませんが、後で作成された場合、通知は、コンポーネントのコンテンツとの通知を送信します。加入XCAP成分が除去されたときに成功したHTTPリクエストを削除した後通知はまた、例えば、通知を送信します。

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, BCP 14 [RFC2119] and indicate requirement levels for compliant implementations.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈されるべきで、BCP 14 [RFC2119]とは、対応する実装の要求レベルを示します。

3. Definitions

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.


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.


This document reuses terminology mostly defined in XCAP [RFC4825] and some in WebDAV [RFC4918].

この文書では、ほとんどのWebDAV [RFC4918]でXCAP [RFC4825]といくつかで定義された用語を再利用します。

4. XCAP Diff Event Package
4. XCAP Diffのイベントパッケージ
4.1. Overview of Operation with Basic Requirements
4.1. 基本要件と操作の概要

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ノードセレクタが追加でXCAPコンポーネントのURLは、ドキュメントの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-


processing" parameter or its value has no influence on XCAP component subscriptions.


4.2. Event Package Name
4.2. イベントパッケージ名

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]で指定されるように、この値は、SUBSCRIBE及びNOTIFYリクエスト中に存在するイベントヘッダフィールドに現れます。

4.3. 'diff-processing' Event Package Parameter
4.3. 「差分処理」イベントパッケージのパラメータ

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).


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.


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.


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.


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.


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-パッチ」と「集約」モードの違いを確認するには、「「1」、「2」、対応のETag値を有するバージョン「A」を有する文書、「B」、および「C」を検討し、及び3" 。 「XCAP-パッチ」モードは、最初のバージョンに対応する 『1』及び 『2』てETagとバージョンから変更「」を「B」とし、それら "と『C』へのバージョン『B』からの変更が含まれます2" と "3" てETag。 「集計」モード変更を最適化し、古い「1」と「」を「C」と新しい「3」てETagから単一の集約された変化を示しています。これらの変化は密接に関連している場合、つまり、同じ要素は何度も更新されている、帯域幅の節約が大きくなっています。

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.


The formal grammar [RFC5234] of the "diff-processing" parameter is:


        diff-processing = "diff-processing" EQUAL (
          "no-patching" /
          "xcap-patching" /
          "aggregate" /
          token )

where EQUAL and token are defined in RFC 3261 [RFC3261].

EQUALトークンは、RFC 3261 [RFC3261]で定義されます。

4.4. SUBSCRIBE Bodies
4.4. ボディをSUBSCRIBE

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]によって記載され、そして最初のSUBSCRIBEリクエストのボディとして含まれます。のみ、その形式の簡単なサブセットは、XCAPリクエストURIのフラットリストを要求されます。 <エントリー>の「URI」属性は、要素は、これらのURI値が含まれています。 (将来的には、セマンティクスがリソースリスト形式で機能のおかげで拡張することができるが)加入者はなど、階層リストまたは<エントリー-ref>を参照を使用してはなりません。そのような期限タイマーをリフレッシュするために使用されるものとして、その後のSUBSCRIBEリクエストでは、加入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.

リクエストがAcceptヘッダーフィールドを含むかもしれSUBSCRIBE。このようなヘッダフィールドが存在しない場合、それは「アプリケーション/ XCAP-diffを+ XML」のデフォルト値を有しています。ヘッダフィールドが存在する場合、それは「アプリケーション/ 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.


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.


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.


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".

「PIDF-操作」アプリケーションの使用で「RLS-サービス」ドキュメントの「リソース・リスト」文書、特定の要素(XCAP成分)、および収集:図1は、いくつかのXCAPリソースを覆うSUBSCRIBEリクエスト及び本体を示します。 「Content-Typeの」このSUBSCRIBEリクエストのヘッダには、「アプリケーション/リソース・リスト+ xml」です。

SUBSCRIBE 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 SIP / 2.0 ...受け入れる:SIPをSUBSCRIBEアプリケーション/ XCAP-diffの+ XMLイベントを:XCAP-diffを。差分処理=集約コンテンツタイプ:アプリケーション/リソース・リスト+ XMLコンテンツ長:[XXX]有効期限:4200

   <?xml version="1.0" encoding="UTF-8"?>
   <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
     <entry uri="resource-lists/users/"/>
     <entry uri="rls-services/users/
     <entry uri="pidf-manipulation/"/>

Figure 1: Example subscription body


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.


4.5. Subscription Duration
4.5. サブスクリプション期間

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秒です。 ExpiresヘッダーフィールドにRFC 3265 [RFC3265]に従って、加入者は別の有効期限のタイマーを指定するかもしれません。

4.6. NOTIFY Bodies
4.6. ボディをNOTIFY

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メッセージのボディは、「アプリケーション/ XCAP-diffを+ XML」のデフォルトであるか、またはSUBSCRIBEのAcceptヘッダーフィールドにリストされている形式のいずれかの形式。

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デフ形式[RFC5874]は加入XCAP成分の内容を含むことができます。文書の場合、フォーマットは、対応するURIを、ETagの値、及びバージョンからパッチ指示「」に「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に記載されています。

4.7. Notifier Generation of NOTIFY Requests
4.7. NOTIFYリクエストの通知の生成

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, 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.

最初のサブスクリプション期間中、または中URIのリストの変更は、リフレッシュ要求を購読している場合、通知は、要求されたXCAPリソースとその特権を解決する必要があります。要求されたURIのリストで余分リソースの選択がある場合、通知は、これらのリソースの重複同様の応答を提供すべきではありません。認証されたユーザーが読み取り権限を持たないためにリソースがXCAPのdiff形式で含んではいけません。 XCAPセマンティクスを見つけることができませんでしたXCAPコンポーネントがエラーを生成しないことに注意してください。代わりに、要求は「保留」状態のままで、それはこのリソースが作成(または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.


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.


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.


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.


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.


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クライアントの変更要求を変更することは簡単です:XML-パッチオプスセマンティクスを使用する(HTTP経由で送信)PUTとDELETE。 XCAPは、すべてのXMLノードタイプのパッチ適用をサポートしていませんが - 例えば、名前空間宣言を別々に添加することはできません - XML-パッチ-OPSの効率的な利用を、時には大幅に余分な処理を犠牲にして、帯域幅の要件を減らすことができます。

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成分の除去を知らせるために、通知は、ブールは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.


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.


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メッセージの信頼性の高い転送を必要とします。これは、すべてのメッセージが正常に転送しなければならないか、または文書が同期してなり、その後、パッチは最も可能性の高い失敗する(または悪化し、意図しない結果を持っている)ことを意味します。この「XCAP-diffの」イベントパッケージは、成功した200-応答が最後に送信のために受信されていない限り、通知は、同じダイアログに新しいNOTIFYリクエストを送ってはいけないことに、パーシャルPIDF-通知RFC 5263 [RFC5263]と同様に、必要となりますNOTIFY要求。 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.


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.


4.8. Subscriber Processing of NOTIFY Requests
4.8. NOTIFYリクエストのサブスクライバ処理

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リクエストは、通常、彼らの強いETagの値を含むHTTPリソースへの参照が含まれています。加入者が同様のローカルにキャッシュされたバージョンを持っていない場合、それは一般的に、これらのリソースに対する無条件の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.


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.


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.


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".


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.


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.


4.9. Handling of Forked Requests
4.9. フォーク要求の処理

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.

この仕様は、最初のSUBSCRIBEリクエストから構築するだけで、単一のダイアログを可能にします。加入者が加入するフォークの応答を受信した場合、加入者は非許可フォークリクエストを処理するためのRFC 3265 [RFC3265]のセクション4.4.9の手順を適用しなければなりません。

4.10. Rate of Notifications
4.10. 通知のレート

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.


4.11. State Agents
4.11. 州のエージェント

State agents play no role in this package.


5. An Initial Example NOTIFY Document

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:


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.


<?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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <D:XCAP-diffののxmlns:D = "URN:IETF:paramsは:XML:NS:XCAP-diffを" のxmlns:S = "URN:IETF :のparams:XML:NS:RLS-サービス」XCAPルート= "">

<d:document new-etag="7ahggs" sel="resource-lists/users/"/>

<D:新しい-のETagを文書化= "7ahggs" SEL = "リソース・リスト/ユーザー/" />

<d:document new-etag="30376adf" sel="pidf-manipulation/users/"/>

<D:新しい-のETagを文書化= "30376adf" SEL = "PIDF-操作/ユーザー/" />

    <d:element sel="rls-services/users/
       ><s:service uri="">
         <s:list name="marketing">
           <rl:entry uri=""/>
           <rl:entry uri=""/>


</ 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-操作」コレクションでは、ユーザーが読み取り権限を持っている唯一の単一の文書があります。 <サービス>要素は、RLS-サービス「インデックス」、文書内に存在し、その内容が示されています。 <service>要素は、それがソース文書中の「S」接頭辞を有しているが既定のドキュメントの名前空間(XCAPノードセレクタ値でない接頭辞)を用いて位置していたことにも留意されたいです。

6. IANA Considerations
6. IANAの考慮事項

IANA has added a new event package to the SIP Event Types Namespace registry as follows:


     Package Name    Type        Contact                      Reference
     -------------   --------    -------                      ---------
     xcap-diff       package     IETF Real-time Applications  [RFC5875]
7. Security Considerations

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のすべてのセキュリティの考慮事項が適用されます。構成データは、機密情報を含むことができ、クライアントとサーバの両方が互いを認証する必要があります。 RFC 3261 [RFC3261]のセクション22で定義されるようにノーティファイアは、例えば、通常のSIPの認証メカニズムを使用してダイジェスト「をXCAP-diffの」イベントパッケージの加入者を認証する必要があります。ノーティファイアは、XCAPユーザー識別子(XUI)を認識し、どのようにXUIsで明確に認証されたSIPのIDをマッピングすることでなければなりません。

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.


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 ("Interdomain Requests") of RFC 3261 [RFC3261].

機構は、整合性を確保しなければならないXCAP-diffのイベント情報を搬送するために使用され、機密情報を確実にすべきです。 S / MIMEは、RFC 3261 [RFC3261]のセクション26.2.4に記載されているようなエンドツーエンドのSIP暗号化機構は、使用すべきです。それが利用できない場合、それはTLS [RFC5246]は、セクション26.2.2に記載のホップバイホップ認証及び暗号化のメカニズムを提供する要素間使用することを推奨して26.3.2.2(「ドメイン間の要求(「URIスキームSIPS」) 「)RFC 3261 [RFC3261]の。

8. Acknowledgments

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.


9. References
9.1. Normative References
9.1. 引用規格

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、Frystyk、H.、Masinter、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP:セッション開始プロトコル" 、RFC 3261、2002年6月。

[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.

[RFC3265]ローチ、A.、 "セッション開始プロトコル(SIP)特異的イベント通知"、RFC 3265、2002年6月。

[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.

[RFC4825]ローゼンバーグ、J.、 "拡張マークアップ言語(XML)設定アクセスプロトコル(XCAP)"、RFC 4825、2007年5月。

[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.

[RFC4826]ローゼンバーグ、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]クロッカー、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]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ(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)パッチOperations Frameworkの利用XMLパス言語(XPath)セレクタ"、RFC 5261、2008年9月。

[RFC5839] Niemi, A. and D. Willis, "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.

[RFC5839]ニエミ、A.とD.ウィリス、RFC 5839、2010年5月 "条件付きイベント通知のためのセッション開始プロトコル(SIP)のイベントへの拡大"。

[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]ローゼンバーグ、J.とJ. Urpalainen、RFC 5874、2010年5月 "XMLコンフィギュレーションアクセスプロトコル(XCAP)リソースの変更を示すための拡張マークアップ言語(XML)ドキュメント・フォーマット"。

9.2. Informative References
9.2. 参考文献

[RFC4918] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.

[RFC4918] Dusseault、L.、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理(WebDAV)のためのHTTP拡張機能"。

[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.、コスタ・レケナ、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, <>.

[W3C.REC-XML-20060816]パオリ、J.、ブレイ、T.、Yergeau、F.、MALER、E.、およびC. Sperberg-マックイーン、 "拡張マークアップ言語(XML)1.0(第4版)"、 World Wide WebコンソーシアムFirstEdition REC-XML-20060816、2006年8月、<>。

Appendix A. Informative Examples


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.


A.1. Initial Documents on an XCAP Server

A.1。 XCAPサーバー上の最初のドキュメント

The following documents exist on an XCAP server ( with an imaginary "tests" application usage (there's no Default Document Namespace defined in this imaginary application usage).



<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is a sample document</note> </doc>

<?xml version = "1.0" エンコード= "UTF-8"?> <ドキュメント> <ノート>これはサンプル文書</ノート> </ DOC>

and then



<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is another sample document</note> </doc>

<?xml version = "1.0" エンコード= "UTF-8"?> <ドキュメント> <ノート>これは、別のサンプルドキュメント</ノート> </ DOC>

A.2. An Initial Subscription


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 "", sends an initial subscription:


SUBSCRIBE SIP/2.0 ... Accept: application/xcap-diff+xml Event: xcap-diff; diff-processing=aggregate Content-Type: application/resource-lists+xml Content-Length: [XXX] SIP / 2.0 ...受け入れる:SIPをSUBSCRIBEアプリケーション/ XCAP-diffの+ XMLイベントを:XCAP-diffを。差分処理=集約コンテンツタイプ:アプリケーション/リソース・リスト+ XMLコンテンツ長:[XXX]

<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="tests/users/"/> </list> </resource-lists>

<?xml version = "1.0" エンコード= "UTF-8"?> <リソース・リストののxmlns = "壷:IETF:のparams:XML:NS:リソース・リスト"> <リスト> <エントリーのURI = "テスト/ユーザー/ / "/> </リスト> </資源リスト>

In addition to the 200 (OK) response, the notifier sends the first NOTIFY:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<document new-etag="7ahggs" sel="tests/users/"/>

<ドキュメント新しい-のETag = "7ahggs" SEL = "テスト/ユーザー/" />


</ 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).


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.


A.3. A Document Addition into a Collection


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:


PUT /tests/users/ HTTP/1.1 Host: .... Content-Type: application/xml Content-Length: [XXX]

PUT /tests/users/ HTTP / 1.1ホスト ....のContent-Type:アプリケーション/ XMLコンテンツ長:[XXX]

<?xml version="1.0" encoding="UTF-8"?> <doc> <note>This is another sample document</note> </doc>

<?xml version = "1.0" エンコード= "UTF-8"?> <ドキュメント> <ノート>これは、別のサンプルドキュメント</ノート> </ DOC>

This HTTP PUT request results in the XCAP client receiving a strong HTTP ETag "terteer" for this new document.

この新しい文書のための強力なHTTPのETag「terteer」を受信XCAPクライアントでこのHTTP PUTリクエストの結果を。

Then the subscriber receives a notification afterwards:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<document new-etag="terteer" sel="tests/users/"/>

<ドキュメント新しい-のETag = "terteer" SEL = "テスト/ユーザー/" />


</ 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.


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.


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.


A.4. A Series of XCAP Component Modifications

A.4。 XCAPコンポーネントの変更のシリーズ

Now Joe's client uses its XCAP patching capability by doing the following:


PUT /tests/users/ HTTP/1.1 Host: .... Content-Type: application/xcap-el+xml Content-Length: [XXX] ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/ HTTP / 1.1ホストをPUT :[XXX]

<foo>this is a new element</foo>

<FOO>これは新しい要素である</ foo>の

Since the insertion of the element is successful, Joe's client receives the new HTTP ETag "fgherhryt3" of the updated "index" document.


Immediately thereafter, Joe's client issues another HTTP request (this request could even be pipe-lined):


PUT /tests/users/ HTTP/1.1 Host: .... Content-Type: application/xcap-el+xml Content-Length: [XXX] ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/ HTTP / 1.1ホストをPUT :[XXX]

<bar>this is a bar element </bar>


The reported new HTTP ETag of "index" is now "dgdgdfgrrr".


And Joe's client issues yet another HTTP request:


PUT /tests/users/ HTTP/1.1 Host: .... Content-Type: application/xcap-el+xml Content-Length: [XXX] ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/ HTTP / 1.1ホストをPUT :[XXX]

<foobar>this is a foobar element</foobar>

<foobarに>これはfoobarの要素である</ foobarに>

The reported new ETag of "index" is now "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:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <D:XCAP-diffののxmlns:D = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp:/ / / ">

<d:document previous-etag="7ahggs3" sel="tests/users/" new-etag="63hjjsll"> <d:add sel="*"

<D:前-のETag = "7ahggs3" SEL =文書化:新しい-のETag = "63hjjsll" "テスト/ユーザー/ SIPは"> <D:追加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は>これは新しい要素が</ foo>の<バー>これはバーの要素</バーです> <foobarに>これはfoobarの要素である</ foobarに> </ D:追加> </ D:ドキュメント>


</ 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.


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.

ジョーのクライアントは、参照文書のローカルにキャッシュされたバージョンを持っていなかった場合、また、その注意してください、それが最初の通知後にHTTP GET要求を行うために必要だろう。 HTTPによって受信されたリソースのETagのは、この集約されたパッチの前の、または新規のETagのいずれかと一致しなかった場合は、同期外れ状態が考えられるだろう。この問題は一般的ではありませんが、それが起こる可能性があります。問題を解決するには、クライアントは、「インデックス」のドキュメントを再フェッチおよび/または一致を検出するために、後続の通知を待つことができます。問題を回避するためのより良いと簡単な方法は、「XCAP-パッチ適用」モードでサブスクリプションをリフレッシュし、後に「集約」モードでリフレッシュすることです。

Alternatively, if the notifier's operational mode been "xcap-patching", the NOTIFY could have been the following:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <D:XCAP-diffののxmlns:D = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp:/ / / ">

<d:document previous-etag="7ahggs" sel="tests/users/" new-etag="fgherhryt3"> <d:add sel="*" ><foo>this is a new element</foo></d:add></d:document>

<D:文書前の-のETag = "7ahggs" SEL = "テスト/ユーザー/" 新-のETag = "fgherhryt3"> <D:追加SEL = "*"> <foo>の本新しい要素は</ foo>の</ D:追加> </ D:ドキュメント>

<d:document previous-etag="fgherhryt3" sel="tests/users/" new-etag="dgdgdfgrrr"> <d:add sel="*" ><bar>this is a bar element </bar></d:add></d:document>

<D:文書前の-のETag = "fgherhryt3" SEL = "テスト/ユーザー/" 新-のETag = "dgdgdfgrrr"> <D:= SELを追加 "*"> <バー>このあるバーの要素</バー> </ D:追加> </ D:ドキュメント>

<d:document previous-etag="dgdgdfgrrr"

<D:文書前の-のETag = "dgdgdfgrrr"

sel="tests/users/" new-etag="63hjjsll"> <d:add sel="*" ><foobar>this is a foobar element</foobar></d:add></d:document>

SEL =追加SEL = "*"> <foobarに>これはfoobarの要素</ foobarに> </ D:新-のETag = "63hjjsll"> <D "テスト/ユーザー/ SIPは" :追加> </ D:ドキュメント>


</ 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/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<document previous-etag="7ahggs3" sel="tests/users/" new-etag="63hjjsll"/>

<文書前の-のETag = "7ahggs3" SEL = "テスト/ユーザー/ SIPは" 新-のETag = "63hjjsll" />


</ XCAP-diffを>

At any time, the notifier may fall back to the "no-patching" mode for some or all of the subscribed documents.


A.5. An XCAP Component Subscription

A.5。 XCAPコンポーネントのサブスクリプション

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は、<ドキュメント>要素の「id」属性の初期サブスクリプションを送信します。 「インデックス」文書が存在しますが、<ドキュメント>ルート要素は、サブスクリプションの時に「id」属性が含まれていません。

SUBSCRIBE SIP/2.0 ... Accept: application/xcap-diff+xml Event: xcap-diff Content-Type: application/resource-lists+xml Content-Length: [XXX]

一口に SIP / 2.0 ...受け入れる:アプリケーション/ XCAP-diffの+ XMLイベントを:XCAP-差分のContent-Type:アプリケーション/リソース・リストを+の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/"/> </list> </resource-lists>

<?xml version = "1.0" エンコード= "UTF-8"?> <リソース・リストののxmlns = "壷:IETF:のparams:XML:NS:リソース・リスト"> <リスト> <エントリーのURI = "テスト/ユーザー/ "/> </リスト> </資源リスト>

The first NOTIFY looks like the following since there is nothing to indicate:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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=""/>

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "の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.

「インデックス」の文書が存在していなかった場合、最初のNOTIFYリクエストは同じであったであろうことに注意してください。 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):


PUT /tests/users/ HTTP/1.1 Host: .... Content-Type: application/xcap-el+xml Content-Length: [XXX]

PUTの/tests/users/のHTTP / 1.1ホスト ....のContent-Type:アプリケーション/ XCAP-EL +のxmlのContent-Length:[ XXX]

<doc id="bar">This is a new root element</doc>

<ドキュメントID = "バー">これは新しいルート要素</ docに>あります

The new HTTP ETag of the "index" document is now "dwawrrtyy".


Then Joe's client gets a notification:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<attribute sel="tests/users/" >bar</attribute>

<属性SEL = "テスト/ユーザー/ SIP:ジョー@ /インデックス/ ~~ / DOC / @ IDを">バー</属性>


</ XCAP-diffを>

Note that the HTTP ETag value of the new document is not shown, as it is irrelevant for this use-case.

それは、このユースケースは無関係であるように、新しいドキュメントのHTTP ETag値は、図示していないことに留意されたいです。

Then Joe's client removes the "id" attribute:


DELETE /tests/users/ HTTP/1.1 Host: .... Content-Length: 0 ....のContent-Length:0 /tests/users/ HTTP / 1.1ホストを削除

And the subscriber gets a notification:


NOTIFY SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口に SIP / 2.0 ...イベント:XCAP-差分のContent-Type:アプリケーション/ 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="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<attribute sel="tests/users/" exists="0"/>

<属性SEL = "テスト/ユーザー/ SIP:ジョー@ /インデックス/ ~~ / DOC / @ idは" 存在= "0" />


</ 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 request. The component selections indicate only the existence of attributes or elements.


A.6. A Conditional Subscription


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:


SUBSCRIBE SIP/2.0 ... Accept: application/xcap-diff+xml Event: xcap-diff; diff-processing=xcap-patching Content-Type: application/resource-lists+xml Content-Length: [XXX] SIP / 2.0 ...受け入れる:SIPをSUBSCRIBEアプリケーション/ XCAP-diffの+ XMLイベントを:XCAP-diffを。差分処理= XCAP-パッチ適用のContent-Type:アプリケーション/リソース・リスト+の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/"/> </list> </resource-lists>

<?xml version = "1.0" エンコード= "UTF-8"?> <リソース・リストののxmlns = "壷:IETF:のparams:XML:NS:リソース・リスト"> <リスト> <エントリーのURI = "テスト/ユーザー/ / "/> </リスト> </資源リスト>

Since there are now two documents in the repository, the first NOTIFY looks like the following:


NOTIFY SIP/2.0 ... Event: xcap-diff SIP-ETag: xggfefe54 Content-Type: application/xcap-diff+xml Content-Length: [XXX] SIP / 2.0 ...イベント:XCAP-差分SIP-ETagを:xggfefe54のContent-Type:アプリケーション/ XCAP-diffの+のXMLのContent-Length:[XXX] SIPをNOTIFY

<?xml version="1.0" encoding="UTF-8"?> <xcap-diff xmlns="urn:ietf:params:xml:ns:xcap-diff" xcap-root="">

<?xml version = "1.0" エンコード= "UTF-8"?> <XCAP-diffののxmlns = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "のhttp://xcap.example .COM / ">

<document new-etag="63hjjsll" sel="tests/users/"/>

<ドキュメント新しい-のETag = "63hjjsll" SEL = "テスト/ユーザー/" />

<document new-etag="terteer" sel="tests/users/"/>

<ドキュメント新しい-のETag = "terteer" SEL = "テスト/ユーザー/" />


</ 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 (or is requested to change):


SUBSCRIBE 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] SIP / 2.0 ...抑止-IF-マッチ:xggfefe54受け入れ:アプリケーション/ XCAP-diffの+ XMLイベントを:SIP SUBSCRIBE XCAP-diffをし;差分処理=集約コンテンツタイプ:アプリケーション/リソース・リスト+ XMLコンテンツ長:[XXX]

<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list> <entry uri="tests/users/"/> </list> </resource-lists>

<?xml version = "1.0" エンコード= "UTF-8"?> <リソース・リストののxmlns = "壷:IETF:のparams:XML:NS:リソース・リスト"> <リスト> <エントリーのURI = "テスト/ユーザー/ / "/> </リスト> </資源リスト>

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]の通り全く報告の変更がない場合、NOTIFY要求の発生が抑制されます。通知は、いくつかの変更を集約することができる場合、この再サブスクリプションは、その後、そのモードの処理を可能にします。実際、再加入は、関連する報告されたリソースの数が多い場合は特に、かなりのプロセスを集中的かもしれません。

Authors' Addresses


Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland

ヤリUrpalainenノキアItamerenkatu 11-13 00180ヘルシンキフィンランド

Phone: +358 7180 37686 EMail:

電話:+358 7180 37686電子メール

Dean Willis (editor) Softarmor Systems LLC 3100 Independence Pk #311-164 Plano, TX 75075 USA

ディーン・ウィリス(エディタ)SoftarmorシステムズLLC 3100独立のPK#311から164プラノ、TX 75075 USA

Phone: +1 214 504 19876 EMail:

電話:+1 214 504 19876 Eメール