RFC 5874 - An Extensible Markup Language (XML) Document Format for Indicating a Change in XML Configuration Access Protocol (XCAP) Resources 日本語訳

URL : https://tools.ietf.org/html/rfc5874
タイトル : RFC 5874 - XMLコンフィギュレーションアクセスプロトコル（XCAP）リソースの変更を示すための拡張マークアップ言語（XML）ドキュメント・フォーマット
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                      J. Rosenberg
Request for Comments: 5874                                   jdrosen.net
Category: Standards Track                                  J. Urpalainen
ISSN: 2070-1721                                                    Nokia
                                                                May 2010

        An Extensible Markup Language (XML) Document Format for
                         Indicating a Change in
           XML Configuration Access Protocol (XCAP) Resources

Abstract

抽象

This specification defines a document format that can be used to indicate that a change has occurred in a document managed by the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format. It can report existing element and attribute content when versions of an XCAP server document change. XCAP diff documents can be delivered to diff clients using a number of means, including a Session Initiation Protocol (SIP) event package.

この仕様は変更は拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）によって管理される文書で発生したことを示すために使用することができ、文書のフォーマットを定義します。この文書が変更された形式のレポートとその前者と新しいエンティティタグ。これは、XMLパッチの形式を使用して、ドキュメントのバージョン間の相違点を報告することができます。これは、既存の要素を報告し、XCAPサーバー文書の変更の際にバージョンコンテンツの属性することができます。 XCAP diffのドキュメントは、セッション開始プロトコル（SIP）イベントパッケージを含む多数の手段を使用して、差分クライアントに配信することができます。

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

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

著作権表示

著作権（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.  Structure of an XCAP Diff Document . . . . . . . . . . . . . .  5
   4.  XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  Example Document . . . . . . . . . . . . . . . . . . . . . . . 11
   6.  Basic Requirements for a System Exchanging XCAP Diff
       Documents  . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
     8.1.  application/xcap-diff+xml MIME Type  . . . . . . . . . . . 14
     8.2.  URN Sub-Namespace Registration for
           urn:ietf:params:xml:ns:xcap-diff . . . . . . . . . . . . . 15
     8.3.  Schema Registration  . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Appendix A.  Informative Examples  . . . . . . . . . . . . . . . . 18
     A.1.  Indicating Existing, Changed, or Removed Documents . . . . 18
     A.2.  Indicating Actual Changes of Documents . . . . . . . . . . 21
     A.3.  Indicating XCAP Component Contents . . . . . . . . . . . . 23

1. Introduction

1. はじめに

The Extensible Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825] is a protocol that allows XCAP clients to manipulate XML documents stored on a server. These XML documents serve as configuration information for application protocols. As an example, resource list [RFC4662] subscriptions (also known as presence lists) allow a SIP client to have a single SIP subscription to a list of users, where the list is maintained on a server. The server will obtain presence for those users and report it back to the SIP client. This application requires the server, called a Resource List Server (RLS), to have access to the list of presentities [RFC2778]. This list needs to be manipulated by XCAP clients so they can add and remove their friends as they desire.

拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）[RFC4825]はXCAPクライアントがサーバに格納されたXMLドキュメントを操作することを可能にするプロトコルです。これらのXML文書は、アプリケーションプロトコルの設定情報として役立ちます。一例として、リソースリスト（また、プレゼンスリストとして知られている）[RFC4662]サブスクリプションは、SIPクライアントがリストをサーバ上で維持されているユーザのリスト、単一のSIPサブスクリプションを持たせます。サーバーは、それらのユーザーのプレゼンスを取得し、SIPクライアントにそれを報告します。このアプリケーションは、[RFC2778]プレゼンのリストへのアクセス権を持っている、リソースリストサーバ（RLS）と呼ばれる、サーバが必要です。このリストは、彼らが望むよう、彼らは彼らの友人を追加および削除することができますので、XCAPクライアントによって操作する必要があります。

Complexities arise when multiple XCAP clients attempt to simultaneously manipulate a document, such as a presence list. Frequently, an XCAP client will keep a copy of the current list in memory, so it can render it to users. However, if another XCAP client modifies the document, the cached version becomes stale. This modification event must be made known to all clients that have cached copies of the document, so that they can fetch the most recent one.

複数のXCAPクライアントが同時に文書を操作しようとすると複雑さは、このようなプレゼンスリストとして、発生します。それは、ユーザーにそれをレンダリングすることができますので、頻繁に、XCAPクライアントは、メモリ内の現在のリストのコピーを保持します。別のXCAPクライアントが文書を変更する場合ただし、キャッシュされたバージョンが古くなってしまいます。この変更イベントは、彼らは最新のものを取り出すことができるように、文書のコピーをキャッシュしているすべてのクライアントに知らせなければなりません。

To deal with this problem, clients can use a Session Initiation Protocol (SIP) [RFC3261] event package [RFC3265] to subscribe to change events [RFC5875] in XCAP documents. This notification needs to indicate the specific resource that changed and how it changed. One solution for the format of such a change notification would be a content indirection object [RFC4483]. Though content indirection can tell a client that a document has changed, it provides it with a MIME Content-ID indicating the new version of the document. The MIME Content-ID is not the same as the entity tag, which is used by XCAP for document versioning. As such, a client cannot easily ascertain whether an indication of a change in a document is due to a change it just made or due to a change another XCAP client made at around the same time. Furthermore, content indirections don't indicate how a document changed; they are only able to indicate that it did change.

この問題に対処するには、クライアントがXCAPドキュメント内のイベント[RFC5875]を変更するためにサブスクライブするために、セッション開始プロトコル（SIP）[RFC3261]イベントパッケージ[RFC3265]を使用することができます。この通知は、変更され、それがどのように変化し、特定のリソースを示す必要があります。そのような変更通知のフォーマットのための一つの解決策は、コンテンツ間接オブジェクト[RFC4483]であろう。コンテンツ間接文書が変更されたことをクライアントに伝えることができますが、それは、ドキュメントの新しいバージョンを示すMIMEコンテンツ-IDとそれを提供します。 MIMEのContent-IDは、文書のバージョン管理のためにXCAPによって使用されるエンティティタグ、同じではありません。そのため、クライアントは、簡単に文書の変化の兆候が同時期に作られた別のXCAPクライアントそれだけで行われた変更または伴う変更によるものかどうかを確認することはできません。さらに、コンテンツの間接は、文書がどのように変化するかを示すものではありません。彼らは、それが変化しなかったことを示すことができます。

To resolve these problems, this document defines a data format that can convey the fact that an XML document managed by XCAP has changed. This data format is an XML document format, called an XCAP diff document. This format reports which document has changed and its former and new entity tags. It can report the differences between versions of the document, using an XML patch format [RFC5261], which indicate how to transform the locally cached XCAP document from the version prior to the change to the version after it. Its intent is to reduce the required overall bandwidth and the number of separate transmissions. It can also report existing element and attribute content when versions of an XML document change at an XCAP server.

