RFC 5875 - An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5875
タイトル : RFC 5875 - 拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）DIFFイベントパッケージ
翻訳編集 : 自動生成

[要約] RFC 5875は、XML Configuration Access Protocol (XCAP) Diff Event Packageに関する仕様です。このRFCの目的は、XCAPの変更イベントを通知するための拡張可能なマークアップ言語（XML）の設定アクセスプロトコルを提供することです。

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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5875で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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

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.

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は、サーバーとクライアント間でリソースを同期させるための効果的なメカニズム（投票を超えて）を提供しません。このメモは、SIPイベント通知フレームワーク[RFC3265]およびXCAP DIFF形式[RFC5874]とともに、ユーザーがXMLドキュメントの変更をサブスクライブし、通知を受け取ることができる「XCAP-Diff」イベントパッケージを定義します。XMLドキュメントの変更。

There are three basic features that this event package enables:

このイベントパッケージが有効にする3つの基本的な機能があります。

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 DIFF形式で表示されるXCAPドキュメントのURLおよび強力なエンティティタグ（ETAG）値を使用して、サーバーリソースとローカルリソースをローカルリソースと比較し、それらを同期させることができます。

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-Patch-Ops [RFC5261]形式を使用して、通知メッセージのドキュメントコンテンツの変更が含まれます。3番目のモードには、同じXML-Patch-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コンポーネント）をサブスクライブできます。要求されたコンポーネントが存在しないが、後で作成された場合、Notifierはコンポーネントのコンテンツに通知を送信します。また、通知者は、サブスクライブされたXCAPコンポーネントが削除された場合、たとえばHTTP削除要求の後に通知を送信します。

2. Terminology

2. 用語

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.

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119、BCP 14 [RFC2119]で説明されているように解釈され、準拠の実装の要件レベルを示します。

3. Definitions

3. 定義

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コンポーネント：XML要素または属性を更新、削除、または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.

集約：XCAPクライアントは、HTTPを使用して一度に1つのXCAPコンポーネントのみを更新できます。ただし、通知者は、XCAP DIFF形式でエンコードされたXML-Patch-Opsセマンティクスを使用して、これらの変更のシリーズを単一の通知に集約できる場合があります。

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

このドキュメントは、主にXCAP [RFC4825]で定義されている用語を再利用し、一部はWebDav [RFC4918]で再利用します。

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」イベントパッケージ機能を受信するために、サブスクライバーは、サブスクリプションボディにnotifierに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- processing" parameter or its value has no influence on XCAP component subscriptions.

NotifierはXCAPコンポーネントサブスクリプションをサポートする必要があります。通知者はサブスクリプションに応じて最初の通知を送信し、この最初の通知には、サブスクリプションの一部であるドキュメントのURLとXCAPコンポーネントコンテンツを含める必要があります。後続の通知には、これらのドキュメントへのパッチが含まれる場合があります。サブスクライバーは、セクション4.3でカバーされている「diff-processing」イベントパッケージパラメーターを使用して、通知者がドキュメントの変更を信号する方法を指定できます。「diff-処理」パラメーターまたはその値の存在は、xcapコンポーネントサブスクリプションに影響を与えないことに注意してください。

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]で指定されているように、この値は、サブスクライブおよび通知リクエストに存在するイベントヘッダーフィールドに表示されます。

4.3. 'diff-processing' Event Package Parameter

4.3. 「diff-processing」イベントパッケージパラメーター

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パッチ」、および「集計」です。3つのモードはすべて、サブスクライバーがローカルキャッシュを同期できるようにする情報を提供しますが、「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変更履歴を示しているわけではありません。通知者は、相互運用性のベースラインとして「パッチなし」モードをサポートする必要があります。もう1つのより複雑なモードはオプションです。

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」値は、NotifierにXCAPクライアントが作成したすべての更新されたXCAPコンテンツとエンティティタグ（ETAG）変更を含むことを意味します（HTTP経由）。クライアントは、ドキュメントの完全な（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-Patch-Ops [RFC5261] diff-generationを実装する必要があります。

If the subscription does not contain the "diff-processing" header field parameter, the notifier MUST default to the "no-patching" mode.

