[要約] RFC 5874は、XML Configuration Access Protocol（XCAP）リソースの変更を示すための拡張可能なXMLドキュメント形式についての規格です。このRFCの目的は、XCAPリソースの変更を効果的に伝えるための標準化を提供することです。
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
XML構成アクセスプロトコル（XCAP）リソースの変更を示すための拡張可能なマークアップ言語（XML）ドキュメント形式
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）イベントパッケージなど、多くの手段を使用して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/rfc5874.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5874で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. 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
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クライアントに報告します。このアプリケーションでは、リソースリストサーバー（RLS）と呼ばれるサーバーが、プレゼンテーションのリスト[RFC2778]にアクセスする必要があります。このリストは、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.
この問題に対処するために、クライアントはセッション開始プロトコル（SIP）[RFC3261]イベントパッケージ[RFC3265]を使用して、XCAPドキュメントのイベント[RFC5875]を変更するように登録できます。この通知は、変更された特定のリソースとその変更方法を示す必要があります。このような変更通知の形式の1つのソリューションは、コンテンツ間接オブジェクト[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ドキュメント形式です。この形式は、どのドキュメントが変更されたか、以前の新しいエンティティと新しいエンティティがタグを付けたかを報告します。XMLパッチ形式[RFC5261]を使用して、ドキュメントのバージョン間の違いを報告できます。これは、変更後のバージョンにローカルにキャッシュされたXCAPドキュメントをバージョンから変換する方法を示しています。その目的は、必要な全体的な帯域幅と個別の送信の数を減らすことです。また、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と同様に、XMLドキュメントのコメント[W3C.REC-XML-C14N-20010315]を備えた標準形式は、この形式を使用してローカルにキャッシュされたXCAPドキュメントをパッチするために論理的等価性を決定します。
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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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）diff」という用語を前に使用せずに使用される場合、xcap diffドキュメントが変更を報告している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.
DIFFドキュメント：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通知者が含まれています。
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.
DIFF Notifier：これは、XCAPドキュメントのセットとその変更の知識に基づいてXCAP DIFFドキュメントを生成するサーバーのエンティティであり、セッション内で生成された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.
DIFFクライアント：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).
ローカルにキャッシュされたリソース：XCAPサーバーからDIFFクライアントにHTTPによって通常ダウンロードされたリソース。XCAP DIFFドキュメント情報に基づいて、DIFFクライアントによってローカルにパッチされた可能性があります。XCAPサーバーでの変更履歴の単一バージョンに相当します。XCAPドキュメントのバージョン履歴は、HTTPエンティティタグ（ETAGS）で示されています。
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値を割り当てます。
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は、[RFC2648]で定義され、[RFC3688]によって拡張された名前空間識別子「IETF」を使用して、URN [RFC2141]です。このurnは次のとおりです。
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-Root」があります。この属性の値は、変更が行われたドキュメントのXCAPルートURIです。単一のXCAP DIFFドキュメントは、同じXCAPルート内のドキュメントの変更のみを表すことができます。<xcap-diff>要素のコンテンツは、<document>、<要素>、および<属性>要素のシーケンスであり、その後に拡張性を目的として他の名前空間からの任意の数の要素が続きます。XMLスキーマ（セクション4を参照）で拡張要素または属性が許可されている場合は、そのような未知のコンテンツはDIFFクライアントによって無視する必要があります。
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ルート内の特定のドキュメントの変更を指定します。いくつかの<document>要素が同じ特定のドキュメントを特定する場合、つまり、完全なエンティティタグ（ETAG）変更履歴が示されている場合、対応するパッチを指定されたXCAP DIFFドキュメント順序で適用できる必要があります。
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).
<document>要素には、1つの必須属性、「SEL」、および2つのオプションの属性、「New-ETAG」と「前ETAG」があります。<document>要素の「SEL」属性は、変更が示されているXCAPルート内の特定のドキュメントを識別します。そのコンテンツは相対パス参照でなければならず、ベースURIはXCAPルートURIに等しくなります。「new-etag」属性は、変更後にドキュメントが存在すると仮定して、ドキュメントのエンティティタグ（ETAG）を提供します。「前のETAG」属性は、変更前にドキュメントインスタンスの識別子を提供します。報告されている変更がドキュメントの削除である場合、「前のETAG」のみを含める必要があり、「new-etag」属性を存在させてはなりません。「new-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」と「New-ETAG」は、サーバーに順次割り当てられたETAGを割り当てる必要はありません。XCAP DIFFドキュメントは、一連のXCAP操作で発生した変更を示すことができます。唯一の要件は、一連のイベントが連続して実行されると、ETAGがETAGが「New-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が割り当てられているが、そのコンテンツは変更されておらず、<ボディノットチェンジ>要素で示されていることを意味します。パッチの命令は、<add>、<plateg>、および<削除>要素によって説明されています。これらの要素は、[RFC5261]で定義されたタイプを対応し、交換し、削除し、局所的にキャッシュされたドキュメントを変換するために適用できるパッチ操作のセットを定義します。この変換の影響については、[RFC5261]を参照してください。<document>要素には、拡張性を目的として、他の名前空間からの要素を含めることもできます。<add>、<plateg>、および<remove>要素により、任意の名前空間から拡張属性が可能になります。
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がターゲットリソースのリクエストを取得することを意味します。アスタリスク文字 '*'は、<document>要素が子要素を持っていることを意味します：<add>、<add>、<plateg>、または<remove>、または<body-not-changed>要素のみがあります。ハイフン文字 ' - 'は、対応するコンテンツ（属性または要素）が<document>要素に存在しないことを意味します。「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
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コンベンションと同様に、ソースドキュメントのように変更されていません。他の名前空間参照は、<要素>またはその親要素のコンテキストから解決する必要があります。XMLノードの適格名（QNAMES）[W3C.REC-XML-NAMES-20060816]のプレフィックスも、元々XCAPドキュメントに存在するように残ります。
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」、およびオプションでは、任意の名前空間から「存在する」属性と拡張属性があります。<Attribute>要素の「SEL」属性は、XCAPドキュメントのXML属性を識別します。属性を選択する際のXCAP規則に続く、それはパーセントエンコードされた相対URIです。「存在」属性は、XCAPドキュメントに属性が存在するかどうかを示します。「存在する」属性が<属性>要素に存在しない場合、示された属性はXCAPドキュメントに存在します。<attribute>要素の子テキストノードは、配置された属性の値を示します。属性が名前空間の適格である場合、XCAP URIのクエリパラメーターは、XCAPソースドキュメントの添付の名前空間URIとプレフィックスを示していることに注意してください。
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].
<Attribute>および<lement>要素の「SEL」属性の名前空間も適切に解決する必要があります。セクション6.4。of [RFC4825]は、XCAPノードセレクターで名前空間プレフィックスを使用する場合のルールを説明します。要素セレクターに名前空間プレフィックスがないと、XCAPデフォルトのドキュメント名空間を適用する必要があります。パッチ操作要素のルールを解決する名前空間：<add>、<plateg>、および<remove>は、[RFC5261]のセクション4.2.1で説明されています。
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">
<!-- include patch-ops -->
<xs:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- document root -->
<xs:element name="xcap-diff">
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<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>
<!-- xcap document type -->
<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: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>
<!-- xcap element type -->
<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 attribute type -->
<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>
<!-- empty type -->
<xs:complexType name="emptyType"/>
</xs:schema>
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/">
<d:document new-etag="7ahggs"
sel="resource-lists/users/sip:joe@example.com/coworkers"
previous-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>
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 "http：// xcap.example.com/root/resource-lists/users/sip:joe@example.com/ Coworkers"を使用したドキュメントが変更されたことを示しています。以前のエンティティタグは「8A77F8D」で、新しいものは「7AHGGS」ですが、実際の変更は表示されません。<Service>要素は、RLSサービス「インデックス」ドキュメントに存在し、その完全なコンテンツが表示されます。<service>要素には、元のドキュメント内のデフォルトの名前空間宣言が添付されていることに注意してください。同様に、「URI」属性コンテンツは、同じ「インデックス」ドキュメントから例示的な例として表示されます。
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 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サーバーのドキュメントはURISによって識別され、XCAPクライアントによってHTTP（PutおよびDelete）メソッドを使用して更新されます。XCAPサーバーは、各ドキュメントバージョンに新しいエンティティタグ値を割り当てます。エンティティタグ値は、RFC 2616 [RFC2616]のセクション3.11で定義されます。「エンティティタグは、特定のリソースに関連付けられたすべてのエンティティのすべてのバージョンにわたって一意でなければなりません」。これらのエンティティタグは、複数の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リソースコピーを更新する信頼できる方法も可能にします。DIFFクライアントがXCAP DIFFドキュメントの変更を適用した場合、図1で定義された表に従って、エンティティタグ値がOctet-by-OCTETの等価と一致する場合にのみ、リソース状態の変更を適用する必要があります。DIFFクライアントが矛盾および/またはエラーに気付いた場合報告されたリソースの変更を適用し、セッションを取り壊すはずです。
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 DIFFで使用されるアプリケーションプロトコルは、重複がドロップされることを確認する必要があります。XCAP DIFF配信が失われた場合、DIFFセッションを取り壊す必要があります。DIFF通知者は、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.
DIFF通知者は、これらのXCAPドキュメントの更新のすべてをETAGSで必ずしも報告するわけではありません。たとえば、急速に変化するリソースなど、ドキュメントの中間バージョンをスキップする場合があります。ただし、ローカルにキャッシュされたリソースの最新の状態（コンテンツとETAG）を適切に更新できるように、常に変更をDIFFクライアントに一貫して報告する必要があります。
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ドキュメントは、比較的短期間で同じ対応するETAG値で識別された異なる「A」、「B」、および「C」バージョンによって更新されます。最初に報告された通知には、「A」「New-Tag」情報（「前のETAG」属性はありません）が含まれており、DIFF Notifierは「B」ETAG値で識別された更新通知をスキップすることを決定します。DIFFクライアントへの2番目の通知には、オプションの対応するコンテンツ変更（バージョン 'A'から 'c'）を備えた「a」「前etag」および「c」「new-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ドキュメントは通常機密であるため、diff notifiersはXCAP認証ルールに従う必要があります。実際には、これは、認証されたDIFFクライアントに変更を通知する際に、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クライアントは、リソースリストリクエストを送信することによりセッションを開始します。次に、リモートのリソースリストをローカルにキャッシュされたリソースリストと比較し、おそらくローカルでキャッシュされていない、またはエンティティタグが異なるリソースをダウンロードします。DIFFクライアントが、ドキュメントの現在のキャッシュコピーに一致する「前のETAG」値でXCAP DIFFを受信すると、DIFFをキャッシュコピーに適用できます。参照ドキュメントをダウンロードするには時間がかかるため、実際のリソース状態の変更後にdiff通知が表示されるため、特に急速に変化するリソースで完全に同期する前に、いくつかの往復が必要になる場合があります。
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ドキュメントには、あるバージョンのドキュメントから別のバージョンへの変更を含めることができます。結果として、ドキュメント自体が機密性が高く、機密性、整合性、または認証が必要な場合、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ドキュメントの非常に頻繁な更新および/または購読されたリソースごとの多くのDIFFクライアントは、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 [RFC3261]のセクション26.2.4で説明されている安全/多目的インターネットメール拡張（S/MIME）などのエンドツーエンドSIP暗号化メカニズムを使用する必要があります。それが利用できない場合は、TLS [RFC5246]を要素間で使用して、セクション26.2.2（「SIPS URIスキーム」）およびセクション26.3.2.2（ "RFC 3261 [RFC3261]のドメイン間要求 "）。イベントパッケージには、アプリケーションごとに考慮する必要がある他の特定の脅威もあります。
There are several IANA considerations associated with this specification.
この仕様に関連するいくつかのIANAの考慮事項があります。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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 [RFC3023]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as the encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
エンコーディングの考慮事項：RFC 3023 [RFC3023]で指定されているアプリケーション/XMLのエンコーディングに関する考慮事項と同じ。
Security considerations: See Section 10 of RFC 3023 [RFC3023] and Section 7 of RFC 5874.
セキュリティ上の考慮事項：RFC 3023 [RFC3023]のセクション10および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ファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
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：この名前空間のURIはurn：ietf：params：xml：ns：xcap-diffです。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（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
This section registers a new XML schema per the procedures in [RFC3688].
このセクションでは、[RFC3688]の手順ごとに新しいXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:xcap-diff
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 4.
このスキーマのXMLは、セクション4の唯一の内容として見つけることができます。
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.
著者は、Pavel Dostal、Jeroen Van Bemmel、Martin Hynar、Anders Lindgren、Mary Barnes、Ben Campbell、Francis Dupont、David Harrington、Alexey Melnikov、Dan Romascanu、およびRobert Sparksに貴重なコメントに感謝します。
[W3C.REC-xml-20060816] Paoli, J., Bray, T., Yergeau, F., Maler, E., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Fourth Edition)", World Wide Web Consortium FirstEdition REC-xml- 20060816, August 2006, <http:// www.w3.org/TR/2006/REC-xml-20060816>.
[W3C.REC-XML-20060816] Paoli、J.、Bray、T.、Yergeau、F.、Maler、E.、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（XML）1.0（第4版）」、World Wide Web Consortium Firstedition Rec-XML-20060816、2006年8月、<http：// www.w3.org/tr/2006/REC-XML-20060816>。
[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] Boyer、J。、「Canonical XMLバージョン1.0」、World Wide Web Consortiumの推奨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-NAMES-20060816] Hollander、D.、Layman、A。、およびT. Bray、「XML 1.0の名前空間（第2版）」、World Wide Web Consortium Firstedition Rec-XML-Names-20060816、2006年8月、<http://www.w3.org/tr/ 2006/rec-xml-names-20060816>。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141] Moats、R。、「Urn Syntax」、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[RFC2648] Moats、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261] Urpalainen、J。、「XML PATH言語（XPATH）セレクターを使用した拡張可能なマークアップ言語（XML）パッチ操作フレームワーク」、RFC 5261、2008年9月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）プロトコルバージョン1.2」、RFC 5246、2008年8月。
[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. Willis、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）DIFFイベントパッケージ」、RFC 5875、2010年5月。
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662] Roach、A.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張」、RFC 4662、2006年8月。
[RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[RFC4826] Rosenberg、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] Burger、E。、「セッション開始プロトコル（SIP）メッセージにおけるコンテンツ間接のメカニズム」、RFC 4483、2006年5月。
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>
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>
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/">
<document new-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"/>
<document new-etag="terteer"
sel="tests/users/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]
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is another sample document</note>
</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/">
<document new-etag="terteer"
sel="tests/users/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]
<?xml version="1.0" encoding="UTF-8"?>
<doc>
<note>This is a modified document</note>
</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/">
<document previous-etag="terteer" new-etag="huwiias"
sel="tests/users/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」と「New-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
This HTTP DELETE request results in the unlinking of the resource, and the XCAP diff may be:
このHTTP削除要求の結果、リソースが解除され、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/">
<document previous-etag="huwiias"
sel="tests/users/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」は、リソースの削除を示します。
Secondly, XCAP diff documents are capable of showing actual changes to documents with [RFC5261] patching semantics.
第二に、XCAP DIFFドキュメントは、[RFC5261]のセマンティクスをパッチするドキュメントの実際の変更を示すことができます。
Now Joe's XCAP client utilizes the XCAP patching capability to add a new element to a document:
Joeの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]
<foo>this is a new element</foo>
Since the insertion of the element is successful, Joe's XCAP client receives the new HTTP ETag "fgherhryt3" of the updated "index" document.
要素の挿入が成功したため、JoeのXCAPクライアントは、更新された「インデックス」ドキュメントの新しいHTTP ETAG「FGHERHRYT3」を受信します。
Immediately thereafter, Joe's XCAP client issues another HTTP request (this request could even be pipelined):
その後すぐに、Joeの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]
<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:
そして、JoeのXCAPクライアントはさらに別のHTTPリクエストを発行します。
PUT /tests/users/sip:joe@example.com/index/~~/doc/foobar HTTP/1.1
Host: xcap.example.com
....
Content-Type: application/xcap-el+xml
Content-Length: [XXX]
<foobar>this is a foobar element</foobar>
The reported new ETag of "index" is now "63hjjsll".
報告された「インデックス」の新しいETAGは、現在「63HJJSLL」になりました。
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/">
<d:document previous-etag="7ahggs3"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foo>this is a new element</foo><bar>this is a bar element
</bar><foobar>this is a foobar element</foobar></d:add>
</d:document>
</d:xcap-diff>
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/">
<d:document previous-etag="7ahggs"
sel="tests/users/sip:joe@example.com/index"
new-etag="fgherhryt3">
<d:add sel="*"
><foo>this is a new element</foo></d:add></d:document>
<d:document previous-etag="fgherhryt3"
sel="tests/users/sip:joe@example.com/index"
new-etag="dgdgdfgrrr">
<d:add sel="*"
><bar>this is a bar element
</bar></d:add></d:document>
<d:document previous-etag="dgdgdfgrrr"
sel="tests/users/sip:joe@example.com/index"
new-etag="63hjjsll">
<d:add sel="*"
><foobar>this is a foobar element</foobar></d:add></d:document>
</d:xcap-diff> This shows the full ETag change history of a document, and ETags change chronologically in the reported XML document order.
</d：xcap-diff>これは、ドキュメントの完全なETAG変更履歴を示し、ETAGは報告されたXMLドキュメントの注文で年代順に変更されます。
Lastly, the XCAP diff format can also indicate the existing full contents of XCAP components, i.e., elements or attributes:
最後に、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/">
<d:attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
>bar</d:attribute>
<d:element sel="tests/users/sip:joe@example.com/index/~~/*/foo"
><foo>this is a new element</foo></d:element>
</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:
その後、JoeのXCAPクライアントは「ID」属性を削除します。
DELETE /tests/users/sip:joe@example.com/index/~~/doc/@id HTTP/1.1
Host: xcap.example.com
....
Content-Length: 0
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/">
<attribute sel="tests/users/sip:joe@example.com/index/~~/doc/@id"
exists="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 DIFFドキュメントのサイズが輸送層には実用的に大きい場合、XCAP DIFFドキュメントから破棄される場合があります。
Authors' Addresses
著者のアドレス
Jonathan Rosenberg jdrosen.net Monmouth, NJ US
Jonathan Rosenberg Jdrosen.netモンマス、ニュージャージー州
EMail: jdrosen@jdrosen.net
URI: http://www.jdrosen.net
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180 Finland
Jari Urpalainen Nokia Itamerenkatu 11-13 Helsinki 00180フィンランド
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com