これらの問題を解決するには、この文書では、XCAPによって管理されるXML文書が変更されたという事実を伝えることができるデータ形式を定義します。このデータ・フォーマットは、XCAP diffのドキュメントと呼ばれ、XML文書形式です。この文書が変更された形式のレポートとその前者と新しいエンティティタグ。それは後のバージョンに変更する前のバージョンからローカルにキャッシュされたXCAP文書を変換する方法を示すXMLパッチ形式[RFC5261]を使用して、ドキュメントのバージョン間の相違点を報告することができます。その意図は、必要な全体の帯域幅と別々の送信回数を減らすことです。また、既存の要素を報告し、XCAPサーバーでのXMLドキュメントの変更の際にバージョンコンテンツの属性することができます。

XML documents that are equivalent for the purposes of many applications may differ in their physical representation. Similar to XCAP, the canonical form with comments [W3C.REC-xml-c14n-20010315] of an XML document determines the logical equivalence when this format is used to patch locally cached XCAP documents.

多くのアプリケーションの目的のために等価であるXML文書は、それらの物理的な表現で異なる場合があります。このフォーマットは、ローカルにキャッシュされたXCAP文書にパッチを適用するために使用される場合XCAPと同様に、XML文書のコメント[W3C.REC-XML-C14N-20010315]を有する標準形式は、論理等価性を決定します。

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

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

This specification also defines the following additional terms:

また、この仕様は、以下の追加の用語を定義しています。

Document: When the term document is used without the "(XCAP) diff" in front of it, it refers to the XCAP document resource about which the XCAP diff document is reporting a change.

文書：用語文書がその前に「（XCAP）差分」なしで使用する場合には、XCAPの差分文書は変更を報告しているかについてXCAP文書リソースを指します。

Diff document: The XML document defined by this specification that reports on a set of changes in an XCAP document resource. It is delivered from a server to a diff client by a transport that is not defined by this specification.

差分文書：XCAPドキュメントリソースの変更のセットに報告し、この仕様で定義されたXMLドキュメント。これは、この仕様で定義されていない交通機関でのdiffサーバからクライアントに配信されます。

XCAP server: A protocol entity that manages XCAP documents and their entity tags. It usually contains an integrated diff notifier.

XCAPサーバー：XCAP文書とそのエンティティタグを管理プロトコルエンティティ。これは通常、統合された差分の通知が含まれています。

Diff notifier: This is the entity of a server that generates XCAP diff documents based on its knowledge of a set of XCAP documents and their changes, and it transmits the generated diff documents to a diff client within a session.

差分通知：これは、XCAP文書とその変更のセットのその知識に基づいてXCAP diffのドキュメントを生成するサーバーのエンティティであり、そしてそれはセッション内のdiffクライアントに生成された差分文書を送信します。

Diff client: A client that consumes XCAP diff documents in order to construct a locally cached document that is equivalent to a specific version of a document resource stored at an XCAP server. It is typically a SIP User Agent (UA) and an XCAP client.

差分クライアント：XCAPサーバーに格納された文書のリソースの特定のバージョンに相当し、ローカルにキャッシュされたドキュメントを構築するためにXCAP diffのドキュメントを消費クライアント。それは、典型的には、SIPユーザエージェント（UA）とXCAPクライアントです。

XCAP Client: A client that updates and retrieves documents stored at an XCAP server. It can also patch element and attribute content of XCAP documents located at an XCAP server.

XCAPクライアント：XCAPサーバーに格納された文書を検索、更新およびクライアント。また、要素にパッチを適用し、XCAPサーバーにあるXCAP文書の内容を属性することができます。

Locally cached resource: A resource that has typically been downloaded by HTTP from an XCAP server to a diff client. It may have been patched locally by a diff client based on the XCAP diff document information. It is equivalent to a single version in its change history at an XCAP server. Version history of XCAP documents is indicated by HTTP entity tags (ETags).

ローカルにキャッシュされたリソース：通常のdiffクライアントにXCAPサーバからHTTPによってダウンロードされたリソース。これは、XCAP diffの文書情報に基づいて差分クライアントによってローカルにパッチが適用された可能性があります。これは、XCAPサーバーでその変化の歴史の中で、単一のバージョンに相当します。 XCAPドキュメントのバージョン履歴は、HTTPエンティティタグ（てETag）で示されます。

ETag: A strong HTTP entity tag whose value is set by an XCAP server. Documents at an XCAP server are updated by XCAP clients. The XCAP server assigns a new ETag value to each document version according to the HTTP specification.

ETagの：値XCAPサーバーによって設定された強力なHTTPのエンティティタグ。 XCAPサーバーでのドキュメントは、XCAPクライアントによって更新されます。 XCAPサーバは、HTTP仕様に従って各ドキュメントバージョンに新しいETag値を割り当てます。

3. Structure of an XCAP Diff Document

XCAP Diffのドキュメントの3構造

An XCAP diff document is an XML [W3C.REC-xml-20060816] document that MUST be well-formed and SHOULD be valid. XCAP diff documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying XCAP diff documents and document fragments. The namespace URI for elements defined by this specification is a URN [RFC2141], using the namespace identifier 'ietf' defined by [RFC2648] and extended by [RFC3688]. This URN is:

XCAP diffの文書は整形式でなければならないと有効である必要がありXML [W3C.REC-XML-20060816]文書です。 XCAP diffの文書は、XML 1.0に基づいていなければならないとUTF-8を使用してエンコードされなければなりません。この仕様は、XCAP diffのドキュメントとドキュメントフラグメントを識別するためのXML名前空間を使用しています。この仕様によって定義された要素の名前空間URIは、名前空間識別子「IETF」[RFC2648]で定義され、[RFC3688]の拡張を使用して、URN [RFC2141]です。このURNは以下のとおりです。

urn:ietf:params:xml:ns:xcap-diff

URN：IETF：のparams：XML：NS：XCAP-diffを

An XCAP diff document begins with the root element tag <xcap-diff>. This element has a single mandatory attribute, "xcap-root". The value of this attribute is the XCAP root URI for the documents in which the changes have taken place. A single XCAP diff document can only represent changes in documents within the same XCAP root. The content of the <xcap-diff> element is a sequence of <document>, <element>, and <attribute> elements followed by any number of elements from other namespaces for the purposes of extensibility. Wherever the XML schema (see Section 4) allows extension elements or attributes, any such unknown content MUST be ignored by the diff client.

XCAP diffのドキュメントには、ルート要素タグ<XCAP-diffを>で始まります。この要素は、単一の必須属性、「XCAPルート」を持っています。この属性の値は、変更が行われてきている文書についてXCAPルートURIです。単一XCAP diffのドキュメントは、同じXCAPルート内のドキュメントの変化を表すことができます。 <XCAP-diffを>の内容は、要素は、<文書>、<要素>、および拡張性の目的のために他の名前空間からの要素の任意の数が続く<属性>要素のシーケンスです。どこXMLスキーマは、（セクション4を参照）、そのような未知のコンテンツは、デフクライアントによって無視されなければならない、拡張要素や属性を可能にします。

Each <document> element specifies changes in a specific document within the XCAP root. If several <document> elements pinpoint the same specific document, i.e., for example, the full entity tag (ETag) change history is indicated, the corresponding patches MUST be able to be applied in the given XCAP diff document order.

各<ドキュメント>要素は、XCAPルート内の特定の文書の変更を指定します。いくつかの<文書>要素が同じ特定の文書を特定した場合、即ち、例えば、完全なエンティティタグ（ETagの）変更履歴が示され、対応するパッチが与えられたXCAPデフ文書順序で適用することができなければなりません。