サブスクリプションに「diff-processing」ヘッダーフィールドパラメーターが含まれていない場合、紹介者は「パッチなし」モードにデフォルトする必要があります。

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パッチ」モードと「アグリゲート」モードの違いを確認するには、「A」、「B」、「C」のバージョン「1」、「2」、および「および」を備えたドキュメントを検討してください。3 "。「XCAP-PATCHING」モードには、最初にバージョン「A」から「B」から「1」と「2」のバージョンで変更が含まれ、次にバージョン「B」から「B」から「C」に変更されます。2 "および" 3 "etags。「集計」モードは、変更を最適化し、「a」から「c」から「1」と新しい「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.

この「diff-processing」パラメーターは、notifierのサブスクライバーのヒントです。Notifierは、より単純なモードを使用して応答する場合がありますが、より複雑なモードでは応答できません。モードの通知機の選択は、セクション4.7でカバーされています。再サブスクリプション中、サブスクライバーはdiff処理パラメーターを変更する場合があります。

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" equal（ "no-patching" / "xcap-patching" / "aggregate" / token）

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

ここで、等しいトークンとトークンはRFC 3261 [RFC3261]で定義されています。

4.4. サブスクライブボディ

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.

購読要求には、suppless-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を使用できます。相対的なリクエスト-urisは許可されているため、通知者はこれらを正しいXCAPルート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は、いくつかの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

   <?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 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ノードセレクターの名前空間プレフィックスは、urisの名前スペースに適切に解決する必要があります。RFC 4825 [RFC4825]のセクション6.4は、XCAPノードセレクターでプレフィックスを使用する際の規則について説明します。XCAPデフォルトのドキュメント名空間のみが使用されている場合、前の例（A <Service>要素が選択されている場合）のように、「URI」値のクエリコンポーネントは必要ありません。

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秒です。RFC 3265 [RFC3265]によると、サブスクライバーはヘッダーフィールドの有効期限タイマーを指定する場合があります。

4.6. NOTIFY Bodies

4.6. 機関に通知します

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ノードセレクターには名前空間プレフィックスを含めることができます。Notifierは、RFC 4825 [RFC4825]の規則に従って、これらのプレフィックスをURISに名前を付けて解決する必要があります。言い換えれば、通知者は、未定の適格なXCAP要素を見つけたときに、アプリケーション使用のためのXCAPデフォルトのドキュメント名スペースに注意する必要があります。パッチ操作要素のルールを解決する名前空間<add>、<plateg>、および<remove>は、[RFC5261]のセクション4.2.1で説明されていることに注意してください。

4.7. Notifier Generation of NOTIFY Requests

4.7. Notify Requestsの通知を生成します

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リストがサブスクライブの更新リクエストで変更された場合、Notifierは要求された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.

通知者が承認されたXCAPリソースのリストを知っていると、最初のNotifyが生成されます。これには、サブスクライバーが特権を読み取るすべてのサブスクライブされた既存のドキュメント、および通常既存のコンテンツのXCAPコンポーネントへのURI参照が含まれます。

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.

最初の通知を送信した後、Notifierは変更を報告するためにdiff処理モードを選択します。サブスクライバーがサブスクライブの「diff-processing」パラメーターのモードを提案した場合、通知者はその要求されたモードを使用するか、よりシンプルな動作モードに戻ることがありますが、通知者は選択したものよりも複雑なモードを使用してはなりません。サブスクライバー。少なくとも最も複雑なものから、モードの順序は次のとおりです。「パッチなし」、「XCAPパッチ」、「集計」。したがって、Notifierは、任意のモードを使用して「アグリゲート」要求に応答する場合がありますが、「集計」モードを使用して「XCAPパッチ」サブスクリプションに返信することはできません。当然のことながら、Notifierは「パッチなし」モードで「パッチなし」リクエストを処理する必要があります。

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 Prologが変更されたときなど）では、NotifierがXML-Patch-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パッチ」モードでは、最初のサブスクリプションも「XCAP-」で開始した場合、「XCAPパッチ」モードを続行する必要があります。パッチング "モード。

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-Patching」モードでは、一部のXCAPクライアントはおそらくHTTP Putリクエストを完全に最適化していないため、冗長な情報を排除することにより、紹介者はdiff世代を最適化しようとする場合があります。

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-Patch-Opsセマンティクスを使用するために、Put and Delete（http経由で送信）。XCAPはすべてのXMLノードタイプのパッチングをサポートしていませんが、たとえば、名前空間宣言を個別に追加することはできませんが、XML-Patch-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.

