[要約] RFC 4825は、XML Configuration Access Protocol（XCAP）に関する規格であり、XMLベースの設定データへのアクセスと編集を可能にする。目的は、ネットワーク上のデバイスやアプリケーションの設定を効率的に管理すること。
Network Working Group J. Rosenberg
Request for Comments: 4825 Cisco
Category: Standards Track May 2007
The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
拡張可能なマークアップ言語（XML）構成アクセスプロトコル（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）The IETF Trust（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形式で保存されているアプリケーション構成データを読み取り、書き込み、変更できます。XCAPマップXMLドキュメントサブツリーと要素属性をHTTP URISにマップするため、これらのコンポーネントはHTTPで直接アクセスできます。
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.
Voice over 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.
ユーザーごとの情報には多くの例があります。1つは存在[20]認証ポリシーです。これは、どのウォッチャーがプレゼンテーションを購読することを許可されているか、およびアクセスを許可されている情報を定義します。もう1つは存在リストです。これは、ウォッチャーが存在するユーザーのリストです[26]。リストの存在情報を取得する1つの方法は、そのリスト[21]を表すリソースを購読することです。この場合、リソースリストサーバー（RLS）は、SIP [16]サブスクライブ[28]リクエストを処理するために、このリストへのアクセスが必要です。リストのユーザーの存在感を取得する別の方法は、ウォッチャーが各ユーザーを個別に購読することです。その場合、サーバーにリストを保存すると便利です。クライアントが起動すると、サーバーからリストを取得します。これにより、ユーザーはさまざまなクライアントからリソースリストにアクセスできます。
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は、XMLドキュメントをマッピングし、コンポーネントをHTTP URIにドキュメントするための一連の規則、あるリソースの変更が別のリソースにどのように影響するかについてのルール、データ検証の制約、およびそれらのリソースへのアクセスに関連する認証ポリシーです。この構造により、通常の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を構築するためのアルゴリズムを定義します。コンポーネントは、ドキュメント内の任意の要素または属性を指します。したがって、XCAPで使用されるHTTP URIは、ドキュメント、またはXMLドキュメント自体よりも細かい粒子である情報の断片に使用されます。ここで定義されている命名規則と検証の制約に従う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削除でリソースの1つを削除します。XCAPリソースは、処理スクリプトを表しません。その結果、XCAPリソースを表すHTTP URIのポスト操作は定義されていません。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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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ドキュメントを表すHTTPリソース、XMLドキュメント内の要素、またはXCAPの命名および検証制約に続くXMLドキュメント内の要素の属性。
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）：アプリケーションの名前空間内の一意の識別子。この仕様によって作成された一意のIDSは、あるアプリケーションが別のアプリケーションからアクセスしたXCAPリソースからアクセスしたXCAPリソースを区別します。
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では、特定のドキュメントの選択が行われます。その結果、ドキュメントに対してGETを実行すると、URIがドキュメントを取得します。
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：XCAPルート、ドキュメントセレクター、ノードセレクターセレクター、およびノードセレクターを含むHTTP URIにより、特定のXMLノードの選択が行われます。
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.
グローバルツリー：特定のXCAPルート内の特定のアプリケーション使用に関するすべてのグローバルドキュメントの親を表すURI。
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.
位置挿入：同じ親の他の子供と比較してその位置がクライアントによって設定されるように、ドキュメントに新しい要素を挿入するようにするプット操作。
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リソースは、アプリケーションに関連付けられています。アプリケーションがこれらのリソースを使用するには、アプリケーション固有の規則を指定する必要があります。これらの規則には、データの構造と制約を定義するXMLスキーマ、よく知られているURIがデータへのアクセスをブートストラップするなどです。これらのアプリケーション固有の規則はすべて、アプリケーションの使用法によって定義されます。
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）と呼ばれる名前に関連付けられています。この名前は、アプリケーション使用の名前空間内のアプリケーションの使用法を一意に識別し、他のアプリケーションで使用されるAUIDとは異なります。AUIDは2つの名前空間のいずれかに存在します。ファーストネームスペースはIETFネームスペースです。この名前空間には一連のトークンが含まれており、それぞれがIANAに登録されています。これらの登録は、セクション15のガイドラインに基づいて、RFCS [27]を追跡する標準トラックの公開で発生します。2番目の名前空間は、ベンダー専用の名前空間です。その名前空間の各AUIDには、AUIDを作成する組織の逆ドメイン名が付いていて、その後の期間が続き、その後にベンダーが定義されたトークンが続きます。例として、example.comドメインは、値「com.example.foo」を持つauidを作成できますが、値「org.example.foo」を持つ値を作成することはできません。ベンダーの名前空間内のauidsは、ianaに登録する必要はありません。ベンダーの名前空間は、中央のレジストリが不要なラボ環境でも使用することを目的としています。abnf [12]で表されるauidsの構文（およびRFC 3986 [13]で定義されているBNFの一部を使用）は次のとおりです。
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 / "-" / "_" / "~"
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で定義されたPCHER生産のサブセットです。特に、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.
XCAPサーバーがURIをドキュメントの要素または属性に一致させるには、URI内で使用されるXMLネームスペースのプレフィックスを拡張する必要があります[3]。この拡張には、名前空間バインディングコンテキストが必要です。そのコンテキストは、名前空間のプレフィックスをネームスペースURISにマップします。また、名前空間のプレフィックスなしでURIの要素に適用されるデフォルトの名前空間を定義します。名前空間バインディングコンテキストは、2つのソースからのものです。まず、名前空間URISへの名前空間プレフィックスのマッピングは、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サーバーの責任の1つは、XCAPクライアントが変更を試みたときに各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つだけあることが必要です。各ユニーク性の制約は、一意である必要があるフィールドまたはフィールドの組み合わせを識別し、その一意性が適用される範囲を識別することによって指定する必要があります。典型的な範囲の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参照は、Base 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のサブスクライブリクエストを受信したときに、RLSがリソースリストの内容を取得できます。アプリケーションの使用法は、サービス定義のリストが、グローバルツリー内に特定の名前を持つ特定のドキュメント内に存在することを指定します。これにより、RLSは単一のXCAP要求を実行して、SIP URIに関連付けられているサービス定義をサブスクライブリクエストで取得できます。
Naming conventions are used by XCAP clients to construct their URIs. The XCAP server does not make use of them.
命名規則は、XCAPクライアントによってURIを構築するために使用されます。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リソースを変更すると、他の多くのリソースのコンテンツが影響を受けます。たとえば、ユーザーがドキュメント内のXML要素を削除する場合、要素リソースに対してURIに対して削除要求を発行することでそうします。ただし、この要素を削除すると、すべての子要素とその属性も削除され、それぞれがXCAPリソースでもあります。そのため、1つのリソースの操作は、他のリソースの状態に影響します。
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サービスドキュメント内に新しい<Service>要素が作成されます）、サーバーは、サーバーが維持しているサービスの読み取り専用グローバルリストにその要素を追加します。グローバルツリー。この読み取り専用のグローバルリストは、SIPサブスクライブリクエストを処理する際に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 XMLスキーマ
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処理を再構築する必要があります。それ以外の場合、クライアントは、プットするたびにドキュメントを再獲得することを余儀なくされます。これは非効率的です。そのため、クライアントがドキュメントのコピーをキャッシュする必要なく、一般的な操作を実行できるようにスキーマを設計することをお勧めします。
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はゼロまたは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の平等は通常複雑です。ただし、属性の等式は、XMLルールを使用してサーバーによって実行されます。これは、ケースに敏感な文字列比較に基づいています。したがって、XCAPは、機能的平等ではなく、語彙の平等に基づいてURISと一致します。そのような場合、アプリケーションの使用はこれらの意味を慎重に考慮する必要があります。
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に適しています。このような変更を加えるには、単一のプットが必要です。後者の場合、ドキュメント全体を置き換える必要があり（これは単一の操作です）、または2つのプット操作が必要です。1つはユーザーを古い許可から削除し、1つはユーザーを新しい許可に追加するために1つを追加する必要があります。。
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.
命名規則は、アプリケーション使用の設計のもう1つの重要な部分を形成します。アプリケーションの使用法は、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 [13]のセクション2.3でアドバイスされているように、ダブルチルド（ "~~"）の値を持つパスセグメントであり、エンコードパーセントではありません。％7e％7eを含むurisは、比較のために~~に正規化する必要があります。それらは同等です。ノードセレクターセパレーターは、ドキュメントセレクターをノードセレクターから分離する構文糖です。ノードセレクターは、要素や属性などのドキュメントのコンポーネントを識別する式です。「~~」がノードセレクター自体の一部として表示される可能性があります。そのような場合、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リクエストを生成すると、RFC 2616リクエスト-URI適用の構築の手順が適用されます。特に、リクエストがOrigin Serverに直接送信された場合、URIの権限コンポーネントはリクエスト-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ルート内でドキュメントを整理するための階層構造を定義します。最初のパスセグメントは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.
o HTTPサーブレットを使用する実装者は、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の下には2つのサブツリーがあります。「ユーザー」と呼ばれる1つは、特定のユーザーに適用されるドキュメントを保持し、もう1つは「グローバル」と呼ばれ、すべてのユーザーに適用されるドキュメントを保持します。「グローバル」の下のサブツリーは、グローバルツリーと呼ばれます。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の値でプロビジョニングされます。SIPアプリケーションをサポートするシステムの場合、XUIはユーザー（つまり、sip：joe@example.com）のrecordアドレス（aor）に等しくなることをお勧めします。SIPエンドポイントは一般に自分のAORを知っているため、XUIも知っています。結果として、XUIが明示的にプロビジョニングされていない場合、SIPユーザーエージェントはAORに等しいと仮定する必要があります。このXUIは、「ユーザー」セグメントの下のパスセグメントとして使用する必要があります。SIP URIは、HTTP URIパスセグメント（ '？'や '/'文字など、SIP 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サービスによって定義されたインデックスドキュメント内で、<Service>要素には、ユーザーホームディレクトリ内のリソースリストをコンテンツが指している<sourceList>と呼ばれる子要素があります。
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 "http://xcap.example.com/Resource-lists/users/ sip：joe@example.com/index"が生成されます。この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 "/"
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文法はXMLネームスペース[3]仕様で定義されており、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.
XCAPにとって意味のある二重引用符、左四角いブラケット、右側の四角いブラケット文字は、HTTP URIで直接表現できないことに注意してください。その結果、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生産を定義します。残念ながら、これらのプロダクションで許可されているキャラクターには、PCHAに許可されていないものが含まれています。AttValueプロダクションにより、スペースを含む米国ASCIIセット内の多くのキャラクターが許可されます。これらのキャラクターは、URIに配置された場合、パーセントエンコードされている必要があります。さらに、QNameとAttValueは、US-ASCII以外の多くのユニコード文字を許可します。これらのキャラクターをHTTP URIで表現する必要がある場合、それらはパーセントエンコードされています。これを行うには、データを最初にUTF-8文字エンコード[18]に従ってオクテットとしてエンコードする必要があります。次に、PCHARセットの文字に対応しないオクテットのみをパーセントエンコードする必要があります。たとえば、キャラクターAは「A」として表され、キャラクターラテンキャピタルレターAが墓をaが「％C3％80」として表され、キャラクターのカタカナ文字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.
その結果、上記の文法は、XCAPサーバーがURIをデコードした後に内部的に処理された式を表します。ワイヤの形式は、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.
述語のコンテンツが属性名と値である場合、その名前と値を持つ属性を所有するすべての要素が選択され、他のすべてが廃棄されます。ドキュメントは要素内の名前空間宣言を持つことができますが、これらの要素は、述語として名前空間宣言を使用して選択できないことに注意してください。つまり、「eL-name [@xmlns = 'namespace']」のようなステップは、「名前空間」のデフォルトの名前空間を指定する要素がある場合でも、要素と一致することはありません。言い換えれば、名前空間ノードは属性ではありません。要素の範囲内の名前空間が必要な場合は、以下に説明する名前空間セレクターを使用して選択できます。指定された名前と値を持つ属性を持つ要素がない場合、結果は試合なしです。
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.
述語が適用された後、結果は一致なし、1つの要素、または複数の要素になります。結果が複数の要素の場合、ノードセレクターは無効です。ノードセレクターの各ステップは、次のステップのコンテキストを形成するために単一の要素を作成する必要があります。これは、コンテキストが複数のノードを含むことを可能にする一般的な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 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].
要素名の一致は次のように実行されます。ステップで比較される要素の名前は、XMLネームスペースで説明されているように拡張されています[3]。ステップの要素名も拡張されています。この拡張では、名前空間プレフィックスが名前空間URIに変換される必要があります。それを行うには、接頭辞からURISの名前を付けるまでのバインディングのセットが必要です。このバインディングのセットは、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.
コメント、テキストコンテンツ（Whitespaceを含む）、および処理手順はドキュメントに存在できますが、ここで定義されている式で選択することはできません。もちろん、そのような情報がドキュメントに存在し、ユーザーがそのデータを囲むXML要素を選択している場合、その情報は結果のGETに含まれます。さらに、空白はXCAPから尊敬されています。クライアントがWhitespaceを含む要素またはドキュメントを配置すると、サーバーはそのWhitespaceを保持し、要素またはドキュメントをまったく同じWhitespaceでクライアントに戻します。同様に、要素が挿入されると、挿入された要素の周りに追加の空白が追加されず、その周りの白人、コメント、または処理命令に比べて非常に特定の場所に要素が挿入されます。セクション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>
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：xml：watcherinfo」であると仮定すると、ノードセレクターwatcherinfo/watcher-list/watcher [@id = "8ajksjda7s"]が次のXML要素を選択します。
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
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式は、元々URISのフラグメント識別子内で使用するために設計されたことに注意してください。ただし、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>
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：test：default-namespace」のデフォルトのドキュメント名空間を定義します。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)
will select the first <baz> child element of the <bar> element in the document. The XCAP URI:
ドキュメント内の<bar>要素の最初の<baz>子要素を選択します。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)
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:
ドキュメント内の<bar>要素の2番目の<baz>子要素を選択します。次のXCAP URIは、ドキュメント内の<bar>要素の2番目の<baz>子要素も選択します。
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)
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.
ドキュメント、要素、または属性リソースを削除または挿入することにより、クライアントがドキュメントを変更するすべての場合において、クライアントは、操作が成功する場合、結果のドキュメントがアプリケーションの使用法によって定義されたデータ制約を満たすことを確認する必要があります。スキーマ検証。たとえば、クライアントが「http://xcap.example.com/rls-services/ users/sip：joe@example.com/mybuddies」のプット操作を実行する場合、rls-servicesはアプリケーションユニークな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でそれを拒否します。409応答には、セクション11.2のスキーマに従ってフォーマットされたXMLボディが含まれている場合があります。エラー。クライアントは、この情報を使用してリクエストを変更して、今回は成功する可能性があります。クライアントは、クライアントの一部を変更せずに単にリクエストを再試行する必要はありません。
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.
場合によっては、アプリケーションの使用は、クライアントがそれ自体で保証できないという独自性の制約を決定します。そのような例の1つは、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は、リクエストを配置および削除することも指定します。これは、クライアントがドキュメントのプットを実行し、成功すると同じプットを実行でき、結果のドキュメントが同じように見えることを意味します。同様に、クライアントが削除を実行すると、成功した場合、同じURIへの後続の削除が404を生成します。リソースは、以前の削除操作によって削除されたため、サーバーに存在しなくなりました。このプロパティを維持するために、クライアントは、変更が行われた後、リクエストのURIがプット用に挿入されたリソース（つまり、リクエストの本文）を指すように、そのURIを構築する必要があります。削除用。このプロパティが維持されている場合、PutのURIに到達するのは同じコンテンツ（つまり、Get（Put（x））== x）を返します。このプロパティは、識別力を意味します。このプロパティを所有していない場合、リクエストは依然としてiDempotentになる可能性がありますが、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]ドキュメントの「アプリケーション/RLSサービスXML」であり、「アプリケーション/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がサーバーに既に存在するドキュメントを識別した場合、プット操作はそのドキュメントをリクエストのコンテンツに置き換えます。Request-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の削除操作を呼び出して、ドキュメントを削除します。
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 Requestを実行することにより、ドキュメントの取得が些細なことに達成されます。
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.
ここで、「親」は、挿入される要素の親の式です。「位置」は、新しい要素を挿入するこの親の既存の子要素の間の位置です。「Asite-Attribute-Value」は、挿入される要素の属性名と値であり、「位置」の現在の要素とは異なります。2番目の述語が必要であるため、現在の子供に対して評価されたときに全体的な式が一致しないようにします。それ以外の場合、プットはその位置の既存の要素を置き換えます。WildCard "*"に加えて、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>.
図3のドキュメントの例を考えてみましょう。クライアントは、<watcher-list>の下の2番目の要素として新しい<watcher>要素を挿入したいと考えています。ただし、WatcherInfo/Watcher-List/*[2]ノードセレクターでURIに配置することはできません。このノードセレクターは、<watcher-list>の既存の2番目の子要素を選択し、それを置き換えます。したがって、プットは、watcherinfo/ watcher-list/*[2] [2] [@id = "hhggff"]を使用してURIに作成する必要があります。ここで、「hhggff」は「id」属性の値です。挿入する新しい要素。このノードセレクターは、現在のドキュメントに対する一致なしであり、<watcher-list>の2番目の子要素として挿入された場合、新しい要素と一致します。
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).
「*」は、<watcher-info>のすべての要素の子供が挿入の位置を計算するときに考慮されるべきであることを示します。ワイルドカード *の代わりに、要素名（QNAME）が存在していた場合、上記の式は、挿入ルールに関する議論については、同じ拡張名のある要素の中の位置要素として新しい要素として新しい要素として挿入されます。）。
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」でなければなりません。ノードセレクターが現在のドキュメントに対して評価された場合、ノーマッチになった場合、サーバーは作成操作を実行します。Nodeセレクターが現在のドキュメントに対して評価された場合、現在のドキュメントの要素と一致する場合、サーバーはそれを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の最終パスセグメントの属性がリクエストの本体の要素の属性と一致することを確認できます。このプロパティを持たず、したがって等ではないリクエストの例として、次のプットリクエストを検討してください（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
<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>
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).
この要求は409で失敗します。リクエストURIには、属性に基づいた述語を持つ最終パスセグメントが含まれています： @uri = "sip：good-friends@example.com"。ただし、これはボディの要素の「uri」属性の値と一致しません（sip：mybuddies@example.com）。
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が要素を選択する目的でその属性の以前の値を使用していたノードセレクターを含む場合、唯一の一意の要素識別子である属性の新しい値を持つ要素に置き換えることはできません。これは、上記の例のまさにユースケースです。この制限を回避するために、選択は属性値の代わりに位置で実行できます。または、交換する要素の親を選択することができ、プット操作の本体には、交換する親、子供が含まれます。そして他のすべての兄弟。
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.
一意の属性名と値を使用せずに位置の削除が可能ですが、限られた場合の場合にのみ等隊が保証されています。特に、削除操作が名前と位置だけで要素を指す場合（親/elname [n]）、削除する要素がその名前のすべての兄弟の中で最後の要素である場合にのみ許可されます。同様に、削除操作が位置単独で要素を指す場合（親/*[n]）、これは、削除される要素がすべての兄弟要素の中で最後である場合にのみ許可されます。
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削除メソッドを呼び出します。サーバーは、ドキュメントから要素を削除します（属性、名前空間宣言、および子などの子孫ノードを含む）。
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の文法に準拠している必要があります。URIにAttValueが存在する場合とは異なり、体のパーセントエンコードはないことに注意してください。この要求は、セクション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プロパティがあることを確認するために、クライアントは、属性が挿入されている要素を選択するパスセグメントの属性の述語が、1つとは異なる属性と一致することを確認できます。リクエストによって挿入されています。このプロパティを持たず、したがって等ではないリクエストの例として、次のプットリクエストを検討してください（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
"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削除メソッドを呼び出します。サーバーはドキュメントから属性を削除します。
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コンテンツを構築するために名前空間バインディングを知る必要があります。クライアントがドキュメントのキャッシュコピーを持っている場合、バインディングがわかります。ただし、ドキュメント全体がキャッシュされていない場合は、その後のプットリクエストを作成するために、要素を範囲のバインディングだけを取得すると便利です。
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応答には、名前空間定義を備えた「Application/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.
クライアントは、要素のスコープで名前空間プレフィックスを設定することはできません。そのため、名前空間プレフィックスを識別するノードセレクターは、プットまたは削除要求に表示されてはなりません。
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-none-noneおよび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マッチヘッダーフィールドを含めることができます、ドキュメント内のすべてのリソースに対してクライアントに知られているエンティティタグの値を含む。ドキュメントが変更された場合、サーバーは412の応答でこのリクエストを拒否します。その場合、クライアントは、キャッシュバージョンをフラッシュし、ドキュメント全体を取得し、200 OKでサーバーによって返された新しいエンティティタグをGETリクエストに保存する必要があります。その後、リクエストを再試行して、新しいエンティティタグを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.
クライアントは、削除リクエストにIFマッチヘッダーフィールドを含めることにより、要素または属性を条件付きで削除することもできます。削除に対する200のOK応答には、削除要求によって識別されたリソースが存在しなくなった場合でも、ドキュメント内の他のすべてのリソースのエンティティタグを含む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.
クライアントが条件付きプット操作と削除操作を使用すると、これらの変更をローカルキャッシュコピーに適用し、応答で返されたETAGヘッダーフィールドに基づいてローカルにキャッシュされたコピーのエンティティタグの値を更新できます。他のクライアントがドキュメントを変更しようとしない限り、クライアントは、ドキュメントとそのエンティティタグをサーバーと同期するために個別の操作を実行することなく、ドキュメントで条件付き操作を実行できます。別のクライアントがドキュメントを変更しようとする場合、これは条件付きメカニズムによって検出され、クライアントは、変更について学習する他の手段がない限り、コピーを再同期させるために実行する必要があります。
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リクエストに、ドキュメントのクライアントが保持している現在のETAGに等しい値を持つIF-Noneマッチヘッダーフィールドを含めることによって行われます。サーバーが保持しているサーバーが保持している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準拠のOrigin Serverです。この仕様によって義務付けられている動作は、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、RFC 2818を介してHTTPを実装する必要があります[14]。管理者は、Digestクライアント認証が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のポスト操作は定義されていません。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.
PUTリクエストを受け取ったサーバーの動作は、HTTP/1.1、セクション9.6で指定されているとおりです。リクエストの内容は指定された場所に配置されます。このセクションでは、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メソッドを含む許可ヘッダーフィールドを含める必要があります。
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は親ウリと呼ばれます。削除されたパスセグメントはターゲットセレクターと呼ばれ、ノード（要素、ドキュメント、または属性）がターゲットノードと呼ばれます。
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の応答を返す必要があり、<No-Parent>要素を含む詳細な競合レポートを含める必要があります。詳細な競合レポートについては、セクション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の応答を返す必要があり、<No-Parent>要素を含む詳細な競合レポートを含める必要があります。それが存在する場合、ノードセレクターが抽出されてデコードされます（ノードセレクターがパーセントエンコードされていることを思い出してください）。ノードセレクターは、セクション6.3で説明した一致操作に基づいてドキュメントに適用されます。結果がマッチまたは無効である場合、サーバーは409の応答を返す必要があり、<No-Parent>要素を含む詳細な競合レポートを含める必要があります。
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 Requestがドキュメントの場合（リクエストURIにノードセレクターセパレーターがなかった）場合、リクエスト本体のコンテンツは、適切に形成されたXMLドキュメントでなければなりません。そうでない場合、サーバーは409の応答コードでリクエストを拒否する必要があります。その応答には、<not-well-formed>要素を含む詳細な紛争レポートを含める必要があります。ドキュメントがよく形成されているが、UTF-8エンコードされていない場合、サーバーは409応答コードでリクエストを拒否する必要があります。その応答には、<not-UTF-8>要素を含む詳細な紛争レポートを含める必要があります。リクエストのコンテンツタイプのヘッダーフィールドの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.
プット要求が要素の場合、リクエスト本文の内容は、XMLフラグメントインターチェンジ[23]仕様のXMLフラグメントボディとしても知られるXMLドキュメントのバランスの取れた領域でなければなりません。。そうでない場合、サーバーは409の応答コードでリクエストを拒否する必要があります。その応答には、<not-xml-frag>要素を含む詳細な競合レポートを含める必要があります。フラグメント本体がバランスが取れているが、UTF-8文字セットの外側に文字が含まれている場合、サーバーは409応答コードでリクエストを拒否する必要があります。その応答には、<not-UTF-8>要素を含む詳細な紛争レポートを含める必要があります。リクエストのコンテンツタイプのヘッダーフィールドの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.
プット要求が属性の場合、リクエスト本体のコンテンツは、上記のようにAttValueの文法に準拠する一連の文字でなければなりません。そうでない場合、サーバーは409の応答コードでリクエストを拒否する必要があります。その応答には、<not-xml-att-value>要素を含む詳細な紛争レポートを含める必要があります。属性値が有効であるが、UTF-8文字セットの外側に文字が含まれている場合、サーバーは409応答コードでリクエストを拒否する必要があります。その応答には、<Not-UTF-8>要素を含む詳細な競合レポートを含める必要があります。リクエストのコンテンツタイプのヘッダーフィールドのMIMEタイプが「アプリケーション/XCAP-ATT XML」と等しくない場合、サーバーは拒否する必要があります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.
パット要求がドキュメントの場合、リクエスト本文のコンテンツがディレクトリに配置され、そのファイル名はドキュメントであるターゲットノードに関連付けられています。
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 Requestが要素の場合、サーバーは、セクション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.
第二に、ドキュメントに既に同じ名前が付いた兄弟要素があるが、挿入が位置的に制約されていない場合、サーバーは「最も早い最後の」位置にあるように要素を挿入する必要があります。「最古の最後」とは、同じ拡張名でその後の要素がないように新しい要素を挿入する必要があり、これが真であるすべての挿入位置について、多くの兄弟ノード（要素、コメント、テキスト、または処理命令）は、できる限りその後表示されます。このケースは、ターゲットセレクターがBYNAMEまたはBY-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」位置にあるように要素を挿入する必要があります。n> 1とnameofanyがワイルドカードではない場合、同じ拡張名でn-1兄弟要素がn-1兄弟要素があるように要素を挿入する必要があります。同じ拡張名のn-1兄弟要素がない場合、リクエストは失敗します。n> 1と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:
実際には、この挿入ロジックは、同じ拡張された名前を密接に伴う要素を維持します。これにより、コンテンツモデルが<sequence>ルールとmaxoccurs = "unbounded"枢機inalで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>
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>要素が含まれ、その後にいくつかの<bar>要素が含まれます。<bar>または<foo>のいずれかの要素は、ワイルドカードや位置の制約なしで簡単に追加できます。<foo>要素の「minoccurs」の枢機inalがゼロであり、<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>
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 = "third"/>であり、ノードセレクターがroot/el1 [@att = "third"]であるリクエストは、次のドキュメントになります。
<?xml version="1.0"?> <root> <el1 att="first"/> <el1 att="second"/><el1 att="third"/> <!-- comment --> <el2 att="first"/> </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"].
<？xml version = "1.0"？> <root> <el1 att = "first"/> <el1 att = "second"/> <el1 att = "third"/> <！ - コメント - > <el2att = "first"/> </root>ドキュメント内の3番目の<EL1>要素として、およびコメントと白色ノードの直前にどのように挿入されたかに注目してください。ノードセレクターがroot/el1 [3] [@att = "3番目"]または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 = "first"/>であり、ノードセレクターがroot/el3であった場合、次のドキュメントになります。
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
<el3 att="first"/></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"/>であり、ノードセレクターがroot/el2 [@att = "2"]であるプット要求は、次のドキュメントになります。
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/><el2 att="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:
ノードセレクターがroot/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> Lastly, if the node selector had been root/el2[1][@att="2"] the result would be:
<？xml version = "1.0"？> <root> <el1 att = "first"/> <el2 att = "2"/> <el1 att = "second"/> <！ - コメント - > <el2att = "first"/> </root>最後に、ノードセレクターがroot/el2 [1] [@att = "2"]だった場合、結果は次のとおりです。
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="2"/><el2 att="first"/>
</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が評価されたときに、リクエストで提供されたコンテンツを返すように要素を挿入できない可能性があります。このようなリクエストは許可されていません。これは、本体の要素がターゲットセレクターの式によって記述されない場合に発生します。このケースの例については、セクション7.4で説明します。これが発生した場合、サーバーは挿入を実行してはならず、409の応答でリクエストを拒否する必要があります。応答の本文には、<Cann-Insert>要素を含む詳細な競合レポートを含める必要があります。挿入の実行中はスキーマコンプライアンスが役割を果たさないことに注意することが重要です。つまり、要素が挿入される場所の決定は、要求-RIの構造、現在の文書、およびこの仕様のルールによって完全に決定されます。
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.
プット要求が属性の場合、サーバーは要求本体のコンテンツを属性の値として挿入します。属性の名前は、ターゲットセレクターの属性セレクターのatt-nameに等しくなります。
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.
プット要求がドキュメントの場合、リクエスト本文のコンテンツがディレクトリに配置され、ドキュメントを同じファイル名に置き換えます。
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 Requestが要素の場合、サーバーはターゲットノードをリクエスト本文のコンテンツに置き換えます。作成の場合のように、交換後、リクエストURIが挿入されたばかりの要素を選択しない可能性があります。これが発生した場合、サーバーは交換を実行する必要はなく、409の応答でリクエストを拒否する必要があります。応答の本文には、<Cann-Insert>要素を含む詳細な競合レポートを含める必要があります。
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.
プット要求が属性の場合、サーバーは選択した属性の値を要求本体のコンテンツに設定します。交換ケースでは（作成の場合はそうではありません）、属性を置き換えた後、リクエストURIが置換されたばかりの属性を選択しなくなる可能性があります。これが起こる可能性のあるシナリオについては、セクション7.7で説明します。この場合、サーバーは交換を実行してはならず、409の応答でリクエストを拒否する必要があります。応答の本文には、<Cann-Insert>要素を含む詳細な競合レポートを含める必要があります。
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の制約やその他の非スキーマデータの制約もチェックします。ドキュメントがこれらの制約のいずれかに故障した場合、サーバーは挿入を実行してはなりません。409の応答でリクエストを拒否する必要があります。その応答には、<Constraint-Failure>要素を含む詳細な競合レポートが含まれている必要があります。その要素は、ドキュメントが非スキーマデータの制約がアプリケーションの使用によって明示的に呼び出されたことを示しています。
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.
他のHTTPリソースと同様に、XCAPリソースのプットリクエストは、IFマッチおよびIF-Noneマッチヘッダーフィールドの使用を通じて条件付きにすることができます。置換のために、これらは[6]で定義されているように処理されます。要素または属性を挿入する場合、条件操作が許可されます。[6]の手順に使用されるエンティティタグは、挿入されている要素または属性の親と同じドキュメント内のすべてのリソースのものです。これを考える1つの方法は、論理的に言えば、Putリクエストを受信すると、XCAPサーバーがリクエストによって参照されるリソースのETAGをインスタンスし、リクエストの処理を適用することです。この動作のため、置換ではなく挿入である操作に条件付けられた属性または要素に条件付き挿入を実行することはできません。言い換えれば、if-none-match： *を使用した要素または属性の条件付きプットは常に失敗します。
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があるため、1つのリソースの作成または変更は、他の多くの状態に影響します。たとえば、ドキュメントの挿入は、そのドキュメント内のすべての要素と属性に対してサーバー上にリソースを作成します。サーバーが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は、新しいドキュメント、要素、または属性を作成するために生成されることに注意してください。PUTに対する200 OK応答には、コンテンツを含める必要はありません。RFC 2616の推奨事項に従って、201は、作成されたリソースを識別するロケーションヘッダーフィールドとエンティティを含めることができます。エンティティタグは、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.
GETのセマンティクスは、RFC 2616で指定されているとおりです。このセクションでは、XCAPリソースを表す特定のURIに対して返される特定のコンテンツを明確にします。
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].
取得操作は条件付きであり、[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.
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.
削除のセマンティクスは、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メソッドを含む許可ヘッダーフィールドを含める必要があります。
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にドキュメントセレクターのみが含まれている場合、サーバーは存在する場合にURIによって指定されたドキュメントを削除し、200 OKを返し、その場合は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の応答でリクエストを拒否する必要があります。応答の本文には、<can delete>要素を含む詳細な競合レポートを含める必要があります。削除が制約の1つの障害を引き起こす場合、削除が行われてはなりません。サーバーは、409の応答を計算するために、セクション8.2.5の手順に従います。削除の結果、まだ有効なドキュメントが得られる場合、サーバーは削除を実行し、アプリケーションの使用によって定義されたリソースの相互依存関係を処理し、200 OK応答を返しなければなりません。
DELETE operations can be conditional, and follow the procedures defined in [6].
操作の削除は条件付きであり、[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.
サーバーが削除に対する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サーバーは、維持するすべてのリソースのエンティティタグを維持する必要があります。この仕様では、ドキュメント内の1つのリソース（ドキュメント自体を含む）が変更された場合、そのリソースに新しいETAGが割り当てられ、そのドキュメント内のすべてのリソースに同じETAG値を割り当てる必要があるという追加の制約が導入されます。事実上、ドキュメント全体に単一のETAGがあります。XCAPサーバーには、操作後もドキュメント自体が存在すると仮定すると、200または201の回答すべてにETAGヘッダーフィールドを含める必要があります。削除の場合、エンティティタグは、要素または属性の削除後のドキュメントのエンティティタグの値を指します。
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要素を含めることにより、簡単に行われます。この要素は、名前空間バインディングが望まれる要素と同じローカル名を持ち、同じ名前空間-Prefixもあります。要素には、スコープ内のデフォルトの名前空間を識別する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：bar/df2：baz/namespace ::*は、要求にxmlnsを含むクエリコンポーネントが添付されていると仮定して、ドキュメント内の<baz>要素の範囲内の名前空間を選択します。= urn：test：default-namespace）およびxmlns（df2 = urn：test：namespace1-uri）。このノードセレクターと名前空間バインディングを含む取得により、次の結果が生成されます。
<baz xmlns="urn:test:namespace1-uri"
xmlns:ns1="urn: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 Section 11.2. Its MIME type, registered by this specification, is "application/xcap-error+xml".
サーバーが409エラー応答を返す場合、その応答には通常、応答の本文にドキュメントが含まれ、エラーの性質に関する詳細を提供します。このドキュメントは、セクション11.2のスキーマに従ってフォーマットされたXMLドキュメントです。この仕様で登録されているMIMEタイプは、「Application/XCap-Error 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-error>が含まれています。この要素の内容は、特定のエラー条件です。各エラー条件は、異なる要素で表されます。これにより、異なるエラー条件がエラーの性質に関する異なるデータを提供できるようになります。すべてのエラー要素は、「フレーズ」属性をサポートしています。これには、人間のユーザーへのレンダリング専用のテキストを含めることができます。
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.
<not-well-formed>：これは、リクエストの本文がよく形成された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.
<Not-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.
<No-Parent>：これは、挿入が発生するはずのディレクトリ、ドキュメント、または要素が存在しないため、ドキュメント、要素、または属性を挿入しようとする試みが失敗したことを示しています。このエラー要素には、有効な挿入ポイントとなる最も近い親を表すHTTP URIを提供するオプションの<Ancestor>要素を含めることができます。この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.
<Schema-validation-error>：この要素は、要求された操作が実行された後、ドキュメントがスキーマに準拠していなかったことを示しています。
<not-xml-att-value>: This indicates that the request was supposed to contain a valid XML attribute value, but did not.
<not-xml-att-value>：これは、リクエストに有効な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.
<Can Can Can-Insert>：これは、PUTの後にそのリソースを取得しても、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.
<Aniqueness-failure>：これは、要求された操作がアプリケーションの使用法によって定義された一意性制約を満たさないドキュメントにつながることを示しています。ユニークではないクライアントによって指定された各URI、要素、または属性について、エラー要素のコンテンツとして<exists>要素が存在します。各<exists>要素には、XML要素または属性を識別する相対的なURIを含む「フィールド」属性があります。相対URIはドキュメント自体に関連しているため、ルート要素から始まります。URIのノードセレクター部分に名前空間プレフィックスが含まれている場合、URIのクエリコンポーネントが存在する必要があります。「フィールド」ノードセレクターは有効なHTTP URIであるため、パーセントエンコードする必要があります。<exists>要素には、オプションで<alt-value>要素のリストを含めることができます。それぞれは、現在サーバーに存在しない推奨される代替値です。
<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.
<constraint-failure>：これは、要求された操作がアプリケーションの使用法によって定義されたデータ制約に失敗したが、スキーマまたは一意性制約によって施行されていないドキュメントになることを示します。
<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.
<extension>：これは、XCAPの拡張によって定義されるエラー条件を示します。拡張要素のコンテンツを理解していないクライアントは、XCAP-Errorドキュメントを破棄し、エラーを資格のない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.
<Not-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:
例として、次のドキュメントは、ユーザーがURI SIP：friends@example.comを使用してRLSサービスを作成しようとしたことを示していますが、そのURIはすでに存在しています。
<?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 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">
<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: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: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: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:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<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: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>
<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:element>
<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: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: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: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: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>
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-CAPS」でアプリケーションの使用法を定義します。すべての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-caps>です。その子供は<auids>、<extensions>、および<namespaces>です。これらには、サーバーがサポートするAUID、拡張機能、名前空間のリストが含まれています。拡張機能は、拡張機能によって定義されたトークンによって命名され、通常、新しいセレクターを定義します。名前空間は、名前空間URIによって識別されます。名前空間を「サポート」するには、サーバーにその名前空間内のすべての要素のスキーマがあり、ドキュメント内に表示される場合は検証できる必要があります。すべてのXCAPサーバーは「XCAP-CAPS」AUIDをサポートしているため、<auids>要素にリストする必要があります。エレメント。
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-CAPS」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">
<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>
The default document namespace used in evaluating a URI is urn:ietf:params:xml:ns:xcap-caps.
URIの評価に使用されるデフォルトのドキュメント名空間はurn：ietf：params：xml：ns：xcap-capsです。
Documents conformant to this schema are known by the MIME type "application/xcap-caps+xml", registered in Section 15.2.5.
このスキーマに準拠したドキュメントは、セクション15.2.5に登録されているMIMEタイプ「Application/XCAP-CAPS XML」で知られています。
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 version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
</list>
</resource-lists>
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):
次に、Billは、このリストを参照する単一のRLSサービスを定義するRLSサービスドキュメントを作成します。このサービスには、sipのURIがあります：myfriends@example.com（urisは読みやすさのために線折しています）：
PUT
/rls-services/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/rls-services+xml
Host: 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>
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
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</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：application/resource-lists 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>
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
<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>
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
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
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：application/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暗号化された通信が発生し、盗聴が防止されます。クライアントはTLSを実装し、そのようなURIがクライアントが使用できることを保証する必要があります。
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への接続をアップグレードしようとする必要があります。同様に、データに対する読み取りおよび書き込み操作の承認が重要であり、これにはクライアント認証が必要です。その結果、サーバーはHTTPダイジェスト[11]を使用してクライアントに挑戦してそのIDを確立する必要があります。これは、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トラフィックと同じポート番号で実行されます。これにより、XCAPトラフィックの処理を他のHTTPトラフィックから分離するために、ファイアウォールにポートベースのフィルタリングルールを適用することが困難になります。
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はすべて同じポートで幅広いコンテンツにアクセスするためにHTTPが使用され、XCAPがアプリケーション構成ドキュメントを別のタイプのHTTPコンテンツとして表示するため、今日は広く存在します。そのため、XCAPトラフィックを他のHTTPトラフィックから個別に処理するには、URL自体を調べるためにファイアウォールが必要です。URLをXCAPリソースを指していると識別する完全な方法はありません。ただし、ダブルチルド（~~）の存在は、URLがXML要素または属性を指しているという強いヒントです。いつものように、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.
XCAP AUIDは、標準トラックRFCSで公開されている場合、IANAによって登録されます。RFCのIANAに関する考慮事項セクションには、IANAレジストリに表示されるRFC番号とともに、次の情報を含める必要があります。
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文字以下でなければなりません。名前は、アルファナムとマーク[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].
この仕様では、RFC 4288 [8]の手順とRFC 3023 [9]のガイドラインに従って、いくつかの新しいMIMEタイプの登録を要求します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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].
オプションのパラメーター：RFC 3023 [9]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ上の考慮事項：RFC 3023 [9]のセクション10を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: 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構成アクセスプロトコル（XCAP）であるRFC 4825のXMLフラグメントボディの輸送をサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xel
ファイル拡張子：.xel
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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].
オプションのパラメーター：RFC 3023 [9]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ上の考慮事項：RFC 3023 [9]のセクション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).
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、XML構成アクセスプロトコル（XCAP）であるRFC 4825のXML属性値の輸送をサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xav Macintosh file type code: "TEXT"
ファイル拡張子：.xav macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
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].
オプションのパラメーター：RFC 3023 [9]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ上の考慮事項：RFC 3023 [9]のセクション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).
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、XML構成アクセスプロトコル（XCAP）であるRFC 4825のXMLフラグメントボディの輸送をサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .xns
ファイル拡張子：.xns
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: xcap-error+xml
MIMEサブタイプ名：XCAP-Error XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメーター：RFC 3023 [9]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ上の考慮事項：RFC 3023 [9]のセクション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ファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: xcap-caps+xml
MIMEサブタイプ名：XCAP-CAPS XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
オプションのパラメーター：RFC 3023 [9]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
考慮事項のエンコード：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[9]。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ上の考慮事項：RFC 3023 [9]のセクション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ファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
This specification registers several new XML namespaces, as per the guidelines in RFC 3688 [17].
この仕様は、RFC 3688のガイドラインに従って、いくつかの新しいXMLネームスペースを登録します[17]。
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML:
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
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML:
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
This section registers two XML schemas per the procedures in [17].
このセクションでは、[17]の手順ごとに2つのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML 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
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML 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.
著者は、多くの重要なコメントを提供し、ドキュメントの編集パスを支援してくれたJari Urpalainenに感謝したいと思います。著者はまた、ベン・キャンベル、エヴァ・マリア・レパネン、ヒシャム・ハルタビル、クリス・ニューマン、ジョエル・ハルパーン、リサ・デュセー、ティム・ブレイ、ピート・コーデル、ジェロエン・ヴァン・ベメル、クリスチャン・シュミット、およびスペンサー・ドーキンスの意見とコメントに感謝します。テッド・ハーディーの意見とサポートに感謝します。
[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.、Paoli、J.、Bray、T。、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（XML）1.0（第3版）」、World Wide Web Consortium 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] Thompson、H.、Maloney、M.、Mendelsohn、N.、およびD. Beech、 "XML Schema Part 1：Structures Second Edition"、World Wide Web Consortiumの推奨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] Layman、A.、Hollander、D。、およびT. Bray、「XMLの名前空間」、World Wide Web Consortium Firstedition Rec-XML-Names-1990114、1999年1月、<http://www.w3.org/tr/1999/rec-xml-names-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] Daniel、R.、Derose、S.、Maler、E。、およびJ. Marsh、 "xpointer xmlns（）Scheme"、World Wide Web Consortiumの推奨REC-XPTR-XMLNS-20030325、2003年3月、<http：// wwww.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] Grosso、P.、Marsh、J.、Maler、E。、およびN. Walsh、「Xpointer Framework」、World Wide Web Consortiumの推奨REC-XPTR-Framework-200325、2003年3月、<http：//www.w3。org/tr/2003/rec-xptr-framework-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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Freed、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] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、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] Clark、J。and S. Derose、「XML Path Language（XPath）バージョン1.0」、World Wide Web Consortiumの推奨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] Franks、J.、Hallam-Baker、P.、Hostetler、J.、Lawrence、S.、Leach、P.、Luotonen、A。、およびL. Stewart、「HTTP認証：基本および消化アクセス認証」、RFC 2617、1999年6月。
[12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[12] Crocker、D.、ed。および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] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[14] Rescorla、E。、「TLS上のHTTP」、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. Lawrence、「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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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] Boyer、J。、「Canonical XMLバージョン1.0」、World Wide Web Consortiumの推奨REC-XML-C14N-20010315、2001年3月、<http://www.w3.org/tr/2001/rec-xml-c14n-20010315>。
[20] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[20] Rosenberg、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] Roach、A.、Campbell、B。、およびJ. Rosenberg、「セッション開始プロトコル（SIP）イベント通知拡張機能の拡張機能」、RFC 4662、2006年8月。
[22] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[22] Rosenberg、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] Grosso、P。and D. Veillard、「XML Fragment Interchange」、World Wide Web Consortium CR-XML-Fragment-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] Berglund、A.、Boag、S.、Chamberlin、D.、Fernandez、M.、Kay、M.、Robie、J。、およびJ. Simeon、「XML Path Language（XPath）2.0」、World Wide Web Consortium CRhttp://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] Newman、C。and J. Myers、「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] Day、M.、Rosenberg、J。、およびH. Sugano、「存在とインスタントメッセージングのモデル」、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.
[27] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[28] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[28] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[29] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[29] Duerst、M。and M. Suignard、「Internationalized Resource Identiers（IRIS）」、RFC 3987、2005年1月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。