Note: This requirement simplifies applications that process XCAP diff documents since there's no need to sort patch instructions when applying them.

注：この要件は、それらを適用する場合、パッチ命令をソートする必要はありませんので、XCAP diffのドキュメントを処理するアプリケーションを簡素化します。

The <document> element has one mandatory attribute, "sel", and two optional attributes, "new-etag" and "previous-etag". The "sel" attribute of the <document> element identifies the specific document within the XCAP root for which changes are indicated. Its content MUST be a relative path reference, with the base URI being equal to the XCAP root URI. The "new-etag" attribute provides the entity tag (ETag) for the document after the application of the changes, assuming the document exists after those changes. The "previous-etag" attribute provides an identifier for the document instance prior to the change. If the change being reported is the removal of a document, only the "previous-etag" MUST be included and the "new-etag" attribute MUST NOT be present. The "new-etag" attribute MUST only exist alone when the document either exists or it was just created (no patch included). Both attributes are present when a patch (or series of XCAP operations) has been applied to the resource. Also, both attributes MAY be used to indicate an ETag change without any document modifications (patches).

<ドキュメント>要素は、1つの必須属性、「SEL」、および2つのオプション属性が、「新-のETag」と「前-のETag」を持っています。 <Document>要素の「SEL」属性は、変更が指示されるXCAPルート内の特定の文書を識別する。その含有量は、ベースURIは、XCAPルートURIに等しいと、相対パス参照でなければなりません。「新規のETag」属性は、文書がその変更後に存在すると仮定すると、変更を適用した後の文書のエンティティタグ（ETagの）を提供します。「前回-のETag」属性は、変更前の文書インスタンスの識別子を提供します。報告された変更は、文書の除去である場合には、唯一の「前の-のETagは」含まれなければならないと「新-のETag」属性が存在してはなりません。文書が存在しているか、それがちょうど（ないパッチが含まれていない）に作成されたいずれかの時に、「新しい-のETag」属性は、一人で存在しなければなりません。パッチ（またはXCAPの一連の動作）がリソースに適用された場合、両方の属性が存在しています。また、両方の属性は、任意のドキュメントの修正（パッチ）なしのETagの変更を示すために使用され得ます。

The "previous-etag" and "new-etag" need not have been sequentially assigned ETags at the server. An XCAP diff document can indicate changes that have occurred over a series of XCAP operations. The only requirement then is that the sequence of events, when executed serially, will result in the transformation of the document with the ETag "previous-etag" to the one whose ETag is "new-etag". Also, the series of operations do not have to be the same exact series of operations that occurred at the server.

「前回-のETag」と「新-のETagは、」順次サーバーでてETagを割り当てられている必要はありません。 XCAP diffのドキュメントは、XCAPの一連の操作の上に発生した変更を示すことができます。唯一の要件は、その後、連続実行されたときにイベントのシーケンスは、ETagを「新しいのETag」であるものとのETag「前-のETag」の文書の変換をもたらすことです。また、一連の操作は、サーバーで発生した操作のとまったく同じシリーズである必要はありません。

Each <document> element contains either a sequence of patching instructions or an indication that the body hasn't semantically changed. The latter means that the document has been assigned a new ETag but its content is unchanged and it is indicated by the <body-not-changed> element. Patching instructions are described by the <add>, <replace>, and <remove> elements. These elements use the corresponding add, replace, and remove types defined in [RFC5261], and define a set of patch operations that can be applied to transform the locally cached document. See [RFC5261] for instructions on how this transformation is effected. The <document> element can also contain elements from other namespaces for the purposes of extensibility. The <add>, <replace>, and <remove> elements allow extension attributes from any namespace.

各<Document>要素は、パッチ命令のシーケンスまたは本体が意味的に変化していないことの表示のいずれかを含みます。後者は、文書が新規のETagが割り当てられているが、その内容は変更され、それが<BODY-変化しない>要素によって示されることを意味します。パッチ適用の手順は、<置き換える>、<追加>、および<削除>要素で記述されています。これらの要素は、対応する追加、置き換え、および[RFC5261]で定義されたタイプを削除し、ローカルにキャッシュされた文書を変換するために適用することができるパッチ・オペレーションのセットを定義する使用します。この変換が行われる方法については、[RFC5261]を参照してください。 <Document>要素は、拡張性の目的のために他の名前空間からの要素をも含むことができます。 <置き換え>、<追加>、および<削除>要素は、拡張子は任意の名前空間からの属性を許します。

Figure 1 shows <document> element content and how the corresponding resource or metadata changes. In practice, an external document retrieval means HTTP GET requests for target resources. The asterisk character '*' means that a <document> element has child element(s): <add>, <replace>, or <remove>, or alternatively only a <body-not-changed> element. The hyphen character '-' means that the corresponding content (attribute or element) doesn't exist in a <document> element. The 'xxx' and 'yyy' are values of entity tags (ETag) of an XCAP document.

図1に示す<Document>要素の内容とどのように対応するリソースやメタデータの変更。実際には、外部の文書検索は、ターゲットリソースに対するHTTP GETリクエストを意味します。唯一の<body--変更していない>要素代わりに<置き換える>、<追加>、または<削除>、または：アスタリスク文字は「*」<ドキュメント>要素は、子要素（複数可）を有することを意味します。ハイフン文字「 - 」、対応するコンテンツ（属性または要素）は、<ドキュメント>要素内に存在しないことを意味します。「XXX」と「YYY」は、XCAP文書のエンティティタグ（ETagの）の値です。

   +-----------+----------+-----------+----------+-------------------+
   | previous- | new-     | <add>     | <body-   | locally cached    |
   | etag      | etag     | <replace> | not-     | XCAP resource/    |
   |           |          | <remove>  | changed> | metadata change   |
   +-----------+----------+-----------+----------+-------------------+
   | xxx       | yyy      | *         | -        | resource patched, |
   |           |          |           |          | patch included    |
   +-----------+----------+-----------+----------+-------------------+
   | xxx       | yyy      | -         | -        | resource patched, |
   |           |          |           |          | external document |
   |           |          |           |          | retrieval         |
   +-----------+----------+-----------+----------+-------------------+
   | xxx       | yyy      | -         | *        | only ETag changed |
   +-----------+----------+-----------+----------+-------------------+
   | -         | yyy      | -         | -        | resource created  |
   |           |          |           |          | or exists,        |
   |           |          |           |          | external document |
   |           |          |           |          | retrieval         |
   +-----------+----------+-----------+----------+-------------------+
   | xxx       | -        | -         | -        | resource removed  |
   +-----------+----------+-----------+----------+-------------------+

Figure 1: <document> element content / corresponding resource changes

図1：<Document>要素の内容/対応するリソースの変更

Each <element> element indicates the existing element content of an XCAP document. It has one mandatory attribute, "sel", and optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the <element> element identifies an XML element of an XCAP document. It is a percent-encoded relative URI following XCAP conventions when selecting elements. The XCAP Node Selector MUST always locate a unique node, the "exists" attribute thus shows whether an element exists or not in the XCAP document. When the "exists" attribute is absent from the <element> element, the indicated element still exists in the XCAP document. The located element exists as a child element of the <element> element. In a corner case where the content of this element cannot be presented for some reason (e.g., the payload is too large) although it exists in the XCAP document, the <element> element MUST NOT have any child nodes.