Notifierが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.

通知者が再サブスクリプションを受信した場合、サブスクライバーがヘッダーフィールド抑制-If-Match：[ETAG値]を使用して条件付きサブスクリプション[RFC5839]を要求しない限り、現在の完全なXML DIFFコンテンツを再送信する必要があります。条件付きの再サブスクリプションを使用すると、通知者は現在のサブスクリプション状態を決定するときにサブスクリプション本体も検査する必要があります。サブスクリプションはXCAP要求URISのリストに基づいているため、以前の状態を「保存」するのと同等性を決定する際に、通信器はこれらのURIの順序を考慮しないことをお勧めします。前の状態との一致が見つからない場合、Notifyメッセージには完全なXML DIFF状態（初期通知と同様）が含まれている必要があります。Notifiersは、このイベントパッケージで条件付きサブスクリプション処理を実装する必要があります。

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処理パラメーターの値を変更する場合があります。値の変更は、（RE）サブスクライブリクエストの直後に通知（生成された場合）に続く通知ではなく、後続の通知のみに影響します。

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.

このようなイベントパッケージには、通知メッセージの信頼できる転送が必要です。これは、すべてのメッセージを正常に転送する必要があるか、ドキュメントが同期しなくなる必要があることを意味し、パッチが失敗する可能性が高い（またはさらに悪いことに、意図しない結果をもたらします）。Partial-PIDF-Notify RFC 5263 [RFC5263]と同様に、この「XCAP-Diff」イベントパッケージには、紹介者が最終送信の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.

注：この要件により、秩序外イベントが発生しないこと、または解決できない通知要求の障害後にダイアログが終了することが保証されます。さらに、可能性のある通知エラー応答の一部（たとえば、401、407、413）は、ダイアログを破壊することなく優雅に処理できます。

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>要素には、サブスクライブされた「完全な」要素コンテンツを表示する子要素はありません。

4.8. Subscriber Processing of NOTIFY Requests

4.8. 通知リクエストのサブスクライバー処理

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.

これは、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-patching」モードに戻ることができます。

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パッチ」モードで提供されている場合、他のリソースが「集計」モードであることが検出された場合、サブスクリプションを「Aggregate」のサブスクリプションを更新する必要があります。モード。

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」パラメーターを「パッチなし」に設定することにより、常にdiff処理の使用を無効にする場合があります。

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.

パッチ処理および/またはプログラミングエラーのために差分形式を適用できない場合（リストについては、[RFC5261]のセクション5.1を参照）、サブスクライバーはサブスクリプションを更新し、「DIFF処理」パラメーターを設定してパッチを無効にする必要があります。パッチなし」。通知者は修正を行うことができないため、サブスクライバーは非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リストが変更されていない限り、サブスクライバーはリソースの現在の状態を保存する必要があります。つまり、サブスクライバーは、たとえば一部のローカルキャッシュからリソースの状態を取得する必要があります。

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.

この仕様により、最初のサブスクライブリクエストから1つのダイアログのみを構築できます。サブスクライバーがサブスクライブに対するフォークの応答を受信した場合、サブスクライバーは、不承認要求を処理するために、RFC 3265 [RFC3265]のセクション4.4.9 [RFC3265]の手順を適用する必要があります。

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.

「xcap-diff」イベントパッケージの通知者は、5秒ごとに1回以上のレートで単一のサブスクリプションの通知を生成してはなりません。

4.11. State Agents

4.11. 国家エージェント

State agents play no role in this package.

州のエージェントは、このパッケージでは役割を果たしません。

5. An Initial Example NOTIFY Document

5. 最初の例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:

