[要約] RFC 4826は、リソースリストを表現するためのXML形式に関する規格です。このRFCの目的は、異なるリソースリストの表現方法を統一し、相互運用性を向上させることです。
Network Working Group J. Rosenberg
Request for Comments: 4826 Cisco
Category: Standards Track May 2007
Extensible Markup Language (XML) Formats for Representing Resource Lists
リソースリストを表すための拡張可能なマークアップ言語（XML）形式
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
In multimedia communications, presence, and instant messaging systems, there is a need to define Uniform Resource Identifiers (URIs) that represent services that are associated with a group of users. One example is a resource list service. If a user sends a Session Initiation Protocol (SIP) SUBSCRIBE message to the URI representing the resource list service, the server will obtain the state of the users in the associated group, and provide it to the sender. To facilitate definition of these services, this specification defines two Extensible Markup Language (XML) documents. One document contains service URIs, along with their service definition and a reference to the associated group of users. The second document contains the user lists that are referenced from the first. This list of users can be utilized by other applications and services. Both documents can be created and managed with the XML Configuration Access Protocol (XCAP).
マルチメディア通信、存在感、およびインスタントメッセージングシステムでは、ユーザーのグループに関連付けられているサービスを表す均一なリソース識別子（URI）を定義する必要があります。一例はリソースリストサービスです。ユーザーがリソースリストサービスを表すURIにセッション開始プロトコル（SIP）をサブスクライブすると、サーバーは関連グループのユーザーの状態を取得し、送信者に提供します。これらのサービスの定義を容易にするために、この仕様では2つの拡張可能なマークアップ言語（XML）ドキュメントを定義します。1つのドキュメントには、サービスの定義と関連するユーザーグループへの参照とともに、サービスURIが含まれています。2番目のドキュメントには、最初のドキュメントから参照されるユーザーリストが含まれています。このユーザーのリストは、他のアプリケーションやサービスで利用できます。両方のドキュメントは、XML構成アクセスプロトコル（XCAP）で作成および管理できます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Resource Lists Documents . . . . . . . . . . . . . . . . . . . 4
3.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 4
3.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. Example Document . . . . . . . . . . . . . . . . . . . . . 9
3.4. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 10
3.4.1. Application Unique ID . . . . . . . . . . . . . . . . 10
3.4.2. MIME Type . . . . . . . . . . . . . . . . . . . . . . 10
3.4.3. XML Schema . . . . . . . . . . . . . . . . . . . . . . 10
3.4.4. Default Namespace . . . . . . . . . . . . . . . . . . 10
3.4.5. Additional Constraints . . . . . . . . . . . . . . . . 11
3.4.6. Data Semantics . . . . . . . . . . . . . . . . . . . . 11
3.4.7. Naming Conventions . . . . . . . . . . . . . . . . . . 11
3.4.8. Resource Interdependencies . . . . . . . . . . . . . . 12
3.4.9. Authorization Policies . . . . . . . . . . . . . . . . 12
4. RLS Services Documents . . . . . . . . . . . . . . . . . . . . 13
4.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Example Document . . . . . . . . . . . . . . . . . . . . . 15
4.4. Usage with XCAP . . . . . . . . . . . . . . . . . . . . . 16
4.4.1. Application Unique ID . . . . . . . . . . . . . . . . 16
4.4.2. MIME Type . . . . . . . . . . . . . . . . . . . . . . 16
4.4.3. XML Schema . . . . . . . . . . . . . . . . . . . . . . 16
4.4.4. Default Namespace . . . . . . . . . . . . . . . . . . 16
4.4.5. Additional Constraints . . . . . . . . . . . . . . . . 16
4.4.6. Data Semantics . . . . . . . . . . . . . . . . . . . . 17
4.4.7. Naming Conventions . . . . . . . . . . . . . . . . . . 17
4.4.8. Resource Interdependencies . . . . . . . . . . . . . . 18
4.4.9. Authorization Policies . . . . . . . . . . . . . . . . 20
4.5. Usage of an RLS Services Document by an RLS . . . . . . . 20
5. SIP URI Canonicalization . . . . . . . . . . . . . . . . . . . 22
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 23
7. Security Considerations . . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 24
8.1.1. resource-lists . . . . . . . . . . . . . . . . . . . . 24
8.1.2. rls-services . . . . . . . . . . . . . . . . . . . . . 24
8.2. MIME Type Registrations . . . . . . . . . . . . . . . . . 25
8.2.1. application/resource-lists+xml . . . . . . . . . . . . 25
8.2.2. application/rls-services+xml . . . . . . . . . . . . . 26
8.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 27
8.3.1. urn:ietf:params:xml:ns:resource-lists . . . . . . . . 27
8.3.2. urn:ietf:params:xml:ns:rls-services . . . . . . . . . 28
8.4. Schema Registrations . . . . . . . . . . . . . . . . . . . 28
8.4.1. urn:ietf:params:xml:schema:resource-lists . . . . . . 28
8.4.2. urn:ietf:params:xml:schema:rls-services . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.1. Normative References . . . . . . . . . . . . . . . . . . . 29
10.2. Informative References . . . . . . . . . . . . . . . . . . 30
The Session Initiation Protocol (SIP) [4] defines the SIP Uniform Resource Identifier (URI) as any resource to which a SIP request can be generated for the purposes of establishing some form of communications operation. These URIs can represent users (for example, sip:joe@example.com). The SIP URI can also represent a service, such as voicemail, conferencing, or a presence list. A common pattern across such SIP services is that the service is defined, and associated with a URI. In order to operate, that service needs to make use of a list of users (or, more generally, a list of resources). When a SIP request is sent to the service URI, the server providing the service reads that list, and then performs some kind of operation against each resource on the list. This is shown in Figure 1.
セッション開始プロトコル（SIP）[4]は、SIPユニフォームリソース識別子（URI）を、何らかの形の通信操作を確立するためにSIP要求を生成できるリソースとして定義します。これらのURIはユーザーを表すことができます（たとえば、sip：joe@example.com）。SIP URIは、ボイスメール、会議、プレゼンスリストなどのサービスを表すこともできます。このようなSIPサービス全体の一般的なパターンは、サービスが定義され、URIに関連付けられていることです。操作するには、そのサービスはユーザーのリスト（より一般的にはリソースのリスト）を使用する必要があります。SIPリクエストがサービスURIに送信されると、サービスを提供するサーバーがそのリストを読み取り、リスト上の各リソースに対して何らかの操作を実行します。これを図1に示します。
/---\
| |
\---/ Resource
+----| | List
| | |
| \---/
|
|
|
|
V
+-------------+
| | -------->
| SIP |
---------------> | Service | -------->
service | |
URI | | -------->
+-------------+
Figure 1
図1
One important example of such a service is a presence [11] list service. A presence list service allows a client to generate a SIP SUBSCRIBE request to ask for presence information for a list of users. The presence list server obtains the presence for the users on the list and provides them back to the client. A presence list server is a specific case of a resource list server (RLS) [14], which allows a client to generate a SIP SUBSCRIBE request to ask for notifications of SIP events for a list of resources.
このようなサービスの重要な例の1つは、存在感[11]リストサービスです。プレゼンスリストサービスにより、クライアントはSIPサブスクライブリクエストを生成して、ユーザーのリストのプレゼンス情報を要求できます。プレゼンスリストサーバーは、リスト上のユーザーの存在感を取得し、クライアントに戻します。プレゼンスリストサーバーは、リソースリストサーバー（RLS）[14]の特定のケースです。これにより、クライアントはSIPサブスクライブリクエストを生成して、リソースのリストのSIPイベントの通知を要求できます。
Another example of such a service is an instant conference service. If a client sends a SIP INVITE request to the URI representing the instance conference service, the conference server will create a conference call containing the client and the associated group of users.
このようなサービスのもう1つの例は、インスタントカンファレンスサービスです。クライアントがインスタンスカンファレンスサービスを表すURIにSIP招待リクエストを送信した場合、会議サーバーは、クライアントと関連するユーザーグループを含む電話会議を作成します。
It is very useful for a user of these systems to define the groups of users or resources (generally called a resource list) separately from the services that access those resource lists. Indeed, there are usages for resource lists even in the absence of any associated network-based service. As an example, rather than use a presence list service, a client might generate individual SUBSCRIBE requests to obtain the presence of each user in a locally stored presence list. In such a case, there is a need for a format for storing the list locally on disk. Furthermore, the user might wish to share the list with friends, and desire to email it to those friends. This also requires a standardized format for the resource list.
これらのシステムのユーザーがユーザーまたはリソースのグループ（一般的にリソースリストと呼ばれる）を、それらのリソースリストにアクセスするサービスとは別に定義することは非常に便利です。実際、関連するネットワークベースのサービスがない場合でも、リソースリストの使用法があります。例として、プレゼンスリストサービスを使用するのではなく、クライアントは個々のサブスクライブリクエストを生成して、ローカルに保存されたプレゼンスリストで各ユーザーの存在を取得する場合があります。そのような場合、ディスクにリストをローカルに保存するための形式が必要です。さらに、ユーザーはリストを友人と共有したいと思うかもしれません。これには、リソースリストの標準化された形式も必要です。
As such, this document defines two Extensible Markup Language (XML) document formats. The first is used to represent resource lists, independent of any particular service. The second is used to define service URIs for an RLS, and to associate a resource list with the service URI. This document also defines an XML Configuration Access Protocol (XCAP) [10] application usage for managing each of these two documents.
そのため、このドキュメントでは、2つの拡張可能なマークアップ言語（XML）ドキュメント形式を定義します。1つ目は、特定のサービスとは無関係に、リソースリストを表すために使用されます。2つ目は、RLSのサービスURIを定義し、リソースリストをサービスURIに関連付けるために使用されます。このドキュメントでは、これら2つのドキュメントのそれぞれを管理するためのXML構成アクセスプロトコル（XCAP）[10]アプリケーションの使用も定義します。
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 [1] and indicate requirement levels for compliant implementations.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "RFC 2119 [1]に記載されているように解釈され、準拠した実装の要件レベルを示します。
A resource lists document is an XML [2] document that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. Resource lists documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying resource lists documents and document fragments. The namespace URI for elements defined by this specification is a URN [3] that uses the namespace identifier 'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This URN is:
リソースリストドキュメントは、XML [2]ドキュメントであり、適切に形成されている必要があり、拡張スキーマを含むスキーマに従って有効である必要があります。リソースリストドキュメントはXML 1.0に基づいている必要があり、UTF-8を使用してエンコードする必要があります。この仕様では、リソースリストを識別するためのXML名空間を使用して、ドキュメントを文書化します。この仕様で定義された要素の名前空間URIは、RFC 2648 [6]で定義され、RFC 3688 [8]によって拡張された名前空間識別子「IETF」を使用するURN [3]です。このurnは次のとおりです。
urn:ietf:params:xml:ns:resource-lists
A resource lists document has the <resource-lists> element as the root element of the document. This element has no attributes. Its content is a sequence of zero or more <list> elements, each of which defines a single resource list.
リソースリストドキュメントには、ドキュメントのルート要素として<リソースリスト>要素があります。この要素には属性がありません。そのコンテンツは、ゼロ以上の<list>要素のシーケンスであり、それぞれが単一のリソースリストを定義します。
Each <list> element can contain an optional "name" attribute. This attribute is a handle for the list. When present, it MUST be unique amongst all other <list> elements within the same parent element. The <list> element may also contain attributes from other namespaces, for the purposes of extensibility.
各<リスト>要素には、オプションの「名前」属性を含めることができます。この属性は、リストのハンドルです。存在する場合、同じ親要素内の他のすべての<リスト>要素の中で一意でなければなりません。<list>要素には、拡張性の目的で、他の名前空間からの属性も含まれる場合があります。
Each <list> element is composed of an optional display name, a sequence of zero or more elements, each of which may be an <entry> element, a <list> element, an <entry-ref> element, or an <external> element, followed by any number of elements from other namespaces, for the purposes of extensibility. The ability of a <list> element to contain other <list> elements means that a resource list can be hierarchically structured. The <display-name> then allows for a human-friendly name to be associated with each level in the hierarchy. An <entry> element describes a single resource, defined by a URI, that is part of the list. An <entry-ref> element allows an entry in a document within the same XCAP root to be included by reference, rather than by value. An <external> element contains a reference to a list stored on this or another server.
各<リスト>要素は、オプションのディスプレイ名、ゼロ以上の要素のシーケンスで構成されています。それぞれが<Entry>要素、<リスト>要素、<Entry-Ref>要素、または<外部である場合があります。>要素に続いて、拡張性の目的のために、他の名前空間からの任意の数の要素が続きます。<リスト>要素が他の<list>要素を含める能力は、リソースリストを階層的に構成できることを意味します。<display-name>では、人間に優しい名前を階層内の各レベルに関連付けることができます。<エントリ>要素は、リストの一部であるURIによって定義された単一のリソースを説明しています。<Entre-Ref>要素により、同じXCAPルート内のドキュメント内のエントリを値ではなく、参照に含めることができます。<外部>要素には、このサーバーまたは別のサーバーに保存されているリストへの参照が含まれています。
The <entry> element describes a single resource. The <entry> element has a single mandatory attribute, "uri". This attribute is equal to the URI that is used to access the resource. The resource list format itself does not constrain the type of URI that can be used. However, the service making use of the resource list may require specific URI schemes. For example, RLS services will require URIs that represent subscribeable resources. This includes the SIP and pres [15] URIs. The "uri" attribute MUST be unique amongst all other "uri" attributes in <entry> elements within the same parent. Uniqueness is determined by case-sensitive string comparisons. As such, it is possible that two "uri" attributes will have the same URI when compared using the functional equality rules defined for that URI scheme, but different ones when compared using case sensitive string comparison. The <entry> element can also contain attributes from other namespaces for the purposes of extensibility.
<エントリ>要素は、単一のリソースを記述します。<エントリ>要素には、単一の必須属性「URI」があります。この属性は、リソースへのアクセスに使用されるURIに等しくなります。リソースリスト形式自体は、使用できるURIのタイプを制約しません。ただし、リソースリストを使用するサービスには、特定のURIスキームが必要になる場合があります。たとえば、RLSサービスには、購読可能なリソースを表すURIが必要です。これには、SIPとPres [15] URIが含まれます。「URI」属性は、同じ親の<Entry>要素の他のすべての「URI」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。そのため、2つの「URI」属性は、そのURIスキームで定義された機能的等式ルールを使用して比較すると同じURIを持つ可能性がありますが、ケースセンシティブストリングの比較を使用して比較すると異なるものがあります。<エントリ>要素には、拡張性の目的で他の名前空間からの属性を含めることもできます。
The <entry> element contains a sequence of elements that provide information about the entry. Only one such element is defined at this time, which is <display-name>. This element provides a UTF-8- encoded string, meant for consumption by a human user, that describes the resource. Unlike the "name" attribute of the <entry> element, the <display-name> has no uniqueness requirements. The <display-name> element can contain the "xml:lang" attribute, which provides the language of the display name. The <entry> element can contain other elements from other namespaces. This is meant to support the inclusion of other information about the entry, such as a phone number or postal address.
<エントリ>要素には、エントリに関する情報を提供する一連の要素が含まれています。この時点で定義されているそのような要素は1つだけです。これは<display-name>です。この要素は、リソースを説明する人間のユーザーによる消費用のUTF-8エンコード文字列を提供します。<Entry>要素の「名前」属性とは異なり、<display-name>には一意性要件がありません。<display-name>要素には、ディスプレイ名の言語を提供する「xml：lang」属性を含めることができます。<エントリ>要素には、他の名前空間から他の要素を含めることができます。これは、電話番号や住所など、エントリに関する他の情報を含めることをサポートすることを目的としています。
The <entry-ref> element allows an entry to be included in the list by reference, rather than by value. This element is only meaningful when the document was obtained through XCAP. In such a case, the referenced entry has to exist within the same XCAP root. The <entry> element has a single mandatory attribute, "ref". The "ref" attribute MUST be unique amongst all other "ref" attributes in <entry-ref> elements within the same parent. Uniqueness is determined by case sensitive string comparisons. The <entry-ref> element also allows attributes from other namespaces, for the purposes of extensibility. The content of an <entry-ref> element is an optional display name, followed by any number of elements from other namespaces, for the purposes of extensibility. The display name is useful for providing a localized nickname as an alternative to the name defined in the <entry> to which the <entry-ref> refers.
<Entre-Ref>要素を使用すると、値ではなく、参照によってエントリをリストに含めることができます。この要素は、ドキュメントがXCAPを介して取得された場合にのみ意味があります。そのような場合、参照されるエントリは同じXCAPルート内に存在する必要があります。<Entry>要素には、単一の必須属性「REF」があります。「ref」属性は、同じ親の<intry-ref>要素の他のすべての「ref」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。<Entre-Ref>要素は、拡張性の目的で、他の名前空間からの属性も許可します。<Entre-Ref>要素のコンテンツは、オプションの表示名であり、その後、拡張性の目的で他の名前空間からの任意の数の要素が続きます。ディスプレイ名は、<entry-ref>が参照する<intrent>で定義されている名前の代替としてローカライズされたニックネームを提供するのに役立ちます。
The content of the "ref" attribute is a relative HTTP URI [7]. Specifically, it MUST be a relative path reference, where the base URI is equal to the XCAP root URI of the document in which the <entry-ref> appears. This relative URI, if resolved into an absolute URI according to the procedures in RFC 3986, MUST resolve to an <entry> element within a resource-lists document. For example, suppose that an <entry> element within a specific XCAP root was identified by the following HTTP URI:
「ref」属性の内容は、相対的なHTTP URIです[7]。具体的には、ベースURIが<Entre-Ref>が表示されるドキュメントのXCAPルートURIに等しい相対パス参照でなければなりません。この相対URIは、RFC 3986の手順に従って絶対URIに解決された場合、リソースリストドキュメント内の<エントリ>要素に解決する必要があります。たとえば、特定のXCAPルート内の<Entry>要素が次のHTTP URIによって識別されたとします。
http://xcap.example.com/resource-lists/users/sip:bill@example.com/
index/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d
If http://xcap.example.com is the XCAP root URI, then an <entry-ref> element pointing to this entry would have the following form:
http://xcap.example.comがXCAPルートURIである場合、このエントリを指す<Entre-Ref>要素には次の形式があります。
<entry-ref ref="resource-lists/users/sip:bill@example.com/
index/~~/resource-lists/list%5b@name=%22list1%22%5d/
entry%5b@uri=%22sip:petri@example.com%22%5d"/>
Note that line folding within the HTTP URI and XML attribute above are for the purposes of readability only. Also note that, as described in RFC 3986, the relative path URI does not begin with the
上記のHTTP URIおよびXML属性内の線の折りたたみは、読みやすさのみの目的であることに注意してください。また、RFC 3986で説明されているように、相対パスはURIが始まっていないことに注意してください。
"/". Since the relative URI used within the "ref" attribute must be a relative path URI, the "/" will never be present as the first character within the content of a "ref" attribute. Since the content of the "ref" attribute is a valid HTTP URI, it must be percent-encoded within the XML document.
"/"。「ref」属性内で使用される相対的なURIは相対パスURIでなければならないため、「/」は「ref」属性のコンテンツ内の最初の文字として存在することはありません。「ref」属性のコンテンツは有効なHTTP URIであるため、XMLドキュメント内でパーセントエンコードする必要があります。
The <external> element is similar to the <entry-ref> element. Like <entry-ref>, it is only meaningful in documents obtained from an XCAP server. It too is a reference to content stored elsewhere. However, it refers to an entire list, and furthermore, it allows that list to be present on another server. The <external> element has a single mandatory attribute, "anchor", which specifies the external list by means of an absolute HTTP URI. The "anchor" attribute MUST be unique amongst all other "anchor" attributes in <external> elements within the same parent. Uniqueness is determined by case-sensitive string comparisons. The <external> element can also contain attributes from other namespaces, for the purposes of extensibility. The content of an <external> element is an optional <display-name> followed by any number of elements from another namespace, for the purposes of extensibility. The value of the "anchor" attribute MUST be an absolute HTTP URI. This URI MUST identify an XCAP resource, and in particular, it MUST represent a <list> element within a resource lists document. The URI MUST be percent-encoded.
<外部>要素は、<Entre-Ref>要素に似ています。<Entre-Ref>のように、XCAPサーバーから取得したドキュメントでのみ意味があります。それも他の場所に保存されているコンテンツへの参照です。ただし、リスト全体を指し、さらに、そのリストを別のサーバーに存在させることができます。<外部>要素には、単一の必須属性「アンカー」があります。これは、絶対的なHTTP URIによって外部リストを指定します。「アンカー」属性は、同じ親の<外部>要素の他のすべての「アンカー」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。<外部>要素には、拡張性の目的のために、他の名前空間からの属性も含めることができます。<Extreent>要素のコンテンツは、拡張性の目的で、オプションの<display <display>に続いて、別の名前空間からの任意の数の要素が続きます。「アンカー」属性の値は、絶対的なHTTP URIでなければなりません。このURIはXCAPリソースを識別する必要があります。特に、リソースリストドキュメント内の<リスト>要素を表す必要があります。URIはパーセントエンコードされている必要があります。
For both the <entry-ref> and <external> elements, the responsibility of resolving their references falls upon the entity that is making use of the document. When the document is used in conjunction with XCAP, this means that the burden falls on the XCAP client. If the XCAP client is a PC-based application using the resource-lists document as a presence list, the references would likely be resolved upon explicit request by the user. They can, of course, be resolved at any time. If the XCAP client is an RLS itself, the references would be resolved when the RLS receives a SUBSCRIBE request for an RLS service associated with a resource list that contains one of these references (see below). An XCAP server defined by this specification will not attempt to resolve the references before returning the document to the client. Similarly, if, due to network errors or some other problem, the references cannot be resolved, the handling is specific to the usage of the document. For resource lists being used by RLS services, the handling is discussed below.
<Entry-Ref>と<外部>要素の両方について、その参照を解決する責任は、ドキュメントを利用しているエンティティにかかっています。ドキュメントがXCAPと組み合わせて使用される場合、これはXCAPクライアントに負担がかかることを意味します。XCAPクライアントがプレゼンスリストとしてリソースリストドキュメントを使用してPCベースのアプリケーションである場合、ユーザーによる明示的な要求に応じて参照が解決される可能性があります。もちろん、彼らはいつでも解決することができます。XCAPクライアントがRLS自体である場合、RLSがこれらの参照のいずれかを含むリソースリストに関連付けられたRLSサービスの購読要求を受信すると、参照が解決されます（以下を参照）。この仕様で定義されたXCAPサーバーは、クライアントにドキュメントを返す前に参照を解決しようとしません。同様に、ネットワークエラーやその他の問題により、参照を解決できない場合、ハンドリングはドキュメントの使用に固有のものです。RLSサービスで使用されているリソースリストについては、ハンドリングについて以下で説明します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:resource-lists"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:resource-lists"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:complexType name="listType">
<xs:sequence>
<xs:element name="display-name" type="display-nameType"
minOccurs="0"/>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:choice>
<xs:element name="list">
<xs:complexType>
<xs:complexContent>
<xs:extension base="listType"/>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element name="external" type="externalType"/>
<xs:element name="entry" type="entryType"/>
<xs:element name="entry-ref" type="entry-refType"/>
</xs:choice>
</xs:sequence>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="entryType">
<xs:sequence>
<xs:element name="display-name" minOccurs="0">
<xs:complexType>
<xs:simpleContent>
<xs:extension base="display-nameType"/>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="entry-refType">
<xs:sequence>
<xs:element name="display-name" type="display-nameType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="ref" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="externalType">
<xs:sequence>
<xs:element name="display-name" type="display-nameType"
minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="anchor" type="xs:anyURI"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:element name="resource-lists">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="list" type="listType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="display-nameType">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:schema>
The following is an example of a document compliant to the schema. All line feeds within element content are for display purposes only.
以下は、スキーマに準拠したドキュメントの例です。要素コンテンツ内のすべてのラインフィードは、ディスプレイ目的のみを目的としています。
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<list name="friends">
<entry uri="sip:bill@example.com">
<display-name>Bill Doe</display-name>
</entry>
<entry-ref ref="resource-lists/users/sip:bill@example.com/index/~~/
resource-lists/list%5b@name=%22list1%22%5d/entry%5b@uri=%22sip:pet
ri@example.com%22%5d"/>
<list name="close-friends">
<display-name>Close Friends</display-name>
<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>
<external anchor="http://xcap.example.org/resource-lists/users/
sip:a@example.org/index/~~/resource-lists/list%5b@name=%22mkti
ng%22%5d">
<display-name>Marketing</display-name>
</external>
</list>
</list>
</resource-lists>
Resource lists documents can be manipulated with XCAP. This section provides the details necessary for such a usage.
リソースリストドキュメントはXCAPで操作できます。このセクションでは、そのような使用に必要な詳細を提供します。
XCAP requires application usages to define an application unique ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "resource-lists" AUID within the IETF tree, via the IANA registration in Section 8.
XCAPでは、IETFツリーまたはベンダーツリーのいずれかでアプリケーション一意のID（AUID）を定義するためのアプリケーション使用法が必要です。この仕様では、セクション8のIANA登録を介して、IETFツリー内の「リソースリスト」AUIDを定義します。
The MIME type for this document is "application/resource-lists+xml".
このドキュメントのMIMEタイプは「アプリケーション/リソースリストXML」です。
The XML Schema for this document is defined as the sole content of Section 3.2.
このドキュメントのXMLスキーマは、セクション3.2の唯一のコンテンツとして定義されます。
The default namespace used in expanding URIs is urn:ietf:params:xml:ns:resource-lists.
URIの拡張で使用されるデフォルトの名前空間はurn：ietf：params：xml：ns：resource-listsです。
In addition to the schema, there are constraints on the values present in the "name" attribute of the <list> element, the "uri" attribute of the <external> element, the "ref" attribute of the <entry-ref> element, and the "anchor" attribute of the <external> element. These constraints are defined in Section 3.1. Some of these constraints are enforced by the XCAP server. Those constraints are:
スキーマに加えて、<リスト>要素の「名前」属性に存在する値に制約があります。要素、および<外部>要素の「アンカー」属性。これらの制約は、セクション3.1で定義されています。これらの制約の一部は、XCAPサーバーによって強制されています。これらの制約は次のとおりです。
o The "name" attribute in a <list> element MUST be unique amongst all other "name" attributes of <list> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison.
o <リスト>要素の「名前」属性は、同じ親要素内の<list>要素の他のすべての「名前」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。
o The "uri" attribute in a <entry> element MUST be unique amongst all other "uri" attributes of <entry> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison.
o A <intry>要素の「uri」属性は、同じ親要素内の他のすべての「uri」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。
o The URI in the "ref" attribute of the <entry-ref> element MUST be unique amongst all other "ref" attributes of <entry-ref> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison. The value of the attribute MUST be a relative path reference. Note that the server is not responsible for verifying that the reference resolves to an <entry> element in a document within the same XCAP root.
o <Entre-Ref>要素の「ref」属性のURIは、同じ親要素内の<Entre-Ref>要素の他のすべての「REF」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。属性の値は、相対パス参照でなければなりません。サーバーは、参照が同じXCAPルート内のドキュメント内の<Entry>要素に解決されることを確認する責任がないことに注意してください。
o The URI in the "anchor" attribute of the <external> element MUST be unique amongst all other "anchor" attributes of <external> elements within the same parent element. Uniqueness is determined by case-sensitive string comparison. The value of the attribute MUST be an absolute HTTP URI. Note that the server is not responsible for verifying that the URI resolves to a <list> element in a document. Indeed, since the URI may reference a server in another domain, referential integrity cannot be guaranteed without adding substantial complexity to the system.
o <外部>要素の「アンカー」属性のURIは、同じ親要素内の<外部>要素の他のすべての「アンカー」属性の中で一意でなければなりません。一意性は、ケースに敏感な文字列比較によって決定されます。属性の値は絶対的なHTTP URIでなければなりません。サーバーは、URIがドキュメント内の<list>要素に解決することを確認する責任がないことに注意してください。実際、URIは別のドメイン内のサーバーを参照する可能性があるため、システムに実質的な複雑さを追加せずに参照整合性を保証することはできません。
Semantics for the document content are provided in Section 3.1.
ドキュメントコンテンツのセマンティクスは、セクション3.1に記載されています。
Resource lists documents are usually identified as references from other application usages. For example, an RLS services document contains a reference to the resource list it uses.
リソースリストドキュメントは通常、他のアプリケーション使用からの参照として識別されます。たとえば、RLSサービスドキュメントには、使用するリソースリストへの参照が含まれています。
Frequently, an XCAP client will wish to insert or remove an <entry>, <entry-ref>, or <external> element from a document without having a cached copy of that document. In such a case, the "uri" attribute of the <entry> element, the "ref" attribute of the <entry-ref> element, or the "anchor" attribute of the <external> element is used as an index to select the element to operate upon. The XCAP server will determine uniqueness by case-sensitive string comparison. However, each of these attributes contain URIs, and the URI equality rules for their schemes may allow two URIs to be the same, even if they are different by case sensitive string comparison. As such, it is possible that a client will attempt a PUT or DELETE in an attempt to modify or remove an existing element. Instead, the PUT ends up inserting a new element, or the DELETE ends up returning an error response.
多くの場合、XCAPクライアントは、そのドキュメントのキャッシュされたコピーを持たずに、ドキュメントから<Entry>、<intre-ref>、または<efternal>要素を挿入または削除することを希望します。このような場合、<Entry>要素の「URI」属性、<Entry-Ref>要素の「REF」属性、または<ExtrenciREN>要素の「アンカー」属性は、選択するインデックスとして使用されます動作する要素。XCAPサーバーは、ケースに敏感な文字列比較によって一意性を決定します。ただし、これらの属性にはそれぞれurisが含まれており、スキームのURI平等規則により、2つのURIが同じである可能性があります。そのため、クライアントは、既存の要素を変更または削除するために、クライアントがプットまたは削除を試みる可能性があります。代わりに、PUTは新しい要素を挿入することになります。または、削除がエラー応答を返すことになります。
If the XCAP client cannot determine whether the user intent is to create or replace, the client SHOULD canonicalize the URI before performing the operation. For a SIP URI (often present in the "uri" attribute of the <entry> element), this canonicalization procedure is defined in Section 5. We expect that the SIP URIs that will be placed into resource lists documents will usually be of the form sip:user@domain, and possibly include a user parameter. The canonicalization rules work perfectly for these URIs.
XCAPクライアントがユーザーの意図が作成または交換するかどうかを判断できない場合、クライアントは操作を実行する前にURIを正規化する必要があります。SIP URI（多くの場合、<Entry>要素の「URI」属性に存在する）の場合、この正規化手順はセクション5で定義されています。SIP：user@domain、そしておそらくユーザーパラメーターを含めることができます。標準化ルールは、これらのURIに完全に機能します。
For HTTP URIs, a basic canonicalization algorithm is as follows. If the port in the URI is equal to the default port (80 for http URIs), then the port is removed. The hostname is converted to all lowercase. Any percent-encoding in the URI for characters which do not need to be percent-encoded is removed. A character needs to be percent-encoded when it is not permitted in that part of the URI based on the grammar for that part of the URI.
HTTP URIの場合、基本的な標準化アルゴリズムは次のとおりです。URIのポートがデフォルトポート（HTTP URISの80）に等しい場合、ポートは削除されます。ホスト名はすべての小文字に変換されます。パーセントエンコードする必要のないキャラクターのURIのパーセントエンコードは削除されます。URIのその部分の文法に基づいて、URIのその部分で許可されていない場合、キャラクターはパーセントエンコードされる必要があります。
There are no resource interdependencies identified by this application usage.
このアプリケーションの使用によって特定されたリソースの相互依存関係はありません。
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write, or modify their own documents. A server can allow privileged users to modify documents that they don't own, but the establishment and indication of such policies is outside the scope of this document. It is anticipated that a future application usage will define which users are allowed to modify a list resource.
このアプリケーションの使用は、デフォルトのXCAP認証ポリシーを変更しません。つまり、ユーザーのみが独自のドキュメントを読み取り、書き込み、または変更できます。サーバーは、特権ユーザーが所有していないドキュメントを変更できるようにすることができますが、そのようなポリシーの確立と兆候はこのドキュメントの範囲外です。将来のアプリケーションの使用により、リストリソースの変更が許可されているユーザーが定義されることが予想されます。
An RLS services document is used to define URIs that represent services provided by a Resource List Server (RLS) as defined in [14]. An RLS services document is an XML [2] document that MUST be well-formed and MUST be valid according to schemas, including extension schemas, available to the validater and applicable to the XML document. RLS services documents MUST be based on XML 1.0 and MUST be encoded using UTF-8. This specification makes use of XML namespaces for identifying RLS services documents and document fragments. The namespace URI for elements defined by this specification is a URN [3] that uses the namespace identifier 'ietf' defined by RFC 2648 [6] and extended by RFC 3688 [8]. This URN is:
RLSサービスドキュメントは、[14]で定義されているように、リソースリストサーバー（RLS）が提供するサービスを表すURIを定義するために使用されます。RLSサービスドキュメントは、XML [2]ドキュメントであり、適切に形成されている必要があり、拡張スキーマを含むスキーマに従って有効である必要があります。RLSサービスドキュメントはXML 1.0に基づいている必要があり、UTF-8を使用してエンコードする必要があります。この仕様では、RLSサービスドキュメントを識別し、断片を文書化するためにXMLネームスペースを使用しています。この仕様で定義された要素の名前空間URIは、RFC 2648 [6]で定義され、RFC 3688 [8]によって拡張された名前空間識別子「IETF」を使用するURN [3]です。このurnは次のとおりです。
urn:ietf:params:xml:ns:rls-services
The root element of an rls-services document is <rls-services>. It contains a sequence of <service> elements, each of which defines a service available at an RLS.
RLSサービスドキュメントのルート要素は<RLS-Services>です。<service>要素のシーケンスが含まれており、それぞれがRLSで利用可能なサービスを定義します。
Each <service> element has a single mandatory attribute, "uri". This URI defines the resource associated with the service. That is, if a client subscribes to that URI, they will obtain the service defined by the corresponding <service> element. The <service> element can also contain attributes from other namespaces, for the purposes of extensibility. The <service> element contains child elements that define the service. For an RLS service, very little service definition is needed: just the resource list to which the server will perform virtual subscriptions [14] and the set of event packages that the service supports. The former can be conveyed in one of two ways. There can be a <resource-list> element, which points to a <list> element in a resource-lists document, or there can be a <list> element, which includes the resource list directly. The supported packages are contained in the <packages> element. The <service> element can also contain elements from other namespaces, for the purposes of extensibility.
各<Service>要素には、単一の必須属性「URI」があります。このURIは、サービスに関連付けられたリソースを定義します。つまり、クライアントがそのURIをサブスクライブする場合、対応する<Service>要素で定義されたサービスを取得します。<service>要素には、拡張性のために、他の名前空間からの属性も含めることができます。<service>要素には、サービスを定義する子要素が含まれています。RLSサービスの場合、サービスの定義はほとんど必要ありません。サーバーが仮想サブスクリプション[14]を実行するリソースリストと、サービスがサポートするイベントパッケージのセットのみです。前者は2つの方法のいずれかで伝えることができます。リソースリストドキュメントに<リスト>要素を指す<リソースリスト>要素があるか、リソースリストを直接含む<リスト>要素がある場合があります。サポートされているパッケージは、<パッケージ>要素に含まれています。<service>要素には、拡張性の目的で、他の名前空間からの要素も含めることができます。
By including the contents of the resource list directly, a user can create lists and add members to them with a single XCAP operation. However, the resulting list becomes "hidden" within the RLS service definition, and is not usable by other application usages. For this reason, the <resource-list> element exists as an alternative. It can reference a <list> element in a resource-lists document. Since the list is separated from the service definition, it can be easily reused by other application usages.
リソースリストの内容を直接含めることにより、ユーザーはリストを作成し、単一のXCAP操作でメンバーを追加できます。ただし、結果のリストはRLSサービス定義内で「非表示」になり、他のアプリケーションの使用では使用できません。このため、<リソースリスト>要素は代替として存在します。リソースリストドキュメントで<リスト>要素を参照できます。リストはサービス定義から分離されているため、他のアプリケーションの使用によって簡単に再利用できます。
The <list> element is of the list type defined by the schema for resource lists. It is discussed in Section 3.1.
<list>要素は、リソースリストのスキーマで定義されたリストタイプのものです。セクション3.1で説明します。
The <resource-list> element contains a URI. This element is only meaningful when the document was obtained through XCAP. The URI MUST be an absolute HTTP URI representing an XCAP element resource. Its XCAP root MUST be the same as the XCAP root of the RLS services document. When the RLS services document is present in a user's home directory, the HTTP URI MUST exist underneath that user's home directory in the resource-lists application usage. When the RLS services document is in the global directory, the HTTP URI MUST exist underneath any user's home directory in the resource-lists application usage. In either case, the element referenced by the URI MUST be a <list> element within a resource-lists document. All of these constraints except for the latter one (which is a referential integrity constraint) will be enforced by the XCAP server.
<リソースリスト>要素にはURIが含まれています。この要素は、ドキュメントがXCAPを介して取得された場合にのみ意味があります。URIは、XCAP要素リソースを表す絶対的なHTTP URIでなければなりません。そのXCAPルートは、RLSサービスドキュメントのXCAPルートと同じでなければなりません。RLSサービスドキュメントがユーザーのホームディレクトリに存在する場合、HTTP URIは、リソースリストアプリケーションの使用においてそのユーザーのホームディレクトリの下に存在する必要があります。RLSサービスドキュメントがグローバルディレクトリにある場合、HTTP URIは、リソースリストアプリケーションの使用のユーザーのホームディレクトリの下に存在する必要があります。どちらの場合でも、URIによって参照される要素は、リソースリストドキュメント内の<list>要素でなければなりません。後者の制約（参照整合性の制約）を除くこれらの制約はすべて、XCAPサーバーによって実施されます。
The <packages> element contains a sequence of <package> elements. The content of each <package> element is the name of a SIP event package [13]. The <packages> element may also contain elements from additional namespaces, for the purposes of extensibility. The <packages> element is optional. When it is not present, it means that the RLS service will accept subscriptions for any event package.
<パッケージ>要素には、<パッケージ>要素のシーケンスが含まれています。各<パッケージ>要素のコンテンツは、SIPイベントパッケージの名前です[13]。<パッケージ>要素には、拡張性の目的のために、追加の名前空間からの要素も含まれる場合があります。<パッケージ>要素はオプションです。存在しない場合、RLSサービスがあらゆるイベントパッケージのサブスクリプションを受け入れることを意味します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:rls-services"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="rls-services">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="service" type="serviceType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="serviceType">
<xs:sequence>
<xs:choice>
<xs:element name="resource-list" type="xs:anyURI"/>
<xs:element name="list" type="rl:listType"/>
</xs:choice>
<xs:element name="packages" type="packagesType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="uri" type="xs:anyURI" use="required"/>
<xs:anyAttribute namespace="##other" processContents="lax"/>
</xs:complexType>
<xs:complexType name="packagesType">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="package" type="packageType"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="packageType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:schema>
This document shows two services. One is sip:mybuddies@example.com, and the other is sip:marketing@example.com. The former service references a resource list in a resource-lists document, and the latter one includes a list locally. Both services are for the presence event package only.
このドキュメントは2つのサービスを示しています。1つはsipです：mybuddies@example.com、もう1つはsip：marketing@example.comです。前者のサービスは、リソースリストのドキュメントのリソースリストを参照し、後者にはローカルのリストが含まれています。両方のサービスは、プレゼンスイベントパッケージ専用です。
<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<service uri="sip:mybuddies@example.com">
<resource-list>http://xcap.example.com/resource-lists/user
s/sip:joe@example.com/index/~~/resource-lists/list%5b@nam
e=%22l1%22%5d</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
<service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
RLS services documents can be manipulated with XCAP. This section provides the details necessary for such a usage.
RLSサービスドキュメントはXCAPで操作できます。このセクションでは、そのような使用に必要な詳細を提供します。
XCAP requires application usages to define an application unique ID ID (AUID) in either the IETF tree or a vendor tree. This specification defines the "rls-services" AUID within the IETF tree, via the IANA registration in Section 8.
XCAPでは、IETFツリーまたはベンダーツリーのいずれかでアプリケーション一意のID ID（AUID）を定義するためのアプリケーション使用法が必要です。この仕様では、セクション8のIANA登録を介して、IETFツリー内の「RLSサービス」AUIDを定義します。
The MIME type for this document is "application/rls-services+xml".
このドキュメントのMIMEタイプは「アプリケーション/RLSサービスXML」です。
The XML Schema for this document is defined as the sole content of Section 4.2.
このドキュメントのXMLスキーマは、セクション4.2の唯一のコンテンツとして定義されます。
The default namespace used in expanding URIs is urn:ietf:params:xml:ns:rls-services.
URIの拡張で使用されるデフォルトの名前空間はurn：ietf：params：xml：ns：rls-servicesです。
In addition to the schema, there are constraints on the URIs present in the <service> and <resource-list> elements. These constraints are defined in Section 3.1. Some of these constraints are enforced by the XCAP server. Those constraints are:
スキーマに加えて、<Service>および<surce-List>要素に存在するURISに制約があります。これらの制約は、セクション3.1で定義されています。これらの制約の一部は、XCAPサーバーによって強制されています。これらの制約は次のとおりです。
o The URI in the "uri" attribute of the <service> element MUST be unique amongst all other URIs in "uri" elements in any <service> element in any document on a particular server. This uniqueness constraint spans across XCAP roots. Furthermore, the URI MUST NOT correspond to an existing resource within the domain of the URI. If a server is asked to set the URI to something that already exists, the server MUST reject the request with a 409, and use the mechanisms defined in [10] to suggest alternate URIs that have not yet been allocated.
o <Service>要素の「URI」属性のURIは、特定のサーバー上の任意のドキュメントの任意の<Service>要素の他のすべてのURIの中で一意でなければなりません。この独自性の制約は、XCAPルーツ全体にわたって及びます。さらに、URIは、URIのドメイン内の既存のリソースに対応してはなりません。サーバーが既に存在するものにURIを設定するように求められた場合、サーバーは409でリクエストを拒否し、[10]で定義されたメカニズムを使用して、まだ割り当てられていない代替URIを提案する必要があります。
o The URI in a <resource-list> element MUST be an absolute URI. The server MUST verify that the URI path contains "resource-lists" in the path segment corresponding to the AUID. If the RLS services document is within the XCAP user tree (as opposed to the global tree), the server MUST verify that the XUI in the path is the same as the XUI in the URI of to the RLS services document. These checks are made by examining the URI value, as opposed to dereferencing the URI. The server is not responsible for verifying that the URI actually points to a <list> element within a valid resource lists document.
o <リソースリスト>要素のURIは絶対的なURIでなければなりません。サーバーは、URIパスにAUIDに対応するパスセグメントに「リソースリスト」が含まれていることを確認する必要があります。RLSサービスドキュメントがXCAPユーザーツリー内（グローバルツリーとは対照的に）内にある場合、サーバーはパス内のXUIがRLSサービスドキュメントのURIのXUIと同じであることを確認する必要があります。これらのチェックは、URIの繰り返しとは対照的に、URI値を調べることによって行われます。サーバーは、URIが実際に有効なリソースリストのドキュメント内の<リスト>要素を指していることを確認する責任を負いません。
o In addition, an RLS services document can contain a <list> element, which in turn can contain <entry>, <entry-ref>, <list>, and <external> elements. The constraints defined for these elements in Section 3.4.7 MUST be enforced.
o さらに、RLSサービスドキュメントには<リスト>要素を含めることができます。これには、<entry>、<entry-ref>、<list>、および<tectruper>要素を含めることができます。セクション3.4.7のこれらの要素に対して定義された制約を実施する必要があります。
o In some cases, an XCAP client will wish to create a new RLS service, and wish to assign it a "vanity URI", such as sip:friends@example.com. However, the client does not know whether this URI meets the uniqueness constraints defined above. In that case, it can simply attempt the creation operation, and if the result is a 409 that contains a detailed conflict report with the <uniqueness-failure> element, the client knows that the URI could not be assigned. It can then retry with a different vanity URI, or use one of the suggestions in the detailed conflict report.
o 場合によっては、XCAPクライアントは新しいRLSサービスを作成し、sip：friends@example.comなどの「Vanity URI」を割り当てたいと考えています。ただし、クライアントは、このURIが上記で定義された一意性の制約を満たしているかどうかを知りません。その場合、単に作成操作を試みることができ、結果が<ユニケネスファイル>要素との詳細な競合レポートを含む409である場合、クライアントはURIを割り当てられないことを知っています。その後、異なる虚栄心URIで再試行するか、詳細な紛争レポートの提案の1つを使用できます。
o If the client wishes to create a new RLS service, and it doesn't care what the URI is, the client creates a random one, and attempts the creation operation. As discussed in [10], if this should fail with a uniqueness conflict, the client can retry with different URIs with increasing randomness.
o クライアントが新しいRLSサービスの作成を希望し、URIが何であるかを気にしない場合、クライアントはランダムなサービスを作成し、作成操作を試みます。[10]で説明したように、これが一意性対立で失敗する場合、クライアントはランダム性を高めると異なるURIを再試行することができます。
Semantics for the document content are provided in Section 4.1.
ドキュメントコンテンツのセマンティクスは、セクション4.1に記載されています。
Typically, there are two distinct XCAP clients that access RLS services documents. The first is a client acting on behalf of the end user in the system. This client edits and writes both resource lists and RLS services documents as they are created or modified by the end user. The other XCAP client is the RLS itself, which reads the RLS services documents in order to process SUBSCRIBE requests.
通常、RLSサービスドキュメントにアクセスする2つの異なるXCAPクライアントがあります。1つ目は、システム内のエンドユーザーに代わって行動するクライアントです。このクライアントは、エンドユーザーによって作成または変更されたときに、リソースリストとRLSサービスドキュメントの両方を編集および書き込みます。他のXCAPクライアントはRLS自体で、リクエストを処理するためにRLSサービスドキュメントを読み取ります。
To make it easier for an RLS to find the <service> element for a particular URI, the XCAP server maintains, within the global tree, a single RLS services document representing the union of all the <service> elements across all documents created by all users within the same XCAP root. There is a single instance of this document, and its name is "index". Thus, if the root services URI is http://xcap.example.com, the following is the URI that an RLS would use to fetch this index:
RLSが特定のURIの<Service>要素を見つけやすくするために、XCAPサーバーはグローバルツリー内で、すべてのドキュメントで作成されたすべてのドキュメントにわたってすべての<Service>要素の結合を表す単一のRLSサービスドキュメントを維持します。同じXCAPルート内のユーザー。このドキュメントには単一のインスタンスがあり、その名前は「インデックス」です。したがって、ルートサービスURIがhttp://xcap.example.comの場合、次のことは、RLSがこのインデックスを取得するために使用するURIです。
http://xcap.example.com/rls-services/global/index
As discussed below, this index is created from all the documents in the user tree that have the name "index" as well. An implication of this is that a client operating on behalf of a user SHOULD define its RLS services within the document named "index". If the root services URI is http://xcap.example.com, for user "sip:joe@example.com" the URI for this document would be:
以下で説明するように、このインデックスは、「インデックス」という名前のユーザーツリー内のすべてのドキュメントから作成されています。これの意味は、ユーザーに代わって動作するクライアントが「インデックス」という名前のドキュメント内でRLSサービスを定義する必要があることです。ルートサービスURIがhttp://xcap.example.comの場合、ユーザー用の "sip：joe@example.com"このドキュメントのURIは次のとおりです。
http://xcap.example.com/rls-services/users/sip:joe@example.com/index
If a client elects to define RLS services in a different document, this document will not be "picked up" in the global index, and therefore, will not be used as an RLS service.
クライアントが別のドキュメントでRLSサービスを定義することを選択した場合、このドキュメントはグローバルインデックスで「ピックアップ」されないため、RLSサービスとして使用されません。
As with other application usages, the XML schema and the XCAP resource naming conventions describe most of the resource interdependencies applicable to this application usage.
他のアプリケーションの使用法と同様に、XMLスキーマとXCAPリソースの命名規則は、このアプリケーションの使用に適用されるリソースの相互依存性のほとんどを説明しています。
This application usage defines an additional resource interdependence between a single document in the global tree and all documents in the user tree with the name "index". This global document is formed as the union of all of the index documents for all users within the same XCAP root. In this case, the union operation implies that each <service> element in a user document will also be present as a <service> element in the global document. The inverse is true as well. Every <service> element in the global document exists within a user document within the same XCAP root.
このアプリケーションの使用法は、グローバルツリー内の単一のドキュメントと、「インデックス」という名前のユーザーツリー内のすべてのドキュメントとの間の追加のリソース相互依存を定義します。このグローバルドキュメントは、同じXCAPルート内のすべてのユーザーのすべてのインデックスドキュメントの結合として形成されます。この場合、ユニオンの操作は、ユーザードキュメントの各<Service>要素がグローバルドキュメントの<Service>要素として存在することを暗示しています。逆も当てはまります。グローバルドキュメントのすべての<Service>要素は、同じXCAPルート内のユーザードキュメント内に存在します。
As an example, consider the RLS services document for user sip:joe@example.com:
例として、ユーザーsip：joe@example.comのRLSサービスドキュメントを検討してください：
<?xml version="1.0" encoding="UTF-8"?> <rls-services> <service uri="sip:mybuddies@example.com"> <resource-list>http://xcap.example.com/resource-lists/users/si p:joe@example.com/index/~~/resource-lists/list%5b@name=%22l1% 22%5d</resource-list> <packages> <package>presence</package> </packages> </service> </rls-services> And consider the RLS services document for user bob:
<？xml version = "1.0" encoding = "utf-8"？> <rls-services> <service uri = "sip：mybuddies@example.com"> <resource-list> http://xcap.example.com/Resource-Lists/Users/SI P：joe@example.com/index/~~/resource-lists/list％5b@name =％22l1％22％5d </resource-list> <packages> <package></package> </packages> </service> </rls-services>およびユーザーBobのRLSサービスドキュメントを検討してください。
<?xml version="1.0" encoding="UTF-8"?>
<rls-services>
<service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
The global document at http://xcap.example.com/rls-services/global/index would look like this:
http://xcap.example.com/rls-services/global/indexのグローバルドキュメントは次のようになります。
<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services"
xmlns:rl="urn:ietf:params:xml:ns:resource-lists"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<service uri="sip:mybuddies@example.com">
<resource-list>http://xcap.example.com/resource-lists/user
s/sip:joe@example.com/index/~~/resource-lists/list%5b@nam
e=%22l1%22%5d</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
<service uri="sip:marketing@example.com">
<list name="marketing">
<rl:entry uri="sip:joe@example.com"/>
<rl:entry uri="sip:sudhir@example.com"/>
</list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
Requests made against the global document MUST generate responses that reflect the most recent state of all the relevant user documents. This requirement does not imply that the server must actually store this global document. It is anticipated that most systems will dynamically construct the responses to any particular request against the document resource.
グローバルドキュメントに対して行われた要求は、関連するすべてのユーザードキュメントの最新の状態を反映する応答を生成する必要があります。この要件は、サーバーがこのグローバルドキュメントを実際に保存する必要があることを意味するものではありません。ほとんどのシステムは、ドキュメントリソースに対する特定の要求に対する応答を動的に構築することが予想されます。
The uniqueness constraint on the "uri" attribute of <service> will ensure that no two <service> elements in the global document have the same value of that attribute.
<Service>の「URI」属性に対する一意性の制約により、グローバルドキュメント内の2つの<Service>要素がその属性と同じ値を持たないようにします。
This application usage does not modify the default XCAP authorization policy, which is that only a user can read, write, or modify their own documents. A server can allow privileged users to modify documents that they don't own, but the establishment and indication of such policies are outside the scope of this document. It is anticipated that a future application usage will define which users are allowed to modify an RLS services document.
このアプリケーションの使用は、デフォルトのXCAP認証ポリシーを変更しません。つまり、ユーザーのみが独自のドキュメントを読み取り、書き込み、または変更できます。サーバーは、特権ユーザーが所有していないドキュメントを変更できるようにすることができますが、そのようなポリシーの確立と兆候はこのドキュメントの範囲外です。将来のアプリケーションの使用により、RLSサービスドキュメントの変更が許可されているユーザーが定義されることが予想されます。
The index document maintained in the global tree represents sensitive information, as it contains the union of all the information for all users on the server. As such, its access MUST be restricted to trusted elements within domain of the server. Typically, this would be limited to the RLSs that need access to this document.
グローバルツリーに維持されているインデックスドキュメントは、サーバー上のすべてのユーザーのすべての情報の結合が含まれているため、機密情報を表しています。そのため、そのアクセスは、サーバーのドメイン内の信頼できる要素に制限されている必要があります。通常、これはこのドキュメントへのアクセスが必要なRLSSに限定されます。
This section discusses how an RLS, on receipt of a SUBSCRIBE request, uses XCAP and the RLS services document to guide its operation.
このセクションでは、rlsが購読要求を受け取ったときに、XCAPとRLSサービスドキュメントを使用して操作をガイドする方法について説明します。
When an RLS receives a SUBSCRIBE request for a URI (present in the Request URI), it obtains the <service> element whose uri attribute matches (based on URI equality) the URI in the SUBSCRIBE request. This document makes no normative statements on how this might be accomplished. The following paragraph provides one possible approach.
RLSがURIのサブスクライブリクエスト（リクエストURIに存在する）を受信すると、URI属性が（URI平等に基づいて）URIとサブスクライブリクエストのURIと一致する<Service>要素を取得します。このドキュメントは、これがどのように達成されるかについて規範的な声明を出しません。次の段落は、1つの可能なアプローチを提供します。
The RLS canonicalizes the Request URI as described in Section 5. It then performs an XCAP GET operation against the URI formed by combining the XCAP root with the document selector of the global index with a node selector of the form "rls-services/ service[@uri=<canonical-uri>]", where <canonical-uri> is the canonicalized version of the Request URI. If the response is a 200 OK, it will contain the service definition for that URI.
RLSは、セクション5で説明されているようにリクエストURIを正規化します。その後、XCAPルートをグローバルインデックスのドキュメントセレクターとフォームのノードセレクター「RLS-Services/ Service [rls-services/ service」と組み合わせることにより、xcap get操作を実行します。@uri = <canonical-uri>] "、<canonical-uri>はリクエストURIの正規化バージョンです。応答が200 OKの場合、そのURIのサービス定義が含まれます。
Once the <service> element has been obtained, it is examined. If the <packages> element is present, and the event package in the SUBSCRIBE request is not amongst those listed in the <package> elements within <packages>, the request MUST be rejected with a 489 (Bad Event) response code, as described in [13]. Otherwise, it SHOULD be processed. The next step is to authorize that the client is allowed to subscribe to the resource. This can be done using the data defined in [12], for example. Assuming the subscriber is authorized to subscribe to that resource, the subscription is processed according to the procedures defined in [14]. This processing requires the RLS to compute a flat list of URIs that are to be subscribed to. If the <service> element had a <list> element, it is extracted. If the <service> element had a <resource-list> element, its URI content is dereferenced. The result should be a <list> element. If it is not, the request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, that <list> element is extracted.
<service>要素が取得されると、調べられます。<パッケージ>要素が存在し、サブスクライブリクエストのイベントパッケージが<パッケージ>内の<パッケージ>要素にリストされているものの中にない場合、記載されているように489（悪いイベント）応答コードでリクエストを拒否する必要があります[13]で。それ以外の場合は、処理する必要があります。次のステップは、クライアントがリソースを購読することを許可されていることを承認することです。これは、たとえば[12]で定義されているデータを使用して実行できます。サブスクライバーがそのリソースを購読する権限があると仮定すると、サブスクリプションは[14]で定義されている手順に従って処理されます。この処理では、RLSがサブスクライブするURIのフラットリストを計算する必要があります。<service>要素に<list>要素がある場合、抽出されます。<service>要素に<surce-list>要素がある場合、そのURIコンテンツは再参入されます。結果は<list>要素にする必要があります。そうでない場合は、502（悪いゲートウェイ）でリクエストを拒否する必要があります。それ以外の場合、その<list>要素が抽出されます。
At this point, the RLS has a <list> element in its possession. The next step is to obtain a flat list of URIs from this element. To do that, it traverses the tree of elements rooted in the <list> element. Before traversal begins, the RLS initializes two lists: the "flat list", which will contain the flat list of the URI after traversal, and the "traversed list", which contains a list of HTTP URIs in <external> elements that have already been visited. Both lists are initially empty. Next, tree traversal begins. A server can use any tree-traversal ordering it likes, such as depth-first search or breadth-first search. The processing at each element in the tree depends on the name of the element:
この時点で、RLSにはその所持されている<リスト>要素があります。次のステップは、この要素からURIのフラットリストを取得することです。そのために、<list>要素に根ざした要素の木を横断します。トラバーサルが始まる前に、RLSは2つのリストを初期化します。トラバーサル後のURIのフラットリストを含む「フラットリスト」と、すでに持っている<外部>要素のhttp urisのリストを含む「トラバースリスト」が含まれます。訪問されました。両方のリストは最初は空です。次に、ツリートラバーサルが始まります。サーバーは、深度最初の検索や幅最初の検索など、好きな任意のツリートラバーサル注文を使用できます。ツリー内の各要素での処理は、要素の名前によって異なります。
o If the element is <entry>, the URI in the "uri" attribute of the element is added to the flat list if it is not already present (based on case-sensitive string equality) in that list, and the URI scheme represents one that can be used to service subscriptions, such as SIP [4] and pres [15].
o 要素が<intry>の場合、そのリストにまだ存在していない場合（ケースに敏感な文字列等式に基づく）、要素の「URI」属性のURIがフラットリストに追加され、URIスキームは1を表します。これは、SIP [4]やPres [15]などのサブスクリプションのサービスに使用できます。
o If the element is an <entry-ref>, the relative path reference making up the value of the "ref" attribute is resolved into an absolute URI. This is done using the procedures defined in Section 5.2 of RFC 3986 [7], using the XCAP root of the RLS services document as the base URI. This absolute URI is resolved. If the result is not a 200 OK containing a <entry> element, the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, the <entry> element returned is processed as described in the previous step.
o 要素が<Entry-Ref>の場合、「ref」属性の値を構成する相対パス参照が絶対URIに解決されます。これは、RLSサービスドキュメントのXCAPルートをベースURIとして使用して、RFC 3986 [7]のセクション5.2で定義されている手順を使用して行われます。この絶対的なURIは解決されます。結果が<Entry>要素を含む200 OKでない場合、サブスクライブリクエストは502（悪いゲートウェイ）で拒否される必要があります。それ以外の場合、返される<Entry>要素は、前のステップで説明されているように処理されます。
o If the element is an <external> element, the absolute URI making up the value of the "anchor" attribute of the element is examined. If the URI is on the traversed list, the server MUST cease traversing the tree, and SHOULD reject the SUBSCRIBE request with a 502 (Bad Gateway). If the URI is not on the traversed list, the server adds the URI to the traversed list, and dereferences the URI. If the result is not a 200 OK containing a <list> element, the SUBSCRIBE request SHOULD be rejected with a 502 (Bad Gateway). Otherwise, the RLS replaces the <external> element in its local copy of the tree with the <list> element that was returned, and tree traversal continues.
o 要素が<外部>要素の場合、要素の「アンカー」属性の値を構成する絶対URIが調べられます。URIがトラバースリストに載っている場合、サーバーはツリーのトラバースを停止する必要があり、502（悪いゲートウェイ）でサブスクライブリクエストを拒否する必要があります。URIがトラバースリストに載っていない場合、サーバーはURIをトラバースリストに追加し、URIを参照します。結果が<リスト>要素を含む200 OKでない場合、サブスクライブリクエストは502（悪いゲートウェイ）で拒否する必要があります。それ以外の場合、RLSは、ツリーのローカルコピーの<外部>要素を返された<リスト>要素に置き換え、ツリートラバーサルが続きます。
Because the <external> element is used to dynamically construct the tree, there is a possibility of recursive evaluation of references. The traversed list is used to prevent this from happening.
<外部>要素はツリーを動的に構築するために使用されるため、参照の再帰評価の可能性があります。トラバースリストは、これが発生しないように使用されます。
Once the tree has been traversed, the RLS can create virtual subscriptions to each URI in the flat list, as defined in [14]. In the processing steps outlined above, when an <entry-ref> or <external> element contains a reference that cannot be resolved, failing the request is at SHOULD strength. In some cases, an RLS may provide better service by creating virtual subscriptions to the URIs in the flat list that could be obtained, omitting those that could not. Only in those cases should the SHOULD recommendation be ignored.
ツリーが通過すると、RLSは[14]で定義されているように、フラットリストで各URIに仮想サブスクリプションを作成できます。上記の処理手順では、<Entre-Ref>または<Extrean>要素に解決できない参照が含まれている場合、リクエストに失敗した場合は強度になります。場合によっては、RLSは、取得できるフラットリストにURISに仮想サブスクリプションを作成し、できないものを省略することにより、より良いサービスを提供することがあります。これらの場合にのみ、推奨が無視されるべきである必要があります。
This section provides a technique for URI canonicalization. This canonicalization produces a URI that, in most cases, is equal to the original URI (where equality is based on the URI comparison rules in RFC 3261). Furthermore, the canonicalized URI will usually be lexically equivalent to the canonicalized version of any other URI equal to the original.
このセクションでは、URI Canonicalizationの手法を提供します。この標準化は、ほとんどの場合、元のURIに等しいURIを生成します（平等はRFC 3261のURI比較ルールに基づいています）。さらに、標準化されたURIは、通常、オリジナルに等しい他のURIの標準化されたバージョンと語彙的に同等です。
To canonicalize the URI, the following steps are followed:
URIを正規化するには、次の手順に従います。
1. First, the domain part of the URI is converted into all lowercase, and any tokens (such as "user" or "transport" or "udp") are converted to all lowercase.
1. まず、URIのドメイン部分はすべての小文字に変換され、トークン（「ユーザー」または「トランスポート」、「UDP」など）はすべての小文字に変換されます。
2. Secondly, any percent-encoding in the URI for characters which do not need to be percent-encoded is removed. A character needs to be percent-encoded when it is not permitted in that part of the URI based on the grammar for that part of the URI. For example, if a SIP URI is sip:%6aoe%20smith@example.com, it is changed to sip:joe%20smith@example.com. In the original URI, the character 'j' was percent-encoded. This is allowed, but not required, since the grammar allows a 'j' to appear in the user part. As a result, it appears as 'j' after this step of canonicalization.
2. 第二に、パーセントエンコードする必要のないキャラクターのURIのパーセントエンコードは削除されます。URIのその部分の文法に基づいて、URIのその部分で許可されていない場合、キャラクターはパーセントエンコードされる必要があります。たとえば、SIP URIがsip：％6aoe%20smith@example.comである場合、sip：joe%20smith@example.comに変更されます。元のURIでは、キャラクター「J」はパーセントエンコードされていました。これは許可されていますが、必要ではありません。文法により、「J」がユーザーパーツに表示される可能性があるためです。その結果、この標準化のこのステップの後に「J」として表示されます。
3. Thirdly, any URI parameters are reordered so that they appear in lexical order based on parameter name. The ordering of a character is determined by the US-ASCII numerical value of that character, with smaller numbers coming first. Parameters are ordered with the leftmost character as most significant. For parameters that contain only letters, this is equivalent to an alphabetical ordering.
3. 第三に、URIパラメーターはすべて並べ替えられて、パラメーター名に基づいて語彙順に表示されます。キャラクターの順序は、そのキャラクターの米国ASCII数値によって決定され、数字が少なくなります。パラメーターは、最も重要なものとして左端の文字で順序付けられます。文字のみを含むパラメーターの場合、これはアルファベット順の順序に相当します。
4. Finally, any header parameters are discarded. This canonicalized URI is used instead of the original URI.
4. 最後に、ヘッダーパラメーターは破棄されます。この正規化されたURIは、元のURIの代わりに使用されます。
If two URIs, A and B, are functionally equal (meaning that they are equal according to the URI comparison rules in RFC 3261), their canonicalized URIs are equal under case-sensitive string comparison if the following are true:
2つのURI、AとBが機能的に等しい場合（RFC 3261のURI比較ルールに従って等しいことを意味します）、それらの標準化されたURIは、次の場合、ケースに敏感な文字列比較の下で等しくなります。
o Neither URI contains header parameters.
o どちらのURIにもヘッダーパラメーターは含まれていません。
o If one of the URI contains a URI parameter not defined in RFC 3261, the other does as well.
o URIの1つにRFC 3261で定義されていないURIパラメーターが含まれている場合、もう1つも同様です。
Resource-lists and RLS services documents are meant to be extended. An extension takes place by defining a new set of elements in a new namespace, governed by a new schema. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the namespaces defined in this specification. The extension MUST NOT change the syntax or semantics of the schemas defined in this document. All XML tags and attributes that are part of the extension MUST be appropriately qualified so as to place them within that namespace.
リソースリストとRLSサービスドキュメントは、拡張することを目的としています。拡張機能は、新しい名前の新しい名前空間で新しい要素のセットを定義することによって行われます。すべての拡張子には、適切なXMLネームスペースが割り当てられている必要があります。拡張機能のXML名空間は、この仕様で定義されている名前空間とは異なる必要があります。拡張機能は、このドキュメントで定義されているスキーマの構文またはセマンティクスを変更してはなりません。拡張機能の一部であるすべてのXMLタグと属性は、それらをその名前空間内に配置するために適切に適格でなければなりません。
This specification defines explicit places where new elements or attributes from an extension can be placed. These are explicitly indicated in the schemas by the <any> and <anyAttribute> elements. Extensions to this specification MUST specify where their elements can be placed within the document.
この仕様は、拡張機能からの新しい要素または属性を配置できる明示的な場所を定義します。これらは、<any>および<AnyAttribute>要素によってスキーマで明示的に示されています。この仕様の拡張は、要素をドキュメント内に配置できる場所を指定する必要があります。
As a result, a document that contains extensions will require multiple schemas in order to determine its validity: a schema defined in this document, along with those defined by extensions present in the document. Because extensions occur by adding new elements and attributes governed by new schemas, the schemas defined in this document are fixed and would only be changed by a revision to this specification. Such a revision, should it take place, would endeavor to allow documents compliant to the previous schema to remain compliant to the new one. As a result, the schemas defined here don't provide explicit schema versions, as this is not expected to be needed.
その結果、拡張機能を含むドキュメントには、その有効性を決定するために複数のスキーマが必要になります。このドキュメントで定義されているスキーマと、ドキュメントに存在する拡張機能によって定義されているスキーマ。拡張機能は、新しいスキーマによって支配された新しい要素と属性を追加することによって発生するため、このドキュメントで定義されているスキーマは修正され、この仕様の改訂によってのみ変更されます。このような改訂が行われた場合、以前のスキーマに準拠した文書を新しいものに準拠させたままにするように努力します。その結果、ここで定義されているスキーマは、明示的なスキーマバージョンを提供しません。これは必要とされていないためです。
The information contained in rls-services and resource-lists documents are particularly sensitive. It represents the principle set of people with whom a user would like to communicate. As a result, clients SHOULD use TLS when contacting servers in order to fetch this information. Note that this does not represent a change in requirement strength from XCAP.
RLSサービスとリソースリストのドキュメントに含まれる情報は、特に敏感です。これは、ユーザーが通信したい人の原則セットを表しています。その結果、クライアントはこの情報を取得するためにサーバーに連絡するときにTLSを使用する必要があります。これは、XCAPからの要件強度の変化を表していないことに注意してください。
There are several IANA considerations associated with this specification.
この仕様に関連するいくつかのIANAの考慮事項があります。
This section registers two new XCAP Application Unique IDs (AUIDs) according to the IANA procedures defined in [10].
このセクションは、[10]で定義されているIANA手順に従って、2つの新しいXCAPアプリケーション一意のID（AUIDS）を登録します。
Name of the AUID: resource-lists
AUIDの名前：リソースリスト
Description: A resource lists application is any application that needs access to a list of resources, identified by a URI, to which operations, such as subscriptions, can be applied.
説明：リソースリストアプリケーションは、サブスクリプションなどの操作を適用できるURIによって識別されるリソースのリストにアクセスする必要があるアプリケーションです。
Name of the AUID: rls-services
AUIDの名前：RLSサービス
Description: A Resource List Server (RLS) services application is a Session Initiation Protocol (SIP) application whereby a server receives SIP SUBSCRIBE requests for resource, and generates subscriptions towards a resource list.
説明：リソースリストサーバー（RLS）サービスアプリケーションは、セッション開始プロトコル（SIP）アプリケーションであり、サーバーがリソースのSIP購読要求を受信し、リソースリストにサブスクリプションを生成します。
This specification requests the registration of two new MIME types according to the procedures of RFC 4288 [9] and guidelines in RFC 3023 [5].
この仕様では、RFC 4288 [9]の手順とRFC 3023 [5]のガイドラインに従って、2つの新しいMIMEタイプの登録を要求します。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: resource-lists+xml
MIMEサブタイプ名：リソースリストXML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5].
オプションのパラメーター：RFC 3023 [5]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
考慮事項のエンコーディング：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[5]。
Security considerations: See Section 10 of RFC 3023 [5] and Section 7 of RFC 4826.
セキュリティ上の考慮事項：RFC 3023 [5]のセクション10およびRFC 4826のセクション7を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4826
公開された仕様：RFC 4826
Applications that use this media type: This document type has been used to support subscriptions to lists of users [14] for SIP-based presence [11].
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、SIPベースの存在[11]のユーザー[14]のリストへのサブスクリプションをサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .rl
ファイル拡張子：.rl
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: rls-services+xml
MIMEサブタイプ名：RLSサービスXML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5].
オプションのパラメーター：RFC 3023 [5]で指定されているCharsetパラメーターアプリケーション/XMLと同じ。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
考慮事項のエンコーディング：RFC 3023で指定されているアプリケーション/XMLの考慮事項のエンコードと同じ[5]。
Security considerations: See Section 10 of RFC 3023 [5] and Section 7 of RFC 4826.
セキュリティ上の考慮事項：RFC 3023 [5]のセクション10およびRFC 4826のセクション7を参照してください。
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: RFC 4826
公開された仕様：RFC 4826
Applications that use this media type: This document type has been used to support subscriptions to lists of users [14] for SIP-based presence [11].
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、SIPベースの存在[11]のユーザー[14]のリストへのサブスクリプションをサポートするために使用されています。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .rs
ファイル拡張子：.rs
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
個人および電子メールアドレス詳細情報：Jonathan Rosenberg、jdrosen@jdrosen.net
Intended usage: COMMON
意図された使用法：共通
Author/Change controller: The IETF.
著者/変更コントローラー：IETF。
This section registers two new XML namespaces, as per the guidelines in RFC 3688 [8].
このセクションは、RFC 3688のガイドラインに従って、2つの新しいXMLネームスペースを登録します[8]。
URI: The URI for this namespace is urn:ietf:params:xml:ns:resource-lists.
URI：この名前空間のURIはurn：ietf：params：xml：ns：resource-listsです。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource Lists Namespace</title>
</head>
<body>
<h1>Namespace for Resource Lists</h1>
<h2>urn:ietf:params:xml:ns:resource-lists</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
RFC4826</a>.</p>
</body>
</html>
END
URI: The URI for this namespace is urn:ietf:params:xml:ns:rls-services.
URI：この名前空間のURIはurn：ietf：params：xml：ns：rls-servicesです。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Resource List Server (RLS) Services Namespace</title>
</head>
<body>
<h1>Namespace for Resource List Server (RLS) Services</h1>
<h2>urn:ietf:params:xml:ns:rls-services</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4826.txt">
RFC4826</a>.</p>
</body>
</html>
END
This section registers two XML schemas per the procedures in [8].
このセクションでは、[8]の手順ごとに2つのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:resource-lists
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 3.2.
このスキーマのXMLは、セクション3.2の唯一の内容として見つけることができます。
URI: urn:ietf:params:xml:schema:rls-services
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者の連絡先：IETF、Simple Working Group、（simple@ietf.org）、Jonathan Rosenberg（jdrosen@jdrosen.net）。
The XML for this schema can be found as the sole content of Section 4.2.
このスキーマのXMLは、セクション4.2の唯一の内容として見つけることができます。
The authors would like to thank Hisham Khartabil, Jari Urpalainen, and Spencer Dawkins for their comments and input. Thanks to Ted Hardie for his encouragement and support of this work.
著者は、コメントと意見について、Hisham Khartabil、Jari Urpalainen、およびSpencer Dawkinsに感謝したいと思います。この作品の励ましとサポートをしてくれたTed Hardieに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Paoli, J., Maler, E., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Second Edition)", World Wide Web Consortium FirstEdition REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/REC-xml-20001006>.
[2] Paoli、J.、Maler、E.、Bray、T。、およびC. Sperberg-Mcqueen、「拡張可能なマークアップ言語（XML）1.0（第2版）」、World Wide Web Consortium Firstedition Rec-XML-20001006、2000年10月、<http://www.w3.org/tr/2000/rec-xml-20001006>。
[3] Moats, R., "URN Syntax", RFC 2141, May 1997.
[3] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[4] 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.
[4] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5] Murata、M.、St。Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[7] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[7] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「ユニフォームリソース識別子（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[8] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[8] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[9] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[9] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。
[10] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[10] Rosenberg、J。、「拡張可能なマークアップ言語（XML）構成アクセスプロトコル（XCAP）」、RFC 4825、2007年5月。
[11] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[11] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[12] Rosenberg, J., "Presence Authorization Rules", Work in Progress, October 2006.
[12] Rosenberg、J。、「プレゼンス認可規則」、2006年10月、進行中の作業。
[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[13] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[14] Roach, A., Rosenberg, J., and B. Campbell, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, January 2005.
[14] Roach、A.、Rosenberg、J。、およびB. Campbell、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張機能」、RFC 4662、2005年1月。
[15] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[15] ピーターソン、J。、「存在のための共通プロファイル（CPP）」、RFC 3859、2004年8月。
Author's Address
著者の連絡先
Jonathan Rosenberg Cisco Edison, NJ US
ジョナサンローゼンバーグシスコエジソン、ニュージャージー州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。