各<要素>要素は、XCAPドキュメントの既存の要素の内容を示します。これは、属性と拡張子は任意の名前空間からの属性を「存在」、1つの必須属性、「SEL」、およびオプションがあります。 <要素>要素の「SEL」属性は、XCAP文書のXML要素を識別します。これは、要素を選択する際XCAP規約を以下のパーセントエンコード相対URIです。 XCAPノードセレクタは、常にユニークなノードを見つける必要があり、「存在」属性は、このように要素がないか、XCAP文書内に存在するかどうかを示します。「存在」属性は、<要素>要素に存在しない場合、指示された要素は依然としてXCAP文書内に存在します。位置要素は、<要素>要素の子要素として存在します。それはXCAP文書内に存在するが、この要素の内容が何らかの理由のために提示することができないコーナーケースに（例えば、ペイロードが大きすぎる）、<要素>要素は、任意の子ノードを有してはなりません。

As the located XML element is typically namespace qualified, all needed namespace declarations MUST exist within the <xml-diff> document. The possible local namespace declarations within the located element exist unmodified as in the source document, similar to XCAP conventions. Other namespace references MUST be resolved from the context of the <element> or its parent elements. The prefixes of qualified names (QNames) [W3C.REC-xml-names-20060816] of XML nodes also remain as they originally exist in the source XCAP document.

あるXML要素は、通常、名前空間で修飾されているように、すべての必要な名前空間宣言は、<XML-diffを>ドキュメント内に存在する必要があります。位置要素内の可能なローカル名前空間宣言XCAP規則と同様に、ソースドキュメントのように修飾されていない存在します。他の名前空間の参照は、<要素>またはその親要素のコンテキストから解決しなければなりません。それらは元々ソースXCAP文書に存在するように修飾名（のQName）[W3C.REC-XML-名-20060816] XMLノードのプレフィックスも残ります。

Each <attribute> element indicates the existing attribute content of an XCAP document. It has one mandatory attribute, "sel", and optionally, an "exists" attribute and extension attributes from any namespace. The "sel" attribute of the <attribute> element identifies an XML attribute of an XCAP document. It is a percent-encoded relative URI following XCAP conventions when selecting attributes. The "exists" attribute indicates whether or not an attribute exists in the XCAP document. When the "exists" attribute is absent from the <attribute> element, the indicated attribute still exists in the XCAP document. The child text node of the <attribute> element indicates the value of the located attribute. Note that if the attribute is namespace qualified, the query parameter of the XCAP URI indicates the attached namespace URI and the prefix in the XCAP source document.

各<属性>要素は、XCAPドキュメントの既存の属性の内容を示します。これは、属性と拡張子は任意の名前空間からの属性を「存在」、1つの必須属性、「SEL」、およびオプションがあります。 <属性>要素の「SEL」属性は、XCAP文書のXML属性を識別します。これは、属性を選択する際にXCAP規約を以下のパーセントエンコード相対URIです。「存在」属性は、属性がXCAP文書内に存在するか否かを示しています。属性は、<属性>要素は存在しない、指示された属性が依然としてXCAP文書内に存在する場合に「存在します」。 <属性>要素の子テキストノードがあり、属性の値を示しています。属性は、名前空間修飾されている場合は、XCAP URIのクエリパラメータは、添付の名前空間URIとXCAPソース文書の接頭辞を示していることに注意してください。

Namespaces of the "sel" attribute of the <attribute> and <element> elements MUST also be resolved properly. Section 6.4. of [RFC4825] describes the rules when using namespace prefixes in XCAP Node Selectors. Without a namespace prefix in an element selector, an XCAP Default Document Namespace MUST be applied. The namespace resolving rules of Patch operation elements: <add>, <replace>, and <remove> are described in Section 4.2.1 of [RFC5261].

<属性>の「SEL」属性の名前空間と<要素>要素も適切に解決されなければなりません。 6.4節。 [RFC4825]のXCAPノードセレクタに名前空間接頭辞を使用しているときのルールを説明しています。要素セレクターで名前空間接頭辞がなければ、XCAP既定のドキュメントの名前空間を適用しなければなりません。パッチの操作要素のルールを解決する名前空間は、<置き換える>、<追加>、および<削除> [RFC5261]のセクション4.2.1で説明されています。

4. XML Schema

4. XMLスキーマ

The XML Schema for the XCAP diff format.

XCAPのdiff形式のXMLスキーマ。

<?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="urn:ietf:params:xml:ns:xcap-diff" targetNamespace="urn:ietf:params:xml:ns:xcap-diff" elementFormDefault="qualified" attributeFormDefault="unqualified">

<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのxmlns：XSの= "http://www.w3.org/2001/XMLSchema" のxmlns = "壷：IETF：のparams：XML ：NS：XCAP-diffを」のtargetNamespace = "壷：IETF：のparams：XML：NS：XCAP-diffを" のelementFormDefault = " "資格" attributeFormDefault =" 修飾されていません>

<xs:include schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>

< - パッチ-OPSを含める - > <！XS：含めるのschemaLocation = "壷：IETF：のparams：XML：スキーマ：パッチ-OPS" />

<xs:element name="xcap-diff"> <xs:complexType> <xs:sequence minOccurs="0"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice>

<！ - ドキュメントルート - > <XS：要素名= "XCAP-diffを"> <XS：complexTypeの> <XS：シーケンスのminOccurs = "0"> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限" > <XS：選択>

<xs:element name="document" type="documentType"/> <xs:element name="element" type="elementType"/> <xs:element name="attribute" type="attributeType"/> </xs:choice> </xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="xcap-root" type="xs:anyURI" use="required"/> <xs:anyAttribute processContents="lax"/> </xs:complexType> </xs:element>

<XS：要素名= "文書" タイプ= "のDocumentType" /> <XS：要素名= "要素" タイプ= "をelementType" /> <XS：要素名= "属性" タイプ= "とattributeType" /> </ XS：選択> </ XS：シーケンス> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "XCAPルート" タイプ= "XS：anyURIの" 使用= "必須" /> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの> </ XS：要素>

<xs:complexType name="documentType"> <xs:choice minOccurs="0"> <xs:element name="body-not-changed" type="emptyType"/> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:choice> <xs:element name="add"> <xs:complexType mixed="true"> <xs:complexContent> <xs:extension base="add"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="remove"> <xs:complexType> <xs:complexContent> <xs:extension base="remove"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:element name="replace"> <xs:complexType mixed="true"> <xs:complexContent> <xs:extension base="replace"> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:complexContent> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax"/> </xs:choice>

<XS：complexTypeの名前= "のDocumentType"> < - - XCAPドキュメントタイプ！> <XS：選択肢のminOccurs = "0"> <XS：要素名= "ボディ・変更されていない" タイプ= "emptyType" /> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素名= "追加"> <XS：complexTypeの混合= "真の"> <XS：complexContentを> <XS：増設ベースanyAttributeはのprocessContents = "緩い" /> </ XS：：拡張> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS：要素名は= "削除"> => <XS "追加" <XS：complexTypeの> <XS：complexContentを> <XS：拡張ベースは= "削除"> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> < / XS：要素> <XS：要素名= "置き換え"> <XS：complexTypeの混合= "真の"> <XS：complexContentを> <XS：増設ベース= "置き換え"> <XS：anyAttributeはのprocessContents = "LAX" / > </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##他" のprocessContents = "緩い" /> </ XS：選択>