図2は、図1の購読例への最初のNotifyリクエストによって提供される初期XCAP DIFF形式のドキュメントの例を示しています。

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

    <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: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>

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操作」コレクションには、ユーザーが特権を読み取る文書は1つだけです。<Service>要素は、RLSサービス「インデックス」ドキュメント内に存在し、そのコンテンツが表示されます。また、<service>要素は、デフォルトのドキュメント名空間（XCAPノードセレクター値にプレフィックスなし）を使用して配置されていたことに注意してください。ただし、ソースドキュメントには「S」プレフィックスがあります。

6. IANA Considerations

6. IANAの考慮事項

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>

7. Security Considerations

7. セキュリティに関する考慮事項

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」イベントパッケージサブスクライバーを認証する必要があります。Notifiersは、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コンポーネントへのサブスクリプション、および必要な帯域幅使用量を極端に最適化しようとするdiffジェネレーションアルゴリズム。

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イベント情報を伝えるために使用されるメカニズムは、整合性を確保し、情報の機密を確保する必要があります。RFC 3261 [RFC3261]のセクション26.2.4で説明されているS/MIMEなどのエンドツーエンドSIP暗号化メカニズムを使用する必要があります。それが利用できない場合は、TLS [RFC5246]を要素間で使用して、セクション26.2.2（ "SIPS URIスキーム"）および26.3.2.2（ "interdomain requests sections 26.2.2（" sips uriスキーム "）に記載されているホップバイホップ認証と暗号化メカニズムを提供することをお勧めします。"）of RFC 3261 [RFC3261]。

8. Acknowledgments

8. 謝辞

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.

著者は、Jonathan Rosenbergの貴重なコメントと最初のイベントパッケージの提供について、Aki Niemi、Pekka Pessi、Miguel Garcia、Pavel Dostal、Krisztian Kiss、Anders Lindgren、Sofie Lassborn、Keith Drage、Stephen Hinton、バイロンカンペンヒントン、Avshalom Houri、Ben Campbell、Paul Kyzivat、Spencer Dawkins、Pasi Eronen、Chris Newmanの貴重なコメントをしてくれました。Lisa DusseaultはIESGレビュー中にこの文書を批判し、ドキュメントの品質が向上する多くの問題を提起しました。さらに、テクニカルライターのA.ジャンマホニーは、リサのコメントを統合し、技術的な英語の使用を整理することに無数の時間を費やしました。

9. References

9. 参考文献

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] 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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-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：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。

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

[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。

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

[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、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、「The Transport Layer Security（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 PATH言語（XPATH）セレクターを使用した拡張可能なマークアップ言語（XML）パッチ操作フレームワーク」、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] 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月。

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。、「Web分散オーサリングおよびバージョン（WebDAV）のHTTP拡張機能」、RFC 4918、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（第4版）」、World Wide Web Consortium Firstedition REC-XML-20060816、2006年8月、<http://www.w3.org/tr/2006/REC-XML-20060816>。

Appendix A. Informative Examples

付録A. 有益な例

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要求のurisは現実に対応していないことに注意してください。

A.1. Initial Documents on an XCAP Server

A.1. XCAPサーバーの初期ドキュメント

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）に存在します（この想像上のアプリケーションの使用で定義されたデフォルトのドキュメント名空間はありません）。

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>

and then

その後

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>

A.2. An Initial Subscription

A.2. 初期サブスクリプション

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:

以下は、コレクションコンテンツのリストを示しており、ユーザーが特権を読み取っているリソースのみを示しています。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]

<?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:

<？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> 200（OK）応答に加えて、notifierは最初のnotifyを送信します。

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

    <document new-etag="7ahggs"
              sel="tests/users/sip:joe@example.com/index"/>

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

サブスクライバーが「テスト/ユーザー/」コレクションを要求していた場合、ジョーにはジョンのリソース（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.

ヘッダーフィールドの有効期限が「0」の値がある場合、リクエストはwebdavのpropfindメソッドに似ています。ただし、構文と応答は異なります。

A.3. A Document Addition into a Collection

A.3. コレクションへのドキュメントの追加

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:

ジョーが同じクライアントまたは別のデバイスで実行されている別のクライアントのいずれかを使用して、彼のコレクションに新しいドキュメントを追加したとしましょう。彼はアプリケーションの使用コレクションにhttpを掲載しています。

   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> This HTTP PUT request results in the XCAP client receiving a strong HTTP ETag "terteer" for this new document.

