RFC4825 日本語訳
4825 The Extensible Markup Language (XML) Configuration AccessProtocol (XCAP). J. Rosenberg. May 2007. (Format: TXT=166627 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 4825 Cisco Category: Standards Track May 2007
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 4825年のコクチマスカテゴリ: 標準化過程2007年5月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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)構成Accessプロトコル(XCAP)を定義します。 XCAPはクライアントにサーバのXML形式で保存されたアプリケーションコンフィギュレーション・データを、読んで、書いて、変更させます。XCAPはXMLドキュメント下位木と要素属性をHTTP URIに写像します、HTTPから直接これらのコンポーネントにアクセスできるように。
Rosenberg Standards Track [Page 1] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[1ページ]。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 4 2。 操作. . . . . . . . . . . . . . . . . . . . 5 3の概要。 用語. . . . . . . . . . . . . . . . . . . . . . . . . 5 4。 定義. . . . . . . . . . . . . . . . . . . . . . . . . 6 5。 アプリケーション用法. . . . . . . . . . . . . . . . . . . . . . 7 5.1。 アプリケーションのユニークなID(AUID。). . . . . . . . . . . . . . . 7 5.2 デフォルトドキュメント名前空間. . . . . . . . . . . . . . . . 8 5.3。 データ合法化. . . . . . . . . . . . . . . . . . . . . 9 5.4。 データ意味論. . . . . . . . . . . . . . . . . . . . . . 10 5.5。 コンベンション. . . . . . . . . . . . . . . . . . . . 11 5.6を命名します。 リソース相互依存性. . . . . . . . . . . . . . . . 11 5.7。 承認方針. . . . . . . . . . . . . . . . . . 12 5.8。 データ伸展性. . . . . . . . . . . . . . . . . . . . 12 5.9。 アプリケーション用法. . . . . . . . . . . . . . 13 5.10を記録します。 アプリケーション用法. . . . . . . . 13 6を作成するためのガイドライン。 URI工事. . . . . . . . . . . . . . . . . . . . . . . 15 6.1。 XCAPは.156.2を根づかせます。 セレクタ. . . . . . . . . . . . . . . . . . . . 16 6.3を記録してください。 ノードセレクタ. . . . . . . . . . . . . . . . . . . . . . 18 6.4。 セレクタ. . . . . . . . . . . 23 7のための名前空間結合。 クライアント操作. . . . . . . . . . . . . . . . . . . . . . 24 7.1。 ドキュメント. . . . . . . . . . . . . . . 26 7.2を作成するか、または取り替えてください。 ドキュメント. . . . . . . . . . . . . . . . . . . . 26 7.3を削除してください。 ドキュメント. . . . . . . . . . . . . . . . . . . . . 26 7.4をとって来てください。 要素. . . . . . . . . . . . . . . 26 7.5を作成するか、または取り替えてください。 要素. . . . . . . . . . . . . . . . . . . . 29 7.6を削除してください。 要素. . . . . . . . . . . . . . . . . . . . . 30 7.7をとって来てください。 属性. . . . . . . . . . . . . . 30 7.8を作成するか、または取り替えてください。 属性. . . . . . . . . . . . . . . . . . . 31 7.9を削除してください。 属性. . . . . . . . . . . . . . . . . . . . 31 7.10をとって来てください。 名前空間結合. . . . . . . . . . . . . . . . . 32 7.11をとって来てください。 条件付き演算. . . . . . . . . . . . . . . . . . 32 8。 サーバの振舞い. . . . . . . . . . . . . . . . . . . . . . . 34 8.1。 取り扱. . . . . . . . . . . . . . . . . . . . . . 35 8.2いを掲示してください。 取り扱. . . . . . . . . . . . . . . . . . . . . . . 35 8.2い.1を置いてください。 親. . . . . . . . . . . . . . . . . 35 8.2.2の場所を見つけます。 ドキュメント内容. . . . . . . . . . . . . . 36 8.2.3について確かめます。 作成. . . . . . . . . . . . . . . . . . . . . . . 37 8.2.4。 交換. . . . . . . . . . . . . . . . . . . . . 41 8.2.5。 合法化. . . . . . . . . . . . . . . . . . . . . . 42 8.2.6。 条件付きの処理. . . . . . . . . . . . . . . . 43 8.2.7。 リソース相互依存性. . . . . . . . . . . . . . 44 8.3。 取り扱. . . . . . . . . . . . . . . . . . . . . . . 44 8.4いを得てください。 取り扱. . . . . . . . . . . . . . . . . . . . . 45 8.5いを削除してください。 Etags. . . . . . . . . . . . . . . . . . . . . . 46 9を管理します。 キャッシュ制御. . . . . . . . . . . . . . . . . . . . . . . . 47
Rosenberg Standards Track [Page 2] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[2ページ]。
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
10. 名前空間の拘束力がある形式. . . . . . . . . . . . . . . . . . . 47 11。 詳細な闘争は.47 11.1を報告します。 構造. . . . . . . . . . . . . . . . . . . . 48 11.2を記録してください。 XML図式. . . . . . . . . . . . . . . . . . . . . . . . 50 12。 XCAPサーバ能力. . . . . . . . . . . . . . . . . . . 53 12.1。 アプリケーションのユニークなID(AUID。). . . . . . . . . . . . . . . 54 12.2 XML図式. . . . . . . . . . . . . . . . . . . . . . . . 54 12.3。 デフォルトドキュメント名前空間. . . . . . . . . . . . . . . . 56 12.4。 MIMEの種類. . . . . . . . . . . . . . . . . . . . . . . . 56 12.5。 合法化規制. . . . . . . . . . . . . . . . . . 56 12.6。 データ意味論. . . . . . . . . . . . . . . . . . . . . . 56 12.7。 コンベンション. . . . . . . . . . . . . . . . . . . . 56 12.8を命名します。 リソース相互依存性. . . . . . . . . . . . . . . . 56 12.9。 承認方針. . . . . . . . . . . . . . . . . . 56 13。 例. . . . . . . . . . . . . . . . . . . . . . . . . . . 56 14。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 59 15。 IANA問題. . . . . . . . . . . . . . . . . . . . . 60 15.1。 XCAPのアプリケーションのユニークなID. . . . . . . . . . . . . . . 60 15.2。 MIMEの種類、.61 15.2、.1. アプリケーション/xcap-高架鉄道+xml MIMEの種類、.61 15.2、.2. アプリケーション/xcap-att+xml MIMEの種類、.62 15.2、.3. アプリケーション/xcapナノ秒+xml MIMEの種類、.63 15.2、.4. アプリケーション/xcap-誤り+xml MIMEの種類、.64 15.2、.5. アプリケーション/xcap-上限+xml MIMEの種類. . . . . . . . . 64 15.3 URN Sub-名前空間Registrations、.65 15.3、.1. つぼ:ietf:params:xml:ナノ秒: xcap誤り、.65 15.3、.2. つぼ:ietf:params:xml:ナノ秒: xcap-上限.66 15.4 XML図式登録証明書. . . . . . . . . . . . . . . . . 67 15.4.1。 XCAP誤り図式登録. . . . . . . . . . . . 67 15.4.2。 XCAP能力図式登録. . . . . . . . 67 16 承認. . . . . . . . . . . . . . . . . . . . . . . 67 17。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 67 17.1。 引用規格. . . . . . . . . . . . . . . . . . . 67 17.2。 有益な参照. . . . . . . . . . . . . . . . . . 69
Rosenberg Standards Track [Page 3] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[3ページ]。
1. Introduction
1. 序論
In many communications applications, such as Voice over IP, instant messaging, and presence, it is necessary for network servers to access per-user information in the process of servicing a request. This per-user information resides within the network, but is managed by the end user themselves. Its management can be done through a multiplicity of access points, including the web, a wireless handset, or a PC application.
ボイス・オーバー IPや、インスタントメッセージングや、存在などの多くのコミュニケーションアプリケーションでは、要求を修理することの途中にネットワークサーバがユーザー情報にアクセスするのが必要です。 このユーザー情報は、ネットワークの中に住んでいますが、エンドユーザによって自分たちで管理されます。 アクセスポイントの多様性を通して管理できます、ウェブ、ワイヤレスの受話器、または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]承認方針です。(その方針はどのウォッチャーがpresentityに加入できるか、そして、彼らがアクセサリーに許容されているというどんな情報に関して規則を定義するか)。 別のものは存在リストです。(そのリストは存在がウォッチャー[26]によって望まれているユーザのリストです)。 リストのための存在情報を得る1つの方法はそのリスト[21]を表すリソースに加入することです。 この場合Resource List Server(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)構成Accessプロトコル(XCAP)と呼ばれます。 XCAPはそれらのリソースへのアクセスに関連しているXMLドキュメントとドキュメントの部品をHTTP URIに写像するための1セットのコンベンションと、1つのリソースの変更がどう別のものに影響するか規則と、データ合法化規制と、承認方針です。 この構造のために、データを操るのに正常なHTTP基関数を使用できます。 それの拡大ではありません、そして、XCAPはずっしりとApplication Configuration Accessプロトコル(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.
汎用のXML検索プロトコル、XMLデータベース更新プロトコル、および汎用、XMLベースの構成がネットワーク要素のために議定書を作るとき、XCAPは設計されませんでした。
Rosenberg Standards Track [Page 4] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[4ページ]。
2. Overview of Operation
2. 操作の概要
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を利用する各アプリケーション(アプリケーションがaについて言及するところでデータと関連意味論の収集を含意するケースを使用する)がアプリケーション用法(セクション5)を指定します。 このアプリケーション用法はアプリケーションで使用されるデータのためにXML図式[2]を定義します、他の主要な情報と共に。 XCAPに関する一義的な仕事はクライアントがそのデータの断片を読んで、書いて、変更して、作成して、削除するのを許容することです。 これらの操作は、HTTP/1.1[6]を使用することでサポートされます。 XCAPサーバはXMLドキュメントの収集のための倉庫として機能します。 各アプリケーションのために保存されたドキュメントがあるでしょう。 各アプリケーションの中に、各ユーザのために保存されたドキュメントがあります。 各ユーザは特定用途のためのドキュメントの多様性を持つことができます。 それらのドキュメントの1つの何らかのコンポーネントにアクセスするために、XCAPはそのコンポーネントに参照をつけるのに使用できるURIを構成するためのアルゴリズムを定義します。 コンポーネントはドキュメントの中のどんな要素や属性も示します。 したがって、URIがドキュメント、または、情報の、より細かい断片にXCAPポイント使用したHTTPは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メソッドを使用することでそれらにアクセスできます。 HTTP GETと共にXCAPリソースを読むのを実行します、そして、1つを作成するか、またはHTTP PUTと共に変更して、HTTP DELETEと共にリソースの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]がある標準形は論理的等値を決定します。 言い換えれば、正準な仕様は、どのように重要な空白を処理しなければならないかを決定します。 また、それは、例えば、新しい挿入された属性が具現の中に順不同に現れるかもしれないのを含意します。
3. Terminology
3. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFCで2119[7]について説明して、対応する実装のために要件レベルを示すとき解釈されることであるべきですか?
Rosenberg Standards Track [Page 5] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[5ページ]。
4. Definitions
4. 定義
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リソース: XCAPの命名と合法化規制に続くXMLドキュメントの中にXMLドキュメント、XMLドキュメントの中の要素、または要素の属性を表すHTTPリソース。
XCAP Server: An HTTP server that understands how to follow the
naming and validation constraints defined in this specification.
XCAPサーバ: 命名に続く方法を理解しているHTTPサーバとこの仕様に基づき定義された合法化規制。
XCAP Client: An HTTP client that understands how to follow the
naming and validation constraints defined in this specification.
XCAPクライアント: 命名に続く方法を理解しているHTTPクライアントとこの仕様に基づき定義された合法化規制。
Application: A collection of software components within a network
whose operation depends on data managed and stored on an XCAP
server.
アプリケーション: 操作がXCAPサーバに管理されて、保存されたデータによるネットワークの中のソフトウェアコンポーネントの収集。
Application Usage: Detailed information on the interaction of an
application with the XCAP server.
アプリケーション用法: XCAPサーバによるアプリケーションの相互作用の詳細な情報。
Application Unique ID (AUID): A unique identifier within the
namespace of application unique IDs created by this specification
that differentiates XCAP resources accessed by one application
from XCAP resources accessed by another.
アプリケーションのユニークなID(AUID): 1つのアプリケーションでXCAPリソースを差別化するこの仕様で作成されたアプリケーション固有のIDの名前空間の中のユニークな識別子は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はHTTP URIで経路要素として有効で、すなわち、XCAPサーバによって役立たれている各ユーザに関連しているストリングです。
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.
セレクタを記録してください: 「各セグメントがある経路セグメントの系列はa」/によって切り離され」て、それは選択されている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.
ノードセレクタ: 「各セグメントがある経路セグメントの系列はa」/によって切り離され」て、それはドキュメントの中に選択されるXMLノード(要素か属性)を特定します。
Rosenberg Standards Track [Page 6] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[6ページ]。
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.
ノードセレクタ分離符: 」 それが使用されている「2つのティルドキャラクタと等しいただ一つの経路セグメント」~~、はHTTP URIの中でノードセレクタとドキュメントセレクタを切り離します。
Document URI: The HTTP URI containing the XCAP root and document
selector, resulting in the selection of a specific document. As a
result, performing a GET against the document URI would retrieve
the document.
URIを記録してください: 特定のドキュメントの選択をもたらして、XCAP根とドキュメントセレクタを含むHTTP URI。 その結果、ドキュメントURIに対してGETを実行すると、ドキュメントは検索されるでしょう。
Node URI: The HTTP URI containing the XCAP root, document selector,
node selector separator, and node selector, resulting in the
selection of a specific XML node.
ノードURI: 特定のXMLノードの選択をもたらして、XCAP根、ドキュメントセレクタ、ノードセレクタ分離符、およびノードセレクタを含むHTTP URI。
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 Root URIはXCAPサーバに関する実際のリソースと食い違っています。実際のリソースは、追加経路情報をXCAP Root 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.
位置の挿入: 位置が同じ親の他の子供に比例しているようにドキュメントへの新しい要素の挿入をもたらすPUT操作はクライアントでセットしました。
5. Application Usages
5. アプリケーション用法
Each XCAP resource on a server is associated with an application. In order for an application to use those resources, application specific conventions must be specified. Those conventions include the XML schema that defines the structure and constraints of the data, well- known URIs to bootstrap access to the data, and so on. All of those application specific conventions are defined by the application usage.
サーバに関するそれぞれのXCAPリソースはアプリケーションに関連しています。 アプリケーションがそれらのリソースを使用するように、アプリケーションの特定のコンベンションを指定しなければなりません。 それらのコンベンションはデータへのアクセスなどを独力で進むために構造とデータの規制、よく知られているURIを定義するXML図式を含めます。 それらのアプリケーションの特定のコンベンションのすべてがアプリケーション用法で定義されます。
5.1. Application Unique ID (AUID)
5.1. アプリケーションのユニークなID(AUID)
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
Application Unique ID(AUID)は、それぞれのアプリケーション用法が名前に関連していると言いました。 この名前は、アプリケーション用法の名前空間の中で唯一アプリケーション用法を特定して、他のアプリケーションで使用されるAUIDsと異なっています。 AUIDsは2つの名前空間の1つで存在しています。 最初の名前空間はIETF名前空間です。 これ
Rosenberg Standards Track [Page 7] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[7ページ]。
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:
名前空間は1セットのトークンを含んでいます。それはそれぞれIANAに登録されます。 これらの登録証明書はセクション15のガイドラインに基づいて標準化過程RFCs[27]の公表で起こります。 2番目の名前空間はベンダー独占である名前空間です。 組織の逆のドメイン名が期間までに続かれるAUIDを作成している状態で名前空間が前に置かれているので、各AUIDはどんなベンダーの定義されたトークンでも続きました。 例として、example.comドメインは、値の"com.example.foo"でAUIDを作成できますが、値の"org.example.foo"で1つは作成できません。 ベンダー名前空間の中のAUIDsによってIANAに登録される必要はありません。 また、ベンダー名前空間はどんな中央の登録も必要でない研究室環境で使用されることになっています。 ABNF[12]で急送されたAUIDsのための構文、(RFC3986[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 / "-" / "_" / "~"
「AUIDは1*a aが無遠慮な状態でuidされたアルファ*(alphanum/「-」)alphanum uidアルファ/炭のalphanum / alphanum*(alphanum/「-」)回転炭のベンダーa uid=ホスト名toplabel*(「.」 domainlabel)」 . 」 a-uid回転ホスト名=domainlabel=alphanum toplabel==をuidするか、pctによってコード化されたかサブdelimsのベンダーaグローバルなa uid/uidグローバルなa uid=a-uid a-uid=/と等しい」:、」 /"@"; aが無遠慮な状態でuidされたRFC4234=アルファ/ケタ/「-」/"_"/「~」からのRFC3986alphanumからのサブdelimsがRFC4234からアルファ/ケタ;ケタと等しいというRFC3986からpctによってコード化されたアルファー
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生産のための許容キャラクタはRFC3986で定義されたpchar生産の部分集合です。 「特に、省略する、」、」、auidが逆のホスト名と切り離されるのを許容する。
5.2. Default Document Namespace
5.2. デフォルトドキュメント名前空間
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
XCAPサーバがドキュメントの要素か属性にURIを合わせるように、整然とします、URIの中で使用されたどんなXML名前空間接頭語も広げなければなりません。[3]。 この拡張は名前空間の拘束力がある関係を必要とします。 その文脈は名前空間接頭語を名前空間URIに写像します。 また、それは名前空間接頭語なしでURIで要素に適用されるデフォルト名前空間を定義します。 名前空間の拘束力がある関係は2つのソースから来ます。 まず最初に、URI自体から名前空間URIへの名前空間接頭語に関するマッピングを得ます(セクション6.4を見てください)。 しかしながら、デフォルトドキュメント名前空間は、アプリケーション用法自体で定義されて、中でリソースに参照をつけるすべてのURIに適用されます。
Rosenberg Standards Track [Page 8] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[8ページ]。
that application usage. All application usages MUST define a namespace URI that represents the default document namespace to be used when evaluating URIs. The default document namespace does not apply to elements or attributes within the documents themselves -- it applies only to the evaluation of URIs within that application usage. Indeed, the term 'default document namespace' is distinct from the term 'default namespace'. The latter has the standard meaning within XML documents, and the former refers to the default used in evaluation of XCAP URIs. XCAP does not change in any way the mechanisms for determining the default namespace within XML documents. However, if a document contains a URI representing an XCAP resource, the default document namespace defined by the application usage applies to that URI as well.
そのアプリケーション用法。 すべてのアプリケーション用法がURIを評価するとき、使用されるためにデフォルトドキュメント名前空間を表す名前空間URIを定義しなければなりません。 デフォルトドキュメント名前空間はドキュメント自体の中に要素か属性に適用されません--それはそのアプリケーション用法の中でURIの評価だけに適用されます。 本当に、'デフォルトドキュメント名前空間'という用語は'デフォルト名前空間'という用語と異なっています。 後者はXMLドキュメントの中に標準の意味を持っています、そして、前者はXCAP URIの評価に使用されるデフォルトを示します。 XCAPは、XMLドキュメントの中にデフォルト名前空間を決定するために何らかの方法でメカニズムを変えません。 しかしながら、ドキュメントがXCAPリソースを表すURIを含んでいるなら、アプリケーション用法で定義されたデフォルトドキュメント名前空間はまた、そのURIに適用されます。
5.3. Data Validation
5.3. データ合法化
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クライアントが1つを変更しようとするとき、それぞれのXCAPリソースの内容を有効にすることです。 これは2つのメカニズムを使用し終わっています。まず第一に、XML図式[2]を使用して、すべてのアプリケーション用法がそれらのドキュメントコンテンツについて説明しなければなりません。 また、アプリケーション用法はその図式への対応することのドキュメントのためにMIMEの種類を特定しなければなりません。
Unfortunately, XML schemas cannot represent every form of data constraint. As an example, one XML element may contain an integer that defines the maximum number of instances of another element. This constraint cannot be represented with XML schema. However, such constraints may be important to the application usage. The application usage defines any additional constraints beyond those in the schema.
残念ながら、XML schemasはあらゆる形式のデータ規制を表すことができません。 例として、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のユニークさなどの他の一意性制約を言い表すことができません。 合法化が必要とするデータを定義するとき、図式がユニークさの要件のいくつかを言い表すのに使用されるか否かに関係なく、アプリケーション用法はすべてのユニークさの要件を指定しなければなりません。
Rosenberg Standards Track [Page 9] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[9ページ]。
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]は、<サービス>要素の"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サーバはRelational Database Management Systems(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 MUSTと共に使用されるすべてのドキュメントが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).
彼らがいつ要求(サーバによって有効にされない参考の保全規制を除いた)を受け取るかというデータ合法化情報は両方のクライアントとサーバによって消費されます。(そのクライアントは、彼らがサーバによって受け入れられる要求を構成するのを確実にするのに彼らを使用します)。(サーバは規制を有効にします)。
5.4. Data Semantics
5.4. データ意味論
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ドキュメントの現在のデータでaは明確になります。意味。 アプリケーション用法はそれを定義します。意味的です、クライアントが構成できて、必要な結果を獲得するために適切にドキュメントを構成してください。 それらはサーバによって使用されないで、データの意味論に故意に気づかないときに、それは管理されています。 データ意味論はイギリスの散文でアプリケーション用法で言い表されます。
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
1つ、特に重要である、意味的であるのは、XCAPリソースに示されたどんな相対的なURI参照の解決にも使用されることになっているベースURIです。 決心している使用が検索URIであったかもしれないならXCAPリソースを示す以下的、そして、相対的なURI参照について議論します。
Rosenberg Standards Track [Page 10] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[10ページ]。
base URI. Therefore, it is up to the application usage to specify the base URI.
URIを基礎づけてください。 したがって、ベースURIを指定するのはアプリケーション用法まで達しています。
5.5. Naming Conventions
5.5. 命名規則
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.
多くのアプリケーション用法のために、ユーザはただ一つのドキュメントだけを必要とします。 このような場合には、アプリケーション用法がこのドキュメントが「インデックス」と呼ばれて、ユーザのホームディレクトリの中に存在するのを必要とするのは、RECOMMENDEDです。
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は登録のSIP URIに関連しているサービスのためのサービス定義に要求をとって来るというただ一つのXCAP要求を実行できます。
Naming conventions are used by XCAP clients to construct their URIs. The XCAP server does not make use of them.
命名規則は、彼らのURIを構成するのにXCAPクライアントによって使用されます。 XCAPサーバはそれらを利用しません。
5.6. Resource Interdependencies
5.6. リソース相互依存性
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に対してDELETE要求を出すことによって、そうします。 しかしながら、この要素を削除すると、また、すべての子供要素とそれらの属性は削除されます。また、それはそれぞれ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図式によって完全に指定されます。 しかしながら、いくつかのアプリケーション用法で、サーバがリソースについて一緒に話す必要があります、そして、図式を通してそのような関係は指定できません。 1通のドキュメントにおける変化が別のドキュメントに影響すると、これは起こります。 アプリケーション用法が他のドキュメントで定義された情報の収集として作動するドキュメントを定義することであるとき、これは通常、そうです。
Rosenberg Standards Track [Page 11] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[11ページ]。
As an example, when a user creates a new RLS service (that is, it creates a new <service> element within an RLS services document), the server adds that element to a read-only global list of services maintained by the server in the global tree. This read-only global list is accessed by the RLS when processing a SIP SUBSCRIBE request.
ユーザが新しいRLSサービスを作成するとき(すなわち、それはRLSサービスドキュメントの中に新しい<サービス>要素を作成します)、例として、サーバはグローバルな木でサーバによって維持されたサービスの書き込み禁止グローバルなリストにその要素を追加します。 SIP SUBSCRIBE要求を処理するとき、この書き込み禁止のグローバルなリストはRLSによってアクセスされます。
Resource interdependencies are used by both XCAP clients and servers.
リソース相互依存性はXCAPクライアントとサーバの両方によって使用されます。
5.7. Authorization Policies
5.7. 承認方針
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サーバによって使用されます。
5.8. Data Extensibility
5.8. データ伸展性
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要求を処理するためにアプリケーション用法を理解しなければなりません。 しかしながら、サーバがアプリケーション用法で使用されるドキュメントのコンテンツのすべてを理解するのにそれは必要ではありません。 サーバが、アプリケーション用法で定義された基線図式を理解するのに必要です。 しかしながら、それらのschemasは他の名前空間と対応するschemasから新しい内容を加えることができる伸展性のポイントを定義できます。 サーバは、時々、それらの名前空間を理解していて、したがって、それらのschemasに近づく手段を持つでしょう。 時々、それはそうしないでしょう。
A server MUST allow for documents that contain elements from namespaces not known to the server. In such a case, the server
サーバはサーバに知られない名前空間からの要素を含むドキュメントのために. このような場合にはサーバを許容しなければなりません。
Rosenberg Standards Track [Page 12] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[12ページ]。
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 Capabilitiesアプリケーション用法を使用することでサーバについて質問できます。
5.9. Documenting Application Usages
5.9. アプリケーション用法を記録します。
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 承認方針
5.10. Guidelines for Creating Application Usages
5.10. アプリケーション用法を作成するためのガイドライン
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.
プライマリデザインタスクは新しいアプリケーション用法を作成するとき、図式を定義することです。 どんなXMLドキュメントと共にもXCAPを使用できますが、それが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
XCAPは1セットの兄弟の中で要素を選択する3つの基本的な方法を提供します: 要素の拡張名前、位置、または特定の属性の値で。 位置の選択で、クライアントはいつもまさにそれが欲しいものを得ることができます。 しかしながら、それは、述部を構成するためにクライアントがドキュメントのコピーをキャッシュするのを必要とします。 それは、その上、クライアントがaであるならPUTを実行するのを必要とします。
Rosenberg Standards Track [Page 13] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[13ページ]。
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.
サーバが地方のキャッシュされたコピーをアップデートするために続くPUT処理を再建するクライアント。 さもなければ、クライアントは再GETに強制されるでしょう。あらゆるPUTの後のドキュメント。PUTは効率が悪いです。 そういうものとして、schemasを設計するのは、クライアントがドキュメントのコピーをキャッシュする必要でない一般的な操作を実行できるための名案です。
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.
位置の選択がなければ、クライアントは各ステップで拡張名前か属性の値で要素を選ぶことができます。 多くのschemasが親の中で繰り返すことができる要素を含んでいます(しばしば、minOccursはゼロか1つと等しいです、そして、maxOccursは限りないです)。 そういうものとして、要素のすべてには、同じ名前があります。 これは要素を選択する唯一の方法として属性値を残します。 これのために、アプリケーション用法が、ユーザが繰り返されることができる要素の子孫である要素か属性を操作すると予想するなら、その要素SHOULDは図式にユニークなインデックスとして適当に使用できる属性を含んでいます。 その上、そのアプリケーション用法SHOULDによって定義された命名規則は明らかにこの一意性制約を指定します。
URIs often make a good choice for such a unique index. They have fundamental uniqueness properties, and are also usually of semantic significance in the application usage. However, care must be taken when using a URI as an attribute value. URI equality is usually complex. However, attribute equality is performed by the server using XML rules, which are based on case sensitive string comparison. Thus, XCAP will match URIs based on lexical equality, not functional equality. In such cases, an application usage SHOULD consider these implications carefully.
URIはそのようなユニークなインデックスのためにしばしばうまく選び当てます。 それらは、基本的なユニークさの特性を持って、アプリケーション用法で通常、意味また意味についてものです。 しかしながら、属性値としてURIを使用するとき、注意しなければなりません。 通常、URI平等は複雑です。 しかしながら、属性平等は、サーバによってXML規則(大文字と小文字を区別するストリング比較に基づいている)を使用することで実行されます。 したがって、XCAPは機能的な平等ではなく、語彙平等に基づくURIに合うでしょう。 そのようなものでは、ケース、アプリケーション用法SHOULDは慎重にこれらの含意を考えます。
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.
結果、schemas SHOULD、一般に、一般的な操作が働くというただ一つの要求を必要とするように、定義されてください。 例を考えてください。 アプリケーション用法が許容を定義することであるとユーザが、ある操作を実行するように言いましょう。 図式は2つの方法で設計される場合があります。 木のトップレベルはユーザを特定できます、そして、各ユーザの中に、ユーザに関連している許容があることができます。 設計代案では、木のトップレベルは、各許可を特定して、その許可(それを持っているユーザのセット)の中でそうします。
Rosenberg Standards Track [Page 14] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[14ページ]。
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.
このアプリケーション用法では、ユーザのために許可を1つの値から別のものに変えるのが一般的であるなら、xcapには、前の図式デザインは、より良いです。 そのような変更を行うのが独身のPUTを必要とするでしょう。 2つのPUT操作が、起こる必要があります--全体のドキュメントが、取り替えられる必要があるか(ただ一つの操作です)、および後者の場合では、古い許可からユーザを外す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.
命名規則はアプリケーション用法のデザインの別の主要な部分を形成します。 アプリケーション用法はXCAPクライアントが、どこから興味深いドキュメントを検索して、変更し「始めるか」を知っているのを確信しているべきです。 一般に、これはよく知られるURIでよく知られているドキュメントの仕様にかかわるでしょう。 そのドキュメントはクライアントが読むか、または変更する必要がある他のドキュメントの参照を含むことができます。
6. URI Construction
6. 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根の中でドキュメントを特定する経路です。 ノードセレクタ分離符は、二重ティルド(「~~」)の値がある経路セグメントであり、パーセントによってコード化されていて、RFC3986[13]のセクション2.3で慎重であるべきではありません。 7Eに%を7ユーロの%含むURIは比較のための~~、に正常にされるべきです。 それらは同等です。 ノードセレクタ分離符はノードセレクタとドキュメントセレクタを切り離す1片のシンタックスシュガーです。 ノードセレクタはドキュメントの要素か属性などの部品を特定する式です。 「それが可能である、そのa」~~、」 ノードセレクタ自体の一部として、現れます。 「このような場合には1番目」~~、」 URIには、ノードセレクタ分離符があります。
The sections below describe these components in more detail.
下のセクションはさらに詳細にこれらのコンポーネントについて説明します。
6.1. XCAP Root
6.1. XCAP根
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 Root URIと呼ばれるHTTP URIで表されます。 このURIは有効なHTTP URIです。 しかしながら、それは実際にサーバに存在するどんなリソースも示しません。目的はすべてのXCAPドキュメントが保存されるドメインの中で木の根を特定することです。
Rosenberg Standards Track [Page 15] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[15ページ]。
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と等しいのは、RECOMMENDEDです。(そこでは、ドメインがプロバイダーのドメインです)。 例として、XCAPがexample.comドメインの中にユリを根づかせるとき、" http://xcap.example.com "は使用されるかもしれません。 通常、XCAP根のURIはクライアントデバイスに食糧を供給されます。 明らかに食糧を供給されないなら、クライアントSHOULDは、フォームがxcap.domainであると仮定します。そこでは、ドメインが彼らのサービスプロバイダーのドメイン(SIPに関して、これは彼らの記録のAddress(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要求を生成すると、Request-URIの工事のためのRFC2616手順は適用されます。 直接発生源サーバに要求を送るなら、URIの権威コンポーネントはRequest-URIで特に、存在していないかもしれません。
The XCAP root URI can also be a relative HTTP URI. It is the responsibility of the application usage to specify the base URI for an HTTP URI representing an XCAP resource whenever such a URI appears within a document defined by that application usage. Generally speaking, it is unsafe to use the retrieval URI as the base URI. This is because any URI that points to an ancestor for a particular element or attribute can contain content including that element or attribute. If that element or attribute contained a relative URI reference, it would be resolved relative to whatever happened to be used to retrieve the content, and this will often not be the base URI defined by the application usage.
また、XCAP根のURIは相対的なHTTP URIであるかもしれません。 そのようなURIがそのアプリケーション用法で定義されたドキュメントの中に現れるときはいつも、XCAPリソースを表すHTTP URIにベースURIを指定するのは、アプリケーション用法の責任です。 概して、ベースURIとして検索URIを使用するのは危険です。 これは特定の要素か属性のために先祖を示すどんなURIもその要素か属性を含む内容を含むことができるからです。 その要素か属性が相対的なURI参照を含んでいるなら、それは内容を検索するのにたまたま使用されたことなら何でもに比例して決議されているでしょうに、そして、これはしばしばアプリケーション用法で定義されたベースURIになるというわけではないでしょう。
6.2. Document Selector
6.2. ドキュメントセレクタ
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名前空間のこの特定の部分集合の中にリソースを置くためにサーバアドミニストレータから認可を得るのを必要とするかもしれないのを意識しているべきです。
Rosenberg Standards Track [Page 16] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[16ページ]。
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つの下位木があります。 「ユーザ」と呼ばれるのは特定のユーザに適切なドキュメントを保持します、そして、「グローバルである」と呼ばれるもう片方がすべてのユーザに適切な状態で書類を保留します。 「グローバルな」下の下位木はグローバルな木と呼ばれます。 経路は後にAUID MUSTを区分します。「グローバルである」か「ユーザ。」
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 User Identifier(XUI)は、サーバに知られているそれぞれのユーザがユーザ名に関連していると言いました。 通常、終点はXUIの値で食糧を供給されます。 SIPにアプリケーションをサポートするシステムのために、ユーザ(すなわち、一口: joe@example.com )にとって、XUIが記録のAddress(AOR)と等しいのは、RECOMMENDEDです。 一般に、終点が知っているSIP以来、自分達のAORであり、また、彼らは自分達のXUIを知るでしょう。 結果として、XUIが全く明らかに食糧を供給されないなら、SIP UserエージェントSHOULDは、それがそれらのAORと等しいと仮定します。 このXUI MUST、経路セグメントとして、「ユーザ」セグメントの下で使用されてください。 'パーセントがコード化されていたなら、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.
基線承認方針の仕様を超えてそれが、ドキュメントが何をユーザに「適用すること」を意味するかを定義して、セクション8で以下で説明されて、XCAPはそれ自体をするというわけではありません。 それぞれのアプリケーション用法はアプリケーション自体で使用されるデータによる追加承認方針を指定できます。
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)の残りはそのアプリケーション用法のための特定のドキュメントを示します。 サブディレクトリは、受入れられますが、NOT RECOMMENDEDです。 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
ドキュメントセレクタの最終的な経路セグメントは階層構造で実際のドキュメントを特定します。 これはファイル名に同等です、XCAPが、ドキュメントリソースがファイルとしてファイルシステムに保存されるのを必要としないのを除いて。 しかしながら、「ファイル名」という用語は、ドキュメントセレクタで最終的な経路セグメントについて説明するのに使用されます。 伝統的なファイルシステムでは、ファイル名は".xml"などのファイル名拡張子を持っているでしょう。 そのような拡張子がファイル名に使用されるのを必要である、または防ぐこの仕様には何もありません。 いくつかの場合、アプリケーション用法は命名を指定するでしょう。
Rosenberg Standards Track [Page 17] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[17ページ]。
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".
ドキュメントのためのコンベンション、およびそれらの命名規則が指定するかもしれませんか、またはファイル拡張子を指定しないかもしれません。 例えば、RLSサービスアプリケーション用法[22]で、ユーザのホームディレクトリのファイル名「インデックス」があるドキュメントはサーバによって使用されます。(それは、グローバルなインデックスを計算して、また、ファイル名「インデックス」があるドキュメントです)。 ユーザに特定用途用法のためのただ一つのドキュメントがあるならアプリケーション用法による特別な基準を禁じて、このSHOULDは呼ばれた「インデックス」です。
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.
または、アプリケーション用法における命名規則がファイル名コンベンション(より一般にドキュメントセレクタ)を抑制しないとき、アプリケーションがファイル名を知る、(より一般に、ドキュメントセレクタ) それがクライアントによってアクセスされたドキュメントにおける参照として含まれているので。 別の例として、内容がURIである<リソースリスト>と呼ばれる子供要素はユーザホームディレクトリの中にRLSサービスで定義されたインデックスドキュメントの中では、<サービス>要素でリソースリストを示します。
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/ 一口: joe@example.com/index 」は生産されます。 このURIでは、AUIDは「リソースリスト」です、そして、ドキュメントがXUIがファイル名で「: joe@example.com をちびちび飲む」という「インデックス」と共にユーザ木にあります。
6.3. Node Selector
6.3. ノードセレクタ
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要素、要素の属性、または1セットの名前空間結合を示します。 ノードセレクタは名前空間結合の要素、属性、またはセットを特定する式です。 文法は以下の通りです。
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 "]"
「[「位置」]」というposによるposによる名前の拡大名前空間ノードセレクタ=要素セレクタ[「/」端末のセレクタ]端末のセレクタ=属性セレクタ/セレクタ/セレクタ要素セレクタ=ステップ*(「/」ステップ)ステップ=//attrによる/pos-attrによる名前の/拡大セレクタ=NameorAny=NameorAny
Rosenberg Standards Track [Page 18] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[18ページ]。
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 "/"
「[「位置」]」という「[「attr-テスト」]」というpos-attrによる「[「attr-テスト」]」というNameorAny=NameorAny att-名前「=」がattrでatt評価する位置=1*DIGIT attr-テスト="@"=NameorAnyはQName/「*」と等しいです。 XML Namespaces att-名前=QName att-価値からのQNameはAttValueと等しいです。 XML仕様属性セレクタ="@"から名前空間セレクタを=とatt命名してください、「名前空間:、:、」*「拡大セレクタ=1*(%x00-2e/%x30-ff)」。 「」 何にもかかわらず、/でも」
The QName grammar is defined in the XML namespaces [3] specification, and the AttValue grammar is defined in the XML specification XML 1.0 [1].
QName文法はXML名前空間[3]仕様に基づき定義されます、そして、AttValue文法はXML仕様XML1.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.
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.
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
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
Rosenberg Standards Track [Page 19] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 19] RFC 4825 XCAP May 2007
would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".
would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%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.
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.
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.
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.
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.
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.
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.
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.
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
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
Rosenberg Standards Track [Page 20] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 20] RFC 4825 XCAP May 2007
(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.
(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.
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.
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.
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.
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.
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.
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.
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.
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
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
Rosenberg Standards Track [Page 21] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 21] RFC 4825 XCAP May 2007
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].
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].
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.
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.
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.
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.
Rosenberg Standards Track [Page 22] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 22] RFC 4825 XCAP May 2007
As an example, consider the following XML document:
As an example, consider the following XML document:
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:professor@example.net"
package="presence">
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
<watcher status="pending"
id="hh8juja87s997-ass7"
display-name="Mr. Subscriber"
event="subscribe">sip:userB@example.org</watcher>
</watcher-list>
</watcherinfo>
<?xml 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
Figure 3: Example XML Document
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:
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:
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
<watcher status="active" id="8ajksjda7s" duration-subscribed="509" event="approved">sip:userA@example.net</watcher>
6.4. Namespace Bindings for the Selector
6.4. Namespace Bindings for the Selector
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.
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.
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.
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.
Rosenberg Standards Track [Page 23] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 23] RFC 4825 XCAP May 2007
The following example shows a more complex matching operation, this time including the usage of namespace bindings. Consider the following document:
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>
<?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:
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/ ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace1-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/foo/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:
will select the first <baz> child element of the <bar> element in the document. The XCAP URI:
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace2-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/foo/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:
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:
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace2-uri) xmlns(d=urn:test:default-namespace)
http://xcap.example.com/test/users/sip:joe@example.com/index/ ~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri) xmlns(b=urn:test:namespace2-uri) xmlns(d=urn:test:default-namespace)
7. Client Operations
7. Client Operations
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.
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.
Rosenberg Standards Track [Page 24] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 24] RFC 4825 XCAP May 2007
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.
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.
The client will know what URI to use based on the naming conventions described by the application usage.
The client will know what URI to use based on the naming conventions described by the application usage.
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.
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.
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.
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.
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
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
Rosenberg Standards Track [Page 25] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 25] RFC 4825 XCAP May 2007
have this property, the server will reject the request with a 409 and indicate a cannot-insert error condition.
have this property, the server will reject the request with a 409 and indicate a cannot-insert error condition.
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].
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].
7.1. Create or Replace a Document
7.1. Create or Replace a Document
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.
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.
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".
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".
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.
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.
7.2. Delete a Document
7.2. Delete a Document
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.
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.
7.3. Fetch a Document
7.3. Fetch a Document
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.
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.
7.4. Create or Replace an Element
7.4. Create or Replace an Element
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
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
Rosenberg Standards Track [Page 26] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 26] RFC 4825 XCAP May 2007
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.
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.
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:
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]
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.
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.
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>.
Consider the example document in Figure 3. The client would like to insert a new <watcher> element as the second element underneath <watcher-list>. However, it cannot just PUT to a URI with the watcherinfo/watcher-list/*[2] node selector; this node selector would select the existing second child element of <watcher-list> and replace it. Thus, the PUT has to be made to a URI with watcherinfo/ watcher-list/*[2][@id="hhggff"] as the node selector, where "hhggff" is the value of the "id" attribute of the new element to be inserted. This node-selector is a no-match against the current document, and would be a match against the new element if it was inserted as the second child element of <watcher-list>.
The "*" indicates that all element children of <watcher-info> are to be considered when computing the position for insertion. If, instead of a wildcard *, an element name (QName) was present, the expression above would insert the new element as the position-th element amongst those with the same expanded name (see Section 8.2.3 for a discussion on insertion rules).
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).
Once the client constructs the URI, it invokes the HTTP PUT method. The content in the request MUST be an XML element. Specifically, it
Once the client constructs the URI, it invokes the HTTP PUT method. The content in the request MUST be an XML element. Specifically, it
Rosenberg Standards Track [Page 27] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 27] RFC 4825 XCAP May 2007
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.
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.
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):
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):
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
PUT /rls-サービス/ユーザ/一口: 22sip: good-friends@example.com%22%5d HTTP/1.1コンテントタイプ: bill@example.com/index/~~/rls-services/ サービス%5b@uri=%アプリケーション/xcap-高架鉄道+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>
<サービスuriが「一口: mybuddies@example.com 」と等しい、gt;、<のリソースリストの>のhttp://xcap.example.com/リソースリスト/ユーザ/一口: joe@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%の5d</リソースリスト><は><パッケージ>存在</パッケージ></パッケージ></サービス>をパッケージします。
This request will fail with a 409. The Request URI contains a final path segment with a predicate based on attributes: @uri="sip:good-friends@example.com". However, this will not match the value of the "uri" attribute in the element in the body (sip:mybuddies@example.com).
この要求は409で失敗するでしょう。 Request URIは属性に基づく述部がある最終的な経路セグメントを含んでいます: @uriは「一口: good-friends@example.com 」と等しいです。 しかしながら、これはボディー(一口: mybuddies@example.com )で要素の"uri"属性の値に合わないでしょう。
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
GET、(PUT(x))==xの特性は操作の可能なタイプでいくつかの制限を導入します。 属性のために要素を新しい値を持っているものに取り替えるのは可能でないでしょう。
Rosenberg Standards Track [Page 28] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[28ページ]。
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.
唯一のユニークな要素識別子URIが要素を選択する目的にその属性の前の値を使用していたノードセレクタを含んだなら。 これによるまさに使用が例で上をケースに入れるということです。 取り替えられるべき要素の親を選ぶことができます、そして、次に、PUT操作のボディーはこの制限を逃れるために、属性値の代わりに位置が選択できますか、または親、取り替えられるべき子供、および他のすべての兄弟を含むでしょう。
7.5. Delete an Element
7.5. 要素を削除してください。
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削除のidempotencyの特性を維持するのに必要です。 ノードセレクタが名前空間接頭語を利用するなら質問コンポーネントが存在していなければならない、その場合、質問コンポーネントにおける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.
可能ですがidempotencyが保証される限られた場合だけでユニークな属性名と値を使用することのない位置の削除。 DELETE操作は単独で名前と位置のそばの要素を示します。特に、(親/elname[n])、削除されるべき要素がその名前をもっているすべての兄弟の中の最後の要素であるときにだけ、これは受入れられます。 DELETE操作は単独で位置のそばの要素を示します。同様である、(親/*[n])、削除されるべき要素がすべての兄弟要素の中の最終であるときにだけ、これは受入れられます、名前にかかわらず。
The client then invokes the HTTP DELETE method. The server will remove the element from the document (including its attributes,
そして、クライアントはHTTP DELETEメソッドを呼び出します。 サーバがドキュメントから要素を取り除く、(属性を含んでいます。
Rosenberg Standards Track [Page 29] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[29ページ]。
namespace declarations, and its descendant nodes, such as any children).
どんな子供などの名前空間宣言、およびその派生ノードも)
7.6. Fetch an Element
7.6. 要素をとって来てください。
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メソッドを呼び出します。 200OK応答はそのXML要素を含むでしょう。 明確に、初めのブラケットをきっかけにXMLドキュメントの中身を含んでいる、その要素のための終了タグのために右角括弧でその要素、および結末のためのタグを始めてください。 これはその結果すべての属性、名前空間宣言、および派生ノードを含むでしょう: その要素の要素、コメント、テキスト、および処理命令。
7.7. Create or Replace an Attribute
7.7. 属性を作成するか、または取り替えてください。
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メソッドを呼び出します。 要求で定義された内容は属性の値であるに違いありません、文法に、XML1.0[1]で定義されるAttValueにおいて、言いなりになります。 ボディーについてパーセントAttValueがURIで存在している時と異なってコード化してはいけないことに注意してください。 セクション15.2.2で定義される「アプリケーション/xcap-att+xml」のコンテントタイプと共にこの要求を送らなければなりません。 サーバは、ノードセレクタが結果として起こるドキュメントの上に評価されると、要求の現在の属性を返すように、属性を加えるでしょう。
To be certain that attribute insertions have the GET(PUT(x))==x property, the client can check that any attribute predicate in the
中属性入にはGETがあるのを確信している、(PUT(x))==xの特性、クライアントが、いずれも述部を結果と考えるのをチェックできる。
Rosenberg Standards Track [Page 30] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[30ページ]。
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):
属性が挿入されて、要求で挿入されるものと異なった属性を合わせる要素を選択する経路セグメント。 この特性を持たないで、またしたがってベキ等元でない要求に関する例と、以下のPUT要求(URIは読み易さのために系列によって折り重ねられる)を考えてください:
PUT
/rls-services/users/sip:bill@example.com/index/~~/rls-services
/service%5b@uri=%22sip:good-friends@example.com%22%5d/@uri
HTTP/1.1
Content-Type:application/xcap-att+xml
Host: xcap.example.com
/rls-サービス/ユーザ/一口: bill@example.com/index/~~/rls-services /サービス%5b@uri=%22sipを置いてください: 22%の5d/@uri HTTP/1.1コンテントタイプ: 良い友人@example.com%アプリケーション/xcap-att+xmlは以下を接待します。 xcap.example.com
"sip:bad-friends@example.com"
「一口: 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が影響を受ける要素を選択するのに属性の前の値を使用するノードセレクタを含んでいると。 これによる使用が例で上をケースに入れるということです。 要素は、代わりに、選択された位置、または取り替えられたその全体の親であるかもしれません。
7.8. Delete an Attribute
7.8. 属性を削除してください。
To delete an attribute from the document, the client constructs a URI whose document selector points to the document containing the attribute to be deleted. The node selector MUST be present following the node selector separator, and evaluate to an attribute in the document to be deleted. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
ドキュメントから属性を削除するために、クライアントはドキュメントセレクタが削除されるために属性を含むドキュメントを示すURIを構成します。 ノードセレクタは、ノードセレクタ分離符に従って、存在していて、削除されるとドキュメントの属性に評価しなければなりません。 ノードセレクタが名前空間接頭語を利用するなら質問コンポーネントが存在していなければならない、その場合、質問コンポーネントにおけるxmlns()式はそれらの接頭語を定義しなければなりません。
The client then invokes the HTTP DELETE method. The server will remove the attribute from the document.
そして、クライアントはHTTP DELETEメソッドを呼び出します。 サーバはドキュメントから属性を取り除くでしょう。
7.9. Fetch an Attribute
7.9. 属性をとって来てください。
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
ドキュメントの属性をとって来るために、クライアントはドキュメントセレクタがとって来られる属性を含むドキュメントを示すURIを構成します。 ノードセレクタ分離符に従って、ノードセレクタは存在していなければなりません、とって来られる値がことである属性を特定する式を含んでいて。 ノードセレクタが名前空間接頭語、コネを利用するなら、質問コンポーネントは存在していなければなりません。
Rosenberg Standards Track [Page 31] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[31ページ]。
which case the xmlns() expressions in the query component MUST define those prefixes.
どれが質問コンポーネントにおける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メソッドを呼び出します。 200OK応答はXMLで1.0の仕様を定義するときAttValueの文法によると、フォーマットされた指定された属性がある「アプリケーション/xcap-att+xml」ドキュメントを含むでしょう。
7.10. Fetch Namespace Bindings
7.10. 名前空間結合をとって来てください。
If a client wishes to insert an element or attribute into a document, and that element or attribute is part of a namespace declared elsewhere in the document, the client will need to know the namespace bindings in order to construct the XML content in the request. If the client has a cached copy of the document, it will know the bindings. However, if it doesn't have the whole document cached, it can be useful to fetch just the bindings that are in scope for an element, in order to construct a subsequent PUT request.
クライアントが要素か属性をドキュメントに挿入したがっていて、その要素か属性がドキュメントのほかの場所で宣言された名前空間の一部であるなら、クライアントは、要求におけるXML内容を構成するために名前空間結合を知る必要があるでしょう。 クライアントにドキュメントのキャッシュされたコピーがあると、それは結合を知るでしょう。 しかしながら、それで全体のドキュメントをキャッシュしないなら、要素のためにまさしく範囲にある結合をとって来るのは役に立つ場合があります、その後のPUT要求を構成するために。
To get those bindings, the client constructs a URI whose document selector points to the document containing the element whose namespace bindings are to be fetched. The node selector MUST be present following the node selector separator, containing an expression identifying the desired namespace bindings. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
それらの結合を得るために、クライアントはドキュメントセレクタがとって来られる名前空間結合がことである要素を含むドキュメントを示すURIを構成します。 ノードセレクタ分離符に従って、必要な名前空間結合を特定する式を含んでいて、ノードセレクタは存在していなければなりません。 ノードセレクタが名前空間接頭語を利用するなら質問コンポーネントが存在していなければならない、その場合、質問コンポーネントにおけるxmlns()式はそれらの接頭語を定義しなければなりません。
The client then invokes the GET method. The 200 OK response will contain an "application/xcap-ns+xml" document with the namespace definitions. The format for this document is defined in Section 10.
そして、クライアントはGETメソッドを呼び出します。 200OK応答は名前空間定義がある「+ アプリケーション/xcap-ナノ秒xml」ドキュメントを含むでしょう。 このドキュメントのための書式はセクション10で定義されます。
A client cannot set the namespace prefixes in scope for an element. As such, a node selector that identifies namespace prefixes MUST NOT appear in a PUT or DELETE request.
クライアントは範囲に名前空間接頭語を要素に設定できません。 そういうものとして、名前空間接頭語を特定するノードセレクタはPUTかDELETE要求に現れてはいけません。
7.11. Conditional Operations
7.11. 条件付き演算
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とIf-マッチヘッダーフィールドでそれらをリソースにおいて実体タグの現行価値に依存するように特に、することができます。 これらの条件付き演算は特に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.
例えば、クライアントが頻繁にドキュメントの最新版をキャッシュしたくなると予期されます。 それで、クライアントが始動すると、それは、サーバからの現在のドキュメントをとって来て、それを保存するでしょう。
Rosenberg Standards Track [Page 32] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[32ページ]。
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応答でこの要求を拒絶するでしょう。 その場合、クライアントは、キャッシュされたバージョンを洗い流して、全体のドキュメントをとって来て、200OKのサーバによってGET要求に返された新しい実体タグを保存する必要があるでしょう。 そして、If-マッチヘッダーフィールドに新しい実体タグを置いて、それは要求を再試行できます。 これが成功するなら、PUTへの応答におけるEtagヘッダーフィールドはただ挿入されたか、または変更されたリソースのための実体タグを含んでいます。 ドキュメントのすべてのリソースがそれらの実体タグのために同じ値を共有するので、この実体タグ価値を他のリソースの変更に適用できます。
A client can also conditionally delete elements or attributes by including an If-Match header field in DELETE requests. Note that the 200 OK responses to a DELETE will contain an Etag header field, containing the entity tag for all of the other resources in the document, even though the resource identified by the DELETE request no longer exists.
また、クライアントは、DELETE要求にIf-マッチヘッダーフィールドを含んでいることによって、条件付きに要素か属性を削除できます。 DELETEへの200のOK応答がEtagヘッダーフィールドを含むことに注意してください、ドキュメントの他のリソースのすべてのための実体タグを含んでいて、DELETE要求で特定されたリソースはもう存在していませんが。
When a client uses conditional PUT and DELETE operations, it can apply those changes to its local cached copy, and update the value of the entity tag for the locally cached copy based on the Etag header field returned in the response. As long as no other clients try to modify the document, the client will be able to perform conditional operations on the document without ever having to perform separate GET operations to synchronize the document and its entity tags with the server. If another client tries to modify the document, this will be detected by the conditional mechanisms, and the client will need to perform a GET to resynchronize its copy unless it has some other means to learn about the change.
クライアントが条件付きのPUTとDELETE操作を使用すると、それは、応答で返されたEtagヘッダーフィールドに基づく局所的にキャッシュされたコピーのために、地方のキャッシュされたコピーにそれらの変化を適用して、実体タグの値をアップデートできます。 他のどんなクライアントもドキュメントを変更しようとしない限り、ドキュメントとその実体タグをサーバと同期させるように別々のGET操作を実行する必要はなくて、クライアントはドキュメントに条件付き演算を実行できるでしょう。別のクライアントがドキュメントを変更しようとすると、これは条件付きのメカニズムによって検出されるでしょう、そして、それに変化に関して学ぶある他の手段がないと、クライアントはコピーを再連動させるようにGETを実行する必要があるでしょう。
If a client does not perform a conditional operation, but did have a cached copy of the document, that cached copy will become invalid once the operation is performed (indeed, it may have become invalid even beforehand). Unconditional operations should only be performed by clients when knowledge of the entire document is not important for the operation to succeed.
操作がいったん実行されて(本当に、それはあらかじめさえ、無効になったかもしれません)、ドキュメントのキャッシュされたコピーを持っていた以外に、クライアントが条件付き演算は実行しないと、そのキャッシュされたコピーが無効になるでしょう。 操作が引き継ぐように全体のドキュメントに関する知識が重要でないときにだけ、無条件の操作はクライアントによって実行されるべきです。
Rosenberg Standards Track [Page 33] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[33ページ]。
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.
別の例、クライアントであるときに、aがドキュメントをとって来て、キャッシュされた旧式のバージョンがあるとき、クライアントが条件付きのGETを使用するのは、キャッシュされたコピーがまだ有効であるならネットワーク用法を減少させるために役に立ちます。 ドキュメントのためにクライアントによって持たれていた現在のetagと等しい値でGET要求になにも合わせないIfヘッダーフィールドを含んでいることによって、これをします。 サーバによって持たれていたetagがクライアントによって保持されたそれより異なる場合にだけ、サーバは200OK応答を生成するでしょう。 異ならないと、サーバは304応答で反応するでしょう。
8. Server Behavior
8. サーバの振舞い
An XCAP server is an HTTP/1.1 compliant origin server. The behaviors mandated by this specification relate to the way in which the HTTP URI is interpreted and the content is constructed.
XCAPサーバはHTTP/1.1の対応する発生源サーバです。この仕様で強制された振舞いはHTTP URIが解釈されて、内容が構成される方法に関連します。
An XCAP server MUST be explicitly aware of the application usage against which requests are being made. That is, the server must be explicitly configured to handle URIs for each specific application usage, and must be aware of the constraints imposed by that application usage.
XCAPサーバは明らかに、要求がされているアプリケーション用法を意識していなければなりません。 すなわち、サーバは、それぞれの特定のアプリケーション用法のためにURIを扱うために明らかに構成しなければならなくて、そのアプリケーション用法で課された規制を意識しているに違いありません。
When the server receives a request, the treatment depends on the URI. If the URI refers to an application usage not understood by the server, the server MUST reject the request with a 404 (Not Found) response. If the URI refers to a user (identified by an XUI) that is not recognized by the server, it MUST reject the request with a 404 (Not Found). If the URI includes extension-selectors that the server doesn't understand, it MUST reject the request with a 404 (Not Found).
サーバが要求を受け取るとき、処理はURIによります。 URIがサーバに解釈されなかったアプリケーション用法を示すなら、サーバは404(Foundでない)応答で要求を拒絶しなければなりません。 URIがサーバによって見分けられないユーザ(XUIによって特定される)について言及するなら、それは404(Foundでない)で要求を拒絶しなければなりません。 URIがサーバが理解していない拡大セレクタを含んでいるなら、それは404(Foundでない)で要求を拒絶しなければなりません。
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 Digestが[11]であると実装しなければなりません。 その上、サーバはTLS、RFC2818[14]の上でHTTPを実装しなければなりません。 管理者がXCAP根のURIとしてHTTPS URIを使用するのは、RECOMMENDEDです、ダイジェストクライアント認証がTLSの上に起こるように。
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
次に、サーバは、適切に要求URIを評価できるのを確実にします。 サーバはノードセレクタとドキュメントセレクタを切り離さなければなりません、ノードセレクタ分離符(「~~」)の最初のインスタンスでURIを分けることによって。 存在しているなら、サーバは要求URIでノードセレクタをチェックしなければなりません。 何か適切な名前が存在しているなら
Rosenberg Standards Track [Page 34] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[34ページ]。
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の質問コンポーネントでxmlns()式で定義されません、そして、サーバは400応答で要求を拒絶しなければなりません。
After checking the namespace prefix definitions, the specific behavior depends on the method and what the URI refers to.
名前空間接頭語定義をチェックした後に、特異的行動はメソッドとURIが示すことによります。
8.1. POST Handling
8.1. ポスト取り扱い
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へのポストの操作は定義されません。 SHOULDが405を返すXCAPリソースに関するそのような要求を受け取るサーバ。
8.2. PUT Handling
8.2. 取り扱いを置いてください。
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(メソッドNot Allowed)で要求を拒絶しなければならなくて、GETメソッドを含むAllowヘッダーフィールドを含まなければなりません。
8.2.1. Locating the Parent
8.2.1. 親の居場所を見つけます。
The first step the server performs is to locate the parent, whether it is a directory or element, in which the resource is to be placed. To do that, the server removes the last path segment from the URI. The rest of the URI refers to the parent. This parent can be a document, element, or prefix of a document selector (called a directory, even though this specification does not mandate that documents are actually stored in a filesystem). This URI is called the parent URI. The path segment that was removed is called the target selector, and the node (element, document, or attribute) it describes is called the target node.
サーバが実行する第一歩は親の居場所を見つけることです、それがディレクトリか要素であることにかかわらず。リソースは要素に置かれることです。 それをするために、サーバはURIから最後の経路セグメントを取り除きます。 URIの残りは親について言及します。 この親は、ドキュメントセレクタ(この仕様は、ドキュメントが実際にファイルシステムで保存されるのを強制しませんが、ディレクトリと呼ばれる)のドキュメント、要素、または接頭語であるかもしれません。 このURIは親URIと呼ばれます。 取り除かれた経路セグメントは目標セレクタと呼ばれます、そして、それが説明するノード(要素、ドキュメント、または属性)は目標ノードと呼ばれます。
If the parent URI has no node selector separator, it is referring to the directory into which the document should be inserted. In normal XCAP operations, this will be either the user's home directory or the global directory, which will always exist on the server. However, if an application usage is making use of subdirectories (despite the fact that this is not recommended), it is possible that the directory into which the document should be inserted does not exist. In this case, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. Detailed
親URIにノードセレクタ分離符が全くないなら、それはドキュメントが挿入されるべきであるディレクトリを参照しています。 通常のXCAP操作では、これは、ユーザのホームディレクトリかグローバルなディレクトリのどちらかになるでしょう。(それは、サーバにいつも存在するでしょう)。しかしながら、アプリケーション用法がサブディレクトリを利用することであるなら(これが推薦されないという事実にもかかわらず)、ドキュメントが挿入されるべきであるディレクトリが存在しないのは、可能です。 この場合、サーバは409応答を返さなければなりません、そして、SHOULDは<親>がない要素を含む詳細な闘争レポートを含んでいます。 詳しく述べられます。
Rosenberg Standards Track [Page 35] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[35ページ]。
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.
セクション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応答を返さなければなりません、そして、SHOULDは<親>がない要素を含む詳細な闘争レポートを含んでいます。 存在しているなら、ノードセレクタは、抽出されて、解読されます(ノードセレクタがパーセントによってコード化されていると思い出してください)。 ノードセレクタはセクション6.3で議論した合っている操作に基づくドキュメントに適用されます。 結果がいいえマッチか病人であるなら、サーバは409応答を返さなければなりません、そして、SHOULDは<親>がない要素を含む詳細な闘争レポートを含んでいます。
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で説明されるように要求の内容を有効にします。
8.2.2. Verifying Document Content
8.2.2. ドキュメント内容について確かめます。
If the PUT request is for a document (the request URI had no node selector separator), the content of the request body has to be a well-formed XML document. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-well-formed> element. If the document is well-formed but not UTF-8 encoded, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element. If the MIME type in the Content-Type header field of the request is not equal to the MIME type defined for the application usage, the server MUST reject the request with a 415.
PUT要求がドキュメントのためのもの(要求URIには、ノードセレクタ分離符が全くなかった)であるなら、要求本体の内容は整形式のXMLドキュメントでなければなりません。 それがそうでないなら、サーバは409応答コードで要求を拒絶しなければなりません。 その応答SHOULDは<の整形式でない>要素を含む詳細な闘争レポートを含んでいます。 ドキュメントが整形式であるか、しかし、どんなUTF-8もコード化されないで、サーバは409応答コードで要求を拒絶しなければなりません。 その応答SHOULDは<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
PUT要求が要素のためのものであるなら、要求本体の内容はただ一つの要素だけを含むまた、XML断片ボディーとしてXML Fragment Interchange[23]仕様で知られているXMLドキュメントのバランスの良い領域でなければなりません。 それがそうでないなら、サーバは409応答コードで要求を拒絶しなければなりません。 応答SHOULDが<を含む詳細な闘争レポートを含んでいるのが>要素をxml破片手榴弾で殺傷しません。 断片ボディーがバランスが良い、含有
Rosenberg Standards Track [Page 36] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[36ページ]。
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.
UTF-8文字集合、サーバにおける外部のキャラクタは409応答コードで要求を拒絶しなければなりません。 その応答SHOULDは<utf-8でない>要素を含む詳細な闘争レポートを含んでいます。 要求のコンテントタイプヘッダーフィールドにおけるMIMEの種類が「アプリケーション/xcap-高架鉄道+xml」と等しくないなら、サーバは415で要求を拒絶しなければなりません。
If the PUT request is for an attribute, the content of the request body has to be a sequence of characters that comply with the grammar for AttValue as defined above. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-xml-att-value> element. If the attribute value is valid but contains characters outside of the UTF-8 character set, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element.If the MIME type in the Content-Type header field of the request is not equal to "application/xcap-att+xml", the server MUST reject the request with a 415.
PUT要求が属性のためのものであるなら、要求本体の内容はAttValueのために上で定義されるように文法に従うキャラクタの系列でなければなりません。 それがそうでないなら、サーバは409応答コードで要求を拒絶しなければなりません。 応答SHOULDが<を含む詳細な闘争レポートを含んでいるのが>要素をxml-att評価しません。 属性値がUTF-8文字集合の外に有効ですが、キャラクタを含んでいるなら、サーバは409応答コードで要求を拒絶しなければなりません。 その応答SHOULDは「アプリケーション/xcap-att+xml」と等しくない状態で要求のコンテントタイプヘッダーフィールドに<utf-8でない>element.If MIMEの種類を含んでいるのがあるという詳細な闘争レポートを含んで、サーバは415で要求を拒絶しなければなりません。
8.2.3. Creation
8.2.3. 作成
The steps in this sub-section are followed if the PUT request will result in the creation of a new document, element, or attribute.
PUT要求が新しいドキュメント、要素、または属性の作成をもたらすなら、この小区分における方法は従われています。
If the PUT request is for a document, the content of the request body is placed into the directory, and its filename is associated with the target node, which is a document.
PUT要求がドキュメントのためのものであるなら、要求本体の内容はディレクトリに置かれます、そして、ファイル名は目標ノードに関連づけられます。(それは、ドキュメントです)。
If the PUT request is for an element, the server inserts the content of the request body as a new child element of the parent element selected in Section 8.2.1. The insertion is done such that the request URI, when evaluated, would now point to the element that was inserted. There exist three possible ways in which new elements are positioned.
PUT要求が要素のためのものであるなら、サーバはセクション8.2.1で選択された親元素の新しい子供要素として要求本体の内容を挿入します。 評価されると要求URIが現在挿入された要素を示すように、挿入をします。 新しい要素が置かれる3つの可能な方法が存在しています。
First, if there were no other sibling elements with the same expanded name, and the insertion is not positionally constrained, the new element is inserted such that it is the last element amongst all element siblings. Furthermore, if there were comment, text, or processing instruction nodes after the former last element, they MUST occur prior to the insertion of the new element. This case occurs when one of the following are true:
まず最初に、同じくらいが広げられている要素が命名する他の兄弟が全くいないで、また挿入が位置に抑制されないなら、新しい要素は、それがすべての要素兄弟の中の最後の要素であるように挿入されます。 その上、コメント、テキスト、または処理命令ノードが最後の前の要素の後にあったなら、それらは新しい要素の挿入の前に起こらなければなりません。 以下の1つが本当であるときに、本件は現れます:
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
o 目標セレクタの要素名はwildcardedされません。 属性セレクタがあるかもしれなくて(その場合、それは挿入される要素の属性に合わなければならないでしょう)、目標セレクタの位置には、休むか、またはaがあるでしょう。
Rosenberg Standards Track [Page 37] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[37ページ]。
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).
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 目標セレクタの要素名はwildcardedされますが、同じ親の下に他の要素が全くありません。 属性セレクタがあるかもしれなくて(その場合、それは挿入される要素の属性に合わなければならないでしょう)、目標セレクタの位置には、休むか、または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 目標セレクタの要素名はwildcardedされます、そして、同じ親の下に他の要素があります。 しかしながら、挿入されるために要素の属性を合わせて、親の下に他の兄弟要素には属性のいずれにも合っていない属性セレクタがあります。 目標セレクタの位置は休んでいます。
Secondly, if there were sibling elements with the same name already in the document, but the insertion is positionally unconstrained, the server MUST insert the element such that it is in the "earliest last" position. "Earliest last" means that the new element MUST be inserted so that there are no elements after it with the same expanded name, and for all insertion positions where this is true, it is inserted such that as many sibling nodes (element, comment, text, or processing instruction) appear after it as possible. This case occurs when the target selector is defined by a by-name or by-attr production, and there is no position indicated.
第二に、既にドキュメントには同じ名前がある兄弟要素がありましたが、挿入が位置に自由であるなら、サーバは、それが「最も早い最終」が置くコネであるように要素を挿入しなければなりません。 「最も早い最終」が、それの後に、要素が全く同じ拡張名前と共にないように新しい要素を挿入しなければならなくて、これが本当であるすべての挿入位置に関して、それが挿入されることを意味するので、同じくらい多くの兄弟ノード(要素、コメント、テキスト、または処理命令)がそれの後に可能に見えます。 目標セレクタが名前かattrによる作品で定義されるとき、本件は現れます、そして、示された位置が全くありません。
Lastly, if the element is positionally constrained, the server MUST insert the element so that it is in the "earliest nth" position. When n>1 and NameofAny is not a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it with the same expanded name. If there are not n-1 sibling elements with the same expanded name, the request will fail. When n>1 and NameorAny is a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it, each of which can have any expanded name. If there are not n-1 sibling elements in the document, the request will fail. In both of these cases, the new element is inserted such that as many sibling nodes appear after it as possible. When n=1 and
要素が位置に抑制されるなら、最後にサーバが中にそれがあるように要素を挿入しなければならない、「早期である、n番目、」 置きます。 n>1とNameofAnyがワイルドカードでないときに、それの前に、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
NameorAnyがワイルドカードでない、同じ拡張名前がある要素が同じ親の子供として既に現れるとき、挿入は位置に抑制されます。 この場合、この同じことがある既存の最初の要素が名前を広くするすぐ前に新しい要素は現れなければなりません。 n=1とNameorAnyがwildcardedされるとき、また、属性セレクタがあるとき、挿入は位置に抑制されます。
Rosenberg Standards Track [Page 38] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[38ページ]。
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.
それは親の最初の兄弟に合っていませんでした(それが合っていたか、または欠けるなら、これは挿入でないでしょうに)。 この場合、新しい要素はそれらの拡張名前にかかわらずすべての既存の要素のすぐ前に現れなければなりません。
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:
実際には、この挿入論理は密接に同じ拡張名前がある要素を団結します。 満足しているモデルがXML図式によって<系列>規則で説明されて、maxOccursが「限りない」基数と等しいと、これは以下のようにアプリケーション論理を簡素化します。
<xs:element name="foobar">
<xs:complexType>
<xs:sequence>
<xs:element ref="foo" maxOccurs="unbounded" />
<xs:element ref="bar" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs: 要素名=、「「><はxsされます: complexType><はxsされます: 系列><はxsされます: 要素審判="foo"maxOccursは「限りない」/><xsと等しいです: 要素審判=「バー」maxOccursは「限りない」/></xsと等しいです: ></xs: complexType></xs: 要素>を配列してください」をfoobarします。
Based on this schema, the document contains some number of <foo> elements followed by some number of <bar> elements. Either <bar> or <foo> elements may easily be added without wildcards and positional constraints. Note that if "minOccurs" cardinality of <foo> element were zero and <foo> elements do not yet exist, a positional predicate with the * wildcard must be used.
この図式に基づいて、ドキュメントは何らかの数の<foo>要素を含んでいます、続いて、何らかの数の<バー>要素を含みます。 <バー>か<foo>要素のどちらかがワイルドカードと位置の規制なしで容易に加えられるかもしれません。 foo>要素が<foo>要素の「minOccurs」基数がゼロと<であるならまだ存在していないというメモ、*ワイルドカードがある位置の述部を使用しなければなりません。
The whole insert logic is best described by complete examples. Consider the following document:
完全な例で全体の差し込み論理について説明するのは最も良いです。 以下のドキュメントを考えてください:
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xmlバージョン= 「1インチ?」「2番目」/>の「1番目」/>の<><根の><el1 att=el1 att=<!--コメント--><el2 attは「1番目」/>の</根の>と等しいです。
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=「3番目」/>であり、ノードセレクタが根/el1[@att= 「3番目」]であるPUT要求は以下のドキュメントをもたらすでしょう:
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/><el1 att="third"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xmlバージョン= 「1インチ?」「3番目」/>の「2番目」/>の<「1番目」/>の<><根の><el1 att=el1 att=el1 att=<!--コメント--><el2 attは「1番目」/>の</根の>と等しいです。
Rosenberg Standards Track [Page 39] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[39ページ]。
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"].
3番目の<el1>要素としてどうドキュメントと、コメントと空白ノードのすぐ前にそれを挿入してあるように注意してくださいか。 それはノードセレクタが根/el1[3][@att= 「3番目」]か根/*[3][@att= 「3番目」]であったならまさに同じ場所に挿入されたでしょうに。
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=「1番目」/>であり、ノードセレクタが根/el3であるなら、以下のドキュメントをもたらすでしょうに:
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
<el3 att="first"/></root>
<?xmlバージョン= 「1インチ?」「1番目」/>の<「2番目」/>の「1番目」/>の<><根の><el1 att=el1 att=<!--コメント--><el2 att=el3 attは「1番目」/>の</根の>と等しいです。
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=であるPUT要求、「2インチ/>とだれのノードセレクタが根/el2[」 @att=2インチ]であるかは以下のドキュメントをもたらすでしょう:
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/><el2 att="2"/>
</root>
<?xmlバージョン= 「1インチ?」「1番目」/>の<「2番目」/>の「1番目」/>の<><根の><el1 att=el1 att=<!--コメント--><el2 att=el2 attは「2インチ/>の</根の>」と等しいです。
It would have been inserted in exactly the same place if the node selector had been root/el2[2][@att="2"]. However, a selector root/ *[2][@att="2"] would result in the following document:
それがノードセレクタが根/el2[2]であったならまさに同じ場所に挿入された、[@attが等しい、「2インチ]」 しかしながら、セレクタが/*[2]を根づかせる、[@attが等しい、「2インチ] 以下のドキュメントをもたらすでしょう:、」
<?xml version="1.0"?>
<root>
<el1 att="first"/><el2 att="2"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xmlバージョン= 「1インチ?」「「1番目」/>の><根><el1 att=<el2 att=「2インチ/>の<el1 att=」2番目」/><!--コメント--><el2 attは「1番目」/>の</根の>と等しいです。
Rosenberg Standards Track [Page 40] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[40ページ]。
Lastly, if the node selector had been root/el2[1][@att="2"] the result would be:
ノードセレクタがあったなら最後に/el2[1]を根づかせてください、[@att= 「2インチ] 結果は以下の通りでしょう」
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="2"/><el2 att="first"/>
</root>
<?xmlバージョン= 「1インチ?」「「2番目」/>の「1番目」/>の<><根の><el1 att=el1 att=<!--コメント--><el2 att=「2インチ/>の<el2 att=」1番目」/></根の>。
It is possible that the element cannot be inserted such that the request URI, when evaluated, returns the content provided in the request. Such a request is not allowed for PUT. This happens when the element in the body is not described by the expression in the target selector. An example of this case is described in Section 7.4. If this happens, the server MUST NOT perform the insertion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element. It is important to note that schema compliance does not play a role while performing the insertion. That is, the decision of where the element gets inserted is dictated entirely by the structure of the request-URI, the current document, and the rules in this specification.
評価されると要求URIが要求に提供された内容を返すように要素を挿入できないのは可能です。 そのような要求はPUTのために許されていません。 ボディーの要素が目標セレクタの式によって説明されないとき、これは起こります。 本件に関する例はセクション7.4で説明されます。 これが起こるなら、サーバは、挿入を実行してはいけなくて、409応答で要求を拒絶しなければなりません。 SHOULDが含む応答では、<を含む詳細な闘争レポートは挿入できません。ボディー、->要素を挿入してください。 図式コンプライアンスが挿入を実行している間役割を果たさないことに注意するのは重要です。 すなわち、要素が挿入されるところに関する決定はこの仕様に完全に要求URI、現在のドキュメント、および規則の構造によって書き取られます。
If the element being inserted (or any of its children) contain namespace declarations, those declarations are retained when the element is inserted, even if those same declarations exist in a parent element after insertion. The XCAP server MUST NOT remove redundant namespace declarations or otherwise change the namespace declarations that were present in the element being inserted.
要素が挿入されるとき、挿入される要素(または、子供のどれか)が名前空間宣言を含んでいるなら、それらの宣言は保有されます、それらの同じ宣言が挿入の後に親元素に存在しても。 XCAPサーバは、余分な名前空間宣言を取り除いてはいけませんし、またそうでなければ、挿入される要素に存在している名前空間宣言を変えてはいけません。
If the PUT request is for an attribute, the server inserts the content of the request body as the value of the attribute. The name of the attribute is equal to the att-name from the attribute-selector in the target selector.
PUT要求が属性のためのものであるなら、サーバは属性の値として要求本体の内容を挿入します。 属性の名前は目標セレクタの属性セレクタからのatt-名前と等しいです。
Assuming that the insertion can be accomplished, the server verifies that the insertion results in a document that meets the constraints of the application usage. This is discussed in Section 8.2.5.
挿入を実行できると仮定して、サーバは、挿入がアプリケーション用法の規制を満たすドキュメントをもたらすことを確かめます。 セクション8.2.5でこれについて議論します。
8.2.4. Replacement
8.2.4. 交換
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要求が要求のコンテンツでドキュメント、要素、または属性の交換をもたらすなら、この小区分における方法は従われています。
Rosenberg Standards Track [Page 41] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[41ページ]。
If the PUT request is for a document, the content of the request body is placed into the directory, replacing the document with the same filename.
PUT要求がドキュメントのためのものであるなら、要求本体の内容はディレクトリに置かれます、ドキュメントを同じファイル名に取り替えて。
If the PUT request is for an element, the server replaces the target node with the content of the request body. As in the creation case, it is possible that, after replacement, the request URI does not select the element that was just inserted. If this happens, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
PUT要求が要素のためのものであるなら、サーバは目標ノードを要求本体の内容に取り替えます。 作成ケースのように、要求URIが交換の後にただ挿入された要素を選択しないのは、可能です。 これが起こるなら、サーバは、交換を実行してはいけなくて、409応答で要求を拒絶しなければなりません。 SHOULDが含む応答では、<を含む詳細な闘争レポートは挿入できません。ボディー、->要素を挿入してください。
As with creation, replacement of an element does not result in the changing or elimination of namespace declarations within the newly modified element.
作成のように、要素の交換は新たに変更された要素の中で名前空間宣言の変化か除去をもたらしません。
If the PUT request is for an attribute, the server sets the value of the selected attribute to the content of the request body. It is possible in the replacement case (but not in the creation case), that, after replacement of the attribute, the request URI no longer selects the attribute that was just replaced. The scenario in which this can happen is discussed in Section 7.7. If this is the case, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
PUT要求が属性のためのものであるなら、サーバは要求本体の内容に選択された属性の値を設定します。 交換では、ケース(しかし、作成場合では、どんなそうしない)、属性、要求URIの交換の後のそれがもうただ取り替えられた属性を選択しないのは、可能です。 セクション7.7でこれが起こることができるシナリオについて議論します。 これがそうであるなら、サーバは、交換を実行してはいけなくて、409応答で要求を拒絶しなければなりません。 SHOULDが含む応答では、<を含む詳細な闘争レポートは挿入できません。ボディー、->要素を挿入してください。
8.2.5. Validation
8.2.5. 合法化
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応答で要求を拒絶しなければなりません。 <図式合法化誤りを含んでいて、その応答SHOULDは詳細な闘争レポートを含んでいます。>要素。 図式が他の名前空間から要素か属性を考慮して、新しいドキュメントが未知の名前空間からの要素か属性を含んでいるなら、サーバは変化を許容しなければなりません。 言い換えれば、XCAPサーバが要素と属性のためにドキュメントの中に名前空間と対応するschemasを理解するのは必要ではありません、図式自体が、そのような要素か属性が含まれているのを許容する限り。 もちろん、そのような未知の名前空間はセクション12で議論したXCAP能力ドキュメントのサーバで広告を出さないでしょう。
If the final document contains elements or attributes from a namespace that the server does understand (and has consequently
最終合意文書が要素を含んでいるか、またはサーバがする名前空間からの属性が分かる、(その結果有
Rosenberg Standards Track [Page 42] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[42ページ]。
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応答で要求を拒絶しなければなりません。 <図式合法化誤りを含んでいて、その応答SHOULDは詳細な闘争レポートを含んでいます。>要素。
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応答で要求を拒絶しなければなりません。 <のユニークさ失敗を含んでいて、その応答SHOULDは詳細な闘争レポートを含んでいます。>要素。 その要素はクライアントが再試行するのに使用できる提案された値を含むことができます。 これらのSHOULD、サーバが409を生成するとき一意性制約を満たす値になってください。
The server also checks for URI constraints and other non-schema data constraints. If the document fails one of these constraints, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <constraint-failure> element. That element indicates that the document failed non-schema data constraints explicitly called out by the application usage.
また、サーバはURI規制と他の非図式データ規制がないかどうかチェックします。 ドキュメントがこれらの規制の1つに失敗するなら、サーバは挿入を実行してはいけません。 それは409応答で要求を拒絶しなければなりません。 <規制失敗を含んでいて、その応答SHOULDは詳細な闘争レポートを含んでいます。>要素。 その要素は、ドキュメントがアプリケーション用法によって明らかに呼び出された非図式データ規制に失敗したのを示します。
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.
要素か属性取り外しには、同様の規制があります。 サーバは、図式の正当性と承諾がないかどうかアプリケーション用法で定義された規制にドキュメントをチェックして、上で説明されるように要求を拒絶します、どちらのチェックも失敗するなら。
8.2.6. Conditional Processing
8.2.6. 条件付きの処理
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
いかなる他のHTTPリソースのようにも、XCAPリソースに関するPUT要求をIf-マッチとなにも合わせないIfヘッダーフィールドの用法で条件付きにすることができます。 交換において、これらは[6]で定義されるように処理されます。 要素か属性の挿入において、条件付き演算は受入れられます。 [6]の手順に使用される実体タグは挿入される要素か属性の親と同じドキュメントの中のリソースのすべてのためのものです。 これを考える1つの方法はPUT要求を受け取り次第論理的に話して、XCAPサーバが要求で参照をつけられるリソースのためにetagを例示して、次に、要求の処理を当てはまるということです。 この振舞いのために、aではなく、挿入である操作を条件とする属性か要素に条件付きの差し込みを実行するのは可能ではありません。
Rosenberg Standards Track [Page 43] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[43ページ]。
replacement. In other words, a conditional PUT of an element or attribute with an If-None-Match: * will always fail.
交換。 言い換えれば、なにも合わせないIfがある要素か属性の条件付きのPUT: * いつも失敗するでしょう。
8.2.7. Resource Interdependencies
8.2.7. リソース相互依存性
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.
作成か交換がうまくいって、リソース相互依存性が決議されているなら、サーバはOKに、それぞれ1か200 201Createdを返します。 201Createdが新しいドキュメント、要素、または属性の作成のために生成されることに注意してください。 PUT MUSTへの200OK応答は少しの内容も含んでいません。 RFC2616の推薦に従って、201は作成されたリソースを特定するLocationヘッダーフィールドと実体を含むことができます。 PUTへのすべてのうまくいっている応答に実体タグを含まなければなりません。
8.3. GET Handling
8.3. 取り扱いを得てください。
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の意味論がRFC2616で指定されるようにあります。 このセクションは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応答です。 200OK応答のボディーの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
URIがノードセレクタを含んでいて、サーバがドキュメントセレクタとそれが見つけられるかどうかによって指定されたドキュメントを入手するという要求がそのドキュメントの中にノードセレクタを評価するなら。 ノードセレクタがドキュメントが全く見つけられないか、いいえマッチまたは病人であるなら、サーバは404応答を返します。 さもなければ、サーバは200OK応答を返します。 ノードセレクタがXML要素を特定するなら、選択された要素を含むXML断片ボディーとして200OK応答でその要素を返します。 サーバは名前空間を加えてはいけません。
Rosenberg Standards Track [Page 44] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[44ページ]。
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.
要素かその子供で使用しましたが、名前空間を表す結合が先祖要素で宣言しました。 クライアントが既にこれらの結合を知るだろうか(それには全体のドキュメントのキャッシュされたコピーがあるので)、またはそれは結合のために明らかに質問することによって、それらを学ぶことができます。 応答のMIMEの種類は「アプリケーション/xcap-高架鉄道+xml」であるに違いありません。 ノードセレクタがXML属性を特定するなら、応答のボディーでその属性の値を返します。 応答のMIMEの種類は「アプリケーション/xcap-att+xml」であるに違いありません。 ノードセレクタが1セットの名前空間結合を特定するなら、サーバは、要素(デフォルトを含んでいる)のために範囲で名前空間結合のセットを計算して、セクション10で定義された「+ アプリケーション/xcap-ナノ秒xml」書式を使用することでそれをコード化します。 そして、応答のボディーでそのドキュメントを返します。
GET operations can be conditional, and follow the procedures defined in [6].
GET操作は、条件付きであり、[6]で定義された手順に従うことができます。
Note that the GET of a resource that was just PUT might not be octet- for-octet equivalent to what was PUT, due to XML normalization and equivalency rules.
ただPUTであったリソースのGETがXML正常化と同等規則のためにPUTであったことと八重奏のための八重奏同等物でないかもしれないことに注意してください。
A successful response to a GET MUST include an entity tag.
GET MUSTへのうまくいっている応答は実体タグを含んでいます。
8.4. DELETE Handling
8.4. 取り扱いを削除してください。
The semantics of DELETE are as specified in RFC 2616. This section clarifies the specific content to be deleted for a particular URI that represents an XCAP resource.
DELETEの意味論がRFC2616で指定されるようにあります。 このセクションは、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(メソッドNot Allowed)で要求を拒絶しなければならなくて、GETメソッドを含むAllowヘッダーフィールドを含まなければなりません。
If the request URI contains only a document selector, the server deletes the document specified by the URI if it exists and returns a 200 OK, else returns a 404 response.
要求URIがドキュメントセレクタだけを含んでいるなら、サーバは、存在しているなら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
URIがノードセレクタを含んでいて、サーバがドキュメントセレクタとそれが見つけられるかどうかによって指定されたドキュメントを入手するという要求がそのドキュメントの中にノードセレクタを評価するなら。 ノードセレクタがドキュメントが全く見つけられないか、いいえマッチまたは病人(複数の要素か属性が選択されるなら無効になることに注意する)であるなら、サーバは404応答を返します。 さもなければ、サーバは、ドキュメントから指定された要素か属性を取り除いて、セクション8.2.5で定義された合法化チェックを実行します。 この削除が削除された要素の周りの少しの余白も含んでいないことに注意してください。 XCAPサーバは周囲の空白を保持しなければなりません。 それは要求URIが削除の後に別の要素を選択するのが可能です。
Rosenberg Standards Track [Page 45] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[45ページ]。
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.
記録します。 これが起こるなら、サーバは、削除を実行してはいけなくて、409応答で要求を拒絶しなければなりません。 SHOULDが含む応答では、<を含む詳細な闘争レポートは削除できません。ボディー、->要素を削除してください。 削除が規制の1つの失敗を引き起こすなら、削除は行われてはいけません。 サーバは409応答を計算するためのセクション8.2.5で手順に従います。 削除がまだ有効なドキュメントをもたらすなら、サーバは、削除を実行して、アプリケーション用法で定義されたリソース相互依存性を処理して、200OK応答を返さなければなりません。
DELETE operations can be conditional, and follow the procedures defined in [6].
DELETE操作は、条件付きであり、[6]で定義された手順に従うことができます。
Before the server returns the 200 OK response to a DELETE, it MUST process the resource interdependencies as defined in Section 8.2.7. As long as the document still exists after the delete operation, any successful response to DELETE MUST include the entity tag of the document.
サーバがDELETEへの200OK応答を返す前に、それはセクション8.2.7で定義されるようにリソース相互依存性を処理しなければなりません。 ドキュメントがまだ後に存在している限り、操作(実体がタグ付けをするドキュメントのDELETE MUSTインクルードへのどんなうまくいっている応答も)を削除してください。
8.5. Managing Etags
8.5. Etagsを管理します。
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サーバはPUT、GET、およびDELETEへのすべての200か201の応答にEtagヘッダーフィールドを含まなければなりません、ドキュメント自体が操作の後にまだ存在していると仮定して。 DELETEの場合では、実体タグは要素か属性の削除の後にドキュメントについて実体タグの値について言及します。
XCAP resources do not introduce new requirements on the strength of the entity tags.
XCAPリソースは実体タグの強さに関する新しい要件を導入しません。
As a result of this constraint, when a client makes a change to an element or attribute within a document, the response to that operation will convey the entity tag of the resource that was just affected. Since the client knows that this entity tag value is shared by all of the other resources in the document, the client can make conditional requests against other resources using that entity tag.
クライアントがドキュメントの中に要素か属性への変更を行うときのこの規制の結果、その操作への応答はただ影響を受けたリソースの実体タグを運ぶでしょう。 クライアントが、この実体タグ価値がドキュメントの他のリソースのすべてによって共有されるのを知っているので、クライアントはその実体タグを使用することで他のリソースに対して条件付き要求をすることができます。
Rosenberg Standards Track [Page 46] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[46ページ]。
9. Cache Control
9. キャッシュ制御
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.
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.
10. Namespace Binding Format
10. Namespace Binding Format
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.
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.
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.
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.
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:
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:
<baz xmlns="urn:test:namespace1-uri"
xmlns:ns1="urn:tes: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.
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.
11. Detailed Conflict Reports
11. Detailed Conflict Reports
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
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
Rosenberg Standards Track [Page 47] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 47] RFC 4825 XCAP May 2007
Section 11.2. Its MIME type, registered by this specification, is "application/xcap-error+xml".
Section 11.2. Its MIME type, registered by this specification, is "application/xcap-error+xml".
11.1. Document Structure
11.1. Document Structure
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.
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.
The following error elements are defined by this specification:
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>: This indicates that the body of the request was not a well-formed XML document.
<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>: 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.
<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>: 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.
<schema-validation-error>: This element indicates that the document
was not compliant to the schema after the requested operation was
performed.
<schema-validation-error>: This element indicates that the document was not compliant to the schema after the requested operation was performed.
<not-xml-att-value>: This indicates that the request was supposed to
contain a valid XML attribute value, but did not.
<not-xml-att-value>: This indicates that the request was supposed to contain a valid XML attribute value, but did not.
<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.
<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.
<cannot-delete>: This indicates that the requested DELETE operation
could not be performed because it would not be idempotent.
<cannot-delete>: This indicates that the requested DELETE operation could not be performed because it would not be idempotent.
Rosenberg Standards Track [Page 48] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 48] RFC 4825 XCAP May 2007
<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.
<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.
<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>: This indicates that the requested operation would result in a document that failed a data constraint defined by the application usage, but not enforced by the schema or a uniqueness constraint.
<extension>: This indicates an error condition that is defined by an
extension to XCAP. Clients that do not understand the content of
the extension element MUST discard the xcap-error document and
treat the error as an unqualified 409.
<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.
<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>: This indicates that the request could not be completed because it would have produced a document not encoded in 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:
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:
<?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"?> <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>
Rosenberg Standards Track [Page 49] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 49] RFC 4825 XCAP May 2007
11.2. XML Schema
11.2. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error"
xmlns="urn:ietf:params:xml:ns:xcap-error"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" 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="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="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="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: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>
Rosenberg Standards Track [Page 50] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 50] RFC 4825 XCAP May 2007
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<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="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="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 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>
Rosenberg Standards Track [Page 51] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 51] RFC 4825 XCAP May 2007
</xs:element>
</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="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="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>
Rosenberg Standards Track [Page 52] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 52] RFC 4825 XCAP May 2007
<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="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="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>
<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>
12. XCAP Server Capabilities
12. XCAP Server Capabilities
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
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
Rosenberg Standards Track [Page 53] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 53] RFC 4825 XCAP May 2007
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.
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.
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.
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.
The following sections provide the information needed to define this application usage.
The following sections provide the information needed to define this application usage.
12.1. Application Unique ID (AUID)
12.1. Application Unique ID (AUID)
This specification defines the "xcap-caps" AUID within the IETF tree, via the IANA registration in Section 15.
This specification defines the "xcap-caps" AUID within the IETF tree, via the IANA registration in Section 15.
12.2. XML Schema
12.2. XML Schema
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-caps"
xmlns="urn:ietf:params:xml:ns:xcap-caps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="xcap-caps">
<xs:annotation>
<xs:documentation>Root element for xcap-caps</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="auids">
<xs:annotation>
<xs:documentation>List of supported AUID.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="auid" type="auidType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extensions" minOccurs="0">
<?xml version="1.0" 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">
Rosenberg Standards Track [Page 54] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 54] RFC 4825 XCAP May 2007
<xs:annotation>
<xs:documentation>List of supported extensions.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="extension" type="extensionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="namespaces">
<xs:annotation>
<xs:documentation>List of supported namespaces.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="namespace" type="namespaceType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="auidType">
<xs:annotation>
<xs:documentation>AUID Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="extensionType">
<xs:annotation>
<xs:documentation>Extension Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="namespaceType">
<xs:annotation>
<xs:documentation>Namespace type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema>
<xs: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>
Rosenberg Standards Track [Page 55] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 55] RFC 4825 XCAP May 2007
12.3. Default Document Namespace
12.3. Default Document Namespace
The default document namespace used in evaluating a URI is urn:ietf:params:xml:ns:xcap-caps.
The default document namespace used in evaluating a URI is urn:ietf:params:xml:ns:xcap-caps.
12.4. MIME Type
12.4. MIME Type
Documents conformant to this schema are known by the MIME type "application/xcap-caps+xml", registered in Section 15.2.5.
Documents conformant to this schema are known by the MIME type "application/xcap-caps+xml", registered in Section 15.2.5.
12.5. Validation Constraints
12.5. Validation Constraints
There are no additional validation constraints associated with this application usage.
There are no additional validation constraints associated with this application usage.
12.6. Data Semantics
12.6. Data Semantics
Data semantics are defined above.
Data semantics are defined above.
12.7. Naming Conventions
12.7. Naming Conventions
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.
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.
12.8. Resource Interdependencies
12.8. Resource Interdependencies
There are no resource interdependencies in this application usage beyond those defined by the schema.
There are no resource interdependencies in this application usage beyond those defined by the schema.
12.9. Authorization Policies
12.9. Authorization Policies
This application usage does not change the default authorization policy defined by XCAP.
This application usage does not change the default authorization policy defined by XCAP.
13. Examples
13. Examples
This section goes through several examples, making use of the resource-lists and rls-services [22] XCAP application usages.
This section goes through several examples, making use of the resource-lists and rls-services [22] XCAP application usages.
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:
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:
PUT /resource-lists/users/sip:bill@example.com/index HTTP/1.1 Content-Type:application/resource-lists+xml Host: xcap.example.com
PUT /resource-lists/users/sip:bill@example.com/index HTTP/1.1 Content-Type:application/resource-lists+xml Host: xcap.example.com
Rosenberg Standards Track [Page 56] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 56] RFC 4825 XCAP May 2007
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?> <resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"> <list name="friends"> </list> </resource-lists>
Figure 24: New Document
Figure 24: New Document
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):
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):
PUT /rls-services/users/sip:bill@example.com/index HTTP/1.1 Content-Type:application/rls-services+xml Host: xcap.example.com
PUT /rls-services/users/sip:bill@example.com/index HTTP/1.1 Content-Type: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>
<?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
Figure 25: RLS Services Example
Next, Bill creates an element in the resource-lists document (Section 7.4). In particular, he adds an entry to the list:
Next, Bill creates an element in the resource-lists document (Section 7.4). In particular, he adds an entry to the list:
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
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>
<entry uri="sip:bob@example.com"> <display-name>Bob Jones</display-name> </entry>
Figure 26: Resource Lists Document
Figure 26: Resource Lists Document
Rosenberg Standards Track [Page 57] RFC 4825 XCAP May 2007
Rosenberg Standards Track [Page 57] RFC 4825 XCAP May 2007
Next, Bill fetches the document (Section 7.3):
Next, Bill fetches the document (Section 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
Figure 27: Fetch Operation
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はEtagを承認します: "wwhha"コンテントタイプ: アプリケーション/リソースリスト+xml
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry></list>
</resource-lists>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><リソースリストxmlnsが「つぼ:ietf:params: xml:ナノ秒:リソースリスト「><リスト名=」友人「><エントリーuri=」一口: bob@example.com 」と等しい、gt;、<ディスプレイ名の>ボブのジョーンズディスプレイ</名の></エントリー></リスト></リソースリスト>。
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
PUT/リソースリスト/ユーザ/一口: bill@example.com/index/~~/ リソースリスト/リスト%5b@name=の%の22friends%の22%の5d/ list%5b@name は%22close-friends%22%5d HTTP/1.1コンテントタイプと等しいです: アプリケーション/xcap-高架鉄道+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>
<リスト名=の「親友「><エントリーuri=」一口: joe@example.com 」、gt;、<ディスプレイ名の>ジョー・スミスディスプレイ</名の></エントリー><エントリーuriが「一口: nancy@example.com 」と等しい、gt;、<ディスプレイ名の>ナンシーGrossディスプレイ</名の></エントリー><エントリーuriが「一口: petri@example.com 」と等しい、gt;、<ディスプレイ名の>ペトリAukiaディスプレイ</名の></エントリー></リスト>。
Figure 29: Adding an Entry
図29: エントリーを加えます。
Rosenberg Standards Track [Page 58] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[58ページ]。
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
/resource-lists/users/sip: bill@example.com/index/ ~~/resource-lists/list/list/ entry%5b@uri =%22sipを削除してください: petri@example.com%22%5d HTTP/1.1は以下を接待します。 xcap.example.com
Figure 30: Deleting an Entry
図30: エントリーを削除します。
Bill decides to check on the URI for Nancy, so he fetches a particular attribute (Section 7.6):
ビルが、ナンシーのためにURIについて検査すると決めるので、彼は特定の属性(セクション7.6)をとって来ます:
GET /resource-lists/users/sip:bill@example.com/index/ ~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1 Host: xcap.example.com
HTTP/1.1が接待する/resource-lists/users/sip: bill@example.com/index/ ~~/resource-lists/list/list/entry%5b2%5d/@uriを手に入れてください: 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はEtagを承認します: 「ad88"コンテントタイプ: アプリケーション/xcap-att+xml」
"sip:nancy@example.com"
「一口: nancy@example.com 」
Figure 32: Results of Fetch
図32: フェッチの結果
14. Security Considerations
14. セキュリティ問題
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を与えるのは、RECOMMENDEDです。 これはクライアントとサーバとのTLS-暗号化通信をもたらして、どんな盗聴も防ぐでしょう。 クライアントがそのようなURIが使用可能になることを保証して、クライアントはTLSを実装しなければなりません。
Client and server authentication are also important. A client needs to be sure it is talking to the server it believes it is contacting. Otherwise, it may be given false information, which can lead to denial-of-service attacks against a client. To prevent this, a client SHOULD attempt to upgrade [15] any connections to TLS. Similarly, authorization of read and write operations against the data is important, and this requires client authentication. As a
また、クライアントとサーバ証明も重要です。 クライアントは、それが連絡であるとそれに信じているサーバと話しているのを確信している必要があります。 さもなければ、偽情報をそれに与えるかもしれません。(それは、クライアントに対するサービス不能攻撃につながることができます)。 これを防ぐために、クライアントSHOULDは、[15] どんな接続もTLSにアップグレードさせるのを試みます。 読んでください、そして、書いてください。同様である、承認、データに対する操作は重要であり、これはクライアント認証を必要とします。 aとして
Rosenberg Standards Track [Page 59] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[59ページ]。
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.
結果、サーバSHOULDは、アイデンティティ、およびこのSHOULDを確立するようにHTTP Digest[11]を使用しているクライアントに挑みます。TLS接続の上に終わっています。 クライアントに挑戦するサーバがある相互運用性を保証して、クライアントはダイジェスト認証を実装しなければなりません。 サーバはTLS接続なしでクライアントに基本認証を実行してはいけません。
Because XCAP is a usage of HTTP and not a separate protocol, it runs on the same port numbers as HTTP traffic normally does. This makes it difficult to apply port-based filtering rules in firewalls to separate the treatment of XCAP traffic from other HTTP traffic.
XCAPが別々のプロトコルではなく、HTTPの用法であるので、それは通常、HTTPトラフィックとしての数が走る同じポートで走ります。 これで、他のHTTPトラフィックとXCAPトラフィックの処理を切り離すためにファイアウォールでポートベースのフィルタリング規則を適用するのは難しくなります。
However, this problem exists broadly today because HTTP is used to access a wide breadth of content, all on the same port, and XCAP views application configuration documents as just another type of HTTP content. As such, separate treatment of XCAP traffic from other HTTP traffic requires firewalls to examine the URL itself. There is no foolproof way to identify a URL as pointing to an XCAP resource. However, the presence of the double tilde (~~) is a strong hint that the URL points to an XML element or attribute. As always, care must be taken in looking for the double-tilde due to the breadth of ways in which a URI can be encoded on-the-wire [29] [13].
しかしながら、HTTPが同じポートの上で内容の広い幅にアクセスするのにおいて使用されているので、この問題は今日広く存在します、そして、XCAPはただのタイプのHTTP内容であるとアプリケーション構成ドキュメントをみなします。 そういうものとして、他のHTTPトラフィックからのXCAPトラフィックの別々の処理は、URL自体を調べるためにファイアウォールを必要とします。 XCAPリソースを示すとしてURLを特定する絶対に安全な方法が全くありません。 しかしながら、二重ティルド(~~)の存在はURLがXML要素か属性を示すという強いヒントです。 いつものように、ワイヤのURIをコード化できる方法の幅による二重ティルドの[29][13]を探しながら、注意を中に入れなければなりません。
15. IANA Considerations
15. IANA問題
There are several IANA considerations associated with this specification.
この仕様に関連しているいくつかのIANA問題があります。
15.1. XCAP Application Unique IDs
15.1. XCAPのアプリケーションのユニークなID
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の参照です。
Rosenberg Standards Track [Page 60] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[60ページ]。
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
アプリケーションユニークなID(AUID)記述参照-------------------- ------------------------------- --------- XCAPサーバのxcap-上限Capabilities RFC4825
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.
彼らが標準化過程RFCsで発行されるとき、XCAP AUIDsはIANAによって登録されます。 RFCのIANA Considerations部は以下の情報を含めなければなりません。(それは、公表のRFC番号に伴うIANA登録に現れます)。
o Name of the AUID. The name MAY be of any length, but SHOULD be no
more than 20 characters long. The name MUST consist of alphanum
and mark [16] characters only.
o AUIDという名前。 名前がどんな長さのそうですがも、SHOULDは20のキャラクタが切望するほどそうではありません。 名前はalphanumとマーク[16]キャラクタだけから成らなければなりません。
o Descriptive text that describes the application usage.
o アプリケーション用法を説明する説明文。
15.2. MIME Types
15.2. MIMEの種類
This specification requests the registration of several new MIME types according to the procedures of RFC 4288 [8] and guidelines in RFC 3023 [9].
RFC4288[8]とガイドラインの手順によると、この仕様はRFC3023[9]でいくつかの新しいMIMEの種類の登録を要求します。
15.2.1. application/xcap-el+xml MIME Type
15.2.1. アプリケーション/xcap-高架鉄道+xml MIMEの種類
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: xcap-el+xml
MIME「副-タイプ」は以下を命名します。 xcap-高架鉄道+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
任意のパラメタ: RFC3023[9]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
問題をコード化します: RFC3023[9]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ問題: RFC3023[9]のセクション10を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4825
広められた仕様: RFC4825
Rosenberg Standards Track [Page 61] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[61ページ]。
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).
このメディアタイプを使用するアプリケーション: このドキュメントタイプは、RFC4825(XML Configuration Accessプロトコル(XCAP))のXML断片ボディーの輸送をサポートするのに使用されました。
Additional Information:
追加情報:
Magic Number: none
マジックナンバー: なし
File Extension: .xel
ファイル拡張子: .xel
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
15.2.2. application/xcap-att+xml MIME Type
15.2.2. アプリケーション/xcap-att+xml MIMEの種類
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].
任意のパラメタ: RFC3023[9]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
問題をコード化します: RFC3023[9]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ問題: RFC3023[9]のセクション10を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4825
広められた仕様: RFC4825
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).
このメディアタイプを使用するアプリケーション: このドキュメントタイプは、RFC4825(XML Configuration Accessプロトコル(XCAP))のXML属性値の輸送をサポートするのに使用されました。
Additional Information:
追加情報:
Magic Number: none
マジックナンバー: なし
File Extension: .xav
ファイル拡張子: .xav
Rosenberg Standards Track [Page 62] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[62ページ]。
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
15.2.3. application/xcap-ns+xml MIME Type
15.2.3. アプリケーション/xcapナノ秒+xml MIMEの種類
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: xcap-ns+xml
MIME「副-タイプ」は以下を命名します。 xcapナノ秒+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
任意のパラメタ: RFC3023[9]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
問題をコード化します: RFC3023[9]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ問題: RFC3023[9]のセクション10を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4825
広められた仕様: RFC4825
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).
このメディアタイプを使用するアプリケーション: このドキュメントタイプは、RFC4825(XML Configuration Accessプロトコル(XCAP))のXML断片ボディーの輸送をサポートするのに使用されました。
Additional Information:
追加情報:
Magic Number: none
マジックナンバー: なし
File Extension: .xns
ファイル拡張子: .xns
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
Rosenberg Standards Track [Page 63] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[63ページ]。
15.2.4. application/xcap-error+xml MIME Type
15.2.4. アプリケーション/xcap-誤り+xml MIMEの種類
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: xcap-error+xml
MIME「副-タイプ」は以下を命名します。 xcap-誤り+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
任意のパラメタ: RFC3023[9]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
問題をコード化します: RFC3023[9]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ問題: RFC3023[9]のセクション10を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4825
広められた仕様: RFC4825
Applications that use this media type: This document type conveys
error conditions defined in RFC 4825
このメディアタイプを使用するアプリケーション: このドキュメントタイプはRFC4825で定義されたエラー条件を伝えます。
Additional Information:
追加情報:
Magic Number: none
マジックナンバー: なし
File Extension: .xer
ファイル拡張子: .xer
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
15.2.5. application/xcap-caps+xml MIME Type
15.2.5. アプリケーション/xcap-上限+xml MIMEの種類
MIME media type name: application
MIMEメディア型名: アプリケーション
MIME subtype name: xcap-caps+xml
MIME「副-タイプ」は以下を命名します。 xcap-上限+xml
Mandatory parameters: none
義務的なパラメタ: なし
Optional parameters: Same as charset parameter application/xml as
specified in RFC 3023 [9].
任意のパラメタ: RFC3023[9]の指定されるとしてのcharsetパラメタアプリケーション/xmlと同じです。
Rosenberg Standards Track [Page 64] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[64ページ]。
Encoding considerations: Same as encoding considerations of
application/xml as specified in RFC 3023 [9].
問題をコード化します: RFC3023[9]の指定されるとしてのアプリケーション/xmlの問題をコード化するのと同じです。
Security considerations: See Section 10 of RFC 3023 [9].
セキュリティ問題: RFC3023[9]のセクション10を見てください。
Interoperability considerations: none
相互運用性問題: なし
Published specification: RFC 4825
広められた仕様: RFC4825
Applications that use this media type: This document type conveys
capabilities of an XML Configuration Access Protocol (XCAP)
server, as defined in RFC 4825.
このメディアタイプを使用するアプリケーション: このドキュメントタイプはRFC4825で定義されるようにXML Configuration Accessプロトコル(XCAP)サーバの能力を伝えます。
Additional Information:
追加情報:
Magic Number: none
マジックナンバー: なし
File Extension: .xca
ファイル拡張子: .xca
Macintosh file type code: "TEXT"
マッキントッシュファイルの種類コード: 「テキスト」
Personal and email address for further information:
Jonathan Rosenberg, jdrosen@jdrosen.net
詳細のためのパーソナルとEメールアドレス: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法: 一般的
Author/Change controller: The IETF.
コントローラを書くか、または変えてください: IETF。
15.3. URN Sub-Namespace Registrations
15.3. つぼのサブ名前空間登録証明書
This specification registers several new XML namespaces, as per the guidelines in RFC 3688 [17].
この仕様はRFC3688[17]のガイドラインに従っていくつかの新しいXML名前空間を登録します。
15.3.1. urn:ietf:params:xml:ns:xcap-error
15.3.1. つぼ:ietf:params:xml:ナノ秒: xcap誤り
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error
URI: この名前空間のためのURI、つぼ:ietf:params:xml:ナノ秒: xcap誤りです。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
記入者接触: IETF、SIMPLEワーキンググループ、( simple@ietf.org )、ジョナサン・ローゼンバーグ( jdrosen@jdrosen.net )。
Rosenberg Standards Track [Page 65] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[65ページ]。
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Error Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Error Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
XML: BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、XCAP誤りのための/><タイトル>XCAP誤り名前空間</タイトル></ヘッド><ボディー><h1>名前空間は</h1><h2>つぼを記録します:、」; ietf:params:xml:ナノ秒:xcap-誤り</h2><p>See<a hrefが等しい、「 http://www.rfc-editor.org/rfc/rfc4825.txt 「>RFC4825</a></p></ボディー></html>END」
15.3.2. urn:ietf:params:xml:ns:xcap-caps
15.3.2. つぼ:ietf:params:xml:ナノ秒: xcap上限
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps
URI: この名前空間のためのURI、つぼ:ietf:params:xml:ナノ秒: xcap上限です。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
記入者接触: IETF、SIMPLEワーキンググループ、( simple@ietf.org )、ジョナサン・ローゼンバーグ( jdrosen@jdrosen.net )。
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Capabilities Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Capability Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-caps</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
XML: BEGIN<?xmlバージョン= 「1インチ?」><!DOCTYPE html PUBLIC「-//W3C//DTD XHTML基礎1.0//アン」、「 http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd 、「><html xmlnsが「 http://www.w3.org/1999/xhtml 「><ヘッド><メタhttp-equiv=」content type」内容=と等しい、「テキスト/html;、charset=iso8859、1インチ、XCAP能力のための/><タイトル>XCAP能力名前空間</タイトル></ヘッド><ボディー><h1>名前空間は</h1><h2>つぼを記録します:、」; ietf:params:xml: ナノ秒: xcap上限の</h2><p>See<a hrefが等しい、「 http://www.rfc-editor.org/rfc/rfc4825.txt 「>RFC4825</a></p></ボディー></html>END」
Rosenberg Standards Track [Page 66] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[66ページ]。
15.4. XML Schema Registrations
15.4. XML図式登録証明書
This section registers two XML schemas per the procedures in [17].
このセクションは[17]に1手順あたり2XML schemasを登録します。
15.4.1. XCAP Error Schema Registration
15.4.1. XCAP誤り図式登録
URI: urn:ietf:params:xml:schema:xcap-error
URI: つぼ:ietf:params:xml:図式: xcap誤り
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
記入者接触: IETF、SIMPLEワーキンググループ、( simple@ietf.org )、ジョナサン・ローゼンバーグ( jdrosen@jdrosen.net )。
XML Schema: The XML for this schema can be found as the sole content
of Section 11.2.
XML図式: セクション11.2の唯一の内容としてこの図式のためのXMLを見つけることができます。
15.4.2. XCAP Capabilities Schema Registration
15.4.2. XCAP能力図式登録
URI: urn:ietf:params:xml:schema:xcap-caps
URI: つぼ:ietf:params:xml:図式: xcap上限
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org),
Jonathan Rosenberg (jdrosen@jdrosen.net).
記入者接触: IETF、SIMPLEワーキンググループ、( simple@ietf.org )、ジョナサン・ローゼンバーグ( jdrosen@jdrosen.net )。
XML Schema: The XML for this schema can be found as the sole content
of Section 12.2.
XML図式: セクション12.2の唯一の内容としてこの図式のためのXMLを見つけることができます。
16. Acknowledgements
16. 承認
The author would like to thank Jari Urpalainen, who has contributed many important comments and has assisted with edit passes in the document. The author would also like to thank Ben Campbell, Eva-Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern, Lisa Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian Schmidt, and Spencer Dawkins for their input and comments. A special thanks to Ted Hardie for his input and support.
作者はヤリUrpalainenに感謝したがっています。(Urpalainenは多くの重要なコメントを寄付して、ドキュメントで編集パスを助けました)。 また、作者は彼らの入力とコメントについてベン・キャンベル、エバ-マリアLeppanen、Hisham Khartabil、クリス・ニューマン、ジョエル・アルペルン、リサDusseault、ティムBray、ピートコーデル、ジョロエンバンBemmel、クリスチャンのシュミット、およびスペンサー・ダウキンズに感謝したがっています。 彼の入力とサポートのためのテッド・ハーディーのおかげで特別番組。
17. References
17. 参照
17.1. Normative References
17.1. 引用規格
[1] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-
McQueen, "Extensible Markup Language (XML) 1.0 (Third
Edition)", World Wide Web Consortium FirstEdition REC-xml-
20040204, February 2004,
<http://www.w3.org/TR/2004/REC-xml-20040204>.
[1] Maler、E.、Yergeau、F.、パオリ、J.はT.、およびC.Sperbergマックィーン、「拡張マークアップ言語(XML)1.0(第3版)」をいななかせます、ワールドワイドウェブコンソーシアムFirstEdition REC-xml20040204、2004年2月、<http://www.w3.org/TR/2004/REC-xml-20040204>。
Rosenberg Standards Track [Page 67] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[67ページ]。
[2] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML
Schema Part 1: Structures Second Edition", World Wide Web
Consortium Recommendation REC-xmlschema-1-20041028,
October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[2] トンプソン、H.、マローニー、M.、メンデルゾーン、N.、およびD.ぶな、「XML図式第1部:」 「構造第2版」、ワールドワイドウェブコンソーシアム推薦REC-xmlschema-1-20041028、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028 2004年10月の>。
[3] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML",
World Wide Web Consortium FirstEdition REC-xml-names-19990114,
January 1999,
<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] 俗人とA.とオランダ人、D.とT.ロバの鳴き声、「XMLの名前空間」ワールドワイドウェブコンソーシアムFirstEdition REC-xml名19990114、1999年1月、<http://www.w3.org/TR/1999/REC-xml名前-19990114>。
[4] Daniel, R., DeRose, S., Maler, E., and J. Marsh, "XPointer
xmlns() Scheme", World Wide Web Consortium Recommendation REC-
xptr-xmlns-20030325, March 2003,
<http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325>.
[4] ダニエルとR.とDeRoseとS.とMaler、E.とJ.Marsh、「XPointer xmlns()は計画する」ワールドワイドウェブコンソーシアムRecommendation REC- xptr-xmlns-20030325(<http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325 2003年3月の>)。
[5] Grosso, P., Marsh, J., Maler, E., and N. Walsh, "XPointer
Framework", World Wide Web Consortium Recommendation REC-xptr-
framework-20030325, March 2003,
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325>.
[5] グロッソとP.とMarshとJ.とMaler、E.とN.ウォルシュ、「XPointerフレームワーク」、ワールドワイドウェブコンソーシアムRecommendation REC-xptrフレームワーク-20030325、2003年3月(<http://www.w3.org/TR/2003/REC-xptrフレームワーク-20030325>)。
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[6] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
解放された[8]とN.とJ.Klensin、「メディアは仕様と登録手順をタイプする」BCP13、RFC4288、2005年12月。
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[9] ムラタとM.と聖ローラン、S.とD.コーン、「XMLメディアタイプ」、RFC3023、2001年1月。
[10] Clark, J. and S. DeRose, "XML Path Language (XPath) Version
1.0", World Wide Web Consortium Recommendation REC-xpath-
19991116, November 1999,
<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[10] クラークとJ.とS.DeRose、「XML経路言語(XPath)バージョン1インチ、ワールドワイドウェブコンソーシアム推薦REC-xpath19991116、<http://www.w3.org/TR/1999/REC-xpath-19991116 1999年11月の>。」
[11] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[11] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
[12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[12] エドクロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
Rosenberg Standards Track [Page 68] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[68ページ]。
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986,
January 2005.
[13]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、STD66、RFC3986、2005年1月。
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[14] レスコラ(E.、「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
[15] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1",
RFC 2817, May 2000.
「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[15]Khare、R.、およびS.ローレンス。
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[16] ローゼンバーグ、J.、Schulzrinne、H.、キャマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
[17] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[17] 食事、M.、「IETF XML登録」、BCP81、RFC3688、2004年1月。
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646",
STD 63, RFC 3629, November 2003.
[18]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[19] Boyer, J., "Canonical XML Version 1.0", World Wide Web
Consortium Recommendation REC-xml-c14n-20010315, March 2001,
<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[19] ボワイエ、J.、「1インチ、正準なXMLバージョンワールドワイドウェブコンソーシアム推薦REC-xml-c14n-20010315、2001年<http://www.w3.org/TR/2001年3月/REC-xml-c14n-20010315>。」
17.2. Informative References
17.2. 有益な参照
[20] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[20] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年8月。
[21] Roach, A., Campbell, B., and J. Rosenberg, "A Session
Initiation Protocol (SIP) Event Notification Extension for
Resource Lists", RFC 4662, August 2006.
[21] ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、「リソースのためのセッション開始プロトコル(一口)イベント通知拡張子は記載します」、RFC4662、2006年8月。
[22] Rosenberg, J., "Extensible Markup Language (XML) Formats for
Representing Resource Lists", RFC 4826, May 2007.
[22] ローゼンバーグ、J.、「リソースリストを表すための拡張マークアップ言語(XML)形式」(RFC4826)は2007がそうするかもしれません。
[23] Grosso, P. and D. Veillard, "XML Fragment Interchange", World
Wide Web Consortium CR CR-xml-fragment-20010212, February 2001,
<http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[23]のグロッソとP.と2001年2月に<http://www.w3.org/TR/2001/CR-xml20010212を断片化しているD.Veillard、「XML断片置き換え」、ワールドワイドウェブコンソーシアムCR 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.とチェンバリンとD.とフェルナンデスとM.とケイとM.とロービー、J.とJ.シミオン、「XML経路言語(XPath)2インチ、ワールドワイドウェブコンソーシアムCR http://www.w3.org/TR/2005/CR-xpath20-20051103 、2005年11月。」
[25] Newman, C. and J. Myers, "ACAP -- Application Configuration
Access Protocol", RFC 2244, November 1997.
[25] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
Rosenberg Standards Track [Page 69] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[69ページ]。
[26] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence
and Instant Messaging", RFC 2778, February 2000.
2000年2月の[26] 日、M.とローゼンバーグ、J.とH.菅野、「存在とインスタントメッセージングのためのモデル」RFC2778。
[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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[28] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[28] ローチ、A.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[29] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[29]DuerstとM.とM.Suignard、「国際化しているリソース識別子(虹彩)」、RFC3987、2005年1月。
Author's Address
作者のアドレス
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコのニュージャージーエディソン(米国)
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
メール: jdrosen@cisco.com ユリ: http://www.jdrosen.net
Rosenberg Standards Track [Page 70] RFC 4825 XCAP May 2007
ローゼンバーグStandardsはXCAP2007年5月にRFC4825を追跡します[70ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg Standards Track [Page 71]
ローゼンバーグ標準化過程[71ページ]
一覧
スポンサーリンク