</xs:sequence> </xs:choice> <xs:attribute name="sel" type="xs:anyURI" use="required"/> <xs:attribute name="new-etag" type="xs:string"/> <xs:attribute name="previous-etag" type="xs:string"/> <xs:anyAttribute processContents="lax"/> </xs:complexType>

</ XS：シーケンス> </ XS：選択> <XS：属性名= "SEL" タイプ= "XS：anyURIの" 使用は= "必要" /> <XS：属性名= "新しい-ETagを" タイプ= "XS ：文字列 "/> <XS：属性名=" 前回-のETag」タイプ= "XS：文字列" /> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：complexTypeの>

<xs:complexType name="elementType"> <xs:complexContent mixed="true"> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any processContents="lax" namespace="##any" minOccurs="0" maxOccurs="1"/> </xs:sequence> <xs:attribute name="sel" type="xs:string" use="required"/> <xs:attribute name="exists" type="xs:boolean"/> <xs:anyAttribute processContents="lax"/> </xs:restriction> </xs:complexContent> </xs:complexType>

<！ - XCAPの要素型 - > <XS：complexTypeの名= "をelementType"> <XS：complexContentを混在= "真の"> <XS：制限ベース= "XS：anyTypeの"> <XS：シーケンス> <XS：どんなのprocessContents = "緩い" 名前空間= "##あらゆる" のminOccurs = "0" のmaxOccurs = "1" /> </ XS：シーケンス> <XS：属性名= "SEL" タイプ= "XS：文字列" 使用=」必要な "/> <XS：属性名=" 存在」タイプ= "XS：ブール値" /> <XS：anyAttributeはのprocessContents = "緩い" /> </ XS：制限> </ XS：complexContentを> </ XS：complexTypeの>

<xs:complexType name="attributeType"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="sel" type="xs:string" use="required"/> <xs:attribute name="exists" type="xs:boolean"/> <xs:anyAttribute processContents="lax"/> </xs:extension> </xs:simpleContent> </xs:complexType>

<！ - XCAP属性タイプ - > <XS：complexTypeの名= "とattributeType"> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性名= "SEL" タイプ= "XS ： "：属性名= /> <XS "" タイプ= "XS存在：ブール"/> <XS：anyAttributeはのprocessContents = "緩い"/> </ XS：拡張> </ XS：simpleContentに文字列」使用=" 必要> </ XS：complexTypeの>

<xs:complexType name="emptyType"/> </xs:schema>

<！ - 空のタイプ - > <XS：complexTypeの名= "emptyType" /> </ XS：スキーマ>

5. Example Document

5.例ドキュメント

The following is an example of a document compliant to the schema.

以下は、スキーマに準拠した文書の一例です。

<?xml version="1.0" encoding="UTF-8"?> <d:xcap-diff xmlns:d="urn:ietf:params:xml:ns:xcap-diff" xmlns="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 = "壷：IETF：のparams：XML：NS：XCAP-diffを" のxmlns = "壷：IETF：のparamsを：XML：NS：RLS-サービス」XCAPルート= "http://xcap.example.com/root/">

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

<D：文書の新しい-のETag = "7ahggs" SEL = "リソース・リスト/ユーザー/ SIP：joe@example.com/coworkers" 前回-のETag = "8a77f8d" />

    <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"
       ><service uri="sip:marketing@example.com">
         <list name="marketing">
           <rl:entry uri="sip:joe@example.com"/>
           <rl:entry uri="sip:sudhir@example.com"/>
         </list>
         <packages>
           <package>presence</package>
         </packages>
       </service></d:element>

    <d:attribute
    sel="rls-services/users/sip:joe@example.com/index/~~/*/service/@uri"
         >sip:marketing@example.com</d:attribute>

</d:xcap-diff>

</ D：XCAP-diffを>

This indicates that the document with the URI "http:// xcap.example.com/root/resource-lists/users/sip:joe@example.com/ coworkers" has changed. Its previous entity tag is "8a77f8d" and its new one is "7ahggs", but actual changes are not shown. The <service> element exists in the rls-services "index" document and its full content is shown. Note that the <service> element is attached with a default namespace declaration within the original document. Similarly, "uri" attribute content is shown from the same "index" document as an illustrative example.

変更された：これは、URI「// xcap.example.com/root/resource-lists/users/sip:joe@example.com/同僚のhttp」との文書があることを示しています。その前のエンティティタグは「8a77f8d」であり、その新しいものが「7ahggs」ですが、実際の変更は表示されません。 <サービス>要素は、RLS-サービス「インデックス」のドキュメントに存在し、その完全な内容が示されています。 <サービス>要素は、元の文書内のデフォルトの名前空間宣言が取り付けられていることに注意してください。同様に、「URI」属性のコンテンツは、例示的な実施例と同様の「インデックス」文書から示されています。

6. Basic Requirements for a System Exchanging XCAP Diff Documents

XCAP Diffのドキュメントを交換するシステムのため6.基本要件

Documents at an XCAP server are identified by URIs, and updated by XCAP clients with HTTP (PUT and DELETE) methods. The XCAP server assigns a new entity tag value for each document version. An entity tag value is defined by Section 3.11 of RFC 2616 [RFC2616]: "An

XCAPサーバーでのドキュメントは、メソッドを（PUTとDELETE）のURIによって識別され、HTTPでXCAPクライアントによって更新されます。 XCAPサーバーは、各ドキュメントのバージョンのために新しいエンティティタグ値を割り当てます。エンティティタグ値は、RFC 2616 [RFC2616]のセクション3.11で定義される「アン

entity tag MUST be unique across all versions of all entities associated with a particular resource". These entity tags are used to protect requests from making overriding changes when multiple XCAP clients update the same XCAP document. An entity tag value can be interpreted as a unique identifier to a specific version of an XCAP document in its change history.

エンティティタグは、特定のリソース」に関連するすべてのエンティティのすべてのバージョンで一意である必要があります。これらのエンティティタグは、複数のXCAPクライアントが同じXCAPドキュメントを更新すると、オーバーライド変更を行うからの要求を保護するために使用されている。エンティティタグの値がユニークと解釈することができますその変化の歴史の中でXCAPドキュメントの特定のバージョンに識別子。

The entity tag values of XCAP resources also enable a reliable way to update the locally cached XCAP resource copies in an XCAP diff implementation. When a diff client applies XCAP diff document changes, it MUST apply a resource state change only if entity tag values match with octet-by-octet equivalence according to the table defined in Figure 1. If a diff client notices inconsistencies and/or errors when it applies reported resource changes, it SHOULD tear down the session.

XCAPリソースのエンティティタグ値もXCAP diffの実装でローカルにキャッシュされたXCAPリソースのコピーを更新するための信頼性の高い方法を可能にします。差分クライアントは、XCAP差分文書の変更を適用する場合には、差分クライアントが不整合及び/又はエラーときに気付いた場合、エンティティタグの値は、図1で定義されたテーブルに従ってオクテット・バイ・オクテット等価と一致する場合にのみ、リソースの状態の変更を適用しなければなりませんそれは、セッションを取り壊すべきで、報告されたリソースの変更を適用します。