<？xml version = "1.0" encoding = "utf-8"？> <doc> <lotes>これは別のサンプルドキュメントです</note> </doc>この新しいドキュメントの「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]

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

</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のクライアントがドキュメントを変更し、サブスクリプションを更新する場合、その変更が通知を引き起こしたため、通常、この通知を無視します。このNotifyを受け取ったクライアントがドキュメントの変更を提出していない場合、おそらくこの新しいドキュメントを取得するでしょう。

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のクライアントが最初のサブスクリプションと同じ要求本文でサブスクリプションを再表示する場合、結果には、これらの2つのドキュメントが含まれます：「インデックス」と「Another_Document」がETAGを使用します。

A.4. A Series of XCAP Component Modifications

A.4. 一連のXCAPコンポーネントの変更

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]

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

<foo>これは新しい要素です</foo>要素の挿入が成功するため、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]

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

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

報告された「インデックス」の新しいHTTP ETAGは、「DGDGDFGRRR」になりました。

And Joe's client issues yet another HTTP request:

ジョーのクライアントはさらに別の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]

   <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のクライアントは、「集計」diff処理を要求しており、通知者はそれらを生成できるため、組み込みパッチで通知を受け取ります。

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

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

   </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のクライアントがリファレンスドキュメントのローカルキャッシュバージョンを持っていなかった場合、最初の通知後にHTTP Getリクエストを実行する必要があることに注意してください。HTTPによる受信リソースのETAGが、この集約されたパッチの前または新しいETAGのいずれかと一致しなかった場合、シンク外の状態が可能性があります。この問題は典型的なものではありませんが、発生する可能性があります。問題を解決するために、クライアントは「インデックス」ドキュメントを再フェッチしたり、後続の通知を待って一致を検出することもできます。問題を回避するより良い方法は、「XCAPパッチ」モードでサブスクリプションを更新し、後で「集計」モードで更新することです。

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

あるいは、通知者の動作モードが「XCAPパッチ」であった場合、Notifyは次のとおりでした。

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

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

   </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-Patching」モードで完全な変更履歴を提供してから同期が達成される可能性があります。

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]

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

</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は、<doc>要素の「ID」属性の初期サブスクリプションを送信します。「インデックス」ドキュメントは存在しますが、<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]

   <?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は、示すものが何もないため、次のように見えます。

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

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

その後、Joeのクライアントは、属性「ID」（典型的なXCAP操作ではなく、ここのイラストではなく、典型的な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]

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

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

「インデックス」ドキュメントの新しいHTTP ETAGは、「dwawrtyy」になりました。

Then Joe's client gets a notification:

その後、ジョーのクライアントは通知を受け取ります。

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

    <attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
     >bar</attribute>

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

その後、ジョーのクライアントは「ID」属性を削除します。

   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]

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

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

通知は、購読された属性がドキュメントから削除されたことを示しています。当然のことながら、属性が所属する要素が削除された場合、たとえばHTTP削除要求によって削除された場合、属性が「削除」されます。コンポーネントの選択は、属性または要素の存在のみを示します。

A.6. A Conditional Subscription

A.6. 条件付きサブスクリプション

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]

   <?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:

リポジトリには2つのドキュメントがあるため、最初の通知は次のようになります。

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

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

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

Notifyリクエストには、SIP-TETAG「XGGFEFE54」が含まれていることに注意してください。このSIP-TETAGは、条件付きサブスクリプションの抑制期間ヘッダーフィールドに配置されます。「diffprocessing」モードも変更されます（または変更するように要求されます）：

   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>

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 Requestの生成が抑制されます。通知者がいくつかの変更を集約できる場合、この再サブスクリプションはその後そのモードの処理を可能にします。実際、特に多数の関連する報告リソースがある場合、再サブスクリプションは非常にプロセス集約的である可能性があります。

Authors' Addresses

著者のアドレス

Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland

Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180フィンランド

   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 Plano、TX 75075 USA

   Phone: +1 214 504 19876
   EMail: dean.willis@softarmor.com