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)差分イベントパッケージ

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.

この文書では、クライアントが拡張マークアップ言語(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 http://www.rfc-editor.org/info/rfc5875.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5875で取得することができます。

Copyright Notice

著作権表示

Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(C)2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント(http://trustee.ietf.org/license-info)に関連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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者(複数可)材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者(単数または複数)から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  XCAP Diff Event Package  . . . . . . . . . . . . . . . . . . .  4
     4.1.  Overview of Operation with Basic Requirements  . . . . . .  4
     4.2.  Event Package Name . . . . . . . . . . . . . . . . . . . .  5
     4.3.  'diff-processing' Event Package Parameter  . . . . . . . .  5
     4.4.  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  6
     4.5.  Subscription Duration  . . . . . . . . . . . . . . . . . .  8
     4.6.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  8
     4.7.  Notifier Generation of NOTIFY Requests . . . . . . . . . .  8
     4.8.  Subscriber Processing of NOTIFY Requests . . . . . . . . . 11
     4.9.  Handling of Forked Requests  . . . . . . . . . . . . . . . 13
     4.10. Rate of Notifications  . . . . . . . . . . . . . . . . . . 13
     4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 13
   5.  An Initial Example NOTIFY Document . . . . . . . . . . . . . . 13
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Informative Examples  . . . . . . . . . . . . . . . . 18
     A.1.  Initial Documents on an XCAP Server  . . . . . . . . . . . 18
     A.2.  An Initial Subscription  . . . . . . . . . . . . . . . . . 18
     A.3.  A Document Addition into a Collection  . . . . . . . . . . 19
     A.4.  A Series of XCAP Component Modifications . . . . . . . . . 20
     A.5.  An XCAP Component Subscription . . . . . . . . . . . . . . 23
     A.6.  A Conditional Subscription . . . . . . . . . . . . . . . . 26
        
1. Introduction
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の差分形式[RFC5874]とユーザがXML文書の変更をサブスクライブし、たびに通知を受信することができ、「XCAP-diffを」イベントパッケージを定義しますXMLドキュメントの変更。

There are three basic features that this event package enables:

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

First, a client can subscribe to a list of XCAP documents' URLs in a collection located on an XCAP server. This allows a subscriber to compare server resources with its local resources using the URLs and the strong entity tag (ETag) values of XCAP documents, which are shown in the XCAP diff format, and to synchronize them.

まず、クライアントは、XCAPサーバー上にあるコレクションにXCAP文書URLのリストを購読することができます。これは、加入者がURLとXCAPの差分形式で示されているXCAP文書の強いエンティティタグ(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パッチ-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
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.

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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を使用して、一度に一つだけXCAPコンポーネントを更新することができます。しかしながら、通知は、XCAPの差分形式で符号化XMLパッチ-OPSセマンティクスを使用して、単一の通知にこれらの修飾の一連を集約することができるかもしれません。

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-

通知は、XCAPコンポーネントのサブスクリプションをサポートしなければなりません。通知は、サブスクリプションに応じて、最初の通知を送信し、この最初の通知は、サブスクリプションの一部である文書のURLとXCAPコンポーネントの内容を含まなければなりません。その後の通知は、これらの文書にパッチを含むかもしれません。加入者は、通知は、セクション4.3でカバー「差分処理」イベントパッケージのパラメータを使用して文書の変更を通知する方法を指定することができます。なお、「diff-の存在

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

処理」パラメータまたはその値が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]で指定されるように、この値は、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).

オプションの「差分処理」イベントヘッダフィールドパラメータを用いて、加入者は、通知がドキュメントの変更通知を示すべきかについての好みを示しています。可能な値は、「無パッチ適用」、「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の変更履歴を示すものではありません。通知機能は、相互運用性のためのベースラインとして「ノー・パッチング」モードをサポートしなければなりません。他の、より複雑なモードはオプションです。

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-パッチ」の値は、通知は、(HTTPを介して)XCAPクライアントによって行われたすべての更新されたXCAP成分の内容とエンティティタグ(ETagの)変化を含むことを意味します。クライアントは、文書の完全な(HTTP)でETag変更履歴を受けます。

The "aggregate" value means that the notifier MAY aggregate several individual XCAP component updates into a single XCAP diff <document> element. The policy for determining whether or not to apply aggregation or to determine how many updates to aggregate is locally determined.

「集計」の値は、通知は、単一XCAPデフ<Document>要素の中にいくつかの個々のXCAPコンポーネントの更新を集約することができることを意味します。アグリゲーションを適用するか、局所的に決定されるどのように多くのアップデート集約するかを決定するか否かを決定するための政策。

The notifier SHOULD support the "xcap-patching" and "aggregate" modes, and thus implement XML-Patch-Ops [RFC5261] diff-generation, because this can greatly reduce the required number of notifications and overall transmissions.

通知は、「XCAP-パッチ」と「集約」モードをサポートし、したがって、これは非常に通知し、全体的な送信の必要数を減らすことができるので、XML-パッチオプス[RFC5261]差分生成を実装する必要があります。

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

サブスクリプションは、「差分加工」ヘッダフィールドのパラメータが含まれていない場合、通知は「ノー・パッチング」モードをデフォルトとしなければなりません。

Note: To see the difference between "xcap-patching" and "aggregate" modes, consider a document that has versions "a", "b", and "c" with corresponding ETag values "1", "2", and "3". The "xcap-patching" mode will include first the change from version "a" to "b" with the versions' corresponding "1" and "2" ETags and then the change from version "b" to "c" with their "2" and "3" ETags. The "aggregate" mode optimizes the change and indicates only a single aggregated change from "a" to "c" with the old "1" and new "3" ETags. If these changes are closely related, that is, the same element has been updated many times, the bandwidth savings are larger.

注:「XCAP-パッチ」と「集約」モードの違いを確認するには、「「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.

この「差分処理」パラメータ通知に加入ヒントです。通知は単純モードではなく、より複雑なものを使用して応答することができます。モードの通知機能の選択は、4.7節で覆われています。再サブスクリプション期間中、加入者は、差分処理パラメータを変更することがあります。

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

「差分処理」パラメータの正式な文法[RFC5234]は次のとおりです。

        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.

SUBSCRIBEリクエストは、後続の通知の本体またはETag値が一致した場合、全体の通知のいずれかを抑制するために通知を指示抑制-If-Matchヘッダフィールド[RFC5839]を含んでいてもよいです。

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に設定SUBSCRIBE要求の要求URIを移入する必要があります。この文書では、そのURIを制約しません。加入者がでプロビジョニングされたか、このイベントパッケージの通知のURIを学習したことを想定しています。

The XCAP server will usually be co-located with the SIP notifier, so the subscriber MAY use relative XCAP Request-URIs. Because relative Request-URIs are allowed, the notifier MUST know how to resolve these against the correct XCAP Root URI value.

XCAPサーバーは、通常、SIP通知と同じ場所に配置されるので、加入者は、相対XCAPリクエスト-URIを使用するかもしれません。相対的な要求-URIは許可されているので、通知は正しいXCAPルートURI値に対して、これらを解決する方法を知っている必要があります。

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

tests@xcap.example.com 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">
    <list>
     <entry uri="resource-lists/users/sip:joe@example.com/index"/>
     <entry uri="rls-services/users/sip:joe@example.com/index/
   ~~/*/service%5b@uri='sip:marketing@example.com'%5d"/>
     <entry uri="pidf-manipulation/"/>
    </list>
   </resource-lists>
        

Figure 1: Example subscription body

図1:例のサブスクリプション体

When subscribing to XCAP components, namespace prefixes of XCAP Node Selectors MUST be properly resolved to namespace URIs. Section 6.4 of RFC 4825 [RFC4825] describes the conventions when using prefixes

XCAPコンポーネントに加入すると、XCAPノードセレクタの名前空間接頭辞が正しく名前空間URIに解決する必要があります。接頭辞を使用した場合、RFC 4825 [RFC4825]のセクション6.4は、表記規則について説明します

in XCAP Node Selectors. If only XCAP Default Document Namespace is used, just like in the previous example (where a <service> element is selected), the query component of the "uri" value is not required.

XCAPノードセレクタインチのみXCAPの既定のドキュメントの名前空間が使用される場合、わずか(<service>要素が選択されている)は、前の例のように、「URI」の値のクエリコンポーネントが必要とされません。

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.

通知は、許可されたXCAPリソースのリストを知った後に、それはすべての加入者が読み取り権限を持っている加入し、既存の文書、および既存のコンテンツの通常XCAP(S)成分へのURI参照を含む、最初のNOTIFYが生成されます。

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.

最初の通知を送信した後、通知は、変更を報告するための差分処理モードを選択します。加入者がSUBSCRIBEの「差分処理」パラメータでモードを提案した場合、通知は、その要求されたモードを使用したり、単純な動作モードに戻って落ちる可能性がありますが、通知はによって選ばれたものよりもより複雑なモードを使用してはなりません加入者。少なくともから最も複雑に、モードの順序は次のようではありません:「無パッチ適用」、「XCAP-パッチ適用」、「集約」。したがって、通知は、任意のモードを使用して、「集約」の要求に応答することができるが、「集計」モードを使用して「XCAP-パッチ適用」のサブスクリプションにはお答えできません。当然のことながら、通知は「ノー・パッチング」モードと「ノー・パッチング」要求を処理する必要があります。

In all modes, the notifier MUST maintain the chronological order of XCAP changes. If several changes to a given resource are presented in a single notification, the chronological update order MUST be preserved in the XML document order of the notification body. Chronological order is preserved to simplify the required subscriber implementation logic.

すべてのモードでは、通知は、XCAP変化の時系列順を維持しなければなりません。与えられたリソースにいくつかの変更は、単一の通知に提示されている場合は、時系列更新順序は、通知本体のXMLドキュメントの順序で保存されなければなりません。年代順が必要な加入者の実装ロジックを簡素化するために保存されています。

While the "aggregate" mode uses bandwidth most efficiently, it introduces other challenges. The initial synchronization might fail with rapidly changing resources, because the "aggregate" mode messages might not include the full version history of a document and the base XCAP protocol does not support version history retrievals of documents. When new documents are created in subscribed collections and the notifier is aggregating patches, the same issue can occur. In a corner case (such as when the XML prolog changes), the notifier may not be able to provide patches with the XML-Patch-Ops [RFC5261] semantics.

「集約」モードは、最も効率的な帯域幅を使用していますが、それは他の課題を紹介します。 「集約」モードメッセージは、文書のフルバージョン履歴とドキュメントのバージョン履歴の回収のをサポートしていないベースXCAPプロトコルが含まれていない可能性があるため、初期同期は、急速に変化するリソースで失敗する可能性があります。新しい文書が、サブスクライブコレクションに作成され、通知がパッチを集約した場合、同じ問題が発生する可能性があります。 (例えば、XMLプロローグの変更など)のコーナー場合、通知は、XMLパッチ-OPS [RFC5261]のセマンティクスでパッチを提供することができないかもしれません。

If the notifier has to temporarily disable diff generation and send only the URI references of some changed documents to the subscriber, it MUST continue with the "xcap-patching" mode afterwards for these resources, if the initial subscription also started with the "xcap-patching" mode.

通知が一時的に差分生成を無効にし、加入者にいくつか変更された文書の唯一のURI参照を送信する必要がある場合は、最初のサブスクリプションがまた、「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体が非現実的に大きくなる又は中間エラーが発生したときに差分生成を無効にすることができます。加入者は、パッチ適用操作のトラックを失ったとして、それが現在の文書をダウンロードすることにより、「既知の正常な」状態に更新する必要があります。それはそうしていたら、それは「集約」モードで、例えば、再登録することができます。

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.

[ETag値]:通知は、再加入を受信すると、加入者がヘッダフィールド抑制-IF-マッチを使用して条件付きサブスクリプション[RFC5839]を要求していない限り、現在の完全なXML差分コンテンツを再送信しなければなりません。現在のサブスクリプションの状態を決定する際の条件に再加入して、通知はまた、サブスクリプション本体を検査しなければなりません。サブスクリプションがXCAPリクエストURIのリストに基づいているので、「保存」以前の状態への等価性を決定する際に通知がこれらのURIの順序を考慮していないことが推奨されます。以前の状態に一致するものが見つからない場合は、NOTIFYメッセージは、(最初​​の通知に似て)完全なXMLのdiff状態を含まなければなりません。届出者は、このイベントパッケージで取り扱い条件付きのサブスクリプションを実装する必要があります。

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.

再購読時、加入者は、差分処理パラメータの値を変更してもよいです。値変化の影響のみその後の通知ではなく、(生成された場合)、通知が(再)SUBSCRIBEリクエストの直後に続きます。

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.

注:この要件は、アウトオブオーダーイベントが起こるかダイアログが解像不可能なNOTIFYリクエストの失敗の後に終了することはないだろうことを保証します。加えて、可能性のいくつか(例えば、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.

例えば、加入者(つまり、NOTIFY中間故障である)通知体が非現実的に大きいであろうように、サブスクライブするためにどのにあまりにも多くの要素を選択した場合、通知は、<要素>要素の内容を捨てるかもしれ。要素の存在は、その後、空の<要素>要素で示され、そして内容は、それらのリソースのために示されていません。言い換えれば、<要素>要素は、サブスクライブ「フル」要素の内容を示すであろう子要素を持っていません。

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.

通知はHTTPの変更後に、好ましくは、いくつかの最小間隔で報告されているために発生することがあります。また、文書の削除は、理由unexistingリソース(急速に変化する)で失敗する可能性が通知および/またはHTTPの回収ので報告することができます。いずれの場合も、加入者は、可能な同期外れた文書を再取得することができ、その後の通知を待つか(「XCAP-パッチ適用」で)サブスクリプションをリフレッシュし、「フル」の同期まで説明した「同期」アルゴリズムを繰り返しが達成された。

If the notifier aggregates patches, the previous modification list may not contain the ETag value retrieved by HTTP simply because of aggregation optimizations. A similar out-of-sync cycle can happen when new (subscribed) documents are created that change rapidly. To avoid such difficulties, the subscriber MAY start the subscription with the "xcap-patching" mode, and then refresh the subscription with the "aggregate" mode after the initial sync is achieved. Naturally, the subscriber can revert back to the "xcap-patching" mode from "aggregate" at any time and vice versa.

通知はパッチを集約した場合は、前回の変更リストは、単にので、集約最適化HTTPによって取得ETagの値を含めることはできません。新しい(サブスクライブ)文書は、急速に変化するように作成されている場合も、同様のアウト同期サイクルが発生する可能性があります。このような困難を回避するために、加入者は、「XCAP-パッチ適用」モードでサブスクリプションを起動し、初期同期が達成された後、「集約」モードでサブスクリプションをリフレッシュするかもしれません。当然のことながら、加入者は任意の時間またはその逆に「集合」からバック「XCAP-パッチ」モードに戻すことができます。

If the subscriber has received a "full" sync and it has detected that some of the resources are being served with the "xcap-patching" mode while others are in the "aggregate" mode, it SHOULD refresh the subscription to the "aggregate" mode.

加入者が「フル」の同期を受けており、それが他の人が「集約」モードになっている一方で、リソースのいくつかは、「XCAP・パッチング」モードで提供されていることを検出した場合には、「集約」へのサブスクリプションをリフレッシュする必要がありますモード。

The notifier MAY at any time temporarily use the "no-patching" mode for some resources so that the subscriber receives only URI references of modifications. When the notifier is acting in this mode, several cycles MAY be needed before an initial "full" sync is achieved. As the notifier MAY change modes in the middle of a dialog, the subscriber is always responsible for taking appropriate actions. Also, as the last resort, the subscriber MAY always disable the usage of diff-processing by setting the "diff-processing" parameter to "no-patching".

加入者が修正の唯一のURI参照を受信するよう通知はいつでも一時的にいくつかのリソースに対して「ノーパッチング」モードを使用するかもしれません。通知は、このモードで動作している場合は、最初の「フル」の同期が達成される前に、いくつかのサイクルが必要になることがあります。通知は、ダイアログの途中でモードを変更する可能性があるため、加入者は、常に適切な行動を取る責任があります。また、最後の手段として、加入者は常に「非パッチング」に「差分処理」パラメータを設定することにより、差分処理の使用を無効にできます。

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を参照)により、パッチ処理および/またはプログラミングエラーに適用できない場合、加入者は、サブスクリプションを更新し、「に「差分処理」パラメータを設定することにより、パッチ無効にする必要があります無パッチングありません」。通知は、修正を行うことができないので、加入者は非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.

この仕様は、最初の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.

「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

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にSUBSCRIBE例にNOTIFYリクエストをすることによって提供される例初期XCAPデフ形式の文書は、このSUBSCRIBEリクエストの例イベントヘッダフィールドであることを示し

Event: xcap-diff; diff-processing=aggregate

イベント:XCAP-diffを。差分処理=集計

The subscriber requests that the notifier "aggregate" XCAP component updates and anticipates that the subsequent notifications will contain aggregated patches to these documents.

その後の通知は、これらの文書に集約されたパッチが含まれることを見込んで通知「集約」XCAPコンポーネントのアップデートと加入者の要求。

<?xml version="1.0" encoding="UTF-8"?> <d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff" xmlns:s="urn:ietf:params:xml:ns:rls-services" xcap-root="http://xcap.example.com/root/">

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

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

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

<d:document new-etag="30376adf" sel="pidf-manipulation/users/sip:joe@example.com/index"/>

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

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

次のように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の」イベントパッケージの加入者を認証する必要があります。ノーティファイアは、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.

届出者に対するサービス拒否攻撃は特筆に値します。集中的な処理にサービス拒否を引き起こす可能性があり、次の両極端に必要な帯域幅の使用を最適化しようとすると、存在しない文書やXCAPコンポーネント、およびデフ生成アルゴリズムへのサブスクリプションの「保留中」のURIの長いリストにサブスクリプションが。

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のイベント情報を搬送するために使用され、機密情報を確実にすべきです。 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
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.

著者は彼の貴重なコメントのために、初期イベントパッケージを提供するためのジョナサン・ローゼンバーグ、およびアキニエミ、ペッカPessi、ミゲル・ガルシア、パベル・ドスタル、Krisztianキス、アンダースリンドグレン、ソフィーLassborn、キース糖剤、スティーブン・ヒントン、バイロンCampenに感謝したいと思います、彼らの貴重なコメントについてAvshalomフーリー、ベン・キャンベル、ポールKyzivat、スペンサードーキンスパシEronen、そしてクリス・ニューマン。リサ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]ブラドナーの、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, <http://www.w3.org/TR/2006/REC-xml-20060816>.

[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月、<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リクエストURIが現実に対応していないことにも注意してください。

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:

hっtp://xかp。えぁmpぇ。こm/てsts/うせrs/しp:じょえ@えぁmpぇ。こm/いんでx:

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

その後

http://xcap.example.com/tests/users/sip:john@example.com/index:

hっtp://xかp。えぁmpぇ。こm/てsts/うせrs/しp:じょhん@えぁmpぇ。こm/いんでx:

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

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]

tests@xcap.example.com 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/sip:joe@example.com/"/> </list> </resource-lists>

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

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

200(OK)応答に加えて、通知は、最初のNOTIFY送信します。

NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

<?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/sip:joe@example.com/index"/>

<ドキュメント新しい-のETag = "7ahggs" SEL = "テスト/ユーザー/ SIP:joe@example.com/index" />

</xcap-diff>

</ XCAP-diffを>

The subscriber learns that the document on this "tests" application usage is equivalent to its locally cached version, so it does not act. If the local version had been different, the subscriber would most likely re-fetch the document.

加入者は、この「テスト」アプリケーションの使用に関する文書がローカルにキャッシュされたバージョンと同等であることを学習し、それは作用しません。ローカルバージョンが異なっていた場合は、加入者が最も可能性の高い文書を再フェッチでしょう。

If the subscriber had requested the "tests/users/" collection, the notification body would have been the same since Joe has no read privileges to John's resources (XCAP default behavior).

加入者が「テスト/ユーザ/」コレクションを要求した場合、ジョーはジョンのリソース(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を行います。

PUT /tests/users/sip:joe@example.com/another_document HTTP/1.1 Host: xcap.example.com .... Content-Type: application/xml Content-Length: [XXX]

PUT /tests/users/sip:joe@example.com/another_document HTTP / 1.1ホスト:xcap.example.com ....の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:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

<?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/sip:joe@example.com/another_document"/>

<ドキュメント新しい-のETag = "terteer" SEL = "テスト/ユーザー/ SIP:joe@example.com/another_document" />

</xcap-diff>

</ XCAP-diffを>

Note that the result is "additive"; it doesn't indicate the already indicated "index" document. Only the initial (or refreshed) notification contains all document URI references.

結果は「添加物」であることに注意してください。それはすでに示し、「インデックス」のドキュメントを示すものではありません。唯一の最初の(または更新)通知は、すべての文書のURI参照が含まれています。

If Joe's client both modifies the documents and refreshes the subscriptions, it would typically ignore this notification, since its modifications had caused the notification. If the client that received this NOTIFY hadn't submitted the document change, it would probably fetch this new document.

ジョーのクライアントの両方がドキュメントを変更し、サブスクリプションをリフレッシュした場合、その変更が通知の原因となったため、それは一般的に、この通知を無視します。これは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.

ジョーのクライアントは、最初のサブスクリプションと同じリクエストボディとサブスクリプションを更新した場合、その結果は、これら二つの文書が含まれます:彼らてETagと「インデックス」と「another_document」。

A.4. A Series of XCAP Component Modifications

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

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

今ジョーのクライアントには、次の操作を行って、その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]

xcap.example.com ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/sip:joe@example.com/index/ 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.

要素の挿入が成功したので、ジョーのクライアントが更新され、「インデックス」ドキュメントの新しいHTTPのETag「fgherhryt3」を受信します。

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

その直後に、ジョーのクライアントは別の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]

xcap.example.com ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/sip:joe@example.com/index/ HTTP / 1.1ホストをPUT :[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]

xcap.example.com ....のContent-Type:アプリケーション/ XCAP-EL + XMLコンテンツ長/tests/users/sip:joe@example.com/index/ HTTP / 1.1ホストをPUT :[XXX]

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

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

The reported new ETag of "index" is now "63hjjsll".

今、「63hjjsll」である「インデックス」の報告新しいETagを。

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

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

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

<d:document previous-etag="7ahggs3" sel="tests/users/sip:joe@example.com/index" new-etag="63hjjsll"> <d:add sel="*"

<D:前-のETag = "7ahggs3" SEL =文書化:新しい-のETag = "63hjjsll" "テスト/ユーザー/ SIPはjoe@example.com/index"> <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>

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

ジョーのクライアントは、ローカルにキャッシュされた「インデックス」の文書には、このパッチを適用した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.

ジョーのクライアントは、参照文書のローカルにキャッシュされたバージョンを持っていなかった場合、また、その注意してください、それが最初の通知後に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]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

<?xml version = "1.0" エンコード= "UTF-8"?> <D:XCAP-diffののxmlns:D = "壷:IETF:のparams:XML:NS:XCAP-diffの" XCAPルート= "の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:文書前の-のETag = "7ahggs" SEL = "テスト/ユーザー/ SIP:joe@example.com/index" 新-のETag = "fgherhryt3"> <D:追加SEL = "*"> <foo>の本新しい要素は</ foo>の</ D:追加> </ D:ドキュメント>

<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:文書前の-のETag = "fgherhryt3" SEL = "テスト/ユーザー/ SIP:joe@example.com/index" 新-のETag = "dgdgdfgrrr"> <D:= SELを追加 "*"> <バー>このあるバーの要素</バー> </ D:追加> </ D:ドキュメント>

<d:document previous-etag="dgdgdfgrrr"

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

sel="tests/users/sip:joe@example.com/index" new-etag="63hjjsll"> <d:add sel="*" ><foobar>this is a foobar element</foobar></d:add></d:document>

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

</d:xcap-diff>

</ D:XCAP-diffを>

If the client had to re-fetch the "index" document after the initial notification, it could have skipped some or all of these patches, depending on whether the HTTP ETag matched some of these ETags in the chain of patches. If the HTTP ETag did not match and the received HTTP version is a newer version indicated in later notification(s), the sync may then be achieved since the notifier provided the full change history in the "xcap-patching" mode.

クライアントは、最初の通知後に「インデックス」のドキュメントを再フェッチしなければならないとしたら、それはHTTPのETagは、パッチのチェーンにこれらてETagの一部にマッチしたかどうかに応じて、これらのパッチの一部またはすべてをスキップすることができました。 HTTPのETagが一致せず、受信したHTTPバージョンが通知(単数または複数)に示される新しいバージョンである場合に通知が「XCAP-パッチ」モードで完全な変更履歴を提供するので、同期はその後達成することができます。

Last, the notifier could (temporarily) fall back to the "no-patching" mode, which allows the notifier to keep the dialog alive when there are too many updates:

最後に、通知は、(一時的に)あまりにも多くの更新がある場合に通知が生きてダイアログを維持することができます「ノーパッチ適用」モードにフォールバックできます。

NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

<?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/sip:joe@example.com/index" new-etag="63hjjsll"/>

<文書前の-のETag = "7ahggs3" SEL = "テスト/ユーザー/ SIPは:joe@example.com/index" 新-のETag = "63hjjsll" />

</xcap-diff>

</ XCAP-diffを>

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

いつでも、通知が戻って加入した文書の一部またはすべてについて「ノー・パッチング」モードに入り得ます。

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:tests@xcap.example.com SIP/2.0 ... Accept: application/xcap-diff+xml Event: xcap-diff Content-Type: application/resource-lists+xml Content-Length: [XXX]

一口にSUBSCRIBE:tests@xcap.example.com 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/sip:joe@example.com/index/~~/doc/@id"/> </list> </resource-lists>

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

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]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/"/>

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

その後、ジョーのクライアントは、属性「ID」(ない典型的なXCAP操作または好ましいもので、ここだけのイラスト)を含む全文書のルート要素を更新します。

PUT /tests/users/sip:joe@example.com/index/~~/doc HTTP/1.1 Host: xcap.example.com .... Content-Type: application/xcap-el+xml Content-Length: [XXX]

PUTの/tests/users/sip:joe@example.com/index/のHTTP / 1.1ホスト:xcap.example.com ....の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".

「インデックス」ドキュメントの新しいHTTPのETagは今、「dwawrrtyy」です。

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]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

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

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

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

</xcap-diff>

</ XCAP-diffを>

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

それは、このユースケースは無関係であるように、新しいドキュメントの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

xcap.example.com ....のContent-Length:0 /tests/users/sip:joe@example.com/index/ HTTP / 1.1ホストを削除

And the subscriber gets a notification:

そして、加入者は、通知を取得します。

NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff Content-Type: application/xcap-diff+xml Content-Length: [XXX]

一口にNOTIFY:joe@userhost.example.com 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="http://xcap.example.com/">

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

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

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

</xcap-diff>

</ XCAP-diffを>

The notification indicates that the subscribed attribute was removed from the document. Naturally, attributes are "removed" if the element where they belong is removed, for example, by an HTTP DELETE request. The component selections indicate only the existence of attributes or elements.

通知は、加入属性が文書から削除されたことを示しています。当然のことながら、属性は、彼らが属している要素が削除された場合、例えば、HTTPによるリクエストをDELETE「削除」されています。コンポーネントの選択は、属性または要素の存在のみを示しています。

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:

最後の例では、リソースに変更がないときフル・リフレッシュを回避することができ、条件付きのサブスクリプションです。ジョーのクライアントは、最初のサブスクリプションを送信します。

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]

tests@xcap.example.com 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/sip:joe@example.com/"/> </list> </resource-lists>

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

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

リポジトリ内の2つの文書が存在することになりますので、最初に以下のようなルックスをNOTIFY:

NOTIFY sip:joe@userhost.example.com SIP/2.0 ... Event: xcap-diff SIP-ETag: xggfefe54 Content-Type: application/xcap-diff+xml Content-Length: [XXX]

joe@userhost.example.com 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="http://xcap.example.com/">

<?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/sip:joe@example.com/index"/>

<ドキュメント新しい-のETag = "63hjjsll" SEL = "テスト/ユーザー/ SIP:joe@example.com/index" />

<document new-etag="terteer" sel="tests/users/sip:joe@example.com/another_document"/>

<ドキュメント新しい-のETag = "terteer" SEL = "テスト/ユーザー/ SIP:joe@example.com/another_document" />

</xcap-diff>

</ XCAP-diffを>

Note that the NOTIFY request contains the SIP-ETag "xggfefe54". This SIP-ETag is placed in the Suppress-If-Match header field of the conditional subscription. The "diff-processing" mode also is changed (or is requested to change):

NOTIFYリクエストは、SIP-ETagを「xggfefe54」が含まれていることに注意してください。このSIP-ETagのは、条件付きサブスクリプションの抑制-If-Matchヘッダフィールドに置かれます。また、「差分処理」モードが変更された(または変更するように要求します)。

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]

tests@xcap.example.com 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/sip:joe@example.com/"/> </list> </resource-lists>

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

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: jari.urpalainen@nokia.com

電話:+358 7180 37686電子メール:jari.urpalainen@nokia.com

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: dean.willis@softarmor.com

電話:+1 214 504 19876 Eメール:dean.willis@softarmor.com