State changes of an XCAP document MUST be delivered reliably from a diff notifier to a diff client, and a diff client MUST be able to apply all changes of an XCAP document in the same chronological order that occurred at an XCAP server. When using an unreliable transport with retransmissions, the application protocol used with the XCAP diff MUST ensure that duplicates are dropped. If an XCAP diff delivery is lost, the diff session MUST be torn down. Note that a diff notifier can easily notice a lost notification when a diff client must respond to each XCAP diff delivery.

XCAPドキュメントの状態の変化は、diffのクライアントへのdiff通知から確実に送達されなければならない、とのdiffクライアントは、XCAPサーバーで発生した同じ年代順にXCAP文書のすべての変更を適用することができなければなりません。再送を伴う信頼性の低いトランスポートを使用する場合は、XCAPデフと共に使用されるアプリケーションプロトコルは、重複が削除されていることを確認しなければなりません。 XCAP diffの配信が失われた場合、差分セッションが切断されなければなりません。デフクライアントは各XCAP diffの配信に応答しなければならない時に差分通知が簡単に失われた通知を気づくことができることに注意してください。

A diff notifier doesn't necessarily report all of these XCAP document updates with ETags; it MAY skip over some intermediate version of a document, for example, with rapidly changing resources. However, it MUST always report changes consistently to a diff client so that it can properly update the latest state (content and ETag) of its locally cached resources.

差分通知は、必ずしもてETagを持つこれらのXCAPドキュメントの更新のすべてを報告しません。それは急速に変化するリソースと、例えば、ドキュメントのいくつかの中間バージョンをスキップするかもしれません。それは適切にローカルにキャッシュされたリソースの最新の状態（コンテンツとのETag）を更新できるようにしかし、それは常に差分クライアントに一貫して変更を報告しなければなりません。

As an example, an XCAP document is updated by different 'a', 'b', and 'c' versions identified with the same corresponding ETag values in a relatively short period. The first reported notification contains the 'a' "new-tag" information (no "previous-etag" attribute), and the diff notifier decides to skip the update notification identified by the 'b' ETag value. The second notification to a diff client MUST then contain the 'a' "previous-etag" and 'c' "new-etag" values with optional corresponding content changes (from version 'a' to 'c').

一例として、XCAP文書は異なる「」、「B」、比較的短い期間で同じ対応のETag値で識別さ「C」バージョンによって更新されます。最初の通知が「」「新しいタグ」情報（なし「前-のETag」属性）が含まれて報告され、差分通知は、「B」のETag値によって識別される更新通知をスキップすることを決定します。差分クライアントへ第2の通知は、次に（バージョンから「」の「C」）任意の対応するコンテンツ変更を '「前-のETag」と「C」、「新のETag」の値を含まなければなりません。

Since XCAP documents are typically confidential, diff notifiers MUST obey the XCAP authorization rules. In practice, this means following the read privilege rules of XCAP resources when notifying the authenticated diff clients of changes. Transport SHOULD be secured by encryption.

XCAP文書は一般的に機密なので、差分ノーティファイアは、XCAP認可ルールに従わなければなりません。実際には、この変更の認証された差分クライアントに通知する際にXCAPリソースの読み込み権限ルールを以下の意味します。交通は、暗号化によって保護する必要があります。

Note: This format specification doesn't define how to select the resources whose differences a diff notifier should report. It also doesn't define whether actual content changes should be reported. Typically, however, a diff client starts a session by sending a resource listing request. Then it compares the remote resource listings with locally cached ones, and probably downloads those resources that aren't locally cached or whose entity tags differ. When a diff client receives an XCAP diff with a "previous-etag" value that matches its current cached copy of a document, it can apply the diffs to the cached copy. As it takes some time to download reference documents, and diff notifications appear after actual resource state changes, several round trips may be needed before a full synchronization is achieved, especially with rapidly changing resources.

注：このフォーマットの仕様は、その違いのdiff通知が報告すべきリソースを選択する方法を定義していません。また、実際のコンテンツの変更を報告する必要があるかどうかを定義していません。しかし、典型的には、diffのクライアントは、リソースリスト要求を送信することにより、セッションを開始します。そして、それがローカルにキャッシュされたもので、リモートリソースのリストを比較し、おそらくローカルにキャッシュされたか、その実体タグが異なっていないこれらのリソースをダウンロードします。デフクライアントは、文書の現在のキャッシュされたコピーに一致する「前-のETag」値でXCAPの差分を受信すると、キャッシュされたコピーに差分を適用することができます。それは参照文書をダウンロードするには、いくつかの時間がかかり、差分通知が実際のリソースの状態が変化した後に表示される完全な同期が達成される前に、いくつかのラウンドトリップは、特に急速に変化するリソースを、必要になる場合があります。

7. Security Considerations

7.セキュリティの考慮事項

XCAP diff documents can include changes from one version of a document to another version. As a consequence, if the document itself is sensitive and requires confidentiality, integrity, or authentication, then the same applies to the XCAP diff format. Therefore, protocols that transport XCAP diff documents must provide sufficient security capabilities for transporting the document itself. Confidential XCAP documents are typically transported using TLS-encrypted (Transport Layer Security) [RFC5246] communication; see RFC 4825 [RFC4825] for further security details.

XCAP diffのドキュメントは別のバージョンへの文書の1版からの変更を含めることができます。文書自体は敏感であり、機密性、完全性、または認証が必要な場合は結果として、その後、同じことがXCAPのdiff形式に適用されます。したがって、プロトコルは、トランスポートXCAP diffの文書は、文書自体を輸送するための十分なセキュリティ機能を提供しなければならないこと。機密XCAP文書は通常、TLSで暗号化（トランスポート層セキュリティ）[RFC5246]の通信を使用して輸送されます。さらに、セキュリティの詳細については、RFC 4825 [RFC4825]を参照してください。

When this format is used to report content changes of XCAP documents, all security considerations of RFC 5261 [RFC5261] apply. Very frequent updates of XCAP documents and/or many diff clients per subscribed resource impose a Denial-of-Service attack possibility to the servers processing XCAP diff documents. An efficient patch processing and throttling can, however, decrease the required overall processings and transactions.

このフォーマットは、XCAP文書の内容の変更を報告するために使用された場合は、RFC 5261のすべてのセキュリティ上の考慮事項は、[RFC5261]適用されます。 XCAP文書および/または加入リソースごとに多くの差分のクライアントの非常に頻繁な更新は、サーバ処理XCAP diffのドキュメントへのサービス拒否攻撃の可能性を課します。効率的なパッチ処理および調整は、しかし、必要な全体的な処理とトランザクションを減少させることができます。

The SIP event package framework specified in RFC 3265 [RFC3265] is the most typical use-case for this format. Then, an end-to-end SIP encryption mechanism, such as Secure/Multipurpose Internet Mail Extensions (S/MIME) described in Section 26.2.4 of RFC 3261 [RFC3261], SHOULD be used. If that is not available, it is RECOMMENDED that TLS [RFC5246] be used between elements to provide hop-by-hop authentication and encryption mechanisms as described in Section 26.2.2 ("SIPS URI Scheme") and Section 26.3.2.2 ("Interdomain Requests") of RFC 3261 [RFC3261]. Event packages MAY also have other specific threats that MUST be considered on an application-by-application basis.

