Network Working Group J. Rosenberg
Request for Comments: 4825 Cisco
Category: Standards Track May 2007
The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.
この仕様は、拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）を定義します。 XCAPは、クライアントが、読み取り、書き込み、およびサーバー上のXML形式で保存されているアプリケーションの設定データを変更することができます。これらのコンポーネントは、直接HTTPによってアクセスできるように、XCAPマップXML文書のサブツリー要素は、HTTP URIに属性。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Application Usages . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 7
5.2. Default Document Namespace . . . . . . . . . . . . . . . . 8
5.3. Data Validation . . . . . . . . . . . . . . . . . . . . . 9
5.4. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 11
5.6. Resource Interdependencies . . . . . . . . . . . . . . . . 11
5.7. Authorization Policies . . . . . . . . . . . . . . . . . . 12
5.8. Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
5.9. Documenting Application Usages . . . . . . . . . . . . . . 13
5.10. Guidelines for Creating Application Usages . . . . . . . . 13
6. URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Document Selector . . . . . . . . . . . . . . . . . . . . 16
6.3. Node Selector . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Namespace Bindings for the Selector . . . . . . . . . . . 23
7. Client Operations . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Create or Replace a Document . . . . . . . . . . . . . . . 26
7.2. Delete a Document . . . . . . . . . . . . . . . . . . . . 26
7.3. Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
7.4. Create or Replace an Element . . . . . . . . . . . . . . . 26
7.5. Delete an Element . . . . . . . . . . . . . . . . . . . . 29
7.6. Fetch an Element . . . . . . . . . . . . . . . . . . . . . 30
7.7. Create or Replace an Attribute . . . . . . . . . . . . . . 30
7.8. Delete an Attribute . . . . . . . . . . . . . . . . . . . 31
7.9. Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. POST Handling . . . . . . . . . . . . . . . . . . . . . . 35
8.2. PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
8.2.1. Locating the Parent . . . . . . . . . . . . . . . . . 35
8.2.2. Verifying Document Content . . . . . . . . . . . . . . 36
8.2.3. Creation . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.4. Replacement . . . . . . . . . . . . . . . . . . . . . 41
8.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . 42
8.2.6. Conditional Processing . . . . . . . . . . . . . . . . 43
8.2.7. Resource Interdependencies . . . . . . . . . . . . . . 44
8.3. GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. DELETE Handling . . . . . . . . . . . . . . . . . . . . . 45
8.5. Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 47
10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
11. Detailed Conflict Reports . . . . . . . . . . . . . . . . . . 47
11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 50
12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
12.3. Default Document Namespace . . . . . . . . . . . . . . . . 56
12.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 56
12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 56
12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14. Security Considerations . . . . . . . . . . . . . . . . . . . 59
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
15.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 60
15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
15.2.1. application/xcap-el+xml MIME Type . . . . . . . . . . 61
15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
15.2.3. application/xcap-ns+xml MIME Type . . . . . . . . . . 63
15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
15.2.5. application/xcap-caps+xml MIME Type . . . . . . . . . 64
15.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 65
15.3.1. urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . 65
15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
15.4.2. XCAP Capabilities Schema Registration . . . . . . . . 67
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
17.1. Normative References . . . . . . . . . . . . . . . . . . . 67
17.2. Informative References . . . . . . . . . . . . . . . . . . 69
In many communications applications, such as Voice over IP, instant messaging, and presence, it is necessary for network servers to access per-user information in the process of servicing a request. This per-user information resides within the network, but is managed by the end user themselves. Its management can be done through a multiplicity of access points, including the web, a wireless handset, or a PC application.
ネットワーク・サーバは、要求にサービスを提供する過程で、ユーザーごとの情報にアクセスするために、このようなボイスオーバーIP、インスタントメッセージング、プレゼンスなど多くの通信アプリケーションでは、それが必要です。このユーザごとの情報は、ネットワーク内に存在するが、エンドユーザー自身によって管理されています。その管理は、Web、無線ハンドセット、またはPCのアプリケーションを含む、アクセスポイントの多重を介して行うことができます。
There are many examples of per-user information. One is presence [20] authorization policy, which defines rules about which watchers are allowed to subscribe to a presentity, and what information they are allowed to access. Another is presence lists, which are lists of users whose presence is desired by a watcher [26]. One way to obtain presence information for the list is to subscribe to a resource which represents that list [21]. In this case, the Resource List Server (RLS) requires access to this list in order to process a SIP [16] SUBSCRIBE [28] request for it. Another way to obtain presence for the users on the list is for a watcher to subscribe to each user individually. In that case, it is convenient to have a server store the list, and when the client boots, it fetches the list from the server. This would allow a user to access their resource lists from different clients.
ユーザごとの情報の多くの例があります。一つは、ウォッチャーがプレゼンに加入することが許可されているかについてのルールを定義し、どのような情報彼らがアクセスを許可されている存在[20]許可ポリシー、です。別のプレゼンスウォッチャ[26]によって望まれるユーザのリストであるプレゼンスリスト、です。リストのプレゼンス情報を取得するための一つの方法は、[21]、そのリストを表すリソースにサブスクライブすることです。この場合には、リソースリストサーバ（RLS）は、それのための[28] SUBSCRIBEリクエストをSIP [16]を処理するために、このリストへのアクセスを必要とします。リスト上のユーザーのプレゼンスを得るための別の方法は、個別に各ユーザーにサブスクライブするウォッチャーのためです。その場合には、サーバーストアにリストを持っていると便利であり、クライアントは起動時に、サーバーからリストを取得したとき。これは、ユーザーが別のクライアントから自分のリソースリストにアクセスできるようになります。
This specification describes a protocol that can be used to manipulate this per-user data. It is called the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is based heavily on ideas borrowed from the Application Configuration Access Protocol (ACAP) [25], but it is not an extension of it, nor does it have any dependencies on it. Like ACAP, XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one.
この仕様は、このユーザーごとのデータを操作するために使用できるプロトコルを記載しています。これは、拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）と呼ばれています。 XCAPはHTTP URIを、一つのリソースの変更は別の、データ検証の制約、およびそれらのリソースへのアクセスに関連した認可ポリシーをどのように影響するかについての規則にマッピングするXMLドキュメントとドキュメントコンポーネントの規則のセットです。この構造のため、通常のHTTPプリミティブは、データを操作するために使用することができます。 XCAPはアプリケーション設定アクセスプロトコル（ACAP）[25]から借りアイデアに大きく基づいていますが、それはそれの延長ではなく、またそれはそれ上の任意の依存関係を持っています。 ACAPのように、XCAPはむしろちょうど単一のものよりも、アプリケーションの多様性のためのコンフィギュレーション・ニーズをサポートするためのものです。
XCAP was not designed as a general purpose XML search protocol, XML database update protocol, nor a general purpose, XML-based configuration protocol for network elements.
XCAPは、汎用XML検索プロトコル、XMLデータベース更新プロトコル、また一般的な目的のために、ネットワーク要素のためのXMLベースのコンフィギュレーションプロトコルとして設計されていません。
Each application (where an application refers to a use case that implies a collection of data and associated semantics) that makes use of XCAP specifies an application usage (Section 5). This application usage defines the XML schema [2] for the data used by the application, along with other key pieces of information. The principal task of XCAP is to allow clients to read, write, modify, create, and delete pieces of that data. These operations are supported using HTTP/1.1 [6]. An XCAP server acts as a repository for collections of XML documents. There will be documents stored for each application. Within each application, there are documents stored for each user. Each user can have a multiplicity of documents for a particular application. To access some component of one of those documents, XCAP defines an algorithm for constructing a URI that can be used to reference that component. Components refer to any element or attribute within the document. Thus, the HTTP URIs used by XCAP point to a document, or to pieces of information that are finer grained than the XML document itself. An HTTP resource that follows the naming conventions and validation constraints defined here is called an XCAP resource.
XCAPの使用は、アプリケーションの使用（セクション5）を指定する各アプリケーション（アプリケーションがデータと関連するセマンティクスのコレクションを意味ユースケースを指します）。このアプリケーションの使用は、情報の他の主要作品と共に、アプリケーションによって使用されるデータ用のXMLスキーマ[2]を定義します。 XCAPの主な仕事は、クライアントは、読み取り、書き込み、変更、作成、およびそのデータの一部を削除できるようにすることです。これらの動作は、HTTP / 1.1を使用してサポートされている[6]。 XCAPサーバーは、XML文書のコレクションのリポジトリとして機能します。アプリケーションごとに保存されたドキュメントがあります。各アプリケーション内では、ユーザーごとに保存された文書があります。各ユーザーは、特定のアプリケーションのための書類の多重度を持つことができます。これらの文書のいずれかのいくつかのコンポーネントにアクセスするために、XCAPは、そのコンポーネントを参照するために使用することができるURIを構築するためのアルゴリズムを定義します。コンポーネントは、文書内の任意の要素または属性を参照してください。したがって、文書、またはXML文書自体よりも細かい粒度であるの情報にXCAPポイントによって使用されるHTTPのURI。ここで定義された命名規則と検証の制約を次のHTTPリソースは、XCAPリソースと呼ばれています。
Since XCAP resources are also HTTP resources, they can be accessed using HTTP methods. Reading an XCAP resource is accomplished with HTTP GET, creating or modifying one is done with HTTP PUT, and removing one of the resources is done with an HTTP DELETE. XCAP resources do not represent processing scripts; as a result, POST operations to HTTP URIs representing XCAP resources are not defined. Properties that HTTP associates with resources, such as entity tags, also apply to XCAP resources. Indeed, entity tags are particularly useful in XCAP, as they allow a number of conditional operations to be performed.
XCAPリソースはまた、HTTPリソースなので、HTTPメソッドを使用してアクセスすることができます。 XCAPリソースがHTTP GETを用いて達成される読み取り、いずれかを作成または変更するHTTPのPUTを用いて行われ、リソースのいずれかを除去するHTTP DELETEを用いて行われます。 XCAPリソースは、スクリプトの処理を表すものではありません。結果として、XCAPリソースを表すHTTP URIにPOST操作が定義されていません。そのようなエンティティタグなどのリソースとHTTPの仲間は、また、XCAPリソースに適用されるプロパティ。それらは、条件付き演算の数を行うことを可能にするように実際に、エンティティタグは、XCAPにおいて特に有用です。
XML documents that are equivalent for the purposes of many applications may differ in their physical representation. With XCAP resources, the canonical form with comments [19] of an XML document determines the logical equivalence. In other words, the canonical specification determines how significant whitespace MUST be processed. It also implies that, for example, new inserted attributes may appear in any order within the physical representation.
多くのアプリケーションの目的のために等価であるXML文書は、それらの物理的な表現で異なる場合があります。 XCAPリソースと、XML文書のコメント[19]との標準形は、論理等価性を決定します。言い換えれば、標準的な仕様では、大きな空白が処理しなければなりません方法を決定します。それはまた、例えば、新たな挿入属性が物理的表現内で任意の順序で表示されることがあり、ことを意味します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" RFC 2119に記載されるように解釈されるべきである[7]及び対応する実装の要求レベルを示します。
The following terms are used throughout this document:
以下の用語は、この文書全体で使用されています。
XCAP Resource: An HTTP resource representing an XML document, an element within an XML document, or an attribute of an element within an XML document that follows the naming and validation constraints of XCAP.
XCAPリソース：XMLドキュメント、XML文書内の要素、またはXCAPの命名と検証制約を次のXML文書内の要素の属性を表すHTTPリソース。
XCAP Server: An HTTP server that understands how to follow the naming and validation constraints defined in this specification.
XCAPサーバー：この仕様で定義された名前付けと検証の制約に従うことをどのように理解してHTTPサーバ。
XCAP Client: An HTTP client that understands how to follow the naming and validation constraints defined in this specification.
XCAPクライアント：この仕様で定義された名前付けと検証の制約に従うことをどのように理解してHTTPクライアント。
Application: A collection of software components within a network whose operation depends on data managed and stored on an XCAP server.
アプリケーション：操作XCAPサーバー上で管理し、格納されたデータに依存して、ネットワーク内のソフトウェア・コンポーネントのコレクション。
Application Usage: Detailed information on the interaction of an application with the XCAP server.
アプリケーション使用状況：XCAPサーバーとアプリケーションの相互作用に関する詳細な情報。
Application Unique ID (AUID): A unique identifier within the namespace of application unique IDs created by this specification that differentiates XCAP resources accessed by one application from XCAP resources accessed by another.
アプリケーション固有ID（AUID）：他によってアクセスXCAPリソースから一つのアプリケーションによってアクセスさXCAPリソースを区別する本明細書により作成されたアプリケーション固有IDの名前空間内で一意の識別子。
Naming Conventions: The part of an application usage that specifies well-known URIs used by an application, or more generally, specifies the URIs that are typically accessed by an application during its processing.
命名規則：より一般的にアプリケーションによって使用される周知のURIを指定し、またはアプリケーションの使用の一部は、典型的には、その処理中にアプリケーションがアクセスするURIを指定します。
XCAP User Identifier (XUI): The XUI is a string, valid as a path element in an HTTP URI, that is associated with each user served by the XCAP server.
XCAPユーザ識別子（XUI）：XUIは、XCAPサーバによってサービスされる各ユーザに関連付けられたHTTP URIのパス要素として有効な文字列です。
XCAP Root: A context that contains all the documents across all application usages and users that are managed by the server.
XCAPルート：サーバーによって管理されているすべてのアプリケーションの用法とユーザー間のすべての文書が含まれていコンテキスト。
Document Selector: A sequence of path segments, with each segment being separated by a "/", that identify the XML document within an XCAP root that is being selected.
ドキュメントセレクター：各セグメントのパスセグメントの配列は、選択されているXCAPルート内のXML文書を識別すること、「/」によって分離されています。
Node Selector: A sequence of path segments, with each segment being separated by a "/", that identify the XML node (element or attribute) being selected within a document.
ノードセレクタ：XMLノード（要素または属性）を識別する各セグメントは、「/」によって分離されているとパスセグメントの配列は、ドキュメント内で選択されます。
Node Selector Separator: A single path segment equal to two tilde characters "~~" that is used to separate the document selector from the node selector within an HTTP URI.
ノードセレクタセパレータ：HTTP URI内のノードセレクタから文書セレクタを分離するために使用された2つのチルダ文字に等しい単一のパスセグメント「~~」。
Document URI: The HTTP URI containing the XCAP root and document selector, resulting in the selection of a specific document. As a result, performing a GET against the document URI would retrieve the document.
文書URI：特定の文書の選択をもたらす、XCAPルートとドキュメントセレクタを含むHTTP URI。その結果、文書URIに対してGETを実行すると、ドキュメントを取得します。
Node URI: The HTTP URI containing the XCAP root, document selector, node selector separator, and node selector, resulting in the selection of a specific XML node.
ノードURI：HTTP URIは、特定のXMLノードの選択をもたらす、XCAPルート、ドキュメントセレクタ、ノードセレクタセパレータ、及びノードセレクタを含みます。
XCAP Root URI: An HTTP URI that represents the XCAP root. Although a syntactically valid URI, the XCAP Root URI does not correspond to an actual resource on an XCAP server. Actual resources are created by appending additional path information to the XCAP Root URI.
XCAPルートURI：XCAPのルートを表すHTTP URI。構文的に有効なURIが、XCAPルートURIは、XCAPサーバー上の実際のリソースに対応していません。実際のリソースは、XCAPルートURIに追加パス情報を追加することによって作成されます。
Global Tree: A URI that represents the parent for all global documents for a particular application usage within a particular XCAP root.
グローバルツリー：URI特定のXCAPルート内の特定のアプリケーションの使用のためのすべてのグローバルのドキュメントの親を表します。
Home Directory: A URI that represents the parent for all documents for a particular user for a particular application usage within a particular XCAP root.
ホームディレクトリ：特定のXCAPルート内の特定のアプリケーションを使用するため、特定のユーザーのすべてのドキュメントの親を表しているURI。
Positional Insertion: A PUT operation that results in the insertion of a new element into a document such that its position, relative to other children of the same parent, is set by the client.
位置挿入：同じ親の他の子に比べてその位置は、クライアントによって設定されるように、ドキュメントに新しい要素の挿入につながるPUT操作。
Each XCAP resource on a server is associated with an application. In order for an application to use those resources, application specific conventions must be specified. Those conventions include the XML schema that defines the structure and constraints of the data, well-known URIs to bootstrap access to the data, and so on. All of those application specific conventions are defined by the application usage.
サーバー上の各XCAPリソースは、アプリケーションに関連付けられています。これらのリソースを使用するアプリケーションのためのためには、アプリケーション固有の規則を指定する必要があります。これらの規則はそれほど上のデータへのアクセスをブートストラップするために、よく知られたURIを、データの構造と制約を定義するXMLスキーマを含めると。これらのアプリケーション固有の規則のすべては、アプリケーション用法で定義されています。
Each application usage is associated with a name, called an Application Unique ID (AUID). This name uniquely identifies the application usage within the namespace of application usages, and is different from AUIDs used by other applications. AUIDs exist in one of two namespaces. The first namespace is the IETF namespace. This namespace contains a set of tokens, each of which is registered with IANA. These registrations occur with the publication of standards track RFCs [27], based on the guidelines in Section 15. The second namespace is the vendor-proprietary namespace. Each AUID in that namespace is prefixed with the reverse domain name of the organization creating the AUID, followed by a period, followed by any vendor defined token. As an example, the example.com domain can create an AUID with the value "com.example.foo" but cannot create one with the value "org.example.foo". AUIDs within the vendor namespace do not need to be registered with IANA. The vendor namespace is also meant to be used in lab environments where no central registry is needed. The syntax for AUIDs, expressed in ABNF [12] (and using some of the BNF defined in RFC 3986 [13]), is:
各アプリケーションの使用は、名前に関連付けられた、アプリケーション固有ID（AUID）と呼ばれます。この名前は一意のアプリケーション用途の名前空間内のアプリケーションの使用状況を識別し、他のアプリケーションで使用AUIDs異なります。 AUIDsは、2つの名前空間のいずれかに存在します。最初の名前空間はIETF名前空間です。この名前空間はIANAに登録されているそれぞれのトークンのセットが含まれています。これらの登録は、第15項のガイドラインに基づいて、第2の名前空間は、ベンダー独自の名前空間で、標準化トラックのRFCの出版[27]で発生します。その名前空間内の各AUIDは、任意のベンダー定義されたトークンによってピリオドAUIDを、作成、組織の逆ドメイン名が付いています。例として、example.comドメインは、値「com.example.foo」とAUIDを作成することができますが、値「org.example.foo」を持つものを作成することはできません。ベンダーの名前空間内AUIDsは、IANAに登録する必要はありません。ベンダーの名前空間にも何の中央レジストリが必要とされていないラボ環境で使用されることを意味しています。 AUIDsの構文、ABNF [12]において発現（およびRFC 3986で定義されたBNF [13]の一部を使用して）は、次のとおりです。
AUID = global-a-uid / vendor-a-uid global-a-uid = a-uid a-uid = 1*a-uid-char vendor-a-uid = rev-hostname "." a-uid rev-hostname = toplabel *( "." domainlabel ) domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum a-uid-char = a-uid-unreserved / pct-encoded / sub-delims / ":" / "@" ;pct-encoded from RFC 3986 ;sub-delims from RFC 3986 alphanum = ALPHA / DIGIT ;DIGIT from RFC 4234 ;ALPHA from RFC 4234 a-uid-unreserved = ALPHA / DIGIT / "-" / "_" / "~"
AUID =グローバル--UID /ベンダー-uidのグローバル-UID =-UID-UID = 1 *-UID-char型のベンダー-UID = REV-ホスト名 "" -UID REVホスト名= toplabel×（ "" domainlabel）domainlabel = alphanum / alphanum *（alphanum / " - "）alphanum toplabel = ALPHA / ALPHA *（alphanum / " - "）alphanum-UID-チャー= A -uid-未予約/ PCTエンコード/サブdelims / "：" / "@"、RFC 3986からのPCTエンコード; RFC 3986 alphanum = ALPHA / DIGITからサブdelims; RFC 4234からDIGIT; ALPHA RFC 4234 Aから-uid-予約されていない= ALPHA / DIGIT / " - " / "_" / "〜"
The allowed characters for the auid production is a subset of the pchar production defined in RFC 3986. In particular, it omits the ".", which allows for the auid to be separated from the reverse hostname.
AUID生産のための許可された文字は、特に、RFC 3986で定義されたのPChar生産のサブセットが、それは省略され、「」、AUIDは逆ホスト名から分離することを可能にします。
In order for the XCAP server to match a URI to an element or attribute of a document, any XML namespace prefixes used within the URI must be expanded [3]. This expansion requires a namespace binding context. That context maps namespace prefixes to namespace URIs. It also defines a default namespace that applies to elements in the URI without namespace prefixes. The namespace binding context comes from two sources. First, the mapping of namespace prefixes to namespace URIs is obtained from the URI itself (see Section 6.4). However, the default document namespace is defined by the application usage itself, and applies to all URIs referencing resources within that application usage. All application usages MUST define a namespace URI that represents the default document namespace to be used when evaluating URIs. The default document namespace does not apply to elements or attributes within the documents themselves -- it applies only to the evaluation of URIs within that application usage. Indeed, the term 'default document namespace' is distinct from the term 'default namespace'. The latter has the standard meaning within XML documents, and the former refers to the default used in evaluation of XCAP URIs. XCAP does not change in any way the mechanisms for determining the default namespace within XML documents. However, if a document contains a URI representing an XCAP resource, the default document namespace defined by the application usage applies to that URI as well.
文書の要素または属性にURIと一致するように、XCAPサーバためには、URI内で使用される任意のXML名前空間接頭辞は、拡張されなければならない[3]。この拡張は、名前空間バインディングコンテキストを必要とします。そのコンテキストは、名前空間URIに名前空間接頭辞をマップします。また、名前空間接頭辞なしでURIの要素に適用されるデフォルトの名前空間を定義します。名前空間バインディングコンテキストは、2つのソースから来ています。まず、URIを名前空間に名前空間接頭辞のマッピングはURI自体から得られる（6.4節を参照してください）。ただし、既定のドキュメントの名前空間は、アプリケーションの使用状況自体によって定義され、そのアプリケーションの使用内のリソースを参照するすべてのURIに適用されます。すべてのアプリケーション用法は、URIを評価する際に使用するデフォルトの文書の名前空間を表した名前空間URIを定義しなければなりません。既定のドキュメントの名前空間は、ドキュメント自体内の要素や属性には適用されません - それは、そのアプリケーションの使用中にURIの評価にのみ適用されます。確かに、用語「既定のドキュメントの名前空間には、」用語「デフォルトの名前空間」から区別されます。後者は、XML文書内の標準的な意味を持っており、前者はXCAP URIの評価に使用されるデフォルトを指します。 XCAPは、どのような方法でXML文書内のデフォルトの名前空間を決定するための仕組みを変更しません。文書は、XCAPリソースを表すURIが含まれている場合は、アプリケーション用法で定義された既定のドキュメントの名前空間は、同様にそのURIに適用されます。
One of the responsibilities of an XCAP server is to validate the content of each XCAP resource when an XCAP client tries to modify one. This is done using two mechanisms. Firstly, all application usages MUST describe their document contents using XML schema [2]. The application usage MUST also identify the MIME type for documents compliant to that schema.
XCAPサーバーの責務の一つは、XCAPクライアントが1を変更しようとすると、各XCAPリソースの内容を検証することです。これは、2つのメカニズムを使用して行われます。まず、すべてのアプリケーションの用法は、XMLスキーマ[2]を使用して文書の内容を記述しなければなりません。アプリケーションの使用状況は、そのスキーマに準拠した文書のMIMEタイプを特定しなければなりません。
Unfortunately, XML schemas cannot represent every form of data constraint. As an example, one XML element may contain an integer that defines the maximum number of instances of another element. This constraint cannot be represented with XML schema. However, such constraints may be important to the application usage. The application usage defines any additional constraints beyond those in the schema.
残念ながら、XMLスキーマは、データ制約のすべてのフォームを表現することはできません。一例として、1つのXML要素が別の要素のインスタンスの最大数を定義する整数を含んでいてもよいです。この制約は、XMLスキーマによって表現することはできません。しかし、そのような制約は、アプリケーションの使用状況に重要であるかもしれません。アプリケーションの使用状況は、スキーマのものを超えて任意の追加の制約を定義します。
Of particular importance are uniqueness constraints. In many cases, an application will require that there be only one instance of some element or attribute within a particular scope. Each uniqueness constraint needs to be specified by identifying the field, or combinations of fields, that need to be unique, and then identifying the scope in which that uniqueness applies. One typical scope is the set of all elements of a certain name within the same parent. Another typical scope is the set of all URIs valid within a particular domain. In some cases, these constraints can be specified using XML schema, which provides the <unique> element for this purpose. Other uniqueness constraints, such as URI uniqueness across a domain, cannot be expressed by schema. Whether or not the schema is used to express some of the uniqueness requirements, the application usage MUST specify all uniqueness requirements when it defines its data validation needs.
特に重要なのは、一意性制約があります。多くの場合、アプリケーションは、特定の範囲内にいくつかの要素または属性のインスタンスを1つだけ存在することを必要とするであろう。各一意性制約は、フィールドを識別する、または一意である必要があるフィールドの組み合わせ、およびその一意性が適用される範囲を特定することによって指定される必要があります。一つの典型的な範囲は、同じ親内の特定の名前のすべての要素の集合です。別の典型的な範囲は、特定のドメイン内の有効なすべてのURIのセットです。いくつかのケースでは、これらの制約は、この目的のために、<ユニーク>要素を提供するXMLスキーマを使用して指定することができます。そのようなドメイン全体URIの一意性などの他の一意性制約は、スキーマによって表現できません。スキーマは一意性要件の一部を表現するために使用されているかどうかは、そのデータの検証の必要性を定義するとき、アプリケーションの使用状況は、すべての一意性要件を指定しなければなりません。
For example, the resource lists application usage [22] requires that each <list> element have a unique value for the "name" attribute within a single parent. As another example, the RLS services application usage [22] requires that the value of the "uri" attribute of the <service> element be a URI that is unique within the domain of the URI.
たとえば、リソースリストのアプリケーションの使用状況[22]は、各<リスト>要素は、単一の親の中で、「名前」属性の一意の値を持つことが必要です。別の例として、RLSサービスのアプリケーションの使用状況[22]は、<service>要素の「URI」属性の値はURIのドメイン内で一意であるURIである必要があります。
URI constraints represent another form of constraints. These are constraints on the scheme or structure of the scheme-specific part of the URI. These kinds of constraints cannot be expressed in an XML schema. If these constraints are important to an application usage, they need to be explicitly called out.
URI制約は、制約の別の形を表しています。これらは、URIのスキーマ固有部分の方式や構造上の制約です。制約のこれらの種類は、XMLスキーマで表現することはできません。これらの制約は、アプリケーションの使用状況に重要な場合は、明示的に呼び出される必要があります。
Another important data constraint is referential integrity. Referential integrity is important when the name or value of an element or attribute is used as a key to select another element or attribute. An application usage MAY specify referential integrity constraints. However, XCAP servers are not a replacement for Relational Database Management Systems (RDBMS), and therefore clients MUST NOT depend on servers to maintain referential integrity. XCAP clients are responsible for making all the appropriate changes to documents in order to maintain referential integrity.
もう一つの重要なデータの制約は、参照整合性です。要素や属性の名前や値が別の要素または属性を選択するためのキーとして使用される場合に参照整合性が重要です。アプリケーションの使用状況は、参照整合性制約を指定するかもしれません。しかし、XCAPサーバは、リレーショナルデータベース管理システム（RDBMS）に代わるものではありませんであるため、クライアントは、参照整合性を維持するために、サーバに依存してはなりません。 XCAPクライアントは、参照整合性を維持するために、文書にすべての適切な変更を行うための責任があります。
Another constraint is character encoding. XML allows documents to be encoded using several different character sets. However, this specification mandates that all documents used with XCAP MUST be encoded using UTF-8. This cannot be changed by an application usage.
もう一つの制約は、文字エンコーディングです。 XML文書は、いくつかの異なる文字セットを使用してエンコードすることができます。しかし、すべての文書は、XCAPで使用されるこの仕様書の義務化は、UTF-8を使用してエンコードされなければなりません。これは、アプリケーションの使用状況によって変更することはできません。
The data validation information is consumed by both clients, which use them to make sure they construct requests that will be accepted by the server, and by servers, which validate the constraints when they receive a request (with the exception of referential integrity constraints, which are not validated by the server).
データ検証情報は、それらが参照整合性制約を除いて、（リクエストを受信したとき、彼らは、サーバーが受け入れる要求、および制約を検証サーバでの構築を確認するためにそれらを使用する両方のクライアントによって消費されます）サーバーによって検証されていません。
For each application usage, the data present in the XML document has a well-defined semantic. The application usage defines that semantic, so that a client can properly construct a document in order to achieve the desired result. They are not used by the server, as it is purposefully unaware of the semantics of the data it is managing. The data semantics are expressed in English prose by the application usage.
各アプリケーションの使用のために、XML文書内に存在するデータは、明確に定義されたセマンティックを有しています。クライアントが正常に所望の結果を達成するには、ドキュメントを作成できるように、アプリケーションの使用状況は、それはセマンティック定義します。それが管理しているデータの意味論の意図認識していないとして彼らは、サーバーによって使用されていません。データのセマンティクスは、アプリケーションの使用状況によって英語の散文で表現されています。
One particularly important semantic is the base URI that is to be used for the resolution of any relative URI references pointed to XCAP resources. As discussed below, relative URI references pointing to XCAP resources cannot be resolved using the retrieval URI as the base URI. Therefore, it is up to the application usage to specify the base URI.
特に重要な1つのセマンティックは、XCAPリソースを指摘任意の相対URI参照の解決に使用されるベースURIです。以下に説明するように、XCAPリソースを指す相対URI参照は、ベースURIとして検索URIを使用して解決することはできません。したがって、それはベースURIを指定するには、アプリケーションの使用状況次第です。
In addition to defining the meaning of the document in the context of a particular application, an application usage has to specify how the applications obtain the documents they need. In particular, it needs to define any well-known URIs used for bootstrapping purposes, and document any other conventions on the URIs used by an application. It should also document how documents reference each other. These conventions are called naming conventions.
特定のアプリケーションのコンテキストで文書の意味を定義するだけで、アプリケーションの使用状況は、アプリケーションが、彼らが必要とする書類を入手する方法を指定する必要があります。特に、それはブートストラップ目的、及び文書アプリケーションによって使用されるURIに他の規則のために使用される任意の周知のURIを定義する必要があります。また、文書が互いを参照する方法文書化する必要があります。これらの規則は、命名規則と呼ばれています。
For many application usages, users need only a single document. In such a case, it is RECOMMENDED that the application usage require that this document be called "index" and exist within the user's home directory.
多くのアプリケーションの用途では、ユーザーは、単一のドキュメントを必要としています。このような場合には、アプリケーションの使用状況は、この文書は、「インデックス」と呼ばれることを要求し、ユーザのホームディレクトリ内に存在することが推奨されます。
As an example, the RLS services application usage allows an RLS to obtain the contents of a resource list when the RLS receives a SUBSCRIBE request for a SIP URI identifying an RLS service. The application usage specifies that the list of service definitions is present within a specific document with a specific name within the global tree. This allows the RLS to perform a single XCAP request to fetch the service definition for the service associated with the SIP URI in a SUBSCRIBE request.
一例として、RLSサービスのアプリケーションの使用は、RLSは、RLSサービスを識別するSIP URIのためのSUBSCRIBEリクエストを受信したときに、リソースリストの内容を取得するためにRLSを可能にします。アプリケーションの使用状況は、サービス定義のリストは、グローバルツリー内の特定の名前を持つ特定の文書内に存在することを指定します。これは、RLSは、SUBSCRIBEリクエストにSIP URIに関連付けられているサービスのサービス定義をフェッチする単一のXCAP要求を実行することを可能にします。
Naming conventions are used by XCAP clients to construct their URIs. The XCAP server does not make use of them.
命名規則は、そのURIを構築するためにXCAPクライアントによって使用されています。 XCAPサーバーは、それらを使用しません。
When a user modifies an XCAP resource, the content of many other resources is affected. For example, when a user deletes an XML element within a document, it does so by issuing a DELETE request against the URI for the element resource. However, deleting this element also deletes all child elements and their attributes, each of which is also an XCAP resource. As such, manipulation of one resource affects the state of other resources.
ユーザーは、XCAPリソースを変更すると、他の多くのリソースの内容が影響を受けています。例えば、ユーザは、要素リソースのURIに対してDELETEリクエストを発行することによってそうする、文書内のXML要素を削除します。しかし、この要素を削除することも、また、XCAPリソースで、それぞれが、すべての子要素とその属性を削除します。そのため、一つのリソースの操作は、他のリソースの状態に影響を与えます。
For the most part, these interdependencies are fully specified by the XML schema used by the application usage. However, in some application usages, there is a need for the server to relate resources together, and such a relationship cannot be specified through a schema. This occurs when changes in one document will affect another document. Typically, this is the case when an application usage is defining a document that acts as a collection of information defined in other documents.
ほとんどの部分については、これらの相互依存関係は完全にアプリケーションの使用状況によって使用されるXMLスキーマによって指定されています。ただし、一部のアプリケーション用法で、一緒にリソースを関連付けるために、サーバーの必要性がある、とそのような関係は、スキーマを使用して指定することはできません。一つの文書の変更が別の文書に影響する場合に発生します。典型的には、これは、アプリケーションの使用が他の文書で定義された情報の集合として作用するドキュメントを定義している場合です。
As an example, when a user creates a new RLS service (that is, it creates a new <service> element within an RLS services document), the server adds that element to a read-only global list of services maintained by the server in the global tree. This read-only global list is accessed by the RLS when processing a SIP SUBSCRIBE request.
ユーザーが新しいRLSサービスを（それはそれは、RLSサービスドキュメント内の新しい<サービス>要素を作成し、ある）作成する例として、サーバは、サーバ内で維持されたサービスの読み取り専用のグローバルリストにその要素を追加しますグローバルツリー。 SIPのSUBSCRIBEリクエストを処理するとき、この読み取り専用グローバルリストは、RLSによってアクセスされます。
Resource interdependencies are used by both XCAP clients and servers.
リソースの相互依存性は、XCAPクライアントとサーバーの両方で使用されています。
By default, each user is able to access (read, modify, and delete) all the documents below their home directory, and any user is able to read documents within the global directory. However, only trusted users, explicitly provisioned into the server, can modify global documents.
デフォルトでは、各ユーザーは自分のホームディレクトリ以下のすべての文書（読み取り、変更、および削除）にアクセスすることができ、かつ任意のユーザがグローバルディレクトリ内のドキュメントを読み込むことができます。しかし、唯一のグローバル文書を変更することができ、明示的にサーバーにプロビジョニングされたユーザーを、信頼できます。
The application usage can specify a different authorization policy that applies to all documents associated with that application usage. An application usage can also specify whether another application usage is used to define the authorization policies. An application usage for setting authorization policies can also be defined subsequent to the definition of the main application usage. In such a case, the main application usage needs only to specify that such a usage will be defined in the future.
アプリケーションの使用状況は、そのアプリケーションの使用に関連するすべての文書に適用される異なる認可ポリシーを指定することができます。アプリケーションの使用状況は、他のアプリケーションの使用が認可ポリシーを定義するために使用されているかどうかを指定することができます。認可ポリシーを設定するためのアプリケーションの使用状況は、メインアプリケーションの使用状況の定義の後に定義することができます。このような場合には、メインアプリケーションの使用は、そのような使用が将来に定義されるように指定する必要があります。
If an application usage does not wish to change the default authorization policy, it can merely state that the default policy is used.
アプリケーションの使用状況は、デフォルトの認可ポリシーを変更したくない場合は、単にデフォルトのポリシーが使用されていることを述べることができます。
The authorization policies defined by the application usage are used by the XCAP server during its operation.
アプリケーション用法で定義された認可ポリシーは、その動作中XCAPサーバーによって使用されています。
An XCAP server MUST understand an application usage in order to process an HTTP request made against a resource for that particular application usage. However, it is not required for the server to understand all of the contents of a document used by an application usage. A server is required to understand the baseline schema defined by the application usage. However, those schemas can define points of extensibility where new content can be added from other namespaces and corresponding schemas. Sometimes, the server will understand those namespaces and therefore have access to their schemas. Sometimes, it will not.
XCAPサーバーは、その特定のアプリケーションの使用のためのリソースに対して作られたHTTPリクエストを処理するために、アプリケーションの使用状況を理解する必要があります。サーバーは、アプリケーションの使用状況によって使用される文書の内容のすべてを理解するしかし、これは必須ではありません。サーバーは、アプリケーション用法で定義されたベースラインのスキーマを理解することが必要です。しかしながら、これらのスキーマは、新しいコンテンツが他の名前空間と対応するスキーマから添加することができる拡張性の点を定義することができます。時には、サーバーはこれらの名前空間を理解し、したがって、そのスキーマにアクセスすることができます。時には、それはしません。
A server MUST allow for documents that contain elements from namespaces not known to the server. In such a case, the server cannot validate that such content is schema compliant; it will only verify that the XML is well-formed.
サーバーは、サーバーに知られていない名前空間からの要素を含む文書を考慮しなければなりません。このような場合、サーバは、コンテンツがスキーマに準拠していることを検証することができません。それだけでXMLが整形されていることを確認します。
If a client wants to verify that a server supports a particular namespace before operating on a resource, it can query the server for its capabilities using the XCAP Capabilities application usage, discussed in Section 12.
クライアントはサーバがリソース上で操作する前に、特定の名前空間をサポートしていることを確認したい場合、それは12節で議論XCAP機能のアプリケーションの使用状況を、使用してその機能のためにサーバーを照会することができます。
Application usages are documented in specifications that convey the information described above. In particular, an application usage specification MUST provide the following information:
アプリケーションの使用法は、上記の情報を伝達する仕様に記載されています。具体的には、アプリケーションの使用の仕様は以下の情報を提供しなければなりません。
o Application Unique ID (AUID): If the application usage is meant for general use on the Internet, the application usage MUST register the AUID into the IETF tree using the IANA procedures defined in Section 15.
Oアプリケーション固有ID（AUID）：アプリケーションの使用は、インターネット上で一般的な使用のために意図されている場合は、アプリケーションの使用は、セクション15で定義されたIANAの手順を使用してIETFツリーにAUIDを登録しなければなりません。
o XML Schema
お ＸＭＬ Ｓちぇま
o Default Document Namespace
Oの既定のドキュメントの名前空間
o MIME Type
O MIMEタイプ
o Validation Constraints
O検証の制約
o Data Semantics
Oデータセマンティクス
o Naming Conventions
Oの命名規則
o Resource Interdependencies
Oリソースの相互依存
o Authorization Policies
O承認ポリシー
The primary design task when creating a new application usage is to define the schema. Although XCAP can be used with any XML document, intelligent schema design will improve the efficiency and utility of the document when it is manipulated with XCAP.
新しいアプリケーションの使用状況を作成する主要な設計タスクはスキーマを定義することです。 XCAPは、任意のXMLドキュメントで使用することができますが、それは、XCAPで操作されたときに、インテリジェントなスキーマ設計は、文書の効率性と有用性が向上します。
XCAP provides three fundamental ways to select elements amongst a set of siblings: by the expanded name of the element, by its position, or by the value of a specific attribute. Positional selection always allows a client to get exactly what it wants. However, it requires a client to cache a copy of the document in order to construct the predicate. Furthermore, if a client performs a PUT, it requires the client to reconstruct the PUT processing that a server would follow in order to update its local cached copy. Otherwise, the client will be forced to re-GET the document after every PUT, which is inefficient. As such, it is a good idea to design schemas such that common operations can be performed without requiring the client to cache a copy of the document.
要素の拡張名により、その位置によって、または特定の属性の値によって：XCAPは、兄弟の集合の中の要素を選択するための3つの基本的な方法を提供します。位置の選択は、常にクライアントが望んで正確に何を取得することができます。ただし、それは述語を構築するには、ドキュメントのコピーをキャッシュするクライアントが必要です。クライアントは、PUTを実行する場合さらに、それは、サーバがローカルにキャッシュされたコピーを更新するためにたどるPUT処理を再構築するためにクライアントが必要です。そうでない場合、クライアントは非効率的であるすべてのPUT、後に文書を再GETするために強制されます。このように、一般的な操作は、文書のコピーをキャッシュするクライアントを必要とせずに実行することができるようにスキーマを設計することをお勧めします。
Without positional selection, a client can pick the element at each step by its expanded name or the value of an attribute. Many schemas include elements that can be repeated within a parent (often, minOccurs equals zero or one, and maxOccurs is unbounded). As such, all of the elements have the same name. This leaves the attribute value as the only way to select an element. Because of this, if an application usage expects the user to manipulate elements or attributes that are descendants of an element that can repeat, that element SHOULD include, in its schema, an attribute that can be suitably used as a unique index. Furthermore, the naming conventions defined by that application usage SHOULD specify this uniqueness constraint explicitly.
位置の選択がなければ、クライアントはその拡張名または属性の値によって各ステップで要素を選択することができます。多くのスキーマは（多くの場合、minOccurs属性が0または1に等しい、とmaxOccursが無制限である）親内に繰り返すことができる要素を含みます。そのように、すべての要素が同じ名前を持っています。これは、要素を選択するための唯一の方法として、属性値を残します。アプリケーションの使用は、ユーザが繰り返すことができる要素の子孫である要素や属性を操作するために期待している場合、このため、その要素は、そのスキーマ内に、適切一意のインデックスとして使用することができる属性を含むべきです。さらに、そのアプリケーションの使用状況によって定義された命名規則が明示的にこの一意性制約を指定する必要があります。
URIs often make a good choice for such a unique index. They have fundamental uniqueness properties, and are also usually of semantic significance in the application usage. However, care must be taken when using a URI as an attribute value. URI equality is usually complex. However, attribute equality is performed by the server using XML rules, which are based on case sensitive string comparison. Thus, XCAP will match URIs based on lexical equality, not functional equality. In such cases, an application usage SHOULD consider these implications carefully.
URIは、多くの場合、このようなユニークなインデックスのために良い選択をします。彼らは基本的な独自性の性質を持っており、また、通常、アプリケーションの使用状況におけるセマンティックな意義のあります。属性値としてURIを使用している場合ただし、注意が必要です。 URIの平等は、通常は複雑です。ただし、属性の平等は、大文字と小文字が区別文字列の比較に基づいているXML規則を使用して、サーバーによって実行されます。したがって、XCAPは字句平等ではなく、機能的平等に基づいてURIを一致します。このような場合には、アプリケーションの使用状況は慎重にこれらの影響を考慮すべきです。
XCAP provides the ability of a client to operate on a single element, attribute, or document at a time. As a result, it may be possible that common operations the client might perform will require a sequence of multiple requests. This is inefficient, and introduces the possibility of failure conditions when another client modifies the document in the middle of a sequence. In such a case, the client will be forced to detect this case using entity tags (discussed below in Section 7.11), and undo its previous changes. This is very difficult.
XCAPは、一度に単一の要素、属性、またはドキュメントを操作するためのクライアントの機能を提供します。その結果、クライアントが実行する可能性のある一般的な操作は、複数の要求のシーケンスを必要とすることが可能かもしれません。これは非効率的であり、別のクライアントは、シーケンスの途中で文書を修正障害状態の可能性を紹介します。このような場合、クライアントは、（7.11節で後述）エンティティタグを使用して、この場合を検出し、その前の変更を取り消すことを余儀なくされるであろう。これは非常に困難です。
As a result, the schemas SHOULD be defined so that common operations generally require a single request to perform. Consider an example. Let's say an application usage is defining permissions for users to perform certain operations. The schema can be designed in two ways. The top level of the tree can identify users, and within each user, there can be the permissions associated with the user. In an alternative design, the top level of the tree identifies each permission, and within that permission, the set of users who have it.
一般的な操作は、一般的に実行するための単一の要求を必要とするその結果、スキーマが定義されるべきです。例を考えてみましょう。ユーザーが特定の操作を実行するためのアプリケーションの利用権限を定義しているとしましょう。スキーマは、2つの方法で設計することができます。ツリーの最上位は、ユーザを識別することができ、各ユーザの中に、ユーザに関連付けられた権限があり得ます。別の設計では、ツリーの最上位には、それぞれの権限を識別し、その権限内で、それを持っているユーザの集合。
If, in this application usage, it is common to change the permission for a user from one value to another, the former schema design is better for xcap; it will require a single PUT to make such a change. In the latter case, either the entire document needs to be replaced (which is a single operation), or two PUT operations need to occur -- one to remove the user from the old permission, and one to add the user to the new permission.
、このアプリケーションの使用状況では、それは別の値からユーザーの権限を変更するのが一般的である場合には、かつてのスキーマ設計は、XCAPのためのより良いです。そのような変更を行うために、単一のPUTが必要になります。いずれかの古い許可からユーザを除去するために、もう1つは新しい許可にユーザーを追加する - 後者の場合には、いずれかの文書全体は、（単一の操作である）、又は二PUT動作が発生する必要が交換する必要があります。
Naming conventions form another key part of the design of an application usage. The application usage should be certain that XCAP clients know where to "start" to retrieve and modify documents of interest. Generally, this will involve the specification of a well-known document at a well-known URI. That document can contain references to other documents that the client needs to read or modify.
命名規則は、アプリケーションの使用状況の設計の別の重要な部分を形成します。アプリケーションの使用は、目的の文書を検索し、修正するために、「開始」する場所XCAPクライアントが知っていることを特定する必要があります。一般的に、これは、よく知られたURIでよく知られている文書の指定を含むことになります。その文書は、クライアントが読み取りまたは修正する必要があり、他の文書への参照を含めることができます。
In order to manipulate an XCAP resource, the data must be represented by an HTTP URI. XCAP defines a specific naming convention for constructing these URIs. The URI is constructed by concatenating the XCAP root with the document selector with the node selector separator with a percent-encoded form of the node selector. This is followed by an optional query component that defines namespace bindings used in evaluating the URI. The XCAP root is the enclosing context in which all XCAP resources live. The document selector is a path that identifies a document within the XCAP root. The node selector separator is a path segment with a value of double tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in Section 2.3 of RFC 3986 [13]. URIs containing %7E%7E should be normalized to ~~ for comparison; they are equivalent. The node selector separator is a piece of syntactic sugar that separates the document selector from the node selector. The node selector is an expression that identifies a component of the document, such as an element or attribute. It is possible that a "~~" appears as part of the node selector itself; in such a case, the first "~~" in the URI is the node selector separator.
XCAPリソースを操作するために、データがHTTP URIによって表されなければなりません。 XCAPは、これらのURIを構築するための具体的な命名規則を定義します。 URIは、ノードセレクタのパーセントエンコードされた形式のノードセレクタセパレータドキュメントセレクタとXCAPルートを連結することによって構築されます。これはURIを評価する際に使用される名前空間のバインディングを定義するオプションのクエリコンポーネントが続きます。 XCAPルートは、すべてのXCAPリソースが住んでいる外側のコンテキストです。文書セレクタは、XCAPルート内のドキュメントを識別するパスです。ノードセレクタセパレータはダブルチルダ（「~~」）の値を有する経路セグメントであり、RFC 3986のセクション2.3に助言として、パーセントエンコードされるべきではない[13]。 ％7E％の7Eを含むURIは、比較のために~~に正規化されるべきです。彼らは同等です。ノードセレクタセパレータは、ノードセレクタから文書セレクタを分離糖衣構文の一部です。ノードセレクタは、要素や属性などの文書の構成要素を特定する表現です。 「~~」は、ノードセレクタ自体の一部として表示されることが可能です。このような場合には、最初の「~~」URIにノードセレクタセパレータです。
The sections below describe these components in more detail.
以下のセクションではより詳細にこれらのコンポーネントを記述する。
The root of the XCAP hierarchy is called the XCAP root. It defines the context in which all other resources exist. The XCAP root is represented with an HTTP URI, called the XCAP Root URI. This URI is a valid HTTP URI; however, it doesn't point to any resource that actually exists on the server. Its purpose is to identify the root of the tree within the domain where all XCAP documents are stored.
XCAP階層のルートは、XCAPルートと呼ばれています。これは、他のすべてのリソースが存在するコンテキストを定義します。 XCAPルートはXCAPルートURIと呼ばれ、HTTP URIで表現されます。このURIは有効なHTTP URIです。しかし、それは実際にはサーバー上に存在するすべてのリソースを指していません。その目的は、すべてのXCAP文書が保存されているドメイン内のツリーのルートを特定することです。
It can be any valid HTTP URI, but MUST NOT contain a query component (a complete XCAP URI may have a query component, but it is not part of the XCAP root URI). It is RECOMMENDED that it be equal to xcap.domain, where domain is the domain of the provider. As an example, "http://xcap.example.com" might be used as the XCAP root URI within the example.com domain. Typically, the XCAP root URI is provisioned into client devices. If not explicitly provisioned, clients SHOULD assume the form xcap.domain, where domain is the domain of their service provider (for SIP, this would be the domain part of their Address-of-Record (AOR)). A server or domain MAY support multiple XCAP root URIs. In such a case, it is effectively operating as if it were serving separate domains. There is never information carryover or interactions between resources in different XCAP root URIs.
これは、任意の有効なHTTP URIすることができますが、クエリコンポーネント（完全なXCAP URIは、クエリコンポーネントを有することができるが、それはXCAPルートURIの一部ではない）を含めることはできません。ドメインは、プロバイダのドメインxcap.domain、に等しくすることが推奨されます。例として、「http://xcap.example.com」example.comドメイン内のXCAPルートURIとして使用される可能性があります。一般的に、XCAPルートURIは、クライアントデバイスにプロビジョニングされます。明示的にプロビジョニングされていない場合、クライアントはドメインがそのサービスプロバイダのドメインであるフォームxcap.domainを、前提とすべきである（SIPのために、これは自分のアドレス・オブ・レコード（AOR）のドメイン部分になります）。サーバーまたはドメインには、複数のXCAPルートURIをサポートするかもしれません。それが別のドメインにサービスを提供しているかのように、このような場合には、効果的に動作しています。情報のキャリーオーバーまたは異なるXCAPルートのURI内のリソース間の相互作用があり決してありません。
When a client generates an HTTP request to a URI identifying an XCAP resource, RFC 2616 procedures for the construction of the Request-URI apply. In particular, the authority component of the URI may not be present in the Request-URI if the request is sent directly to the origin server.
クライアントは、XCAPリソースを識別するURIに対してHTTPリクエストを生成する場合、リクエストURIの構築のためのRFC 2616の手順が適用されます。リクエストは、オリジンサーバに直接送信される場合、特に、URIの権限コンポーネントは、Request-URIに存在しなくてもよいです。
The XCAP root URI can also be a relative HTTP URI. It is the responsibility of the application usage to specify the base URI for an HTTP URI representing an XCAP resource whenever such a URI appears within a document defined by that application usage. Generally speaking, it is unsafe to use the retrieval URI as the base URI. This is because any URI that points to an ancestor for a particular element or attribute can contain content including that element or attribute. If that element or attribute contained a relative URI reference, it would be resolved relative to whatever happened to be used to retrieve the content, and this will often not be the base URI defined by the application usage.
XCAPルートURIはまた、相対的なHTTP URIすることができます。そのようなURIは、そのアプリケーションの使用によって定義された文書内に現れるたびにXCAPリソースを表すHTTP URIのベースURIを指定するアプリケーションの使用状況の責任です。一般的に言えば、ベースURIとして検索URIを使用することは危険です。特定の要素または属性の先祖を指す任意のURIは、その要素または属性を含むコンテンツを含むことができるからです。その要素または属性が相対URI参照が含まれていた場合、それがコンテンツを取得するために使用されるように起こったものは何でもに対する解決されるだろうし、これは多くの場合、アプリケーション用法で定義されたベースURIではありません。
Each document within the XCAP root is identified by its document selector. The document selector is a sequence of path segments, separated by a slash ("/"). These path segments define a hierarchical structure for organizing documents within any XCAP root. The first path segment MUST be the XCAP AUID. So, continuing the example above, all of the documents used by the resource lists application would be under "http://xcap.example.com/resource-lists".
XCAPルート内の各ドキュメントは、そのドキュメントセレクタによって識別されます。文書セレクタは、スラッシュ（「/」）によって分離され、パスセグメントのシーケンスです。これらのパスセグメントは、任意のXCAPルート内のドキュメントを整理するための階層構造を定義します。第1の経路セグメントは、XCAP AUIDなければなりません。したがって、上記の例を続けて、リソースリストのアプリケーションによって使用されるすべての文書は、「http://xcap.example.com/resource-lists」の下になります。
o Implementors making use of HTTP servlets should be aware that XCAP may require them to get authorization from the server administrator to place resources within this specific subset of the URI namespace.
HTTPサーブレットを利用したOの実装者は、XCAPは、URI名前空間のこの特定のサブセット内のリソースを配置するために、サーバ管理者から承認を得るためにそれらを必要とするかもしれないことに注意する必要があります。
It is assumed that each application will have data that is set by users, and/or it will have global data that applies to all users. As a result, beneath each AUID, there are two sub-trees. One, called "users", holds the documents that are applicable to specific users, and the other, called "global", holds documents applicable to all users. The sub-tree beneath "global" is called the global tree. The path segment after the AUID MUST either be "global" or "users".
各アプリケーションは、ユーザーによって設定されたデータを持っていると思われ、および/またはそれは、すべてのユーザーに適用されるグローバルデータを持つことになります。その結果、各AUID下に、二つのサブ木があります。 「ユーザー」と呼ばれる一つは、特定のユーザーに適用されている文書を保持し、かつ、「グローバル」と呼ばれ、他のすべてのユーザーに適用される文書を保持しています。 「グローバル」の下のサブツリーは、グローバルツリーと呼ばれています。 AUID後のパスセグメントのいずれか「グローバル」または「ユーザー」でなければなりません。
Within the "users" tree are zero or more sub-trees, each of which identifies documents that apply to a specific user. Each user known to the server is associated with a username, called the XCAP User Identifier (XUI). Typically, an endpoint is provisioned with the value of the XUI. For systems that support SIP applications, it is RECOMMENDED that the XUI be equal to the Address-of-Record (AOR) for the user (i.e., sip:joe@example.com). Since SIP endpoints generally know their AOR, they will also know their XUI. As a consequence, if no XUI is explicitly provisioned, a SIP User Agent SHOULD assume it is equal to their AOR. This XUI MUST be used as the path segment beneath the "users" segment. Since the SIP URI allows for characters that are not permitted in HTTP URI path segments (such as the '?' and '/' characters, which are permitted in the user part of the SIP URI), any such characters MUST be percent encoded. The sub-tree beneath an XUI for a particular user is called their home directory. "User" in this context should be interpreted loosely; a user might correspond to a device, for example.
「ユーザー」ツリー内の特定のユーザに適用されるドキュメントを識別する各々が、ゼロ以上のサブ木です。サーバに知られている各ユーザは、ユーザ名に関連付けられている、XCAPユーザ識別子（XUI）と呼ばれます。典型的には、エンドポイントはXUIの値がプロビジョニングされています。 （：joe@example.comすなわち、SIP）SIPアプリケーションをサポートするシステムのためには、XUIは、ユーザのアドレス・オブ・レコード（AOR）に等しくすることが推奨されます。 SIPエンドポイントは、一般的に彼らのAORを知っているので、彼らはまた、彼らのXUIを知っています。その結果、何のXUIが明示的にプロビジョニングされていない場合は、SIPユーザエージェントは、それが彼らのAORに等しいと仮定すべきです。このXUIは、「ユーザー」セグメントの下にパスセグメントとして使用しなければなりません。 SIP URIは、（例えば、SIP URIのユーザ部分に許可されている「？」と「/」文字、など）HTTP URIパスセグメントに許可されていない文字を可能にするので、このような文字は％が符号化されなければなりません。特定のユーザーのためのXUIの下のサブツリーは、自分のホームディレクトリと呼ばれています。この文脈での「ユーザー」緩く解釈されるべきです。ユーザは、例えば、デバイスに対応するかもしれません。
XCAP does not itself define what it means for documents to "apply" to a user, beyond specification of a baseline authorization policy, described below in Section 8. Each application usage can specify additional authorization policies that depend on data used by the application itself.
XCAPは、ドキュメントがユーザーに「適用」することが何を意味するのか自分自身を定義していない、ベースラインの認可ポリシーの仕様を超えて、各アプリケーションの使用状況は、アプリケーション自体によって使用されるデータに依存して、追加の認可ポリシーを指定することができ、セクション8に説明。
The remainder of the document selector (the path following "global" or the XUI) points to specific documents for that application usage. Subdirectories are permitted, but are NOT RECOMMENDED. XCAP provides no way to create sub-directories or to list their contents, thus limiting their utility. If subdirectories are used, there MUST NOT be a document in a directory with the same name as a sub-directory.
ドキュメントセレクタの残り、そのアプリケーションを使用するための特定の文書への点（「グローバル」またはXUIを次のパス）。サブディレクトリは許可されていますが、推奨されていません。 XCAPは、このようにその有用性を制限し、サブディレクトリを作成するか、その内容を一覧表示する方法を提供していません。サブディレクトリを使用する場合は、サブディレクトリと同じ名前のディレクトリ内の文書があってはなりません。
The final path segment in the document selector identifies the actual document in the hierarchy. This is equivalent to a filename, except that XCAP does not require that its document resources be stored as files in a file system. However, the term "filename" is used to describe the final path segment in the document selector. In traditional filesystems, the filename would have a filename extension, such as ".xml". There is nothing in this specification that requires or prevents such extensions from being used in the filename. In some cases, the application usage will specify a naming convention for documents, and those naming conventions may or may not specify a file extension. For example, in the RLS services application usage [22], documents in the user's home directory with the filename "index" will be used by the server to compute the global index, which is also a document with the filename "index". Barring specific guidelines in the application usage, if a user has a single document for a particular application usage, this SHOULD be called "index".
ドキュメントセレクタの最後のパスセグメントは、階層内の実際の文書を識別する。これは、XCAPは、その文書のリソースは、ファイルシステム内のファイルとして保存されることを必要としないことを除いて、ファイル名と同じです。しかしながら、用語「ファイル名」は、ドキュメントセレクタの最後のパスセグメントを記述するために使用されます。伝統的なファイルシステムでは、ファイル名は、「.xmlファイル」などのファイル名拡張子を、持っているでしょう。ファイル名に使用されているから、このような拡張を必要とするか、または防ぐこの仕様では何もありません。いくつかのケースでは、アプリケーションの使用状況は、文書の命名規則を指定し、それらの命名規則は、ファイルの拡張子を指定しない場合があります。例えば、RLSサービスのアプリケーションの使用状況[22]で、ファイル名の「インデックス」を持つユーザのホームディレクトリ内のドキュメントも、ファイル名「インデックス」と文書であるグローバルインデックスを計算するためにサーバーによって使用されます。ユーザーが特定のアプリケーションを使用するための単一の文書を持っている場合は、アプリケーションの使用中に具体的なガイドラインがなければ、これは「インデックス」と呼ばれるべきです。
When the naming conventions in an application usage do not constrain the filename conventions (or, more generally, the document selector), an application will know the filename (or more generally, the document selector) because it is included as a reference in a document accessed by the client. As another example, within the index document defined by RLS services, the <service> element has a child element called <resource-list> whose content is a URI pointing to a resource list within the users home directory.
アプリケーションの使用中に命名規則（または、より一般的には、ドキュメントセレクタ）ファイル名規則を制限しない場合、それが文書に参照として含まれているため、アプリケーションは、（より一般的に文書セレクタまたは）ファイル名を知っているであろうクライアントがアクセスします。別の例として、RLSサービスによって定義されたインデックスドキュメント内、<サービス>要素は、そのコンテンツ、ユーザーのホームディレクトリ内のリソースのリストを指し示すURIである<リソースリスト>と呼ばれる子要素を持っています。
As a result, if the user creates a new document, and then references that document from a well-known document (such as the index document above), it doesn't matter whether or not the user includes an extension in the filename, as long as the user is consistent and maintains referential integrity.
ユーザが新しい文書を作成し、（例えば上記インデックス文書など）は、周知の文書から、その文書を参照する場合、結果として、ユーザとして、ファイル名に拡張子が含まれているか否かは問題ではありませんユーザー限りは一貫性があり、参照整合性を維持します。
As an example, the path segment "/resource-lists/users/sip:joe@example.com/index" is a document selector. Concatenating the XCAP root URI with the document selector produces the HTTP URI "http://xcap.example.com/resource-lists/users/ sip:joe@example.com/index". In this URI, the AUID is "resource-lists", and the document is in the user tree with the XUI "sip:joe@example.com" with filename "index".
一例として、経路セグメント「/resource-lists/users/sip:joe@example.com/indexは、」文書セレクタです。ドキュメントセレクタとXCAPルートURIを連結すると、HTTP URI「：joe@example.com/index http://xcap.example.com/resource-lists/users/一口」を生成します。このURIで、AUIDは、「リソース・リスト」であり、文書がXUI「SIP：joe@example.com」でユーザーツリーにあるファイル名の「インデックス」と。
The node selector specifies specific nodes of the XML document that are to be accessed. A node refers to an XML element, an attribute of an element, or a set of namespace bindings. The node selector is an expression that identifies an element, attribute, or set of namespace bindings. Its grammar is:
ノードセレクタは、アクセスされるXML文書の特定のノードを指定します。ノードは、XML要素、要素の属性、または名前空間バインディングのセットを指します。ノードセレクタは、要素、属性、または名前空間バインディングのセットを識別する表現です。その文法は次のとおりです。
node-selector = element-selector ["/" terminal-selector] terminal-selector = attribute-selector / namespace-selector / extension-selector element-selector = step *( "/" step) step = by-name / by-pos / by-attr / by-pos-attr / extension-selector by-name = NameorAny by-pos = NameorAny "[" position "]" position = 1*DIGIT attr-test = "@" att-name "=" att-value by-attr = NameorAny "[" attr-test "]" by-pos-attr = NameorAny "[" position "]" "[" attr-test "]" NameorAny = QName / "*" ; QName from XML Namespaces att-name = QName att-value = AttValue ; from XML specification attribute-selector = "@" att-name namespace-selector = "namespace::*" extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/"
ノードセレクタ=要素セレクタ[「/」端子セレクタ]端末セレクタ=属性セレクタ/名前空間セレクタ/拡張セレクタ要素セレクタ=ステップ*（「/」ステップ）ステップ=による名/バイPOS /バイATTR /によって-POS-ATTR /拡張セレクタによって名= NameorAnyによって-POS = NameorAny "[" 位置 "]" の位置= 1 * DIGITのATTRテスト= "@" ATT名 "=" ATT値によって、ATTR = NameorAny "[" ATTRテスト "]" によって-POS-ATTR = NameorAny "[" 位置 "]" "[" ATTRテスト "]" NameorAny = QNameの/ "*"。 ATT-名XML名前空間からのQNameのQName = ATT値= ATTVALUE。 XML仕様の属性セレクタから= "@" ATT名の名前空間セレクター= "名前空間:: *" 拡張セレクタ= 1 *（％x00-2e /％X30-FF）;何が、「/」
The QName grammar is defined in the XML namespaces [3] specification, and the AttValue grammar is defined in the XML specification XML 1.0 [1].
QNameの文法は、[3]仕様のXML名前空間で定義され、そしてATTVALUE文法はXML仕様のXML 1.0で定義されている[1]。
The extension-selector is included for purposes of extensibility. It can be composed of any character except the slash, which is the delimiter amongst steps. Any characters in an extension that cannot be represented in a URI MUST be percent-encoded before placement into a URI.
拡張セレクタは、拡張性の目的のために含まれています。これは、手順の中で区切り文字であるスラッシュを除く任意の文字で構成することができます。 URIで表現できない拡張子のいずれかの文字は、パーセントエンコードされたURIへの配置の前でなければなりません。
Note that the double quote, left square bracket and right square bracket characters, which are meaningful to XCAP, cannot be directly represented in the HTTP URI. As a result, they are percent-encoded when placed within the HTTP URI. In addition to these characters, an apostrophe (') character can be used as a delimiter within XPath expressions. Furthermore, since XML allows for non-ASCII characters, the names of elements and attributes may not be directly representable in a URI. Any such characters MUST be represented by converting them to an octet sequence corresponding to their representation in UTF-8, and then percent-encoding that sequence of octets.
二重引用符は、角括弧と直接HTTP URIで表現できない、XCAPにとって意味のある右角カッコの文字を、左のことに注意してください。結果として、彼らは、パーセントエンコードHTTP URI内に配置されたときです。これらの文字に加えて、アポストロフィ（ '）文字は、XPath式内の区切り文字として使用することができます。 XMLは、非ASCII文字が可能になりますので、要素と属性の名前は、URIで直接表現できない場合があります。任意のこのような文字は、UTF-8でそれらの表現に対応するオクテットシーケンスに変換し、次いでオクテットのシーケンスをパーセントコードによって表現されなければなりません。
Similarly, the XML specification defines the QName production for the grammar for element and attribute names, and the AttValue production for the attribute values. Unfortunately, the characters permitted by these productions include some that are not allowed for pchar, which is the production for the allowed set of characters in path segments in the URI. The AttValue production allows many such characters within the US-ASCII set, including the space. Those characters MUST be percent-encoded when placed in the URI. Furthermore, QName and AttValue allow many Unicode characters, outside of US-ASCII. When these characters need to be represented in the HTTP URI, they are percent-encoded. To do this, the data should be encoded first as octets according to the UTF-8 character encoding [18], and then only those octets that do not correspond to characters in the pchar set should be percent-encoded. For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".
同様に、XML仕様では、要素のための文法のためのQNameの生産を定義し、属性名、属性値のATTVALUE生産。残念ながら、これらのプロダクションによって許可文字は、URIのパスセグメント内の文字の許可セットの製造であるPChar型のために許可されていない一部を含みます。 ATTVALUE生産はスペースを含むUS-ASCIIセット内の多くのような文字を、ことができます。 URIに置かれたとき、それらの文字はパーセントエンコードする必要があります。さらに、QNameにとATTVALUEは、US-ASCIIの外に、多くのUnicode文字を許可します。これらの文字がHTTP URIで表現する必要があるときは、パーセントエンコードされています。これを行うために、データはUTF-8文字エンコード[18]に記載のオクテットとして最初に符号化されるべきであり、その後のPCharセット内の文字に対応していないだけのオクテットは、パーセントエンコードされなければなりません。例えば、文字Aは「A」と表記される、グレーブ付き文字ラテン大文字Aは、「％のC3％80」として表現される、文字カタカナLETTER Aは％E3の％82％A2」として表現されます」。
As a result, the grammar above represents the expressions processed by the XCAP server internally after it has decoded the URI. The on-the-wire format is dictated by RFC 3986 [13]. In the discussions and examples below, when the node selectors are not part of an HTTP URI, they are presented in their internal format prior to encoding. If an example includes a node selector within an HTTP URI, it is presented in its percent-encoded form.
その結果、上記の文法は、URIをデコードした内部後XCAPサーバーによって処理された式を表します。オン・ザ・ワイヤ形式は、RFC 3986 [13]によって決定されます。ノードセレクタがHTTP URIの一部ではない場合に議論および以下の実施例では、それらは符号化の前に、それらの内部形式で提示されています。例では、HTTP URI内のノードセレクタを含む場合、それは、そのパーセントエンコードされた形で提示されます。
The node selector is based on the concepts in XPath [10]. Indeed, the node selector expression, before it is percent-encoded for representation in the HTTP URI, happens to be a valid XPath expression. However, XPath provides a set of functionality far richer than is needed here, and its breadth would introduce much unneeded complexity into XCAP.
ノードセレクタは、XPath [10]で概念に基づいています。それはパーセントエンコードHTTP URIで表現するためのものである前に、実際には、ノードセレクタ式は、有効なXPath式であることを起こります。しかし、XPathはここで必要とされるよりもはるかに豊富な機能セットを提供し、その幅はXCAPに多くの不必要な複雑さを導入します。
To determine the XML element, attribute, or namespace bindings selected by the node selector, processing begins at the root node of the XML document. The first step in the element selector is then taken. Each step chooses a single XML element within the current document context. The document context is the point within the XML document from which a specific step is evaluated. The document context begins at the root node of the document. When a step determines an element within that context, that element becomes the new context for evaluation of the next step. Each step can select an element by its name (expanded), by a combination of name and attribute value, by name and position, or by name, position and attribute. In all cases, the name can be wildcarded, so that all elements get selected.
ノード選択部によって選択されたXML要素、属性、または名前空間バインディングを決定するために、処理は、XMLドキュメントのルートノードで開始します。要素セレクタの最初のステップは、その後行われます。各ステップは、現在のドキュメントのコンテキスト内の単一のXML要素を選択します。文書のコンテキストでは、特定のステップが評価されたXMLドキュメント内の点です。文書の文脈では、文書のルート・ノードから始まります。ステップは、そのコンテキスト内の要素を決定すると、その要素は次の段階を評価するための新たなコンテキストになります。各ステップは、その名前（拡張）により、名前と属性値の組み合わせによって、名前および位置によって、または名前、位置および属性で要素を選択することができます。すべての要素が選択されますように、すべてのケースでは、名前は、ワイルドカードすることができます。
The selection operation operates as follows. Within the current document context, the children of that context are enumerated in document order. If the context is the root node of the document, its child element is the root element of the document. If the context is an element, its children are all of the children of that element (naturally). Next, those elements whose name is not a match for NameorAny are discarded. An element name is a match if NameorAny is the wildcard, or if it is not a wildcard, the element name matches NameorAny. Matching is discussed below. The result is an ordered list of elements.
次のように選択動作が動作します。現在の文書の文脈の中で、そのコンテキストの子どもたちは、ドキュメント順に列挙されています。コンテキストは、文書のルート・ノードである場合は、その子要素は、ドキュメントのルート要素です。コンテキストが要素である場合、その子は、その要素のすべての子（自然）です。次に、名前がそれらの要素は破棄されNameorAnyの一致ではありません。 NameorAnyがワイルドカードである、またはそれはワイルドカードでない場合、要素名はNameorAnyと一致した場合に要素名が一致しています。マッチングについては後述します。結果は、要素の順序付きリストです。
The elements in the list are further filtered by the predicates, which are the expressions in square brackets following NameorAny. Each predicate further prunes the elements from the current ordered list. These predicates are evaluated in order. If the content of the predicate is a position, the position-th element is selected (that is, treat "position" as a variable, and take the element whose position equals that variable), and all others are discarded. If there are fewer elements in the list than the value of position, the result is a no-match.
リスト内の要素をさらにNameorAny以下の角括弧内の式である述語によってフィルタリングされます。各々は、プルーン、現在の順序付けられたリストから要素を述語。これらの述語は順番に評価されます。述語のコンテンツが位置である場合、位置番目の要素が選択されている（つまり、変数として「位置」を扱い、その位置が、その変数に等しい要素を取る）、そして他のすべては廃棄されます。位置の値よりもリスト内の少数の要素が存在する場合、結果には一致しません。
If the content of the predicate is an attribute name and value, all elements possessing an attribute with that name and value are selected, and all others are discarded. Note that, although a document can have namespace declarations within elements, those elements cannot be selected using a namespace declaration as a predicate. That is, a step like "el-name[@xmlns='namespace']" will never match an element, even if there is an element in the list that specifies a default namespace of "namespace". In other words, a namespace node is NOT an attribute. If the namespaces in scope for an element are needed, they can be selected using the namespace-selector described below. If there are no elements with attributes having the given name and value, the result is a no-match.
述語の内容は、属性名と値である場合は、その名前と値を持つ属性を持つすべての要素が選択され、他のすべてが廃棄されています。文書は、要素内の名前空間宣言を有することができるが、これらの要素は、述語として、名前空間の宣言を使用して選択することができない、ということに注意してください。つまり、のようなステップ「エル名[@のxmlns = 『名前空間』]は、」「名前空間」のデフォルトの名前空間を指定し、リスト内の要素があっても、要素にマッチすることはありません。言い換えれば、名前空間ノードは、属性ではありません。要素のスコープ内の名前空間が必要な場合、それらは以下に記載する名前空間セレクタを使用して選択することができます。指定された名前と値を持つ属性を持つ要素がない場合、結果には一致しません。
After the predicates have been applied, the result will be a no-match, one element, or multiple elements. If the result is multiple elements, the node selector is invalid. Each step in a node selector MUST produce a single element to form the context for the next step. This is more restrictive than general XPath expressions, which allow a context to contain multiple nodes. If the result is a no-match, the node selector is invalid. The node selector is only valid if a single element was selected. This element becomes the context for the evaluation of the next step in the node selector expression.
述語が適用された後、結果が不一致、一つの要素、または複数の要素であろう。結果が複数の要素である場合、ノードセレクタは無効です。ノード選択の各ステップは、次のステップのためのコンテキストを形成するために、単一の要素を生成しなければなりません。このコンテキストは、複数のノードを含めることができ、一般的なXPath式、より限定的です。結果は全くマッチしない場合、ノードセレクタは無効です。単一の要素を選択した場合、ノードセレクタにのみ有効です。この要素は、ノードセレクタ式における次の段階の評価のためのコンテキストになります。
The last location step is either the previously described element selector or a "terminal selector". If the terminal selector is an attribute selector, the server checks to see if there is an attribute with the same expanded name in the current element context. If there is not, the result is considered a no-match. Otherwise, that attribute is selected. If the terminal selector is a namespace selector, the result is equal to the set of namespace bindings in scope for the element, including the possible default namespace declaration. This specification defines a syntax for representing namespace bindings, so they can be returned to the client in an HTTP response.
最後のロケーションステップは、前述の要素セレクタまたは「端末セレクタ」のいずれかです。ターミナルセレクタは属性セレクタがある場合は、サーバが現在の要素のコンテキスト内で同じ拡張名を持つ属性があるかどうかをチェックします。存在しない場合、結果は全く一致とみなされません。それ以外の場合は、その属性が選択されています。端末セレクタが名前空間の選択である場合、結果は、可能なデフォルトの名前空間宣言を含む要素のスコープ内の名前空間バインディングのセット、に等しいです。この仕様は、名前空間のバインディングを表現するための構文を定義するので、彼らはHTTP応答でクライアントに返すことができます。
As a result, once the entire node selector is evaluated against the document, the result will either be a no-match, invalid, a single element, a single attribute, or a set of namespace bindings.
全体ノードセレクタがドキュメントに対して評価されると結果として、結果は、いずれかの不一致、無効、単一の要素、単一の属性、または名前空間バインディングのセットであろう。
Matching of element names is performed as follows. The element being compared in the step has its name expanded as described in XML namespaces [3]. The element name in the step is also expanded. This
次のように要素名のマッチングが行われます。 XML名前空間に記載されるようにステップで比較される要素は、その名前は、[3]の拡大しています。ステップの要素名も展開されています。この
expansion requires that any namespace prefix is converted to its namespace URI. Doing that requires a set of bindings from prefixes to namespace URIs. This set of bindings is obtained from the query component of the URI (see Section 6.4). If the prefix of the QName of an element is empty, the corresponding URI is then the default document namespace URI defined by the application usage, or null if not defined. Comparisons are then performed as described in XML namespaces [3]. Note that the namespace prefix expansions described here are different than those specified in the XPath 1.0 specification, but are closer to those currently defined by the XPath 2.0 specification [24].
拡張は、任意の名前空間接頭辞は、その名前空間URIに変換されている必要があります。それを実行すると、URIを名前空間に接頭辞からのバインディングのセットが必要です。バインディングのこのセットはURIのクエリコンポーネントから取得される（セクション6.4参照）。要素のQNameに接頭辞が空の場合は、対応するURIが定義されていない場合、デフォルトの文書のアプリケーション用法で定義された名前空間URI、またはnullです。 XML名前空間[3]で説明されるような比較は、次に実行されます。ここで説明した名前空間接頭辞の拡張は、XPath 1.0仕様で指定されたものと異なっているが、現在のXPath 2.0仕様[24]によって定義されたものに近いことに留意されたいです。
Matching of attribute names proceeds in a similar way. The attribute in the document has its name expanded as described in XML namespaces [3]. If the attribute name in the attribute selector has a namespace prefix, its name is expanded using the namespace bindings obtained from the query component of the URI. An unprefixed attribute QName is in no namespace.
属性名のマッチングは、同様の方法で進行します。 XML名前空間[3]で説明したように、文書内の属性は、その名前が拡大しています。属性セレクタの属性名が名前空間接頭辞を持っている場合は、その名前は、URIのクエリコンポーネントから取得した名前空間バインディングを使用して展開されています。接頭辞属性のQNameはありません名前空間にあります。
Comments, text content (including whitespace), and processing instructions can be present in a document, but cannot be selected by the expressions defined here. Of course, if such information is present in a document, and a user selects an XML element enclosing that data, that information would be included in a resulting GET, for example. Furthermore, whitespace is respected by XCAP. If a client PUTs an element or document that contains whitespace, the server retains that whitespace, and will return the element or document back to the client with exactly the same whitespace. Similarly, when an element is inserted, no additional whitespace is added around the inserted element, and the element gets inserted in a very specific location relative to any whitespace, comments, or processing instructions around it. Section 8.2.3 describes where the insertion occurs.
コメント、（空白を含む）テキストコンテンツ、および処理命令は、文書中に存在することができるが、ここで定義された式で選択することはできません。そのような情報は、文書中に存在し、ユーザがそのデータを囲むXML要素を選択した場合はもちろん、その情報は、例えば、得られたGETに含まれるであろう。さらに、空白はXCAPで尊敬されています。クライアントが空白を含む要素または文書を置く場合は、サーバーはその空白を保持し、まったく同じ空白で、クライアントに要素または文書を返します。要素が挿入されたとき、同様に、追加の空白が挿入された要素の周囲に追加されず、要素がその周りに空白、コメント、または処理命令に対して非常に特定の場所に挿入されます。挿入が発生した場所8.2.3項について説明します。
As an example, consider the following XML document:
例として、次のXML文書を考えてみます。
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:professor@example.net" package="presence"> <watcher status="active" id="8ajksjda7s" duration-subscribed="509" event="approved">sip:userA@example.net</watcher> <watcher status="pending" id="hh8juja87s997-ass7" display-name="Mr. Subscriber" event="subscribe">sip:userB@example.org</watcher> </watcher-list> </watcherinfo>
<xmlのバージョン= "1.0"？> <watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <ウォッチャーリストリソース= "一口：例@教授.NET "パッケージ= "存在"> <ウォッチャーは、ステータス= "アクティブ" ID = "8ajksjda7s" は期間加入= "509" イベント= ""：userA@example.net </ウォッチャー> <ウォッチャーステータス=> SIP" 承認しました。「ID = "hh8juja87s997-ass7" 表示名= "ミスター加入" イベントは= "" 購読保留> SIP：userB@example.org </ウォッチャー> </ウォッチャーリスト> </ watcherinfo>
Figure 3: Example XML Document
図3：例XMLドキュメント
Assuming that the default document namespace for this application usage is "urn:ietf:params:xml:ns:watcherinfo", the node selector watcherinfo/watcher-list/watcher[@id="8ajksjda7s"] would select the following XML element:
このアプリケーションの使用のための既定のドキュメントの名前空間であると仮定すると、「URN：IETF：paramsは：XML：NS：watcherinfo」、ノードセレクタwatcherinfo /ウォッチャーリスト/ウォッチャーは[ID =「8ajksjda7s」@]次のXML要素を選択するであろう。
<watcher status="active" id="8ajksjda7s" duration-subscribed="509" event="approved">sip:userA@example.net</watcher>
<ウォッチャステータス= "アクティブ" ID = "8ajksjda7s" 期間、加入= "509" イベント= "承認"> SIP：userA@example.net </ウォッチャー>
In order to expand the namespace prefixes used in the node selector, a set of bindings from those namespace prefixes to namespace URI must be used. Those bindings are contained in the query component of the URI. If no query component is present, it means that only the default document namespace (as identified by the application usage) is defined. The query component is formatted as a valid xpointer expression [5] after suitable URI encoding as defined in Section 4.1 of the Xpointer framework. This xpointer expression SHOULD only contain expressions from the xmlns() scheme [4]. A server compliant to this specification MUST ignore any xpointer expressions not from the xmlns() scheme. The xmlns() xpointer expressions define the set of namespace bindings in use for evaluating the URI.
ノードセレクタに使用される名前空間の接頭辞を拡大するために、URIを名前空間にそれらの名前空間接頭辞のバインディングのセットを使用しなければなりません。これらのバインディングは、URIのクエリコンポーネントに含まれています。何のクエリコンポーネントが存在しない場合は、それが唯一の既定のドキュメントの名前空間は、（アプリケーションの使用状況によって識別される）に定義されていることを意味します。 XPointerのフレームワークのセクション4.1で定義されたクエリコンポーネントは、適切なURI符号化後の有効のXPointer式[5]としてフォーマットされます。このXPointerの発現のみのxmlns（）スキーム[4]の式を含むべきです。この仕様に準拠したサーバがないのxmlns（）スキームからの任意のXPointer表現を無視しなければなりません。 xmlns（）のXPointer式は、URIを評価するため、使用中の名前空間バインディングのセットを定義します。
Note that xpointer expressions were originally designed for usage within fragment identifiers of URIs. However, within XCAP, they are used within query components of URIs.
XPointerの式は、元々のURIのフラグメント識別子内の使用のために設計されたことに注意してください。しかし、XCAP以内に、彼らは、URIのクエリコンポーネント内で使用されています。
The following example shows a more complex matching operation, this time including the usage of namespace bindings. Consider the following document:
次の例では、名前空間バインディングの使用を含む、より複雑な整合動作は、この時間を示しています。次のドキュメントを考えてみます。
<?xml version="1.0"?> <foo xmlns="urn:test:default-namespace"> <ns1:bar xmlns:ns1="urn:test:namespace1-uri" xmlns="urn:test:namespace1-uri"> <baz/> <ns2:baz xmlns:ns2="urn:test:namespace2-uri"/> </ns1:bar> <ns3:hi xmlns:ns3="urn:test:namespace3-uri"> <there/> </ns3:hi> </foo>
<fooというのxmlns = "壷：テスト：デフォルトの名前空間"> <xmlのバージョン= "1.0"？> <NS1：バーのxmlns：NS1 = "壷：テスト：namespace1-URI" のxmlns = "壷：テスト：namespace1- URI "> <バズ/> <NS2：バズのxmlns：NS2 =" 壷：テスト：namespace2-URI "/> </ NS1：バー> <NS3：ハイテクのxmlns：NS3 =" 壷：テスト：namespace3-URI "> <そこに/> </ NS3：こんにちは> </ foo>の
Assume that this document has a document URI of "http://xcap.example.com/test/users/sip:joe@example.com/index", where "test" is the application usage. This application usage defines a default document namespace of "urn:test:default-namespace". The XCAP URI:
この文書は、「テスト」は、アプリケーションの使用状況である文書「http://xcap.example.com/test/users/sip:joe@example.com/index」のURIを、持っていることを前提としています。 「：テスト：デフォルトの名前空間URN」このアプリケーションの使用状況は、既定のドキュメントの名前空間を定義します。 XCAP URI：
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace1-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~ / fooの/：バー/ B：バズのxmlns？（= URN：テスト：namespace1-URI）のxmlns （B = URN：試験：namespace1-URI）
will select the first <baz> child element of the <bar> element in the document. The XCAP URI:
ドキュメント内の<バー>要素の最初の<バズ>子要素を選択します。 XCAP URI：
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace2-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~ / fooの/：バー/ B：バズのxmlns？（= URN：テスト：namespace1-URI）のxmlns （B = URN：試験：namespace2-URI）
will select the second <baz> child element of the <bar> element in the document. The following XCAP URI will also select the second <baz> child element of the <bar> element in the document:
ドキュメント内の<バー>要素の2番目の<バズ>子要素を選択します。以下のXCAP URIは、文書内の<バー>要素の2番目の<バズ>子要素を選択します：
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace2-uri) xmlns(d=urn:test:default-namespace)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~ / D：FOO /：バー/ B：バズのxmlns（= URN：？テスト：namespace1-URI ）のxmlns（B = URN：試験：namespace2-URI）のxmlns（D = URN：試験：デフォルト名前空間）
An XCAP client is an HTTP/1.1 compliant client. Specific data manipulation tasks are accomplished by invoking the right set of HTTP methods with the right set of headers on the server. This section describes those in detail.
XCAPクライアントは、HTTP / 1.1準拠のクライアントです。具体的なデータ操作タスクは、サーバー上のヘッダの右のセットとHTTPメソッドの右のセットを呼び出すことによって達成されます。このセクションでは、詳細にこれらについて説明します。
In all cases where the client modifies a document, by deleting or inserting a document, element or attribute resource, the client SHOULD verify that, if the operation were to succeed, the resulting document would meet the data constraints defined by the application usage, including schema validation. For example, if the client performs a PUT operation to "http://xcap.example.com/rls-services/ users/sip:joe@example.com/mybuddies", rls-services is the application unique ID, and the constraints defined by it SHOULD be followed.
クライアントが削除や文書、要素や属性のリソースを挿入することによって、文書を修正するすべての場合において、クライアントは、操作が成功した場合、結果として得られる文書は、アプリケーションの使用状況によって定義されたデータ制約を満たす含むであろう、それを確認する必要がスキーマ検証。例えば、クライアントは、PUT操作を行った場合に、「http://xcap.example.com/rls-services/ユーザ/ SIP：joe@example.com/mybuddies」、RLS-サービスは、アプリケーション固有のIDで、それによって定義された制約に従う必要があります。
The client will know what URI to use based on the naming conventions described by the application usage.
クライアントは、URIはアプリケーションの使用状況によって記述の命名規則に基づいて使用することを知っています。
If the document, after modification, does not meet the data constraints, the server will reject it with a 409. The 409 response may contain an XML body, formatted according to the schema in Section 11.2, which provides further information on the nature of the error. The client MAY use this information to try and alter the request so that, this time, it might succeed. The client SHOULD NOT simply retry the request without changing some aspect of it.
文書は、変更後に、データの制約を満たしていない場合、サーバーは409応答がの性質に関する更なる情報を提供して11.2節のスキーマに従ってフォーマットされた、XML本体を含むことが409でそれを拒否しますエラー。クライアントがそのように要求を試してみて、変更するためにこの情報を使用することができるが、この時、それが成功する可能性があります。クライアントは、単にそれのいくつかの側面を変更することなく、要求を再試行すべきではありません。
In some cases, the application usage will dictate a uniqueness constraint that the client cannot guarantee on its own. One such example is that a URI has to be unique within a domain. Typically, the client is not the owner of the domain, and so it cannot be sure that a URI is unique. In such a case, the client can either generate a sufficiently random identifier, or it can pick a "vanity" identifier in the hopes that it is not taken. In either case, if the identifier is not unique, the server will reject the request with a 409 and suggest alternatives that the client can use to try again. If the server does not suggest alternatives, the client SHOULD attempt to use random identifiers with increasing amounts of randomness.
いくつかのケースでは、アプリケーションの使用状況は、クライアントが独自に保証することはできません一意性制約を決定します。その一例は、URIは、ドメイン内で一意でなければならないことです。通常、クライアントは、ドメインの所有者ではない、そしてURIが一意であることを確認することはできません。このような場合、クライアントは十分にランダムな識別子を生成するか、またはそれが取られていないことを期待して「虚栄心」の識別子を選ぶことができます。識別子が一意でない場合はいずれの場合も、サーバは409で要求を拒否し、クライアントが再試行してくださいするために使用できる代替案を提案します。サーバは選択肢を示唆していない場合、クライアントはランダム性の量が増加すると、ランダムな識別子を使用しようとすべきです。
HTTP also specifies that PUT and DELETE requests are idempotent. This means that, if the client performs a PUT on a document and it succeeds, it can perform the same PUT, and the resulting document will look the same. Similarly, when a client performs a DELETE, if it succeeds, a subsequent DELETE to the same URI will generate a 404; the resource no longer exists on the server since it was deleted by the previous DELETE operation. To maintain this property, the client SHOULD construct its URIs such that, after the modification has taken place, the URI in the request will point to the resource just inserted for PUT (i.e., the body of the request), and will point to nothing for DELETE. If this property is maintained, it is the case that GET to the URI in the PUT will return the same content (i.e., GET(PUT(X)) == x). This property implies idempotency. Although a request can still be idempotent if it does not possess this property, XCAP does not permit such requests. If the client's request does not have this property, the server will reject the request with a 409 and indicate a cannot-insert error condition.
HTTPはまた、要求が冪等されPUTやDELETEのように指定します。これにより、クライアントは、ドキュメント上のPUTを実行し、それが成功した場合、それは同じPUTを実行することができることを意味し、そして得られた文書は同じように見えます。クライアントは、DELETEを実行するとき、それが成功した場合、同様に、同じURIにDELETE後続404を生成します。それは前回のDELETE操作によって削除されましたので、リソースは、もはやサーバー上に存在していません。この特性を維持するために、クライアントは、変更が行われた後、リクエストURI内だけでPUT（すなわち、リクエストのボディ）のために挿入されたリソースを指すようになりますように、というそのURIを構築すべきである、と何を指すようになりますDELETEのため。このプロパティが維持されている場合は、同じコンテンツが返されるPUTにURIに着く場合（すなわち、GET（PUT（X））== x）です。このプロパティは、冪等を意味します。それは、このプロパティを持たない場合、要求はまだ冪等することができますが、XCAPは、このような要求を許可しません。クライアントの要求は、このプロパティを持っていない場合、サーバーは409で、要求を拒否し、缶のインサートないエラー状態を示します。
If the result of the PUT is a 200 or 201 response, the operation was successful. Other response codes to any request, such as a redirection, are processed as per RFC 2616 [6].
PUTの結果は、200または201応答である場合、操作は成功しました。そのようなリダイレクションのような任意の要求に対する他のレスポンスコードは、RFC 2616に従って処理される[6]。
To create or replace a document, the client constructs a URI that references the location where the document is to be placed. This URI MUST be a document URI, and therefore contain the XCAP root and document selector. The client then invokes a PUT method on that URI.
ドキュメントを作成または置換するには、クライアントが文書を配置する場所を参照するURIを構築します。このURIは、文書URIであり、したがって、XCAPルートと文書選択を含まなければなりません。クライアントはそのURI上のPUTメソッドを呼び出します。
The MIME content type MUST be the type defined by the application usage. For example, it would be "application/rls-services+xml" for an RLS services [22] document, and not "application/xml".
MIMEコンテンツタイプは、アプリケーション用法で定義されたタイプでなければなりません。例えば、RLSサービス[22]文書ではなく、「アプリケーション/ XML」の「アプリケーション/ RLS-サービスは+ xml」であろう。
If the Request-URI identifies a document that already exists in the server, the PUT operation replaces that document with the content of the request. If the Request-URI does not identify an existing document, the document is created on the server at that specific URI.
要求URIが既にサーバーに存在する文書を識別する場合、PUT操作は要求の内容と、その文書を置き換えます。リクエスト-URIが既存のドキュメントを識別しない場合は、文書はその特定のURIのサーバ上に作成されます。
To delete a document, the client constructs a URI that references the document to be deleted. This URI MUST be a document URI. The client then invokes a DELETE operation on the URI to delete the document.
文書を削除するには、クライアントは、削除する文書を参照するURIを構築します。このURIは、文書URIでなければなりません。その後、クライアントは、文書を削除するには、URIにDELETE操作を呼び出します。
As one would expect, fetching a document is trivially accomplished by performing an HTTP GET request with the Request URI set to the document URI.
予想されるように、ドキュメントをフェッチすることは些細なURIは、文書URIに設定リクエストとHTTP GET要求を実行することによって達成されます。
To create or replace an XML element within an existing document, the client constructs a URI whose document selector points to the document to be modified. The node selector MUST be present in the URI, delimited from the document selector with the node selector separator. The query component MUST be present if the node selector makes use of namespace prefixes, in which case, the xmlns() expressions in the query component MUST define those prefixes. To create this element within the document, the node selector is constructed such that it is a no-match against the current document, but if the element in the body of the request was added to the document as desired by the client, the node selector would select that element. To replace an element in the document, the node selector is constructed so that it is a match against the element in the current document to be replaced, as well as a match to the new element (present in the body of the PUT request) that is to replace it.
既存のドキュメント内のXML要素を作成または置換するには、クライアントは、その文書セレクタポイント文書に修正するURIを構築します。ノードセレクタは、ノードセレクタセパレータドキュメントセレクタから区切られたURIに存在していなければなりません。ノードセレクタは、クエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。文書内のこの要素を作成するために、ノードセレクタは、それが現在の文書に対してはマッチしないが、リクエストのボディの要素がドキュメントに追加された場合、クライアント、ノード選択によって所望のようにように構成されていますその要素を選択することになります。それを交換する現在のドキュメント内の要素に対する一致、並びに（PUT要求の体内に存在する）新しい要素に一致するように、文書内の要素を交換するために、ノードセレクタが構築されますそれを交換することです。
Oftentimes, the client will wish to insert an element into a document in a certain position relative to other children of the same parent. This is called a positional insertion. They often arise because the schema constrains where the element can occur, or because ordering of elements is significant within the schema. To accomplish this, the client can use a node selector of the following form:
多くの場合、クライアントは、同じ親の他の子に一定の位置に文書に要素を挿入したいでしょう。これは、位置の挿入と呼ばれています。要素が発生する可能性がどこスキーマを制約するので、または要素の順序は、スキーマ内で重要であるので、彼らはしばしば発生します。これを実現するために、クライアントは次の形式のノードセレクタを使用することができます。
parent/*[position][unique-attribute-value]
Here, "parent" is an expression for the parent of the element to be inserted. "position" is the position amongst the existing child elements of this parent where the new element is to be inserted. "unique-attribute-value" is an attribute name and value for the element to be inserted, which is different from the current element in "position". The second predicate is needed so that the overall expression is a no-match when evaluated against the current children. Otherwise, the PUT would replace the existing element in that position. Note that in addition to wildcard "*" a QName can also be used as a node test. The insert logic is described in more detail in Section 8.2.3.
ここで、「親は」挿入する要素の親のための表現です。 「位置」は、新しい要素を挿入する、この親の既存の子要素の中での位置です。 「ユニークな属性値は」「位置」に現在の要素とは異なる要素を挿入するための属性名と値です。現在の子どもたちに対して評価する場合、全体的な表現は全くマッチしないように2番目の述部が必要とされています。そうでなければ、PUTは、その位置にある既存の要素を置き換えます。 QNameがノードテストとしても使用することができる「*」以外にワイルドカードすることに留意されたいです。挿入ロジックは、8.2.3項で詳細に記載されています。
Consider the example document in Figure 3. The client would like to
insert a new <watcher> element as the second element underneath
<watcher-list>. However, it cannot just PUT to a URI with the
watcherinfo/watcher-list/*[2] node selector; this node selector would
select the existing second child element of <watcher-list> and
replace it. Thus, the PUT has to be made to a URI with watcherinfo/
watcher-list/*[2][@id="hhggff"] as the node selector, where "hhggff"
is the value of the "id" attribute of the new element to be inserted.
This node-selector is a no-match against the current document, and
would be a match against the new element if it was inserted as the
second child element of <watcher-list>.
The "*" indicates that all element children of <watcher-info> are to be considered when computing the position for insertion. If, instead of a wildcard *, an element name (QName) was present, the expression above would insert the new element as the position-th element amongst those with the same expanded name (see Section 8.2.3 for a discussion on insertion rules).
「*」を挿入するための位置を計算するとき、<ウォッチャー-info>の子要素すべてが考慮されるようにしていることを示しています。代わりにワイルドカード*、要素名（QNameが）存在し、場合、上記式は同じ拡張名を有するものの中で位置番目の要素として新しい要素を挿入する（挿入規則に関する議論については、セクション8.2.3を参照してください）。
Once the client constructs the URI, it invokes the HTTP PUT method. The content in the request MUST be an XML element. Specifically, it contains the element, starting with the opening bracket for the begin tag for that element, including the attributes and content of that element (whether it be text or other child elements), and ending with the closing bracket for the end tag for that element. The MIME type in the request MUST be "application/xcap-el+xml", defined in Section 15.2.1. If the node selector, when evaluated against the current document, results in a no-match, the server performs a creation operation. If the node selector, when evaluated against the current document, is a match for an element in the current document, the server replaces it with the content of the PUT request. This replacement is complete; that is, the old element (including its attributes, namespace declarations and content: text, element, comment and processing instruction nodes) are removed, and the new one, including its attributes, namespace declarations and content, is put in its place.
クライアントはURIを構築したら、それはHTTPのPUTメソッドを呼び出します。要求の内容は、XML要素でなければなりません。具体的には、属性とその元素の含有量（それはテキストまたは他の子要素であるかどうか）を含め、その要素のタグを開始するための開口ブラケットで始まる要素を含み、の終了タグの閉じ括弧で終わりますその要素。要求にMIMEタイプは、セクション15.2.1に定義された「アプリケーション/ XCAP-EL + XML」でなければなりません。現在のドキュメントに対して評価する際ノードセレクタは、不一致が生じる場合、サーバは、作成動作を行います。現在のドキュメントに対して評価する際ノードセレクタは、現在のドキュメント内の要素の一致である場合、サーバは、PUT要求の内容に置き換えます。この交換は完了です。つまり、（その属性、名前空間宣言およびコンテンツを含む：テキスト、要素、コメントおよび処理命令ノード）古い要素が除去され、その属性、名前空間宣言およびコンテンツを含む新しいものは、その場所に置かれています。
To be certain that element insertions have the GET(PUT(x))==x property, the client can check that the attribute predicates in the final path segment of the URI match the attributes of the element in the body of the request. As an example of a request that would not have this property, and therefore would not be idempotent, consider the following PUT request (URIs are line-folded for readability):
その要素の挿入がGET（PUT（X））== X特性を有する特定的には、クライアントは、属性は、要求の本体内の要素の属性に一致するURIの最終パスセグメントに述することを確認することができます。このプロパティを持っていないので、冪等されない要求の例として、以下のPUTリクエストを（URIは、ライン折り畳ま読みやすくするためです）考えてみます。
PUT /rls-services/users/sip:bill@example.com/index/~~/rls-services/ service%5b@uri=%22sip:good-friends@example.com%22%5d HTTP/1.1 Content-Type:application/xcap-el+xml Host: xcap.example.com
good-friends@example.com%22%5d HTTP / 1.1のContent：/rls-services/users/sip:bill@example.com/index/サービス％5bは、@ URI =％22sipをPUTタイプ：application / XCAP-EL + XMLホスト：xcap.example.com
<service uri="sip:mybuddies@example.com"> <resource-list>http://xcap.example.com/resource-lists/users /sip:joe@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%5d </resource-list> <packages> <package>presence</package> </packages> </service>
<サービスのURI = "SIP：mybuddies@example.com"> <リソース・リスト> http://xcap.example.com/resource-lists/users /sip:joe@example.com/index/リスト/リスト名@％5bは=％22L1％22％5dと</リソース・リスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス>
This request will fail with a 409. The Request URI contains a final path segment with a predicate based on attributes: @uri="sip:good-friends@example.com". However, this will not match the value of the "uri" attribute in the element in the body (sip:mybuddies@example.com).
@ URI =「SIP：good-friends@example.com」この要求は、URIが属性に基づいて述語との最終パスセグメントが含まれている409の要求に失敗します。しかし、これは、体内の要素で「URI」属性（：mybuddies@example.com SIP）の値と一致しません。
The GET(PUT(x))==x property introduces some limitations on the types of operations possible. It will not be possible to replace an element with one that has a new value for an attribute that is the sole unique element identifier, if the URI contained a node selector that was using the previous value of that attribute for purposes of selecting the element. This is exactly the use case in the example above. To get around this limitation, the selection can be done by position instead of attribute value, or the parent of the element to be replaced can be selected, and then the body of the PUT operation would contain the parent, the child to be replaced, and all other siblings.
GET（PUT（X））は== Xプロパティは、可能な操作の種類にいくつかの制限を導入します。 URIの要素を選択する目的のためにその属性の前の値を使用していたノードセレクタが含まれている場合、唯一のユニークな要素識別子である属性の新しい値を持つものとエレメントを交換することはできません。これはまさに上記の例のユースケースです。この制限を回避するために、選択ではなく、属性値の位置で行うことができ、または交換される要素の親を選択することができ、その後、PUT操作の体が親を含むことになり、子供を交換します、他のすべての兄弟。
To delete an element from a document, the client constructs a URI whose document selector points to the document containing the element to be deleted. The node selector MUST identify a single element. The node selector MUST be present following the node selector separator, and identify the specific element to be deleted. Furthermore, the node selector MUST match no element after the deletion of the target element. This is required to maintain the idempotency property of HTTP deletions. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
文書から要素を削除するには、クライアントが削除される要素を含む文書を、その文書セレクタポイントURIを構築します。ノードセレクタは、単一の要素を識別しなければなりません。ノードセレクタは、ノードセレクタセパレータ以下存在すること、および削除する特定の要素を識別しなければなりません。また、ノードセレクタは、ターゲット要素の削除後には要素と一致してはなりません。これは、HTTPの削除の冪等の特性を維持するために必要とされます。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
If the client wishes to delete an element in a specific position, this is referred to as a positional deletion. Like a positional insertion, the node selector has the following form:
クライアントが特定の位置にある要素を削除したい場合は、これは、位置削除と呼ばれています。位置挿入のような、ノードセレクタは、次の形式を有します。
parent/*[position][unique-attribute-value]
Where "parent" is an expression for the parent of the element to be deleted, "position" is the position of the element to be deleted amongst the existing child elements of this parent, and "unique-attribute-value" is an attribute name and value for the element to be deleted, where this attribute name and value are different than any of the siblings of the element.
「親」が削除される要素の親のための表現で、「位置」は、この親の既存の子要素の中で、削除する要素の位置であり、「ユニークな属性値は、」属性名です要素の値は、この属性名と値が要素の兄弟のいずれよりも異なっている場合は、削除します。
Positional deletions without using a unique attribute name and value
are possible, but only in limited cases where idempotency is
guaranteed. In particular, if a DELETE operation refers to an
element by name and position alone (parent/elname[n]), this is
permitted only when the element to be deleted is the last element
amongst all its siblings with that name. Similarly, if a DELETE
operation refers to an element by position alone (parent/*[n]), this
is permitted only when the element to be deleted is the last amongst
all sibling elements, regardless of name.
The client then invokes the HTTP DELETE method. The server will remove the element from the document (including its attributes, namespace declarations, and its descendant nodes, such as any children).
クライアントは、HTTP DELETEメソッドを呼び出します。サーバーは、（任意の子としてその属性、名前空間宣言、およびその子孫ノードを含む）文書から要素を削除します。
To fetch an element of a document, the client constructs a URI whose document selector points to the document containing the element to be fetched. The node selector MUST be present following the node selector separator, and must identify the element to be fetched. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
文書の要素を取得するために、クライアントがフェッチされる要素を含む文書を、その文書セレクタポイントURIを構築します。ノードセレクタは、ノードセレクタセパレータ以下存在していなければなりません、そしてフェッチする要素を識別しなければなりません。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
The client then invokes the GET method. The 200 OK response will contain that XML element. Specifically, it contains the content of the XML document, starting with the opening bracket for the begin tag for that element, and ending with the closing bracket for the end tag for that element. This will, as a result, include all attributes, namespace declarations and descendant nodes: elements, comments, text, and processing instructions of that element.
その後、クライアントは、GETメソッドを呼び出します。 200 OK応答は、そのXML要素が含まれます。具体的には、その要素の開始タグの開口ブラケット始まる、XML文書の内容を含んでおり、その要素の終了タグの閉じ括弧で終わります。要素、コメント、テキスト、およびその要素の処理命令：これは、結果として、すべての属性、名前空間宣言と子孫ノードが含まれます。
To create or replace an attribute in an existing element of a document, the client constructs a URI whose document selector points to the document to be modified. The node selector, following the node selector separator, MUST be present. The node selector MUST be constructed such that, if the attribute was created or replaced as desired, the node selector would select that attribute. If the node selector, when evaluated against the current document, results in a no-match, it is a creation operation. If it matches an existing attribute, it is a replacement operation. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
文書の既存の要素に属性を作成または置換するには、クライアントは、その文書セレクタポイント文書に修正するURIを構築します。ノードセレクタは、ノードセレクタセパレータ以下、存在しなければなりません。ノードセレクタは、必要に応じて属性が作成または置換された場合、ノードセレクタがその属性を選択する、ように構成されなければなりません。現在のドキュメントに対して評価する際ノードセレクタは、不一致が生じる場合には、作成操作です。それは既存の属性に一致する場合、それは、交換作業です。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
The client then invokes the HTTP PUT method. The content defined by the request MUST be the value of the attribute, compliant to the grammar for AttValue as defined in XML 1.0 [1]. Note that, unlike when AttValue is present in the URI, there is no percent-encoding of the body. This request MUST be sent with the Content-Type of "application/xcap-att+xml" as defined in Section 15.2.2. The server will add the attribute such that, if the node selector is evaluated on the resulting document, it will return the attribute present in the request.
次に、クライアントは、HTTPのPUTメソッドを呼び出します。 XML 1.0で定義されるように要求することによって定義されたコンテンツは、[1] ATTVALUEための文法に準拠した属性の値でなければなりません。なお、ATTVALUEはURI中に存在する場合とは異なり、身体のいかなるパーセントエンコーディングは存在しません。 15.2.2項で定義されている。この要求は、「アプリケーション/ XCAP-ATT + XML」のコンテンツタイプを送らなければなりません。サーバは、ノードセレクタが得られた文書上で評価されている場合、それはリクエスト中に存在する属性が返されるよう、こと属性を追加します。
To be certain that attribute insertions have the GET(PUT(x))==x property, the client can check that any attribute predicate in the path segment that selects the element into which the attribute is inserted, matches a different attribute than the one being inserted by the request. As an example of a request that would not have this property, and therefore would not be idempotent, consider the following PUT request (URIs are line-folded for readability):
属性の挿入がGET（PUT（X））== X性質を持っていることを確実にするために、クライアントは、属性が挿入される要素を選択するパスセグメント内の任意の属性述語は、とは異なる属性と一致することを確認することができ要求によって挿入されます。このプロパティを持っていないので、冪等されない要求の例として、以下のPUTリクエストを（URIは、ライン折り畳ま読みやすくするためです）考えてみます。
PUT /rls-services/users/sip:bill@example.com/index/~~/rls-services /service%5b@uri=%22sip:good-friends@example.com%22%5d/@uri HTTP/1.1 Content-Type:application/xcap-att+xml Host: xcap.example.com
PUT /rls-services/users/sip:bill@example.com/index/ /service%5b@uri=%22sip:good-friends@example.com%22%5d/@uri HTTP / 1.1のContent-Type：アプリケーション/ XCAP-ATT + XMLホスト：xcap.example.com
"sip:bad-friends@example.com"
"SIP：bad-friends@example.com"
This request will fail with a 409.
この要求は409で失敗します。
As with element insertions and replacements, the GET(PUT(x))==x property introduces limitations on attribute replacements. It will not be possible to replace the attribute value of an attribute, when that attribute is the sole unique element identifier, and the URI contains a node selector that uses the previous value of the attribute to select the affected element. This is the use case in the example above. Instead, the element can be selected positionally, or its entire parent replaced.
要素の挿入や交換、GET（PUT（x））を持つよう== Xプロパティは、属性の交換に制限を導入しています。その属性が唯一のユニークな要素の識別子であり、URIが影響を受けた要素を選択するために、属性の前の値を使用してノードセレクタが含まれている場合、属性の属性値を交換することはできません。これは、上記の例のユースケースです。代わりに、要素は、位置的に選択することができ、またはその全体の親を交換します。
To delete an attribute from the document, the client constructs a URI whose document selector points to the document containing the attribute to be deleted. The node selector MUST be present following the node selector separator, and evaluate to an attribute in the document to be deleted. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
文書から属性を削除するには、クライアントは、削除する属性を含むドキュメントにそのドキュメントセレクタポイントURIを構築します。ノードセレクタは、ノードセレクタセパレータ以下存在すること、および削除する文書に記載されている属性に評価されなければなりません。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
The client then invokes the HTTP DELETE method. The server will remove the attribute from the document.
クライアントは、HTTP DELETEメソッドを呼び出します。サーバは、文書から属性を削除します。
To fetch an attribute of a document, the client constructs a URI whose document selector points to the document containing the attribute to be fetched. The node selector MUST be present following the node selector separator, containing an expression identifying the attribute whose value is to be fetched. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
文書の属性を取得するために、クライアントがフェッチされる属性を含む文書にその文書セレクタポイントURIを構築します。ノードセレクタは、値フェッチする属性を識別式を含む、ノードセレクタセパレータ以下存在していなければなりません。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
The client then invokes the GET method. The 200 OK response will contain an "application/xcap-att+xml" document with the specified attribute, formatted according to the grammar of AttValue as defined in the XML 1.0 specifications.
その後、クライアントは、GETメソッドを呼び出します。 200 OK応答は、XML 1.0仕様で定義されているようATTVALUEの文法に従ってフォーマット指定された属性と「アプリケーション/ XCAP-ATT + XML」のドキュメントが含まれます。
If a client wishes to insert an element or attribute into a document, and that element or attribute is part of a namespace declared elsewhere in the document, the client will need to know the namespace bindings in order to construct the XML content in the request. If the client has a cached copy of the document, it will know the bindings. However, if it doesn't have the whole document cached, it can be useful to fetch just the bindings that are in scope for an element, in order to construct a subsequent PUT request.
クライアントが文書に要素や属性を挿入することを希望し、その要素や属性が文書内の別の場所で宣言された名前空間の一部である場合、クライアントはリクエストでXMLコンテンツを構築するためには、名前空間バインディングを知っておく必要があります。クライアントは、ドキュメントのキャッシュされたコピーを持っている場合、それは、バインディングを知っています。それは文書全体をキャッシュしていない場合は、それ以降のPUTリクエストを構築するために、要素の範囲内にあるだけのバインディングを取得するために役立ちます。
To get those bindings, the client constructs a URI whose document selector points to the document containing the element whose namespace bindings are to be fetched. The node selector MUST be present following the node selector separator, containing an expression identifying the desired namespace bindings. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
これらのバインディングを取得するには、クライアントは、名前空間バインディングフェッチされることになる要素を含むドキュメントにそのドキュメントセレクタポイントURIを構築します。ノードセレクタは、所望の名前空間バインディングを識別する式を含む、ノードセレクタセパレータ以下存在していなければなりません。ノードセレクタがクエリコンポーネント内のxmlns（）式はこれらのプレフィックスを定義しなければならない場合には名前空間接頭辞の使用を行う場合、クエリコンポーネントが存在しなければなりません。
The client then invokes the GET method. The 200 OK response will contain an "application/xcap-ns+xml" document with the namespace definitions. The format for this document is defined in Section 10.
その後、クライアントは、GETメソッドを呼び出します。 200 OK応答は、名前空間の定義を「アプリケーション/ XCAP-NS + XML」のドキュメントが含まれます。この文書のフォーマットは、セクション10で定義されています。
A client cannot set the namespace prefixes in scope for an element. As such, a node selector that identifies namespace prefixes MUST NOT appear in a PUT or DELETE request.
クライアントは、要素のスコープ内の名前空間接頭辞を設定することはできません。このように、名前空間接頭辞を識別するノードセレクタは、PUTに表示されるか、要求を削除してはなりません。
The HTTP specification defines several header fields that can be used by a client to make the processing of the request conditional. In particular, the If-None-Match and If-Match header fields allow a client to make them conditional on the current value of the entity tag for the resource. These conditional operations are particularly useful for XCAP resources.
HTTP仕様は、条件付きリクエストの処理を行うためにクライアントによって使用され得るいくつかのヘッダーフィールドを定義します。特に、もし-なしマッチとIF-Matchヘッダフィールドは、クライアントがリソースのエンティティタグの現在の値にそれらを条件付きにすることができます。これらの条件の操作は、XCAPリソースのために特に有用です。
For example, it is anticipated that clients will frequently wish to cache the current version of a document. So, when the client starts up, it will fetch the current document from the server and store it.
例えば、クライアントが頻繁に文書の現在のバージョンをキャッシュしたくなることが予想されます。クライアントが起動するときに、それがサーバーから現在のドキュメントを取得し、それを格納します。
When it does so, the GET response will contain the entity tag for the document resource. Each resource within a document maintained by the server will share the same value of the entity tag. As a result, the entity tag returned by the server for the document resource is applicable to element and attribute resources within the document.
それはそうすると、GET応答は、文書リソースのエンティティタグが含まれています。サーバによって維持文書内の各リソースは、エンティティタグの同じ値を共有します。その結果、文書のリソースのためのサーバから返されたエンティティタグは、ドキュメント内の要素と属性のリソースに適用されます。
If the client wishes to insert or modify an element or attribute within the document, but it wants to be certain that the document hasn't been modified since the client last operated on it, it can include an If-Match header field in the request, containing the value of the entity tag known to the client for all resources within the document. If the document has changed, the server will reject this request with a 412 response. In that case, the client will need to flush its cached version, fetch the entire document, and store the new entity tag returned by the server in the 200 OK to the GET request. It can then retry the request, placing the new entity tag in the If-Match header field. If this succeeds, the Etag header field in the response to PUT contains the entity tag for the resource that was just inserted or modified. Because all resources in a document share the same value for their entity tag, this entity tag value can be applied to the modification of other resources.
クライアントは、文書内の要素または属性を挿入または変更したいが、それは、クライアントが最後に上で動作するので、それはリクエストにIf-Matchヘッダフィールドを含めることができ、ドキュメントが変更されていないことを確信することを希望する場合、ドキュメント内のすべてのリソースのためにクライアントに知られているエンティティタグの値を含みます。ドキュメントが変更された場合、サーバは412応答でこの要求を拒否します。その場合、クライアントは、そのキャッシュされたバージョンをフラッシュし、文書全体をフェッチし、GETリクエストに200 OKで、サーバから返された新しいエンティティタグを格納する必要があります。その後、If-Matchヘッダフィールドに新しいエンティティタグを配置し、要求を再試行することができます。これが成功した場合、PUTに応答したEtagヘッダフィールドだけ挿入または変更されたリソースのエンティティタグを含みます。ドキュメント内のすべてのリソースがそのエンティティタグに同じ値を共有しているので、このエンティティタグの値は、他のリソースの変更にも適用することができます。
A client can also conditionally delete elements or attributes by including an If-Match header field in DELETE requests. Note that the 200 OK responses to a DELETE will contain an Etag header field, containing the entity tag for all of the other resources in the document, even though the resource identified by the DELETE request no longer exists.
また、クライアントは条件付きDELETEリクエストにIf-Matchヘッダフィールドを含めることによって、要素や属性を削除することができます。削除する200のOK応答は、DELETEリクエストによって識別されたリソースがもはや存在していても、文書内の他のすべてのリソースのためのエンティティタグを含む、たEtagヘッダフィールドを含まないことに注意してください。
When a client uses conditional PUT and DELETE operations, it can apply those changes to its local cached copy, and update the value of the entity tag for the locally cached copy based on the Etag header field returned in the response. As long as no other clients try to modify the document, the client will be able to perform conditional operations on the document without ever having to perform separate GET operations to synchronize the document and its entity tags with the server. If another client tries to modify the document, this will be detected by the conditional mechanisms, and the client will need to perform a GET to resynchronize its copy unless it has some other means to learn about the change.
クライアントが条件付きPUTを使用して、操作を削除すると、それは、ローカルにキャッシュされたコピーにそれらの変更を適用し、それに応答して返されたEtagヘッダフィールドに基づいて、ローカルにキャッシュされたコピーのエンティティタグの値を更新することができます。限り、他のクライアントがドキュメントを変更しようとしないように、クライアントはこれまでサーバと文書とそのエンティティタグを同期するために別々のGET操作を実行することなく、ドキュメントに条件付きの操作を実行することができるようになります。別のクライアントがドキュメントを変更しようとすると、これは条件付きのメカニズムによって検出され、それが変更について学ぶためにいくつかの他の手段を持っていない限り、クライアントはそのコピーを再同期するためにGETを実行する必要があります。
If a client does not perform a conditional operation, but did have a cached copy of the document, that cached copy will become invalid once the operation is performed (indeed, it may have become invalid even beforehand). Unconditional operations should only be performed by clients when knowledge of the entire document is not important for the operation to succeed.
クライアントが条件付きの操作を実行しますが、ドキュメントのキャッシュされたコピーを持っていたしない場合は、操作が実行されると、そのキャッシュされたコピーは、（確かに、それも事前に無効になっている場合があります）無効となります。文書全体の知識は操作が成功するために重要でない場合無条件の操作はクライアントのみが行ってください。
As another example, a when a client fetches a document, and there is an older version cached, it is useful for clients to use a conditional GET in order to reduce network usage if the cached copy is still valid. This is done by including, in the GET request, the If-None-Match header field with a value equal to the current etag held by the client for the document. The server will only generate a 200 OK response if the etag held by the server differs than that held by the client. If it doesn't differ, the server will respond with a 304 response.
クライアントがドキュメントをフェッチし、キャッシュされた古いバージョンがあるときにキャッシュされたコピーがまだ有効である場合、クライアントがネットワークの使用を削減するために、条件付きGETを使用するために別の例として、それは便利です。これは、GETリクエスト、ドキュメントのためにクライアントによって保持された現在のETagと等しい値を持つIf-None-Matchヘッダフィールドに含めることによって行われます。サーバーが保持したETagは、クライアントが保持しているよりも異なっている場合、サーバは200 OK応答を生成します。それは異なっていない場合、サーバーは304応答で応答します。
An XCAP server is an HTTP/1.1 compliant origin server. The behaviors mandated by this specification relate to the way in which the HTTP URI is interpreted and the content is constructed.
XCAPサーバーは、HTTP / 1.1に準拠しオリジンサーバです。この仕様で義務動作はHTTP URIが解釈され、コンテンツが構築される方法に関する。
An XCAP server MUST be explicitly aware of the application usage against which requests are being made. That is, the server must be explicitly configured to handle URIs for each specific application usage, and must be aware of the constraints imposed by that application usage.
XCAPサーバーは、要求が行われている、それに対してアプリケーションの使用状況の明示的に認識する必要があります。これは、サーバが明示的に、各特定のアプリケーションを使用するためのURIを処理するように設定する必要がありますされており、そのアプリケーションの使用状況による制約を認識する必要があります。
When the server receives a request, the treatment depends on the URI. If the URI refers to an application usage not understood by the server, the server MUST reject the request with a 404 (Not Found) response. If the URI refers to a user (identified by an XUI) that is not recognized by the server, it MUST reject the request with a 404 (Not Found). If the URI includes extension-selectors that the server doesn't understand, it MUST reject the request with a 404 (Not Found).
サーバーが要求を受信した場合、治療は、URIに依存します。 URIは、サーバによって理解されていないアプリケーションの使用状況を参照する場合、サーバは404（見つかりません）応答で要求を拒絶しなければなりません。 URIは、サーバによって認識されない（XUIによって識別される）ユーザを参照する場合、それは404（見つかりません）で要求を拒絶しなければなりません。 URIがサーバが理解していない拡張子-セレクタが含まれている場合、それは404（見つかりません）で、要求を拒絶しなければなりません。
Next, the server authenticates the request. All XCAP servers MUST implement HTTP Digest [11]. Furthermore, servers MUST implement HTTP over TLS, RFC 2818 [14]. It is RECOMMENDED that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication occurs over TLS.
次に、サーバは要求を認証します。すべてのXCAPサーバは、HTTPダイジェスト[11]を実装しなければなりません。さらに、サーバがTLS上でHTTPを実装しなければならない、RFC 2818 [14]。ダイジェストクライアント認証がTLS上で行われるように、管理者は、XCAPルートURIとしてHTTPS URIを使用することをお勧めします。
Next, the server determines if the client has authorization to perform the requested operation on the resource. The application usage defines the authorization policies. An application usage may specify that the default is used. This default is described in Section 5.7.
クライアントがリソースに対して要求された操作を実行する権限を持っている場合次に、サーバが決定します。アプリケーションの使用は許可ポリシーを定義します。アプリケーションの使用状況は、デフォルトが使用されていることを指定してもよいです。このデフォルトは、セクション5.7に記載されています。
Next, the server makes sure that it can properly evaluate the request URI. The server MUST separate the document selector from the node selector, by splitting the URI at the first instance of the node selector separator ("~~"). The server MUST check the node selector in the request URI, if present. If any qualified names are present that use a namespace prefix, and that prefix is not defined in an xmlns() expression in the query component of the request URI, the server MUST reject the request with a 400 response.
次に、サーバは、それが適切にリクエストURIを評価できることを確認します。サーバは、ノードセレクタセパレータ（「~~」）の最初のインスタンスでURIを分割することによって、ノードセレクタから文書セレクタを分離しなければなりません。存在する場合、サーバは、リクエストURI内のノードセレクタをチェックしなければなりません。任意の修飾名は、名前空間接頭辞を使用すること存在し、その接頭辞は、要求URIのクエリコンポーネント内のxmlns（）式で定義されていない場合、サーバは400応答で要求を拒絶しなければなりません。
After checking the namespace prefix definitions, the specific behavior depends on the method and what the URI refers to.
名前空間接頭辞の定義を確認した後、具体的な行動は法とどのようなURIが参照によって異なります。
XCAP resources do not represent processing scripts. As a result, POST operations to HTTP URIs representing XCAP resources are not defined. A server receiving such a request for an XCAP resource SHOULD return a 405.
XCAPリソースは、処理スクリプトを表すものではありません。結果として、XCAPリソースを表すHTTP URIにPOST操作が定義されていません。 XCAPリソースのような要求を受信したサーバ405を返すべきです。
The behavior of a server in receipt of a PUT request is as specified in HTTP/1.1, Section 9.6 -- the content of the request is placed at the specified location. This section serves to define the notion of "placement" and "specified location" within the context of XCAP resources.
HTTP / 1.1、9.6節で指定されるようにPUT要求を受信したサーバの動作は、 - 要求の内容は、指定された場所に配置されています。このセクションでは、XCAPリソースのコンテキスト内で「配置」と「指定された場所」の概念を定義するのに役立ちます。
If the request URI contained a namespace-selector, the server MUST reject the request with a 405 (Method Not Allowed) and MUST include an Allow header field including the GET method.
リクエストURIが名前空間セレクタが含まれている場合、サーバは405（方法不可）で要求を拒絶しなければなりませんし、GETメソッドを含むAllowヘッダーフィールドを含まなければなりません。
The first step the server performs is to locate the parent, whether it is a directory or element, in which the resource is to be placed. To do that, the server removes the last path segment from the URI. The rest of the URI refers to the parent. This parent can be a document, element, or prefix of a document selector (called a directory, even though this specification does not mandate that documents are actually stored in a filesystem). This URI is called the parent URI. The path segment that was removed is called the target selector, and the node (element, document, or attribute) it describes is called the target node.
サーバが実行する最初のステップは、リソースが配置されているディレクトリまたは要素があるかどうかを、親の位置を特定することです。そのためには、サーバはURIから最後のパスセグメントを削除します。 URIの残りの部分は親を指します。この親は（この仕様は、文書が実際のファイルシステムに格納されていることを義務付けていなくても、ディレクトリと呼ばれる）ドキュメントセレクタの文書、要素、またはプレフィックスことができます。このURIは、親URIと呼ばれています。削除された経路セグメントは、ターゲットセレクタと呼ばれ、それは説明ノード（要素、文書、または属性）をターゲットノードと呼ばれます。
If the parent URI has no node selector separator, it is referring to the directory into which the document should be inserted. In normal XCAP operations, this will be either the user's home directory or the global directory, which will always exist on the server. However, if an application usage is making use of subdirectories (despite the fact that this is not recommended), it is possible that the directory into which the document should be inserted does not exist. In this case, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. Detailed conflict reports are discussed in Section 11. If the directory does exist, the server checks to see if there is a document with the same filename as the target node. If there is, the operation is the replacement operation, discussed in Section 8.2.4. If it does not exist, it is the creation operation discussed in Section 8.2.3.
親URIがどのノードセレクタセパレータを有していない場合は、文書が挿入される内にディレクトリを参照しています。通常のXCAP操作では、これは常にサーバー上に存在するであろう、ユーザのホームディレクトリまたはグローバルディレクトリのいずれかになります。アプリケーションの使用状況は、（これは推奨されていないという事実にもかかわらず）のサブディレクトリを利用している場合は、その文書が挿入されるにディレクトリが存在しないことも可能です。この場合、サーバは409応答を返さなければなりません、そして、<無親>要素を含む詳細な競合レポートを含めるべきです。ディレクトリが存在しない場合は、詳細な競合レポートは、セクション11で議論され、サーバがターゲットノードと同じファイル名を持つドキュメントがあるかどうかを確認します。ある場合、操作は8.2.4項で述べた交換作業、です。それが存在しない場合は、8.2.3項で述べた作成操作です。
If the parent URI has a node selector separator, the document selector is extracted, and that document is retrieved. If the document does not exist, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. If it does exist, the node selector is extracted and decoded (recall that the node selector is percent-encoded). The node selector is applied to the document based on the matching operations discussed in Section 6.3. If the result is a no-match or invalid, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element.
親URIは、ノードセレクタセパレータを有する場合、文書セレクタは抽出され、その文書が検索されます。文書が存在しない場合、サーバーは409応答を返さなければなりません、そして<無親>要素を含む詳細な競合レポートを含めるべきです。それが存在する場合、ノードセレクタは、（ノードセレクタがパーセントエンコードされていることを思い出して）抽出して復号化されます。ノードセレクタは、セクション6.3で説明したマッチング動作に基づいて、ドキュメントに適用されます。結果は全く一致または無効でない場合、サーバーは409応答を返さなければなりません、そして<無親>要素を含む詳細な競合レポートを含めるべきです。
If the node-selector is valid, the server examines the target selector, and evaluates it within the context of the parent node. If the target node exists within the parent, the operation is a replacement, as described in Section 8.2.4. If it does not exist, it is the creation operation, discussed in Section 8.2.3.
ノードセレクタが有効な場合、サーバーは、ターゲットセレクタを調べ、親ノードのコンテキスト内で、それを評価します。ターゲットノードが親内に存在する場合は、セクション8.2.4で説明したように、動作は、予備です。それが存在しない場合は、8.2.3項で説明し、作成操作です。
Before performing the replacement or creation, as determined based on the logic above, the server validates the content of the request as described in Section 8.2.2.
セクション8.2.2に記載のように置換または作成を行う前に、上記の論理に基づいて決定されるように、サーバは、要求の内容を検証します。
If the PUT request is for a document (the request URI had no node selector separator), the content of the request body has to be a well-formed XML document. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-well-formed> element. If the document is well-formed but not UTF-8 encoded, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element. If the MIME type in the Content-Type header field of the request is not equal to the MIME type defined for the application usage, the server MUST reject the request with a 415.
PUT要求は文書（URIがどのノードセレクタセパレータを有していなかった要求）のためのものである場合、リクエストボディのコンテンツは、整形式XML文書でなければなりません。そうでない場合、サーバーは409応答コードで要求を拒絶しなければなりません。その応答は、<未整形>要素を含む詳細な競合レポートを含めるべきです。文書は整形式ではなく、UTF-8でエンコードされている場合、サーバは409応答コードとの要求を拒絶しなければなりません。その応答は、<しないUTF-8>要素を含む詳細な競合レポートを含めるべきです。リクエストのContent-TypeヘッダフィールドにMIMEタイプがアプリケーションでの使用のために定義されたMIMEタイプに等しくない場合、サーバは415で要求を拒絶しなければなりません。
If the PUT request is for an element, the content of the request body has to be a well-balanced region of an XML document, also known as an XML fragment body in The XML Fragment Interchange [23] specification, including only a single element. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-xml-frag> element. If the fragment body is well-balanced but contains characters outside of the UTF-8 character set, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element. If the MIME type in the Content-Type header field of the request is not equal to "application/xcap-el+xml", the server MUST reject the request with a 415.
PUT要求は要素のためのものである場合、リクエストボディの内容はまた、単一の要素を含むXMLフラグメント交換[23]仕様のXMLフラグメント体として知られているXML文書のバランスのとれた領域、でなければなりません。そうでない場合、サーバーは409応答コードで要求を拒絶しなければなりません。その応答は、<ない-XML-FRAG>要素を含む詳細な競合レポートを含めるべきです。フラグメントの体はバランスのとれたですが、UTF-8文字セットの外の文字が含まれている場合、サーバーは409応答コードで要求を拒絶しなければなりません。その応答は、<しないUTF-8>要素を含む詳細な競合レポートを含めるべきです。リクエストのContent-TypeヘッダフィールドにMIMEタイプが「アプリケーション/ XCAP-EL +のXML」に等しくない場合、サーバは415で要求を拒絶しなければなりません。
If the PUT request is for an attribute, the content of the request body has to be a sequence of characters that comply with the grammar for AttValue as defined above. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-xml-att-value> element. If the attribute value is valid but contains characters outside of the UTF-8 character set, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element.If the MIME type in the Content-Type header field of the request is not equal to "application/xcap-att+xml", the server MUST reject the request with a 415.
PUT要求が属性のためのものである場合、リクエストボディの含有量は、上記で定義した通りATTVALUEための文法に準拠する文字のシーケンスでなければなりません。そうでない場合、サーバーは409応答コードで要求を拒絶しなければなりません。その応答は、<未XML-ATT値>要素を含む詳細な競合レポートを含めるべきです。属性値が有効ですが、UTF-8文字セットの外の文字が含まれている場合、サーバーは409応答コードで要求を拒絶しなければなりません。その応答は、要求のContent-TypeヘッダフィールドにMIMEタイプelement.If <ないUTF-8>を含む詳細な競合レポートを含めるべきである「アプリケーション/ XCAP-ATT + XML」に等しくない場合、サーバMUST 415で要求を拒否します。
The steps in this sub-section are followed if the PUT request will result in the creation of a new document, element, or attribute.
PUT要求が新しい文書、要素、または属性が作成される場合は、このサブセクションの手順に従います。
If the PUT request is for a document, the content of the request body is placed into the directory, and its filename is associated with the target node, which is a document.
PUT要求は文書のためのものである場合、リクエストボディの内容をディレクトリに配置され、そのファイル名は文書であるターゲットノードに関連付けられています。
If the PUT request is for an element, the server inserts the content of the request body as a new child element of the parent element selected in Section 8.2.1. The insertion is done such that the request URI, when evaluated, would now point to the element that was inserted. There exist three possible ways in which new elements are positioned.
PUTリクエストは、要素のためであれば、サーバは8.2.1項で選択された親要素の新しい子要素としてリクエストボディの内容を挿入します。挿入は、リクエストURIが、評価されたとき、今挿入した要素を指すことになるように行われます。新しい要素が配置されている3つの方法が存在します。
First, if there were no other sibling elements with the same expanded name, and the insertion is not positionally constrained, the new element is inserted such that it is the last element amongst all element siblings. Furthermore, if there were comment, text, or processing instruction nodes after the former last element, they MUST occur prior to the insertion of the new element. This case occurs when one of the following are true:
そこに同じ拡張名を持つ他の兄弟要素がなかった、と挿入は位置的に制約されていない場合はまず、新しい要素は、それがすべての要素の兄弟の中で最後の要素であるように挿入されています。かつての最後の要素の後にコメント、テキスト、または処理命令ノードがあった場合はさらに、彼らは前に新しい要素の挿入を行わなければなりません。次のいずれかに該当する場合、このケースが発生します。
o The element name in the target selector is not wildcarded. There could be an attribute selector (in which case, it would have to match an attribute of the element being inserted), and the position in the target selector will either be absent or have a value of 1 (a value greater than 1 would always result in rejection of the request, since this is the first element with the given name underneath the parent).
O対象セレクタで要素名がワイルドカードではありません。常に1より（大きい値があろう属性セレクタ（その場合、それが挿入される要素の属性と一致しなければならない）とすることができる、ターゲットセレクタの位置が存在しない又は1の値を有するであろういずれかこれは親の下に指定された名前の最初の要素であるため）、要求の拒絶をもたらします。
o The element name in the target selector is wildcarded, but there are no other elements underneath the same parent. There could be an attribute selector (in which case, it would have to match an attribute of the element being inserted), and the position in the target selector will either be absent or have a value of 1 (a value greater than 1 would always result in rejection of the request, since this is the first element underneath the parent).
O対象セレクタで要素名がワイルドカードであるが、同じ親の下に他の要素が存在しません。常に1より（大きい値があろう属性セレクタ（その場合、それが挿入される要素の属性と一致しなければならない）とすることができる、ターゲットセレクタの位置が存在しない又は1の値を有するであろういずれかこれは親の下に最初の要素であるため）、要求の拒絶をもたらします。
o The element name in the target selector is wildcarded, and there are other elements underneath the same parent. However, there is an attribute selector that matches none of the attributes in the other sibling elements underneath the parent, but does match an attribute of the element to be inserted. The position in the target selector is absent.
O対象セレクタの要素名はワイルドカードであり、同じ親の下に他の要素があります。しかしながら、親の下に他の兄弟要素の属性のどれも一致しないが、挿入される要素の属性と一致しない属性セレクタがあります。ターゲットセレクタの位置が存在しません。
Secondly, if there were sibling elements with the same name already in the document, but the insertion is positionally unconstrained, the server MUST insert the element such that it is in the "earliest last" position. "Earliest last" means that the new element MUST be inserted so that there are no elements after it with the same expanded name, and for all insertion positions where this is true, it is inserted such that as many sibling nodes (element, comment, text, or processing instruction) appear after it as possible. This case occurs when the target selector is defined by a by-name or by-attr production, and there is no position indicated.
そこにすでにドキュメント内の同じ名前を持つ兄弟要素があったが、挿入が位置拘束された場合第二に、サーバーは、それが「早い最後」の位置にあるように要素を挿入しなければなりません。 「最古の最後の」新しい要素が同じ展開名を持つことの後に要素がないように挿入する必要があり、これが真であるすべての挿入位置のために、それはできるだけ多くの兄弟ノード（要素、コメントそのように挿入されていることを意味し、テキスト、または処理命令は）できるだけそれの後に表示されます。この場合、ターゲットセレクタは名前によって、またはバイATTR生産によって定義されるときに発生する、と示されない位置が存在しません。
Lastly, if the element is positionally constrained, the server MUST insert the element so that it is in the "earliest nth" position. When n>1 and NameofAny is not a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it with the same expanded name. If there are not n-1 sibling elements with the same expanded name, the request will fail. When n>1 and NameorAny is a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it, each of which can have any expanded name. If there are not n-1 sibling elements in the document, the request will fail. In both of these cases, the new element is inserted such that as many sibling nodes appear after it as possible. When n=1 and
要素が位置的に拘束されている場合、それは「早いn番目」の位置にあるように、最後に、サーバは、要素を挿入しなければなりません。 NameofAnyがワイルドカードでない場合、N> 1と同じ拡張名とその前のn-1個の兄弟要素があるように、要素が挿入されなければなりません。同じ拡張名を持つN-1兄弟要素が存在しない場合、要求は失敗します。 > 1、nおよびNameorAnyがワイルドカードである場合、任意の拡張名を有することができ、その各々はその前のn-1個の兄弟要素が存在するように、要素が挿入されなければなりません。文書中のn-1兄弟要素がない場合、要求は失敗します。これらの場合の両方において、新しい要素は、多くの兄弟ノードが可能なようにした後に現れるように挿入されています。 n = 1の場合と
NameorAny is not a wildcard, the insertion is positionally constrained when an element with the same expanded name already appears as a child of the same parent. In this case, the new element MUST appear just before the existing first element with this same expanded name. When n=1 and NameorAny is wildcarded, the insertion is positionally constrained when there is also an attribute selector that didn't match the first sibling of the parent (if it did match, or was absent, this wouldn't have been an insertion). In this case, the new element MUST appear just before all existing elements, regardless of their expanded name.
NameorAnyは同じ拡張名を持つ要素が既に同じ親の子として表示されたときに挿入が制約位置で、ワイルドカードではありません。この場合、新しい要素は、ちょうどこの同じ拡張名を持つ既存の最初の要素の前に現れなければなりません。 N = 1とNameorAnyがワイルドカードされたとき、それが一致した、または存在しない場合、これは挿入されていない（親の最初の兄弟と一致しませんでした属性セレクタがある場合、挿入は拘束位置であります）。この場合、新しい要素は関係なく、拡張名の、ちょうどすべての既存の要素の前に現れなければなりません。
In practice, this insertion logic keeps elements with the same expanded names closely together. This simplifies the application logic when the content model is described by XML schema with <sequence> rules and maxOccurs="unbounded" cardinalities, like:
実際には、この挿入ロジックは密接に一緒に同じ名前の拡大の要素を保持します。コンテンツモデルが<シーケンス>ルールとmaxOccurs =「unbounded」を基数とXMLスキーマによって記述されている場合、これは同様に、アプリケーションロジックを簡素化します。
<xs:element name="foobar"> <xs:complexType> <xs:sequence> <xs:element ref="foo" maxOccurs="unbounded" /> <xs:element ref="bar" maxOccurs="unbounded" /> </xs:sequence> </xs:complexType> </xs:element>
<XS：要素名= "foobarという"> <XS：complexTypeの> <XS：シーケンス> <XS：要素REF = "foo" というのmaxOccurs = "無制限" /> <XS：要素REF = "バー" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> </ XS：要素>
Based on this schema, the document contains some number of <foo> elements followed by some number of <bar> elements. Either <bar> or <foo> elements may easily be added without wildcards and positional constraints. Note that if "minOccurs" cardinality of <foo> element were zero and <foo> elements do not yet exist, a positional predicate with the * wildcard must be used.
このスキーマに基づいて、文書には、<バー>要素のいくつかの数字が続く<foo>の要素のいくつかの数が含まれています。いずれか<バー>または<FOO>要素は、容易に、ワイルドカードと位置制約なし添加してもよいです。 <FOO>要素の場合は「minOccurs属性」カーディナリティはゼロであり、<FOO>要素がまだ存在しない、*ワイルドカードとの位置述語が使用されなければならないことに留意されたいです。
The whole insert logic is best described by complete examples. Consider the following document:
全挿入ロジックは、最高の完全な例で説明されます。次のドキュメントを考えてみます。
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/> <!-- comment --> <el2 att="first"/> </root>
<？xml version = "1.0"？> <ルート> <electricity1へ= "最初" /> <electricity1へ= "秒" /> <！ - コメント - > <electricity2へ= "最初" /> </ルート>
A PUT request whose content is <el1 att="third"/> and whose node selector is root/el1[@att="third"] would result in the following document:
その内容</ EL1 ATT =「第三」>と、そのノードセレクタルート/ EL1ある[ATT @ =「第3」以下の文書をもたらすであるPUT要求：
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/><el1 att="third"/> <!-- comment --> <el2 att="first"/> </root>
<？xml version = "1.0"？> <ルート> <electricity1 "最初の" =へ/> <electricity1 "第二" =へ/> <electricity1 = "第3" /へ> <！ - コメント - > <electricity2 = "最初" /> </ rootに>
Notice how it has been inserted as the third <el1> element in the
document, and just before the comment and whitespace nodes. It would
have been inserted in exactly the same place if the node selector had
been root/el1[3][@att="third"] or root/*[3][@att="third"].
If the content of the request had been <el3 att="first"/> and the node selector was root/el3, it would result in the following document:
要求の内容はされていた場合、<EL3 ATT =「最初の」/>とノードセレクタがルート/ EL3であった、それは、次の文書をもたらすであろう。
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/> <!-- comment --> <el2 att="first"/> <el3 att="first"/></root>
<？xml version = "1.0"？> <ルート> <electricity1 "最初の" =へ/> <electricity1 "第二" =へ/> <！ - コメント - > <electricity2 "最初の" = /へ> <electricity3 = "最初" /> </ rootに>
A PUT request whose content is <el2 att="2"/> and whose node selector is root/el2[@att="2"] would result in the following document:
その含有量が<EL2 ATT =「2」/>と、そのノードセレクタルート/ EL2ある[ATT @ =「2」]以下の文書をもたらすPUT要求：
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/> <!-- comment --> <el2 att="first"/><el2 att="2"/> </root>
<？xml version = "1.0"？> <ルート> <electricity1 "最初の" =へ/> <electricity1 "第二" =へ/> <！ - コメント - > <electricity2 "最初の" = /へ> <electricity2 = "2" /> </ rootに>
It would have been inserted in exactly the same place if the node selector had been root/el2[2][@att="2"]. However, a selector root/ *[2][@att="2"] would result in the following document:
ノードセレクタがあった場合、それはまったく同じ場所に挿入されていたであろうルート/ EL2 [2] [ATT @ =「2」]。しかし、セレクタルート/ * [2] [ATT @ = "2"]は、以下の文書をもたらすであろう。
<?xml version="1.0"?> <root> <el1 att="first"/><el2 att="2"/> <el1 att="second"/> <!-- comment --> <el2 att="first"/> </root>
<？xml version = "1.0"？> <ルート> <electricity1へ= "最初" /> <electricity2へ= "2" /> <electricity1へ= "秒" /> <！ - コメント - > <electricity2 = "最初" /> </ rootに>
Lastly, if the node selector had been root/el2[1][@att="2"] the result would be:
最後に、[ATT =「2」@] [1]ノードセレクタがルート/ EL2であった場合、結果は次のようになります。
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/> <!-- comment --> <el2 att="2"/><el2 att="first"/> </root>
<？xml version = "1.0"？> <ルート> <electricity1 / "最初の" =に> <electricity1 "第二" = /へ> <！ - コメント - > <electricity2へ= "2" /> <electricity2 = "最初" /> </ rootに>
It is possible that the element cannot be inserted such that the request URI, when evaluated, returns the content provided in the request. Such a request is not allowed for PUT. This happens when the element in the body is not described by the expression in the target selector. An example of this case is described in Section 7.4. If this happens, the server MUST NOT perform the insertion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element. It is important to note that schema compliance does not play a role while performing the insertion. That is, the decision of where the element gets inserted is dictated entirely by the structure of the request-URI, the current document, and the rules in this specification.
要素が評価要求URIは、要求で提供されたコンテンツを返すように挿入することができない可能性があります。このような要求は、PUTのために許可されていません。体の要素がターゲットセレクタでの発現によって記述されていない場合に発生します。この場合の例は、セクション7.4に記載されています。この問題が発生した場合、サーバーは挿入を実行してはならない、と409応答で要求を拒絶しなければなりません。レスポンスのボディは、<できません-挿入>要素を含んだ詳細な競合レポートを含めるべきです。挿入を実行しながら、スキーマへの準拠が役割を果たしていないことに注意することが重要です。すなわち、素子が挿入取得する場所の決定は、リクエストURI、現在の文書、及び本明細書で規定の構造によって完全に決定されます。
If the element being inserted (or any of its children) contain namespace declarations, those declarations are retained when the element is inserted, even if those same declarations exist in a parent element after insertion. The XCAP server MUST NOT remove redundant namespace declarations or otherwise change the namespace declarations that were present in the element being inserted.
要素が挿入されている（またはその子のいずれかが）名前空間宣言が含まれている場合の要素が挿入されたとき、これらの宣言は、同じ宣言が挿入された後、親要素に存在していても、保持されます。 XCAPサーバは、冗長名前空間宣言を削除するか、そうでなければ挿入される要素に存在した名前空間宣言を変更しないでください。
If the PUT request is for an attribute, the server inserts the content of the request body as the value of the attribute. The name of the attribute is equal to the att-name from the attribute-selector in the target selector.
PUTリクエストが属性の場合、サーバーは、属性の値としてリクエストボディの内容を挿入します。属性の名前は、ターゲットセレクタにおける属性セレクタからATT名と同じです。
Assuming that the insertion can be accomplished, the server verifies that the insertion results in a document that meets the constraints of the application usage. This is discussed in Section 8.2.5.
挿入を達成することができると仮定すると、サーバは、挿入は、アプリケーションの使用状況の制約を満たす文書になることを検証します。これは、8.2.5項で説明されています。
The steps in this sub-section are followed if the PUT request will result in the replacement of a document, element, or attribute with the contents of the request.
PUT要求は、要求の内容と文書、要素、または属性の置換をもたらす場合、このサブセクションの手順に従っています。
If the PUT request is for a document, the content of the request body is placed into the directory, replacing the document with the same filename.
PUTリクエストは、文書のためのものである場合、リクエストボディの内容は同じファイル名で文書を交換し、ディレクトリに置かれています。
If the PUT request is for an element, the server replaces the target node with the content of the request body. As in the creation case, it is possible that, after replacement, the request URI does not select the element that was just inserted. If this happens, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
PUT要求は要素のためのものである場合、サーバは、リクエストボディのコンテンツとターゲットノードを置き換えます。創造場合のように、交換後、リクエストURIがちょうど挿入された要素を選択していない、ということも可能です。この問題が発生した場合、サーバーは、交換を行ってはならない（MUST NOT）、および409応答で要求を拒絶しなければなりません。レスポンスのボディは、<できません-挿入>要素を含んだ詳細な競合レポートを含めるべきです。
As with creation, replacement of an element does not result in the changing or elimination of namespace declarations within the newly modified element.
作成と同じように、要素の交換は、新たに変更された要素内の名前空間宣言の変更または除去にはなりません。
If the PUT request is for an attribute, the server sets the value of the selected attribute to the content of the request body. It is possible in the replacement case (but not in the creation case), that, after replacement of the attribute, the request URI no longer selects the attribute that was just replaced. The scenario in which this can happen is discussed in Section 7.7. If this is the case, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
PUTリクエストが属性のためであれば、サーバはリクエストボディの内容に選択した属性の値を設定します。それはそれは、属性の交換後、リクエストURIは、もはや単なる置換された属性を選択し、（ただし作成の場合）交換の場合には可能ではありません。これが起こることが可能なシナリオは、セクション7.7で説明されています。この場合、サーバーは、交換を行ってはならない（MUST NOT）、および409応答で要求を拒絶しなければなりません。レスポンスのボディは、<できません-挿入>要素を含んだ詳細な競合レポートを含めるべきです。
Once the document, element, or attribute has been tentatively inserted, the server needs to verify that the resulting document meets the data constraints outlined by the application usage.
文書、要素、または属性が仮挿入された後、サーバは、得られた文書は、アプリケーションの使用状況によって概説データ制約を満たしていることを確認する必要があります。
First, the server checks that the final document is compliant with the schema. If it is not, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <schema-validation-error> element. If a schema allows for elements or attributes from other namespaces, and the new document contains elements or attributes from an unknown namespace, the server MUST allow the change. In other words, it is not necessary for an XCAP server to understand the namespaces and corresponding schemas for elements and attributes within a document, as long as the schema itself allows for such elements or attributes to be included. Of course, such unknown namespaces would not be advertised by the server in its XCAP capabilities document, discussed in Section 12.
まず、サーバは、最終文書がスキーマに準拠していることを確認します。そうでない場合は、サーバーは挿入を実行してはなりません。それは409応答で要求を拒絶しなければなりません。その応答は、<スキーマ検証エラー>要素を含んだ詳細な競合レポートを含めるべきです。スキーマは、他の名前空間からの要素や属性を可能にし、新しい文書が未知の名前空間の要素または属性が含まれている場合、サーバーは、変更を許可する必要があります。 XCAPサーバがあれば、スキーマ自体は、そのような要素を可能にするか、含まれるべき属性として、文書内の要素および属性の名前空間と対応するスキーマを理解するために他の言葉で、それは必要ではありません。もちろん、このような未知の名前空間は、セクション12で説明し、そのXCAP機能文書にサーバーによってアドバタイズされません。
If the final document contains elements or attributes from a namespace that the server does understand (and has consequently advertised in its XCAP capabilities document), but the server does not have the schema for that particular element or attribute, the server MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <schema-validation-error> element.
最終文書は、要素が含まれているか、サーバーが理解しない（結果的にそのXCAP機能文書で宣伝している）の名前空間からの属性が、サーバーがその特定の要素または属性のスキーマを持っていない場合、サーバーは、との要求を拒絶しなければなりません409応答。その応答は、<スキーマ検証エラー>要素を含んだ詳細な競合レポートを含めるべきです。
Next, the server checks for any uniqueness constraints identified by the application usage. If the application usage required that a particular element or attribute had a unique value within a specific scope, the server would check that this uniqueness property still exists. If the application usage required that a URI within the document was unique within the domain, the server checks whether it is the case. If any of these uniqueness constraints are not met, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <uniqueness-failure> element. That element can contain suggested values that the client can use to retry. These SHOULD be values that, at the time the server generates the 409, would meet the uniqueness constraints.
次に、アプリケーションの使用状況によって識別される任意の一意性制約のため、サーバーをチェックします。アプリケーションの使用率が特定の要素や属性が特定の範囲内で一意の値を持っていたことを必要とした場合、サーバは、この一意性プロパティがまだ存在することを確認します。アプリケーションの使用状況は、文書内のURIは、ドメイン内で一意であったことを必要とした場合、サーバはそれに該当するかどうかをチェックします。これらの一意性制約のいずれかが満たされていない場合は、サーバーは挿入を実行してはなりません。それは409応答で要求を拒絶しなければなりません。その応答は、<一意性障害>要素を含んだ詳細な競合レポートを含めるべきです。その要素は、クライアントが再試行するために使用できる推奨値を含めることができます。これらは、サーバーが409を生成時に、一意性制約を満たすだろう、値である必要があります。
The server also checks for URI constraints and other non-schema data constraints. If the document fails one of these constraints, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <constraint-failure> element. That element indicates that the document failed non-schema data constraints explicitly called out by the application usage.
また、サーバはURIの制約やその他の非スキーマデータの制約のためにチェックします。文書は、これらの制約の1つに失敗した場合、サーバーは挿入を実行してはなりません。それは409応答で要求を拒絶しなければなりません。その応答は、<制約失敗>要素を含んだ詳細な競合レポートを含めるべきです。その要素は、ドキュメントが明示的にアプリケーションの使用状況によって呼び出さ非スキーマデータの制約を失敗したことを示します。
Element or attribute removals have similar constraints. The server checks the document for schema validity and compliance to constraints defined by the application usage, and rejects the request as described above, if either check fails.
要素または属性の削除は、同様の制約があります。サーバは、アプリケーション用法で定義された制約のために、スキーマの妥当性とコンプライアンスのための文書をチェックし、上記のようにどちらかのチェックが失敗した場合、要求を拒否します。
A PUT request for an XCAP resource, like any other HTTP resource, can be made conditional through usage of the If-Match and If-None-Match header fields. For a replacement, these are processed as defined in [6]. For an insertion of an element or attribute, conditional operations are permitted. The entity tag that is used for the procedures in [6] is the one for all of the resources within the same document as the parent of the element or attribute being inserted. One way to think of this is that, logically speaking, upon receipt of the PUT request, the XCAP server instantiates the etag for the resource referenced by the request, and then applies the processing of the request. Because of this behavior, it is not possible to perform a conditional insert on an attribute or element that is conditioned on the operation being an insertion and not a replacement. In other words, a conditional PUT of an element or attribute with an If-None-Match: * will always fail.
XCAPリソースのPUT要求は、他のHTTPリソースように、もしマッチの使用を介して、条件付き製If-None-Matchヘッダフィールドすることができます。交換のために、これらは、[6]で定義されるように処理されます。要素または属性を挿入するために、条件付きの動作が許可されています。 [6]の手順のために使用されるエンティティタグが挿入されている要素または属性の親と同じドキュメント内のリソースのすべてのためのものです。これを考えるための一つの方法は、論理的に言えば、PUT要求の受信時に、XCAPサーバーは、要求が参照するリソースのためのETagをインスタンス化する、ということで、その後、要求の処理を適用します。この動作のため、挿入せず、交換され、操作を条件とされる属性または要素を条件に挿入を実行することはできません。言い換えれば、もし-なしマッチを持つ要素や属性の条件付きのPUTは：*常に失敗します。
Because XCAP resources include elements, attributes, and documents, each of which has its own HTTP URI, the creation or modification of one resource affects the state of many others. For example, insertion of a document creates resources on the server for all of the elements and attributes within that document. After the server has performed the insertion associated with the PUT, the server MUST create and/or modify those resources affected by that PUT. The structure of the document completely defines the inter-relationship between those resources.
XCAPリソースは、独自のHTTP URIを持っているそれぞれの要素、属性、およびドキュメントを、含まれているため、一つのリソースの作成や変更は、他の多くの状態に影響を与えます。例えば、文書の挿入は、そのドキュメント内の要素と属性のすべてのためのサーバー上のリソースを作成します。サーバはPUTに関連付けられた挿入を行った後、サーバは、作成および/またはそのPUTによって影響を受け、それらのリソースを変更する必要があります。ドキュメントの構造は、完全にそれらのリソース間の相互関係を定義します。
However, the application usage can specify other resource inter-dependencies. The server MUST create or modify the resources specified by the application usage.
ただし、アプリケーションの使用状況は、他のリソース間の依存関係を指定することができます。サーバは、アプリケーションの使用状況によって指定されたリソースを作成または変更しなければなりません。
If the creation or replacement was successful, and the resource interdependencies are resolved, the server returns a 201 Created or 200 OK, respectively. Note that a 201 Created is generated for creation of new documents, elements, or attributes. A 200 OK response to PUT MUST not contain any content. Per the recommendations of RFC 2616, the 201 can contain a Location header field and entity that identify the resource that was created. An entity tag MUST be included in all successful responses to a PUT.
作成または交換が成功した場合、リソースの相互依存関係が解決され、サーバはそれぞれ、作成された201または200 OKを返します。作成された201は新しいドキュメント、要素、または属性の作成のために生成されることに注意してください。置くために200 OK応答は、任意のコンテンツを含めることはできません。 RFC 2616の推奨に従って、201は、作成されたリソースを識別Locationヘッダフィールド及びエンティティを含むことができます。エンティティタグは、PUTに成功したすべての応答に含まれなければなりません。
The semantics of GET are as specified in RFC 2616. This section clarifies the specific content to be returned for a particular URI that represents an XCAP resource.
このセクションでは、XCAPリソースを表す特定のURIのために返される特定のコンテンツを明確RFC 2616で指定されるようにGETの意味です。
If the request URI contains only a document selector, the server returns the document specified by the URI if it exists, else returns a 404 response. The MIME type of the body of the 200 OK response MUST be the MIME type defined by that application usage (i.e., "application/resource-lists+xml").
リクエストURIが唯一のドキュメントセレクタが含まれている場合、サーバはそれが存在する場合は、URIで指定されたドキュメントを返し、それ以外の404応答を返します。 200 OKレスポンスのボディのMIMEタイプは、そのアプリケーションの使用（すなわち、「アプリケーション/リソース・リスト+ XML」）によって定義されたMIMEタイプである必要があります。
If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid, the server returns a 404 response. Otherwise, the server returns a 200 OK response. If the node selector identifies an XML element, that element is returned in the 200 OK response as an XML fragment body containing the selected element. The server MUST NOT add namespace bindings representing namespaces used by the element or its children, but declared in ancestor elements; the client will either know these bindings already (since it has a cached copy of the whole document), or it can learn them by explicitly querying for the bindings. The MIME type of the response MUST be "application/xcap-el+xml". If the node selector identifies an XML attribute, the value of that attribute is returned in the body of the response. The MIME type of the response MUST be "application/xcap-att+xml". If the node selector identifies a set of namespace bindings, the server computes the set of namespace bindings in scope for the element (including the default) and encodes it using the "application/xcap-ns+xml" format defined in Section 10. That document is then returned in the body of the response.
リクエストURIは、ノードセレクタが含まれている場合、サーバは、ドキュメントセレクタによって指定された文書を取得し、それが見つかった場合、そのドキュメント内のノードセレクタを評価します。いかなる文書が見つからない場合、ノードセレクタが全く一致又は無効でない場合、または、サーバ404の応答を返します。そうでなければ、サーバは200 OK応答を返します。ノードセレクタがXML要素を識別する場合、その要素は、選択された元素を含むXMLフラグメント体として200 OK応答で返されます。サーバーは、要素またはその子によって使用される名前空間を表す名前空間バインディングを追加しますが、祖先要素で宣言されてはなりません。 （それは文書全体のキャッシュされたコピーを持っているので）クライアントは、すでにこれらのバインディングを知っているだろうか、それが明示的バインディングを照会することによって、それらを学ぶことができます。応答のMIMEタイプが「アプリケーション/ XCAP-EL +のXML」でなければなりません。ノードセレクタがXML属性を識別する場合、その属性の値は、応答のボディに戻されます。応答のMIMEタイプが「アプリケーション/ XCAP-ATT + XML」でなければなりません。ノードセレクタが名前空間バインディングのセットを識別する場合、サーバは、（デフォルトを含む）要素のスコープ内の名前空間バインディングのセットを計算し、セクション10で定義された「アプリケーション/ XCAP-NS + XML」形式を使用してそれをコードします文書は、レスポンスのボディに返されます。
GET operations can be conditional, and follow the procedures defined in [6].
GET操作は条件付きであり、及び[6]で定義された手順に従うことができます。
Note that the GET of a resource that was just PUT might not be octet-for-octet equivalent to what was PUT, due to XML normalization and equivalency rules.
ちょうど置かれたリソースのGETが原因XMLの標準化と同等のルールに、置かれたものにオクテットのためのオクテット同等ではないかもしれないことに注意してください。
A successful response to a GET MUST include an entity tag.
GETに成功した応答は、エンティティタグを含まなければなりません。
The semantics of DELETE are as specified in RFC 2616. This section clarifies the specific content to be deleted for a particular URI that represents an XCAP resource.
DELETEのセマンティクスは、RFC 2616で指定されているように、このセクションでは、XCAPリソースを表す特定のURIのために削除する特定のコンテンツを明確。
If the request URI contained a namespace-selector, the server MUST reject the request with a 405 (Method Not Allowed) and MUST include an Allow header field including the GET method.
リクエストURIが名前空間セレクタが含まれている場合、サーバは405（方法不可）で要求を拒絶しなければなりませんし、GETメソッドを含むAllowヘッダーフィールドを含まなければなりません。
If the request URI contains only a document selector, the server deletes the document specified by the URI if it exists and returns a 200 OK, else returns a 404 response.
リクエストURIのみドキュメントセレクタが含まれている場合、サーバは、それが存在し、200 OKを返す場合他、URIで指定された文書を削除する404応答を返します。
If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid (note that it will be invalid if multiple elements or attributes are selected), the server returns a 404 response. Otherwise, the server removes the specified element or attribute from the document and performs the validation checks defined in Section 8.2.5. Note that this deletion does not include any white space around the element that was deleted; the XCAP server MUST preserve surrounding whitespace. It is possible that, after deletion, the request URI selects another element in the document. If this happens, the server MUST NOT perform the deletion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-delete> element. If the deletion will cause a failure of one of the constraints, the deletion MUST NOT take place. The server follows the procedures in Section 8.2.5 for computing the 409 response. If the deletion results in a document that is still valid, the server MUST perform the deletion, process the resource interdependencies defined by the application usage, and return a 200 OK response.
リクエストURIは、ノードセレクタが含まれている場合、サーバは、ドキュメントセレクタによって指定された文書を取得し、それが見つかった場合、そのドキュメント内のノードセレクタを評価します。いかなる文書が見つからない場合、ノードセレクタが無一致または無効な（複数の要素または属性が選択されている場合、それは無効になることに注意してください）しない場合、または、サーバ404の応答を返します。そうでない場合、サーバは、文書から指定された要素または属性を削除し、セクション8.2.5で定義された検証チェックを行います。この削除は、削除された要素の周囲に空白が含まれていないことに注意してください。 XCAPサーバーは、前後の空白を保存しなければなりません。削除した後、リクエストURIは、文書内の別の要素を選択、ということも可能です。この問題が発生した場合、サーバーは、削除を実行してはならない、と409応答で要求を拒絶しなければなりません。レスポンスのボディは、<-削除することはできません>要素を含んだ詳細な競合レポートを含めるべきです。削除は制約の1つの故障の原因となります場合は、削除は行われてはなりません。サーバ409の応答を計算するためのセクション8.2.5の手順に従います。まだ有効である文書の削除結果ならば、サーバは、削除を行うアプリケーション用法で定義されたリソースの依存関係を処理し、200 OK応答を返さなければなりません。
DELETE operations can be conditional, and follow the procedures defined in [6].
DELETE操作は条件付きであり、及び[6]で定義された手順に従うことができます。
Before the server returns the 200 OK response to a DELETE, it MUST process the resource interdependencies as defined in Section 8.2.7. As long as the document still exists after the delete operation, any successful response to DELETE MUST include the entity tag of the document.
サーバーは、DELETEに200 OK応答を返す前に、8.2.7項で定義されているように、リソースの相互依存を処理しなければなりません。限り、文書がまだ削除操作の後に存在するとして、削除するには、任意の正常な応答は、文書のエンティティタグを含まなければなりません。
An XCAP server MUST maintain entity tags for all resources that it maintains. This specification introduces the additional constraint that when one resource within a document (including the document itself) changes, that resource is assigned a new etag, and all other resources within that document MUST be assigned the same etag value. Effectively, there is a single etag for the entire document. An XCAP server MUST include the Etag header field in all 200 or 201 responses to PUT, GET, and DELETE, assuming the document itself still exists after the operation. In the case of a DELETE, the entity tag refers to the value of the entity tag for the document after the deletion of the element or attribute.
XCAPサーバーは、それが保持するすべてのリソースのためのエンティティタグを維持しなければなりません。この仕様は、（文書自体を含む）文書内の場合つのリソースた変更を追加の制約を導入し、そのリソースが新しいのETagが割り当てられ、そのドキュメント内の他のすべてのリソースが同じETag値を割り当てなければなりません。効果的に、文書全体のための単一のETagがあります。 XCAPサーバは、ドキュメント自体がまだ動作した後に存在すると仮定すると、PUT、GET、および削除するために、すべての200のまたは201応答でたEtagヘッダフィールドを含まなければなりません。 DELETEの場合には、エンティティタグは、要素または属性の削除後の文書のエンティティタグの値を指します。
XCAP resources do not introduce new requirements on the strength of the entity tags.
XCAPリソースは、エンティティタグの強度に新しい要件を導入していません。
As a result of this constraint, when a client makes a change to an element or attribute within a document, the response to that operation will convey the entity tag of the resource that was just affected. Since the client knows that this entity tag value is shared by all of the other resources in the document, the client can make conditional requests against other resources using that entity tag.
クライアントは、文書内の要素または属性に変更を加え、この制約の結果として、その操作への応答だけで影響を受けたリソースのエンティティタグを伝えます。クライアントは、このエンティティタグの値は、文書内の他のすべてのリソースで共有されていることを知っているので、クライアントはそのエンティティタグを使用して他のリソースに対する条件付きの要求を行うことができます。
An XCAP resource is a valid HTTP resource, and therefore, it can be cached by clients and network caches. Network caches, however, will not be aware of the interdependencies between XCAP resources. As such, a change to an element in a document by a client will invalidate other XCAP resources affected by the change. For application usages containing data that is likely to be dynamic or written by clients, servers SHOULD indicate a no-cache directive.
XCAPリソースは有効なHTTPリソースであるため、それがクライアントとネットワークキャッシュでキャッシュすることができます。ネットワークキャッシュは、しかし、XCAPリソース間の相互依存性を認識しません。そのため、クライアントによって文書内の要素を変更すると、変更によって影響を受ける他のXCAPリソースを無効にします。動的またはクライアントによって書かれた可能性が高いデータを含むアプリケーションの使用法については、サーバはキャッシュなしのディレクティブを示すべきです。
A node-selector can identify a set of namespace bindings that are in scope for a particular element. In order to convey these bindings in a GET response, a way is needed to encode them.
ノードセレクタは、特定の要素の範囲内にある名前空間バインディングのセットを識別することができます。 GET応答にこれらのバインディングを伝えるためには、方法は、それらをコードするために必要とされます。
Encoding is trivially done by including a single XML element in an XML fragment body. This element has the same local-name as the element whose namespace bindings are desired, and also the same namespace-prefix. The element has an xmlns attribute identifying the default namespace in scope, and an xmlns:prefix declaration for each prefix that is in scope.
エンコーディングは自明XMLフラグメント本体内の単一のXML要素を含むことによって行われます。この要素は、名前空間バインディング望まれている要素、および同じ名前空間接頭辞と同じローカル名を持っています。スコープ内にある各プレフィックスのプレフィックス宣言：要素がスコープ内にデフォルトの名前空間を特定のxmlns属性、およびのxmlnsを持っています。
For example, consider the XML document in Section 6.4. The node-selector df:foo/df2:bar/df2:baz/namespace::* will select the namespaces in scope for the <baz> element in the document, assuming the request is accompanied by a query component that contains xmlns(df=urn:test:default-namespace) and xmlns(df2=urn:test:namespace1-uri). A GET containing this node selector and namespace bindings will produce the following result:
例えば、セクション6.4でXML文書を考えてみましょう。ノードセレクタDF：FOO / DF2：バー/ DF2：バズ/名前空間:: *要求がのxmlns（DFを含むクエリコンポーネントを伴うと仮定すると、文書内の<バズ>要素のスコープ内の名前空間を選択します= URN：テスト：デフォルトの名前空間）とのxmlns（DF2 = URN：テスト：namespace1-URI）。このノードセレクタと名前空間のバインディングを含むGETは、以下の結果を生成します。
<baz xmlns="urn:test:namespace1-uri" xmlns:ns1="urn:tes:namespace1-uri"/>
<バズのxmlns = "壷：テスト：namespace1-URI" のxmlns：NS1 = "壷：TES：namespace1-uriの" />
It is important to note that the client does not need to know the actual namespace bindings in order to construct the URI. It does need to know the namespace URI for each element in the node-selector. The namespace bindings present in the query component are defined by the client, mapping those URIs to a set of prefixes. The bindings returned by the server are the actual bindings used in the document.
クライアントがURIを構築するために、実際の名前空間バインディングを知っている必要はないことに注意することが重要です。これは、ノード・セレクタ内の各要素の名前空間URIを知っている必要がありません。クエリコンポーネントに存在する名前空間バインディングはプレフィクスのセットにそれらのURIをマッピングし、クライアントによって定義されています。サーバから返されたバインディングは、文書内で使用される実際のバインディングです。
In cases where the server returns a 409 error response, that response will usually include a document in the body of the response which provides further details on the nature of the error. This document is an XML document, formatted according to the schema of
サーバが409エラー応答を返す場合には、その応答は、通常、エラーの性質に関する更なる詳細を提供するレスポンスのボディで文書を含むであろう。この文書はのスキーマに従って、フォーマットされたXML文書であります
Section 11.2. Its MIME type, registered by this specification, is "application/xcap-error+xml".
11.2節。この仕様によって登録のMIMEタイプは、「アプリケーション/ XCAP-エラー+ xml」です。
The document structure is simple. It contains the root element <xcap-error>. The content of this element is a specific error condition. Each error condition is represented by a different element. This allows for different error conditions to provide different data about the nature of the error. All error elements support a "phrase" attribute, which can contain text meant for rendering to a human user.
文書構造は単純です。これは、ルート要素<XCAP-エラーが>含まれています。この要素の内容は、特定のエラー状態です。各エラー状態は、様々な要素によって表されます。これは、エラーの性質に関するさまざまなデータを提供するために、さまざまなエラー条件が可能になります。すべてのエラー要素がテキストを含めることができます「という句」属性は、人間のユーザにレンダリングするためのものでサポートされています。
The following error elements are defined by this specification:
次のエラー要素がこの仕様で定義されています。
<not-well-formed>: This indicates that the body of the request was not a well-formed XML document.
<ない-整形>：これはリクエストのボディが整形式のXML文書ではなかったことを示しています。
<not-xml-frag>: This indicates that the request was supposed to contain a valid XML fragment body, but did not. Most likely this is because the XML in the body was malformed or not balanced.
<ない-XML-FRAG>：これは、要求が有効なXMLフラグメント体を含むようになっていたことを示しているが、しませんでした。体内のXMLが不正な形式またはバランスではなかったので、ほとんどの場合、これはあります。
<no-parent>: This indicates that an attempt to insert a document, element, or attribute failed because the directory, document, or element into which the insertion was supposed to occur does not exist. This error element can contain an optional <ancestor> element, which provides an HTTP URI that represents the closest parent that would be a valid point of insertion. This HTTP URI MAY be a relative URI, relative to the document itself. Because this is a valid HTTP URI, its node selector component MUST be percent-encoded.
<無親が>：これは挿入が起こることになっていた先のディレクトリ、ドキュメント、または要素が存在しないため、ドキュメント、要素、または属性を挿入しようとする試みが失敗したことを示していません。このエラー要素は、挿入の有効なポイントであろう最も近い親を表すHTTP URIを提供するオプションの<祖先>要素を含むことができます。このHTTP URIは、文書自体に対する相対URIであってもよいです。これが有効なHTTP URIであるため、そのノードセレクタコンポーネントは、パーセントエンコードする必要があります。
<schema-validation-error>: This element indicates that the document was not compliant to the schema after the requested operation was performed.
<スキーマ検証エラー>：この要素は、要求された操作が行われた後の文書がスキーマに準拠していませんでしたことを示しています。
<not-xml-att-value>: This indicates that the request was supposed to contain a valid XML attribute value, but did not.
<ない-XML-ATT-値>：これは、要求が有効なXML属性値が含まれていることになっていたことを示しているが、しませんでした。
<cannot-insert>: This indicates that the requested PUT operation could not be performed because a GET of that resource after the PUT would not yield the content of the PUT request.
<ない-挿入することができます>：これは、PUT後、そのリソースのGETは、PUT要求の内容が得られないため、要求さPUT操作が実行できなかったことを示しています。
<cannot-delete>: This indicates that the requested DELETE operation could not be performed because it would not be idempotent.
<-削除することはできません>：これは、冪等されないため、要求されたDELETE操作を実行することができなかったことを示しています。
<uniqueness-failure>: This indicates that the requested operation would result in a document that did not meet a uniqueness constraint defined by the application usage. For each URI, element, or attribute specified by the client that is not unique, an <exists> element is present as the content of the error element. Each <exists> element has a "field" attribute that contains a relative URI identifying the XML element or attribute whose value needs to be unique, but wasn't. The relative URI is relative to the document itself, and will therefore start with the root element. The query component of the URI MUST be present if the node selector portion of the URI contains namespace prefixes. Since the "field" node selector is a valid HTTP URI, it MUST be percent-encoded. The <exists> element can optionally contain a list of <alt-value> elements. Each one is a suggested alternate value that does not currently exist on the server.
<一意性障害>：これは、要求された操作は、アプリケーション用法で定義された一意性制約を満たしていませんでした文書につながることを示しています。一意でないクライアントで指定された各URI、要素、または属性の場合は、<存在>要素は、エラー要素の内容として存在しています。各<存在>要素は値ユニークである必要がXMLエレメントまたは属性を識別する相対URIを含む「フィールド」属性を持っていますが、ありませんでした。相対URIは、ドキュメント自体に対してであるため、ルート要素で始まります。 URIのノード選択部は、名前空間接頭辞が含まれている場合は、URIのクエリコンポーネントが存在しなければなりません。 「フィールド」ノードセレクタが有効なHTTP URIであるので、パーセントエンコードする必要があります。要素は、必要に応じて、<ALT値>要素のリストを含むことができ、<存在します>。一人一人は現在、サーバー上に存在しない提案の代替値です。
<constraint-failure>: This indicates that the requested operation would result in a document that failed a data constraint defined by the application usage, but not enforced by the schema or a uniqueness constraint.
<制約障害>：これは、要求された操作は、アプリケーションの使用状況によって定義されたデータ制約が失敗しましたが、スキーマまたは一意性制約によって強制されないドキュメントをもたらすことを示しています。
<extension>: This indicates an error condition that is defined by an extension to XCAP. Clients that do not understand the content of the extension element MUST discard the xcap-error document and treat the error as an unqualified 409.
<拡張は、>：これは、XCAPに拡張することにより定義されるエラー状態を示します。拡張要素の内容を理解していないクライアントは、XCAP-エラー文書を破棄し、修飾されていない409などのエラーを扱わなければなりません。
<not-utf-8>: This indicates that the request could not be completed because it would have produced a document not encoded in UTF-8.
<ないUTF-8>：これは、UTF-8でエンコードされていない文書を作成していたため、要求を完了できなかったことを示します。
As an example, the following document indicates that the user attempted to create an RLS service using the URI sip:friends@example.com, but that URI already exists:
friends@example.com、しかしURIが既に存在していること：例として、以下の文書は、ユーザーがURIのSIPを使用してRLSサービスを作成しようとしたことを示しています。
<?xml version="1.0" encoding="UTF-8"?> <xcap-error xmlns="urn:ietf:params:xml:ns:xcap-error"> <uniqueness-failure> <exists field="rls-services/service/@uri"> <alt-value>sip:mybuddies@example.com</alt-value> </exists> </uniqueness-failure> </xcap-error>
<XMLバージョン= "1.0" エンコード= "UTF-8"？> <XCAP-エラーのxmlns = "壷：IETF：のparams：XML：NS：XCAP-エラー"> <一意-障害が> <フィールド= "RLSが存在します-services /サービス/ @のURI "> <ALT値> SIP：mybuddies@example.com </ ALT値> </存在> </独自性障害> </ XCAP-エラー>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error" xmlns="urn:ietf:params:xml:ns:xcap-error" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：XCAP-エラー" のxmlns = "壷：IETF：のparams：XML：NS ：XCAP-エラー」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "" 修飾されていません>
<xs:element name="error-element" abstract="true"/> <xs:element name="xcap-error"> <xs:annotation> <xs:documentation>Indicates the reason for the error. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element ref="error-element"/> </xs:sequence> </xs:complexType> </xs:element>
<XS：要素名= "エラー要素" 抽象= "真" /> <XS：要素名= "XCAP-エラー"> <XS：注釈> <XS：ドキュメント>は、エラーの理由を示します。 </ XS：ドキュメント> </ XS：注釈> <XS：complexTypeの> <XS：配列> <XS：要素REF = "エラー要素" /> </ XS：配列> </ XS：complexTypeの> </ XS ：要素>
<xs:element name="extension" substitutionGroup="error-element"> <xs:complexType> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element>
<XS：要素名= "拡張子" のsubstitutionGroup = "エラー要素"> <XS：complexTypeの> <XS：シーケンス> <XS：任意の名前空間= "##あらゆる" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素>
<xs:element name="schema-validation-error" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This element indicates that the document was not compliant to the schema after the requested operation was performed.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：要素名=「スキーマ検証エラー」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>この要素は、要求された操作が実行された後の文書がスキーマに準拠していませんでしたことを示しています。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="not-xml-frag" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the request was supposed to contain a valid XML fragment body, but did not.</xs:documentation> </xs:annotation>
<XS：要素名=「ではない-XML-FRAG」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、要求が有効なXMLフラグメント体を含むようになったが、なかったことを示しています。 </ XS：ドキュメンテーション> </ XS：注釈>
<xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="no-parent" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that an attempt to insert an element, attribute, or document failed because the document or element into which the insertion was supposed to occur does not exist.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="ancestor" type="xs:anyURI" minOccurs="0"> <xs:annotation> <xs:documentation>Contains an HTTP URI that points to the element that is the closest ancestor that does exist. </xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：要素名は=「非親」のsubstitutionGroupは=「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、要素、属性、またはドキュメントを挿入しようとする試みはに文書または要素ために失敗したことを示していますその挿入が存在していないが発生することになった</ XS：ドキュメント>。</ XS：注釈> <XS：complexTypeの> <XS：シーケンス> <XS：要素名= "祖先" タイプ= "XS：anyURIの" minOccurs属性=「0」> <XS：注釈> <XS：ドキュメント>が存在する最も近い祖先である要素を指すHTTP URIを含みます。 </ XS：ドキュメンテーション> </ XS：注釈> </ XS：要素> </ XS：シーケンス> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS ：complexTypeの> </ XS：要素>
<xs:element name="cannot-insert" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the requested PUT operation could not be performed because a GET of that resource after the PUT would not yield the content of the PUT request. </xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<：「ではない-挿入することができます」のsubstitutionGroup =「エラー要素」要素名は= XS> <は、xs：注釈は> <XSは：ドキュメント>これは、要求されたPUT操作が実行できなかったことを示しているので、PUT後、そのリソースのGETを希望PUTリクエストの内容が得られません。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="not-xml-att-value" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the request was supposed to contain a valid XML attribute value, but did not.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType>
<XS：要素名=「ではない-XML-ATT値」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、要求が有効なXML属性値が含まれていることになってますが、やったことを示していますではない。</ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの>
</xs:element>
</ XS：要素>
<xs:element name="uniqueness-failure" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the requested operation would result in a document that did not meet a uniqueness constraint defined by the application usage. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="exists" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>For each URI, element, or attribute specified by the client that is not unique, one of these is present.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0"> <xs:element name="alt-value" type="xs:string" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>An optional set of alternate values can be provided.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> <xs:attribute name="field" type="xs:string" use="required"/> </xs:complexType> </xs:element> </xs:sequence> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：要素名=「一意性障害」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、要求された操作は、によって定義された一意性制約を満たしていませんでした文書につながることを示していますアプリケーションの使用状況。 </ XS：ドキュメント> </ XS：注釈> <XS：complexTypeの> <XS：配列> <XS：要素は、名前は= "存在" のmaxOccurs = "無制限"> <XS：注釈>：各URIの<文書XS> 、ユニークでないクライアントによって指定された要素、または属性、これらのいずれかが存在している。</ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：シーケンスのminOccurs = "0"> <XS：要素名= "ALT値" TYPE = "XS：文字列" のmaxOccurs = "無制限"> <XS：注釈> <XS：ドキュメント>代替の値の任意のセットを提供することができる</ XS：ドキュメント> </ XS ：注釈> </ XS：要素> </ XS：シーケンス> <XS：属性名= "フィールド" タイプ= "XS：文字列" 使用= "必須" /> </ XS：complexTypeの> </ XS：要素> </ XS：シーケンス> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="not-well-formed" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the body of the request was not a well-formed document.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：要素名=「不整形」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>。これは、要求の本体が整形文書ではなかったことを示す</ XS ：ドキュメント> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="constraint-failure" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the requested operation would result in a document that failed a data constraint defined by the application usage, but not enforced by the schema or a uniqueness constraint.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XS：要素名=「制約失敗」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、要求された操作は、アプリケーションの使用状況によって定義されたデータ制約を失敗した文書につながることを示していますしかし、スキーマや一意性制約によって強制されません。</ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="cannot-delete" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the requested DELETE operation could not be performed because it would not be idempotent.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element>
<XSは：要素名は=のsubstitutionGroup =「エラー要素を」「削除することはできません」> <XS：注釈> <XS：ドキュメント>。これは、それが冪等されないため、要求されたDELETE操作が実行できなかったことを示します。</ XS ：ドキュメント> </ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素>
<xs:element name="not-utf-8" substitutionGroup="error-element"> <xs:annotation> <xs:documentation>This indicates that the request could not be completed because it would have produced a document not encoded in UTF-8.</xs:documentation> </xs:annotation> <xs:complexType> <xs:attribute name="phrase" type="xs:string" use="optional"/> </xs:complexType> </xs:element> </xs:schema>
<XS：要素名=「ではないUTF-8」のsubstitutionGroup =「エラー要素」> <XS：注釈> <XS：ドキュメント>これは、文書がでエンコードされていない生産しているだろうので、要求を完了できなかったことを示しUTF-8 </ XS：ドキュメント>。</ XS：注釈> <XS：complexTypeの> <XS：属性名= "フレーズ" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：complexTypeの> </ XS：要素> </ XS：スキーマ>
XCAP can be extended through the addition of new application usages and extensions to the core protocol. Application usages may define MIME types with XML schemas that allow new extension nodes from new namespaces. It will often be necessary for a client to determine what extensions, application usages, or namespaces a server supports before making a request. To enable that, this specification defines an application usage with the AUID "xcap-caps". All XCAP servers MUST support this application usage. This usage defines a single document within the global tree that lists the capabilities of the server. Clients can read this well-known document, and therefore learn the capabilities of the server.
XCAPは、コアプロトコルに新しいアプリケーション用途および拡張の添加によって拡張することができます。アプリケーション用法は、新しい名前空間から新しい拡張ノードを許可するXMLスキーマでMIMEタイプを定義することもできます。クライアントがサーバに要求を行う前に、サポートしている名前空間どんな拡張機能、アプリケーションの使用状況、または決定することがしばしば必要になります。それを可能にするために、この仕様はAUID「XCAPキャップ」を使用してアプリケーションの使用状況を定義します。すべてのXCAPサーバは、このアプリケーションの使用をサポートしなければなりません。この用法は、サーバーの能力を示していますグローバルツリー内の単一のドキュメントを定義します。クライアントは、このよく知られた文書を読んで、そのため、サーバの機能を学ぶことができます。
The structure of the document is simple. The root element is <xcap-caps>. Its children are <auids>, <extensions>, and <namespaces>. Each of these contain a list of AUIDs, extensions, and namespaces supported by the server. Extensions are named by tokens defined by the extension, and typically define new selectors. Namespaces are identified by their namespace URI. To 'support' a namespace, the server must have the schemas for all elements within that namespace, and be able to validate them if they appear within documents. Since all XCAP servers support the "xcap-caps" AUID, it MUST be listed in the <auids> element, and the "urn:ietf:params:xml:ns:xcap-caps" namespace MUST be listed in the <namespaces> element.
文書の構造が簡単です。ルート要素は<XCAPキャップ>です。その子は<auids>、<拡張子>、および<名前空間>です。これらのそれぞれは、サーバーでサポートされているAUIDs、拡張、および名前空間のリストが含まれています。拡張機能は、拡張によって定義されたトークンによって名付けられ、一般的に新しいセレクタを定義しています。名前空間は、その名前空間URIによって識別されます。 「サポート」の名前空間に、サーバーはその名前空間内のすべての要素のスキーマを持っている、と彼らは、文書内に表示された場合、それらを検証できるようにする必要があり。名前空間には、<名前空間>に記載されている必要があり、すべてのXCAPサーバーは、「XCAP-キャップ」AUIDをサポートしているので、それは<auids>要素に記載されている必要があり、かつ「XCAPキャップのurn：IETF：のparams：XML：：nsが」素子。
The following sections provide the information needed to define this application usage.
次のセクションでは、このアプリケーションの使用状況を定義するために必要な情報を提供します。
This specification defines the "xcap-caps" AUID within the IETF tree, via the IANA registration in Section 15.
この仕様は、セクション15にIANA登録を介して、IETFツリー内の「XCAPキャップ」AUIDを定義します。
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-caps" xmlns="urn:ietf:params:xml:ns:xcap-caps" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:element name="xcap-caps"> <xs:annotation> <xs:documentation>Root element for xcap-caps</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:element name="auids"> <xs:annotation> <xs:documentation>List of supported AUID.</xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="auid" type="auidType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="extensions" minOccurs="0">
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：XCAP-キャップ" のxmlns = "壷：IETF：のparams：XML：NS ：XCAP-キャップ」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS：要素名は= "XCAP-キャップ"> <XS：注釈> <XS：ドキュメント> XCAP-キャップのルート要素</ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：シーケンス> <XS：要素名= "auids"> <XS：注釈> <XS：ドキュメント>サポートAUIDの一覧</ XS：ドキュメント>。</ XS：注釈> <XS：complexTypeの> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "AUID "タイプ=" auidType "/> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素> <XS：要素名=" 拡張子」のminOccurs = "0">
<xs:annotation> <xs:documentation>List of supported extensions. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="extension" type="extensionType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="namespaces"> <xs:annotation> <xs:documentation>List of supported namespaces. </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:element name="namespace" type="namespaceType"/> </xs:sequence> </xs:complexType> </xs:element> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> </xs:element> <xs:simpleType name="auidType"> <xs:annotation> <xs:documentation>AUID Type</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="extensionType"> <xs:annotation> <xs:documentation>Extension Type</xs:documentation> </xs:annotation> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="namespaceType"> <xs:annotation> <xs:documentation>Namespace type</xs:documentation> </xs:annotation> <xs:restriction base="xs:anyURI"/> </xs:simpleType> </xs:schema>
<XS：注釈> <XS：ドキュメント>サポートの拡張機能の一覧。 </ XS：ドキュメント> </ XS：注釈> <XS：complexTypeの> <XS：配列のminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "拡張子" タイプ= "extensionType" /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "名前空間"> <XS：注釈> <XS：ドキュメント>サポート名前空間の一覧。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：complexTypeの> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "名前空間" タイプ= "namespaceType" /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素> <XS：単純型名= "auidType"> <XS：注釈> <XS：ドキュメント> AUIDタイプ</ XS：ドキュメンテーション> </ XS：注釈> <XS：制限ベース= "XS：文字列" /> </ XS：単純> <XS：単純型名= "extensionType"> <XS：注釈> <XS：ドキュメント>拡張タイプ</ XS：ドキュメンテーション> </ XS：注釈> < XS：制限ベース= "XS：文字列" /> </ XS：単純> <XS：単純型名= "namespaceType"> <XS：注釈> <XS：ドキュメント>名前空間の種類</ XS：ドキュメンテーション> </ XS：注釈> <XS：制限ベース= "XS：anyURIの" /> </ XS：単純> </ XS：スキーマ>
The default document namespace used in evaluating a URI is urn:ietf:params:xml:ns:xcap-caps.
IETF：：のparams：XML：NS：XCAP-キャップURIを評価する際に使用される既定のドキュメントの名前空間は、URNです。
Documents conformant to this schema are known by the MIME type "application/xcap-caps+xml", registered in Section 15.2.5.
このスキーマに準拠した文書は、「+ xmlのアプリケーション/ XCAP-キャップ」MIMEタイプによって知られているセクション15.2.5に登録されています。
There are no additional validation constraints associated with this application usage.
このアプリケーションの使用に関連する追加の検証制約がありません。
Data semantics are defined above.
データの意味は、上で定義されています。
A server MUST maintain a single instance of the document in the global tree, using the filename "index". There MUST NOT be an instance of this document in the user's tree.
サーバーは、ファイル名「インデックス」を使用して、グローバルツリーのドキュメントの単一のインスタンスを維持しなければなりません。ユーザーのツリーに、このドキュメントのインスタンスがあってはなりません。
There are no resource interdependencies in this application usage beyond those defined by the schema.
スキーマで定義されたものを超えて、このアプリケーションの使用には、リソースの依存関係はありません。
This application usage does not change the default authorization policy defined by XCAP.
このアプリケーションの使用状況は、XCAPによって定義されたデフォルトの認可ポリシーを変更しません。
This section goes through several examples, making use of the resource-lists and rls-services [22] XCAP application usages.
このセクションでは、リソース・リストやRLS-サービス[22] XCAPアプリケーションの用法を利用して、いくつかの例を経由します。
First, a user Bill creates a new document (see Section 7.1). This document is a new resource-list, initially with a single list, called friends, with no users in it:
まず、ユーザビルは、新しいドキュメントを作成します（7.1節を参照してください）。この文書では、その中にいないユーザーと、最初は友人と呼ばれる単一のリスト、で、新しいリソース・リストであります：
PUT /resource-lists/users/sip:bill@example.com/index HTTP/1.1 Content-Type:application/resource-lists+xml Host: xcap.example.com
アプリケーション/リソース・リストは+ XMLホスト：xcap.example.com /resource-lists/users/sip:bill@example.com/index HTTP / 1.1のContent-TypeをPUT
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> </list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト名= "友人"> </リスト> </資源リスト>
Figure 24: New Document
図24：新規ドキュメント
Next, Bill creates an RLS services document defining a single RLS service referencing this list. This service has a URI of sip:myfriends@example.com (URIs are line-folded for readability):
次に、ビルは、このリストを参照し、単一のRLSサービスを定義するRLSサービス文書を作成します。このサービスは、SIPのURIを持っていますmyfriends@example.com（URIは読みやすくするために、ラインに折り畳まれています）：
PUT /rls-services/users/sip:bill@example.com/index HTTP/1.1 Content-Type:application/rls-services+xml Host: xcap.example.com
PUT /rls-services/users/sip:bill@example.com/index HTTP / 1.1のContent-Type：アプリケーション/ RLS-サービス+ XMLホスト：xcap.example.com
<?xml version="1.0" encoding="UTF-8"?> <rls-services xmlns="urn:ietf:params:xml:ns:rls-services"> <service uri="sip:myfriends@example.com"> <resource-list>http://xcap.example.com/resource-lists/users/ sip:bill@example.com/index/~~/resource-lists/ list%5b@name=%22friends%22%5d </resource-list> <packages> <package>presence</package> </packages> </service> </rls-services>
<？xml version = "1.0" エンコード= "UTF-8"？> <RLS-サービスのxmlns = "壷：IETF：のparams：XML：NS：RLS-サービス"> <サービスURI = "一口例：@マイフレンド。 comの "> <リソース・リスト> http://xcap.example.com/resource-lists/users/ SIP：bill@example.com/index/~~/resource-lists/リスト％5bは@名=％22friends％ 22％5D </リソース・リスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> </ RLS-サービス>
Figure 25: RLS Services Example
図25：RLSサービスの例
Next, Bill creates an element in the resource-lists document (Section 7.4). In particular, he adds an entry to the list:
次に、ビルは、リソース・リストの文書（7.4節）の要素を作成します。特に、彼はリストにエントリを追加します。
PUT /resource-lists/users/sip:bill@example.com/index /~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1 Content-Type:application/xcap-el+xml Host: xcap.example.com
アプリケーション/ xcap-：名前=％22friends％22％5D /エントリのHTTP / 1.1のContent-Type @ /resource-lists/users/sip:bill@example.com/index / ~~ /リソース・リスト/リスト％5bはPUT EL +のXMLホスト：xcap.example.com
<entry uri="sip:bob@example.com"> <display-name>Bob Jones</display-name> </entry>
<エントリーURI = "SIP：bob@example.com"> <表示名>ボブ・ジョーンズ</表示名> </ entry>の
Figure 26: Resource Lists Document
図26：リソースリストドキュメント
Next, Bill fetches the document (Section 7.3):
次に、ビルは、文書（7.3節）を取り出し：
GET /resource-lists/users/sip:bill@example.com/index HTTP/1.1
GET /resource-lists/users/sip:bill@example.com/index HTTP / 1.1
Figure 27: Fetch Operation
図27：フェッチ操作
And the result is (note how white space text nodes appear in the document):
そして、その結果は、（ノードが文書に表示されますどのように空白のテキストに注意してください）です。
HTTP/1.1 200 OK Etag: "wwhha" Content-Type: application/resource-lists+xml
HTTP / 1.1 200 OKのEtag： "wwhha" のContent-Type：アプリケーション/リソース・リスト+ xmlの
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> <entry uri="sip:bob@example.com"> <display-name>Bob Jones</display-name> </entry></list> </resource-lists>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト"> <リスト名= "友人"> <エントリーのURI = "SIP：bob@example.com"> <表示名>ボブ・ジョーンズ</表示名> </ entry>の</リスト> </資源リスト>
Figure 28: Results of Fetch
図28：フェッチの結果
Next, Bill adds another entry to the list, which is another list that has three entries. This is another element creation (Section 7.4):
次に、ビルは3つのエントリを持っている別のリストで、リストに別のエントリを追加します。これは、他の要素の作成（7.4節）です。
PUT /resource-lists/users/sip:bill@example.com/index/~~/ resource-lists/list%5b@name=%22friends%22%5d/ list%5b@name=%22close-friends%22%5d HTTP/1.1 Content-Type: application/xcap-el+xml Host: xcap.example.com
名前=％22friends％22％5dと/リスト％5bを@ /resource-lists/users/sip:bill@example.com/index/リソース・リスト/リスト％5bにPUT名=％22close-友人％22 @ ％5D HTTP / 1.1のContent-Type：アプリケーション/ XCAP-EL + XMLホスト：xcap.example.com
<list name="close-friends"> <entry uri="sip:joe@example.com"> <display-name>Joe Smith</display-name> </entry> <entry uri="sip:nancy@example.com"> <display-name>Nancy Gross</display-name> </entry> <entry uri="sip:petri@example.com"> <display-name>Petri Aukia</display-name> </entry> </list>
<リスト名= "クローズ友人"> <エントリーのURI = "SIP：joe@example.com"> <表示名>ジョー・スミス</表示名> </ entry>の<エントリーのURI =「SIP：ナンシー@ example.com "> <表示名>ナンシーグロス</表示名> </ entry>の<エントリーのURI =" SIP：petri@example.com "> <表示名>ペトリAukia </表示名> < /エントリ> </リスト>
Figure 29: Adding an Entry
図29：エントリの追加
Then, Bill decides he doesn't want Petri on the list, so he deletes the entry (Section 7.5):
その後、ビルは彼がリストにペトリを望んでいないことを決定ので、彼は、エントリ（7.5節）を削除します。
DELETE /resource-lists/users/sip:bill@example.com/index/ ~~/resource-lists/list/list/ entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1 Host: xcap.example.com
@ URI =％22sip 5bは/resource-lists/users/sip:bill@example.com/index/ ~~ /リソース・リスト/リスト/リスト/エントリ％をDELETE：petri@example.com%22%5d HTTP / 1.1をホスト：xcap.example.com
Figure 30: Deleting an Entry
図30：エントリの削除
Bill decides to check on the URI for Nancy, so he fetches a particular attribute (Section 7.6):
ビルはナンシーのためのURIを確認することを決定したので、彼は特定の属性（7.6節）を取り出し：
GET /resource-lists/users/sip:bill@example.com/index/ ~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1 Host: xcap.example.com
xcap.example.com：/resource-lists/users/sip:bill@example.com/index/ ~~ /リソース・リスト/リスト/リスト/エントリ％5B2％5Dの/ @ URI HTTP / 1.1ホストをGET
Figure 31: Fetching an Attribute
図31：属性の取得
and the server responds:
サーバが応答します。
HTTP/1.1 200 OK Etag: "ad88" Content-Type:application/xcap-att+xml
HTTP / 1.1 200 OKのEtag： "ad88" のContent-Type：アプリケーション/ XCAP-ATT + xmlの
"sip:nancy@example.com"
"SIP：nancy@example.com"
Figure 32: Results of Fetch
図32：フェッチの結果
Frequently, the data manipulated by XCAP contains sensitive information. To avoid eavesdroppers from seeing this information, it is RECOMMENDED that an administrator hand out an HTTPS URI as the XCAP root URI. This will result in TLS-encrypted communications between the client and server, preventing any eavesdropping. Clients MUST implement TLS, assuring that such URIs will be usable by the client.
しばしば、XCAPによって操作されるデータは機密情報が含まれています。この情報を見てから、盗聴を避けるには、管理者がXCAPルートURIとしてHTTPS URIを配ることが推奨されます。これは、任意の盗聴を防止し、クライアントとサーバ間のTLS暗号化通信になります。クライアントは、そのようなURIがクライアントによって使用可能になることを保証する、TLSを実装しなければなりません。
Client and server authentication are also important. A client needs to be sure it is talking to the server it believes it is contacting. Otherwise, it may be given false information, which can lead to denial-of-service attacks against a client. To prevent this, a client SHOULD attempt to upgrade [15] any connections to TLS. Similarly, authorization of read and write operations against the data is important, and this requires client authentication. As a result, a server SHOULD challenge a client using HTTP Digest [11] to establish its identity, and this SHOULD be done over a TLS connection. Clients MUST implement digest authentication, assuring interoperability with servers that challenge the client. Servers MUST NOT perform basic authentication without a TLS connection to the client.
クライアントとサーバー認証も重要です。クライアントは、それが接触していると考えているサーバーに話していることを確認する必要があります。それ以外の場合は、クライアントに対するサービス拒否攻撃につながることができ虚偽の情報を、与えてもよいです。これを防ぐために、クライアントはTLSへの接続を[15]をアップグレードしようとすべきです。同様に、データに対する読み取りおよび書き込み操作の許可が重要であり、これは、クライアント認証を必要とします。その結果、サーバーは、そのアイデンティティを確立するためにHTTPダイジェスト[11]を使用してクライアントにチャレンジすべきで、これはTLS接続を介して行われるべきです。クライアントは、クライアントに挑戦サーバとの相互運用性を確保し、ダイジェスト認証を実装しなければなりません。サーバーは、クライアントへのTLS接続なしで基本認証を行ってはなりません。
Because XCAP is a usage of HTTP and not a separate protocol, it runs on the same port numbers as HTTP traffic normally does. This makes it difficult to apply port-based filtering rules in firewalls to separate the treatment of XCAP traffic from other HTTP traffic.
XCAPは、別のプロトコルHTTPの使用法ではないのでHTTPトラフィックは通常どおり、それは同じポート番号で実行されます。これは、それが困難な他のHTTPトラフィックからのXCAPトラフィックの治療を分離するために、ファイアウォールでポートベースのフィルタリングルールを適用することができます。
However, this problem exists broadly today because HTTP is used to access a wide breadth of content, all on the same port, and XCAP views application configuration documents as just another type of HTTP content. As such, separate treatment of XCAP traffic from other HTTP traffic requires firewalls to examine the URL itself. There is no foolproof way to identify a URL as pointing to an XCAP resource. However, the presence of the double tilde (~~) is a strong hint that the URL points to an XML element or attribute. As always, care must be taken in looking for the double-tilde due to the breadth of ways in which a URI can be encoded on-the-wire [29] [13].
しかし、HTTPはコンテンツの広い幅にアクセスするために使用されているため、この問題は、同じポート上のすべてのは、今日広く存在し、XCAPはHTTPコンテンツのちょうど別のタイプとして、アプリケーション構成の文書を表示します。そのため、他のHTTPトラフィックからのXCAPトラフィックの別の治療は、URL自体を調べるために、ファイアウォールが必要です。 XCAPリソースを指すようURLを識別するために、何の確実な方法はありません。しかし、二重のチルダ（~~）の存在は、XML要素または属性にURLを指していることに強いヒントです。いつものように、注意が原因URIがオン・ザ・ワイヤ符号化することができる方法[29]〜[13]の幅にダブルチルダを探しに注意しなければなりません。
There are several IANA considerations associated with this specification.
この仕様に関連したいくつかのIANAの考慮事項があります。
Per this specification's instructions, IANA created a new registry for XCAP application unique IDs (AUIDs). This registry is defined as a table that contains three columns:
この仕様書の指示に従って、IANAは、XCAPアプリケーション固有のID（AUIDs）のための新しいレジストリを作成しました。このレジストリは、3つの列を含むテーブルのように定義されます。
AUID: This will be a string provided in the IANA registrations into the registry.
AUID：これは、レジストリにIANA登録で提供文字列になります。
Description: This is text that is supplied by the IANA registration into the registry.
説明：これはレジストリにIANA登録によって供給されているテキストです。
Reference: This is a reference to the RFC containing the registration.
参考：これは、登録を含むRFCへの参照です。
Per this specification's instructions, IANA created this table with an initial entry. The resulting table looks like:
この仕様書の指示に従って、IANAは、最初のエントリでこの表を作成しました。結果のテーブルには、次のようになります。
Application Unique
ID (AUID) Description Reference
-------------------- ------------------------------- ---------
xcap-caps Capabilities of an XCAP server RFC 4825
XCAP AUIDs are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication.
それらは標準トラックRFCで公開されているときXCAPのAUIDsは、IANAによって登録されています。 RFCのIANA条項のセクションでは、出版物のRFC番号とともに、IANAレジストリに表示される次の情報を含める必要があります。
o Name of the AUID. The name MAY be of any length, but SHOULD be no more than 20 characters long. The name MUST consist of alphanum and mark [16] characters only.
O AUIDの名前。名前は、任意の長さであり得るが、これ以上20文字以下に長くなければなりません。名前はalphanumで構成されており、[16]の文字だけをマークしなければなりません。
o Descriptive text that describes the application usage.
アプリケーションの使用状況を説明する説明テキストを、O。
This specification requests the registration of several new MIME types according to the procedures of RFC 4288 [8] and guidelines in RFC 3023 [9].
この仕様は、[8] RFC 4288の手順に従って、いくつかの新しいMIMEタイプの登録を要求し、RFC 3023のガイドライン[9]。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xcap-el+xml
MIMEサブタイプ名：XCAP-EL + XMLの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメータ：[9] RFC 3023で指定されるように、application / xmlのcharsetパラメータと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティの考慮事項：[9] RFC 3023のセクション10を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4825
公開された仕様：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML fragment bodies in RFC 4825, the XML Configuration Access Protocol (XCAP).
このドキュメントタイプはRFC 4825でXMLフラグメント体の輸送をサポートするために使用されてきた、XMLコンフィギュレーションアクセスプロトコル（XCAP）：このメディアタイプを使用するアプリケーション。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xel
ファイル拡張子：.xel
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。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xcap-att+xml
MIMEサブタイプ名：XCAP-ATT + xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメータ：[9] RFC 3023で指定されるように、application / xmlのcharsetパラメータと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティの考慮事項：[9] RFC 3023のセクション10を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4825
公開された仕様：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML attribute values in RFC 4825, the XML Configuration Access Protocol (XCAP).
このドキュメントタイプはRFC 4825でXML属性値の輸送をサポートするために使用されてきた、XMLコンフィギュレーションアクセスプロトコル（XCAP）：このメディアタイプを使用するアプリケーション。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xav
ファイル拡張子：奨励
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。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xcap-ns+xml
MIMEサブタイプ名：XCAP-NS + xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメータ：[9] RFC 3023で指定されるように、application / xmlのcharsetパラメータと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティの考慮事項：[9] RFC 3023のセクション10を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4825
公開された仕様：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML fragment bodies in RFC 4825, the XML Configuration Access Protocol (XCAP).
このドキュメントタイプはRFC 4825でXMLフラグメント体の輸送をサポートするために使用されてきた、XMLコンフィギュレーションアクセスプロトコル（XCAP）：このメディアタイプを使用するアプリケーション。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xns
ファイル拡張子：.xns
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。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xcap-error+xml
MIMEサブタイプ名：XCAP-エラー+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメータ：[9] RFC 3023で指定されるように、application / xmlのcharsetパラメータと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティの考慮事項：[9] RFC 3023のセクション10を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4825
公開された仕様：RFC 4825
Applications that use this media type: This document type conveys error conditions defined in RFC 4825
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、RFC 4825で定義されたエラー条件を伝えます
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xer
ファイル拡張子：.xer
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。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: xcap-caps+xml
MIMEサブタイプ名：XCAPキャップ+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメータ：[9] RFC 3023で指定されるように、application / xmlのcharsetパラメータと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティの考慮事項：[9] RFC 3023のセクション10を参照してください。
Interoperability considerations: none
相互運用性に関する注意事項：なし
Published specification: RFC 4825
公開された仕様：RFC 4825
Applications that use this media type: This document type conveys capabilities of an XML Configuration Access Protocol (XCAP) server, as defined in RFC 4825.
RFC 4825で定義されている。このドキュメントタイプは、XMLコンフィギュレーションアクセスプロトコル（XCAP）サーバの機能を伝える：このメディアタイプを使用するアプリケーション。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xca
ファイル拡張子：.xca
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。
This specification registers several new XML namespaces, as per the guidelines in RFC 3688 [17].
この仕様はRFC 3688 [17]のガイドラインに従って、いくつかの新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error
URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：XCAP-エラー
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
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 Error Namespace</title> </head> <body> <h1>Namespace for XCAP Error Documents</h1> <h2>urn:ietf:params:xml:ns:xcap-error</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt"> RFC4825</a></p> </body> </html> END
！XML：BEGIN <？xmlのバージョン= "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 = XCAPエラー文書のISO-8859-1" /> <タイトル> XCAPエラー名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS： XCAP-エラー</ H2> <P> </a>の</ P> </ BODY> </ <a href="http://www.rfc-editor.org/rfc/rfc4825.txt"> RFC4825を参照してください。 HTML> END
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps
URI：この名前空間のURIはURNです：IETF：のparams：XML：NS：XCAPキャップ
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
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 Capabilities Namespace</title> </head> <body> <h1>Namespace for XCAP Capability Documents</h1> <h2>urn:ietf:params:xml:ns:xcap-caps</h2> <p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt"> RFC4825</a></p> </body> </html> END
！XML：BEGIN <？xmlのバージョン= "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 = XCAP能力ドキュメントのISO-8859-1" /> <タイトル> XCAP機能の名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS： XCAP-キャップ</ H2> <P> </a>の</ P> </ BODY> </ <a href="http://www.rfc-editor.org/rfc/rfc4825.txt"> RFC4825を参照してください。 HTML> END
This section registers two XML schemas per the procedures in [17].
このセクションでは、[17]の手順ごとに2つのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:xcap-error
URI：URN：IETF：のparams：XML：スキーマ：XCAP-エラー
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
XML Schema: The XML for this schema can be found as the sole content of Section 11.2.
XMLスキーマ：このスキーマのXMLは、セクション11.2の唯一の内容として求めることができます。
URI: urn:ietf:params:xml:schema:xcap-caps
URI：URN：IETF：のparams：XML：スキーマ：XCAPキャップ
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（jdrosen@jdrosen.net）。
XML Schema: The XML for this schema can be found as the sole content of Section 12.2.
XMLスキーマ：このスキーマのXMLは、セクション12.2の唯一の内容として求めることができます。
The author would like to thank Jari Urpalainen, who has contributed many important comments and has assisted with edit passes in the document. The author would also like to thank Ben Campbell, Eva-Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern, Lisa Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian Schmidt, and Spencer Dawkins for their input and comments. A special thanks to Ted Hardie for his input and support.
著者は、多くの重要なコメントを貢献してきましたし、文書の編集パスで支援してきましたヤリUrpalainenを、感謝したいと思います。著者はまた、彼らの入力とコメントのためにベン・キャンベル、エヴァ・マリア・Leppanen、ヒシャムKhartabil、クリス・ニューマン、ジョエル・ハルパーン、リサDusseault、ティム・ブレイ、ピートコーデル、イェルーンバンBemmel、クリスチャン・シュミット、およびスペンサードーキンスに感謝したいと思います。彼の入力やサポートのためのテッドハーディーへの特別な感謝。
[1] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
[1] MALER、E.、Yergeau、F.、パオリ、J.、ブレイ、T.、およびC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0（第3版）"、ワールドワイドウェブコンソーシアムFirstEdition REC -xml-20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml-20040204>。
[2] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[2]トンプソン、H.、マロニー、M.、メンデルゾーン、N.、およびD.ブナ、 "XMLスキーマパート1：構造第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-1から20041028、2004年10月、 <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。
[3] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3]素人、A.、オランダ、D.、およびT.ブレイ、 "XMLで名前空間"、ワールド・ワイド・ウェブ・コンソーシアムFirstEdition REC-XML-名-19990114、1999年1月、<http://www.w3.org / TR / 1999 / REC-XML-名-19990114>。
[4] Daniel, R., DeRose, S., Maler, E., and J. Marsh, "XPointer xmlns() Scheme", World Wide Web Consortium Recommendation REC-xptr-xmlns-20030325, March 2003, <http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325>.
[4]ダニエル、R.、DeRose、S.、MALER、E.、およびJ.マーシュ、 "のXPointerのxmlns（）スキーム"、World Wide Web Consortium（W3C）の勧告REC-XPTR-のxmlns-20030325、2003年3月、<のhttp： //www.w3.org/TR/2003/REC-xptr-xmlns-20030325>。
[5] Grosso, P., Marsh, J., Maler, E., and N. Walsh, "XPointer Framework", World Wide Web Consortium Recommendation REC-xptr-framework-20030325, March 2003, <http://www.w3.org/TR/2003/REC-xptr-framework-20030325>.
[5]グロッソ、P.、マーシュ、J.、MALER、E.、およびN.ウォルシュ、 "XPointerのフレームワーク"、World Wide Web Consortium（W3C）の勧告REC-XPTRフレームワーク-20030325、2003年3月、<のhttp：// WWW .w3.org / TR / 2003 / REC-XPTRフレームワーク-20030325>。
[6] 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.
[6]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8]フリード、N.とJ. Klensin、 "メディアタイプの仕様と登録手順"、BCP 13、RFC 4288、2005年12月。
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[10] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[10]クラーク、J.とS. DeRose、 "XMLパス言語（XPath）バージョン1.0"、World Wide Web Consortium（W3C）の勧告REC-のxpath-19991116、1999年11月、<http://www.w3.org/TR/ 1999 / REC-のxpath-19991116>。
[11] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[11]フランクス、J.、ハラム・ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、 "HTTP認証：基本とダイジェストアクセス認証" 、RFC 2617、1999年6月。
[12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[12]クロッカー、D.、エド。そして、P. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[13]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、STD 66、RFC 3986、2005年1月。
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[14]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[15] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[15] Khare、R.およびS.ローレンス、 "HTTP / 1.1内でTLSへのアップグレード"、RFC 2817、2000年5月。
[16] 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.
[16]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[17] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[17] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[18] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[19] 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>.
[19]ボイヤー、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>。
[20] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[20]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
[21] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[21]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。
[22] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[22]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）リソースリストを表現するための形式"、RFC 4826、2007年5月。
[23] Grosso, P. and D. Veillard, "XML Fragment Interchange", World Wide Web Consortium CR CR-xml-fragment-20010212, February 2001, <http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[23]グロッソ、P。およびD. Veillard、 "XMLフラグメントインターチェンジ"、ワールドワイドウェブコンソーシアムCR CR-XMLフラグメント-20010212、2001年2月、<http://www.w3.org/TR/2001/CR -xml-フラグメント-20010212>。
[24] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium CR http://www.w3.org/TR/2005/CR-xpath20-20051103, November 2005.
[24]ベルグルンド、A.、ボーグ、S.、チェン、D.、フェルナンデス、M.、ケイ、M.、Robie、J.、およびJ.シメオン、 "XMLパス言語（XPath）2.0"、ワールド・ワイド・WebコンソーシアムCR http://www.w3.org/TR/2005/CR-xpath20-20051103、2005年11月。
[25] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[25]ニューマン、C.及びJ.マイヤーズ、 "ACAP - アプリケーション構成アクセスプロトコル"、RFC 2244、1997年11月。
[26] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[26]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[27] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
、BCP 26、RFC 2434、1998年10月[27] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"。
[28] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[28]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[29] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[29] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
Author's Address
著者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。