RFC 3265 [RFC3265]で指定されたSIPイベントパッケージ・フレームワークは、この形式のための最も一般的なユースケースです。そして、このようなRFC 3261のセクション26.2.4に記載のセキュア/多目的インターネットメール拡張（S / MIME）[RFC3261]などのエンドツーエンドのSIP暗号化メカニズム、使用すべきです。それが利用できない場合、それは、セクション26.2.2に記載されているようにTLS [RFC5246]はホップバイホップ認証及び暗号化のメカニズムを提供する要素間使用することを推奨され、セクション26.3.2.2（」（「URIスキームSIPS」） RFC 3261 [RFC3261]のドメイン間の要求」）。イベントパッケージはまた、アプリケーションごとに考えなければなりません、他の特定の脅威を持っているかもしれません。

8. IANA Considerations

8. IANAの考慮事項

There are several IANA considerations associated with this specification.

この仕様に関連したいくつかのIANAの考慮事項があります。

8.1. application/xcap-diff+xml MIME Type

8.1. アプリケーション/ XCAP-diffの+ xmlのMIMEタイプ

MIME media type name: application

MIMEメディアタイプ名：application

MIME subtype name: xcap-diff+xml

MIMEサブタイプ名：XCAP-diffの+ xmlの

Mandatory parameters: none

必須パラメータ：なし

Optional parameters: Same as the charset parameter application/xml as specified in RFC 3023 [RFC3023].

オプションのパラメータ：RFC 3023で指定され、application / xmlのcharsetパラメータと同じです[RFC3023]。

Encoding considerations: Same as the encoding considerations of application/xml as specified in RFC 3023 [RFC3023].

符号化の考慮事項：RFC 3023で指定されたアプリケーション/ XMLの符号化の考慮事項と同じ[RFC3023]。

Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 7 of RFC 5874.

セキュリティの考慮事項：RFC 3023のセクション10 [RFC3023]およびRFC 5874のセクション7を参照してください。

Interoperability considerations: none.

相互運用性に関する注意事項：なし。

Published specification: This document.

公開された仕様：このドキュメント。

Applications that use this media type: This document type has been used to support manipulation of resource lists [RFC4826] using XCAP.

このドキュメントタイプは、XCAPを使用してリソースリスト[RFC4826]の操作をサポートするために使用されています：このメディアタイプを使用するアプリケーション。

Additional Information:

追加情報：

Magic Number: None

マジックナンバー：なし

File Extension: .xdf

ファイル拡張子：.xdf

Macintosh file type code: "TEXT"

Macintoshのファイルタイプコード：「TEXT」

Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net

詳しくは、個人やメールアドレス：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net

Intended usage: COMMON

意図している用法：COMMON

Author/Change controller: The IETF.

著者/変更コントローラ：IETF。

8.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:xcap-diff

8.2. 骨壷のためのURNサブ名前空間の登録：IETF：のparams：XML：NS：XCAP-diffを

This section registers a new XML namespace, as per the guidelines in [RFC3688].

このセクションでは、[RFC3688]のガイドラインに従って、新しいXML名前空間を登録します。

URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-diff.

URI：IETF：：のparams：XML：NS：XCAP-diffをこの名前空間のURIはURNです。

Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。

XML:

XML：

BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>XCAP Diff Namespace</title> </head> <body> <h1>Namespace for XCAP Diff</h1> <h2>urn:ietf:params:xml:ns:xcap-diff</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc5874.txt">RFC5874</a>.</p> </body> </html> END

BEGINの<？xml version = "1.0"？> <！DOCTYPE htmlのをPUBLIC！ " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/xhtml- basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =イソ8859-1" /> <タイトル> XCAP Diffの名前空間</ TITLE> </ HEAD> <BODY> <H1> XCAP Diffのための名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：XCAP-diffを</ H2> <P> <a href="http://www.rfc-editor.org/rfc/rfc5874.txt"> RFC5874 </a>を参照してください。</ P> </ body> </ html>この終わり

8.3. Schema Registration

8.3. Schemaの登録

This section registers a new XML schema per the procedures in [RFC3688].

このセクションでは、[RFC3688]の手順ごとに新しいXMLスキーマを登録します。

URI: urn:ietf:params:xml:schema:xcap-diff

URI：URN：IETF：のparams：XML：スキーマ：XCAP-diffを

Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).

登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。

The XML for this schema can be found as the sole content of Section 4.

このスキーマのためのXMLは、第4節の唯一の内容として求めることができます。

9. Acknowledgments

9.謝辞

The authors would like to thank Pavel Dostal, Jeroen van Bemmel, Martin Hynar, Anders Lindgren, Mary Barnes, Ben Campbell, Francis Dupont, David Harrington, Alexey Melnikov, Dan Romascanu, and Robert Sparks for their valuable comments.

作者は彼らの貴重なコメントをパベル・ドスタル、イェルーンバンBemmel、マーティンHynar、アンダース・リンドグレン、メアリー・バーンズ、ベン・キャンベル、フランシスデュポン、デヴィッド・ハリントン、アレクセイ・メルニコフ、ダンRomascanu、およびロバート・スパークスに感謝したいと思います。

10. References

10.参考文献

10.1. Normative References

10.1. 引用規格

[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版）"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XMLベース20060816、2006年8月、<のhttp：// www.w3.org/TR/2006/REC-xml-20060816>。

[W3C.REC-xml-c14n-20010315] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/ REC-xml-c14n-20010315>.

[W3C.REC-XML-C14N-20010315]ボイヤー、J.、 "標準的なXMLバージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-XML-C14N-20010315、2001年3月、<http://www.w3.org/ TR / 2001 / REC-XML-C14N-20010315>。

[W3C.REC-xml-names-20060816] Hollander, D., Layman, A., and T. Bray, "Namespaces in XML 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-names-20060816, August 2006, <http://www.w3.org/TR/ 2006/REC-xml-names-20060816>.

[W3C.REC-XML-名-20060816]オランダ、D.、素人、A.、およびT.ブレイ、 "XML 1.0での名前空間（第二版）"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XML-名-20060816、 2006年8月、<http://www.w3.org/TR/ 2006 / REC-XML-名-20060816>。

[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.

[RFC2141]堀、R.、 "URN構文"、RFC 2141、1997年5月。

[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月。

[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.

[RFC3023]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。

[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.

[RFC2648]堀、R.、 "IETFドキュメントのためのURN名前空間"、RFC 2648、1999年8月。

[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[RFC3688] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年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月。

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

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

[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月。

[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月。

10.2. Informative References

10.2. 参考文献

[RFC5875] Urpalainen, J. and D. Willis, "An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Diff Event Package", RFC 5875, May 2010.

[RFC5875] Urpalainen、J.とD.ウィリス、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）差分イベントパッケージ"、RFC 5875、2010年5月。

[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.

[RFC2778]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。

[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月。

[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.

[RFC4662]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。

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

[RFC4826]ローゼンバーグ、J.、 "リソース・リストを表すための拡張マークアップ言語（XML）フォーマット"、RFC 4826、2007年5月。

[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006.

[RFC4483]バーガー、E.、 "セッション開始プロトコル（SIP）におけるコンテンツの間接化の仕組みメッセージ"、RFC 4483、2006年5月。

Appendix A. Informative Examples

付録A.参考例

These informative examples illustrate basic features of XCAP diff format.

これらの有益な例では、XCAPのdiff形式の基本的な特徴を説明します。

The following documents exist at 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 id="bar"> <note>This is a sample document</note> </doc>

<？xml version = "1.0" エンコード= "UTF-8"？> <ドキュメントID = "バー"> <ノート>これはサンプル文書</ノート> </ 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>

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

A.1. Indicating Existing, Changed, or Removed Documents

A.1。変更、または削除、既存の文書を示します

Firstly, an XCAP diff document can indicate what documents exist in a collection. An XCAP diff document may then be:

まず、XCAP diffの文書は、文書がコレクション内に存在するものを示すことができます。 XCAP diffのドキュメントは、ことがあります

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

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

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

</xcap-diff>

</ XCAP-diffを>

This listing indicates current ETags of existing documents and their relative URIs.

このリストは、既存の文書とその相対URIの現在てETagを示しています。

Let's say that Joe adds a new document to his collection:

ジョーは、彼のコレクションに新しいドキュメントを追加するとしましょう：

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>

The requests result header has an HTTP ETag "terteer" for this new document.

リクエストヘッダは、この新しい文書のためのHTTPのETag「terteer」を持っている結果。

Then an XCAP diff document may then indicate only the creation of this single new document:

そして、XCAP diffのドキュメントは、この単一の新しい文書の作成のみを示していることがあります。

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

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

</xcap-diff>

</ XCAP-diffを>

A "new-etag" without a "previous-etag" attribute indicates a creation of a new document.

「前回-ETagを」属性のない「新しい-のETagは、」新規文書の作成を示します。

Then Joe decides to modify an existing resource:

その後、ジョーは、既存のリソースを変更することを決定しました。

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 a modified document</note> </doc>

<？xml version = "1.0" エンコード= "UTF-8"？> <DOC> <注意>これは、変更された文書</注意> </ DOC>であります

The reported new HTTP ETag is "huwiias".

報告された新しいHTTPのETagは「huwiias」です。

Then an XCAP diff document may be:

そして、XCAP diffのドキュメントは次のようになります。

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

<文書前の-のETag = "terteer" 新-のETag = "huwiias" SEL = "テスト/ユーザー/ SIP：joe@example.com/another_document" />

</xcap-diff>

</ XCAP-diffを>

Both "previous-etag" and "new-etag" attributes signal that a modification has happened to a resource, but actual changes are not shown.

「前回-のETag」と「新-のETag」属性の両方が変更をリソースに起こっているが、実際の変更が示されていないことを知らせます。

Let's say that Joe then removes a document from his collection:

のは、ジョーはその後、彼のコレクションから文書を削除するとしましょう：

DELETE /tests/users/sip:joe@example.com/another_document HTTP/1.1 Host: xcap.example.com

xcap.example.com：/tests/users/sip:joe@example.com/another_document HTTP / 1.1ホストを削除

This HTTP DELETE request results in the unlinking of the resource, and the XCAP diff may be:

このHTTPは、リソースのリンク解除のリクエスト結果を削除し、XCAPの差分であってもよいです。

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

<文書前の-のETag = "huwiias" SEL = "テスト/ユーザー/ SIP：joe@example.com/another_document" />

</xcap-diff>

</ XCAP-diffを>

Thus, a "previous-etag" without a "new-etag" attribute indicates the removal of a resource.

このように、「新-ETagを」属性のない「前-のETagは、」リソースの除去を示しています。

A.2. Indicating Actual Changes of Documents

A.2。文書の実際の変更を指示します

Secondly, XCAP diff documents are capable of showing actual changes to documents with [RFC5261] patching semantics.

第二に、XCAPの差分文書は[RFC5261]パッチのセマンティクスを有するドキュメントに対する実際の変化を示すことが可能です。

Now Joe's XCAP client utilizes the XCAP patching capability to add a new element to a document:

今ジョーのXCAPクライアントは、ドキュメントに新しい要素を追加するために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 XCAP client receives the new HTTP ETag "fgherhryt3" of the updated "index" document.

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

Immediately thereafter, Joe's XCAP client issues another HTTP request (this request could even be pipelined):

その直後に、ジョーのXCAPクライアントは別の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 then Joe's XCAP client issues yet another HTTP request:

そして、さらに別のHTTPリクエストジョーのXCAPクライアントの問題：

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

XCAP diff format document may then indicate these XCAP component changes by:

XCAP diff形式の文書は、次にによってこれらXCAP成分の変化を示すことができます。

<?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="*" ><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：文書前の-のETag = "7ahggs3" SEL = "テスト/ユーザー/ SIP：joe@example.com/index" 新-のETag = "63hjjsll"> <D：追加SEL = "*"> <foo>の本新しい要素は</ foo>の<バー>これはバーの要素</バー> <foobarに>これはfoobarの要素である</ foobarに> </ D：追加> </ D：ドキュメント>

</d:xcap-diff>

</ D：XCAP-diffを>

Note how several XCAP component modifications were aggregated together, and full history information got lost.

一緒に凝集し、そして完全な履歴情報が失われてしまったか、いくつかのXCAPコンポーネントの変更に注意してください。

Alternatively, the content could have been:

また、コンテンツがされている可能性が：

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

</d:xcap-diff>

</ D：XCAP-diffを>

This shows the full ETag change history of a document, and ETags change chronologically in the reported XML document order.

これは、文書の完全なETagの変更履歴を示し、そしててETagを報告XMLドキュメントの順序に沿って時系列変化します。

A.3. Indicating XCAP Component Contents

A.3。 XCAPコンポーネントの内容を示します

Lastly, the XCAP diff format can also indicate the existing full contents of XCAP components, i.e., elements or attributes:

最後に、XCAPの差分形式はまた、XCAP成分、すなわち、要素や属性の既存の完全な内容を示すことができます。

<?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:attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id" >bar</d:attribute>

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

    <d:element sel="tests/users/sip:joe@example.com/index/~~/*/foo"
       ><foo>this is a new element</foo></d:element>

</d:xcap-diff>

</ D：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 XCAP client removes the "id" attribute:

そして、ジョーのXCAPクライアントは「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 XCAP diff document may then be:

そして、XCAP diffのドキュメントは、ことがあります

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

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

</xcap-diff>

</ XCAP-diffを>

This indicates that the subscribed attribute was removed from the document. The element content in this use-case may be discarded from the XCAP diff document, for example, when the size of XCAP diff document would be impractically large to the transport layer.

これは、加入属性は、文書から削除されたことを示しています。このユースケースにおける元素の含有量は、XCAPの差分文書のサイズがトランスポート層に非現実的に大きいであろう場合、例えば、XCAPデフ文書から廃棄することができます。

Authors' Addresses

著者のアドレス

Jonathan Rosenberg jdrosen.net Monmouth, NJ US

ジョナサン・ローゼンバーグjdrosen.netモンマス、NJ US

EMail: jdrosen@jdrosen.net URI: http://www.jdrosen.net

電子メール：jdrosen@jdrosen.net URI：http://www.jdrosen.net

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