Network Working Group J. Rosenberg
Request for Comments: 4826 Cisco
Category: Standards Track May 2007
Extensible Markup Language (XML)
Formats for Representing Resource Lists
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
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).
マルチメディア通信、プレゼンス、インスタントメッセージングシステムにおいて、ユーザのグループに関連付けられているサービスを表すUniform Resource Identifier（URI）を定義する必要があります。一つの例は、リソースリストサービスです。ユーザがセッション開始プロトコル（SIP）は、リソース・リスト・サービスを表すURIにSUBSCRIBEメッセージを送信した場合、サーバは、関連するグループ内のユーザの状態を取得し、送信者に提供します。これらのサービスの定義を容易にするために、この仕様は2拡張マークアップ言語（XML）文書を定義します。一つの文書には、そのサービス定義とユーザの関連するグループを参照するとともに、サービスの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リクエストは、通信動作のいくつかのフォームを確立する目的のために生成可能な任意のリソースとしてSIP URI（Uniform Resource Identifier）を定義します。これらのURIは、ユーザ（：joe@example.com例えば、SIP）を表すことができます。 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.
このようなサービスの一つの重要な例が存在する[11]リストサービスです。プレゼンスリストサービスは、クライアントがユーザーのリストについては、プレゼンス情報を求めるためのSIP SUBSCRIBEリクエストを生成することができます。プレゼンスリストサーバは、リスト上のユーザーのプレゼンスを取得し、クライアントにそれらを提供します。プレゼンスリストサーバは、クライアントがリソースのリストのためのSIPイベントの通知を要求するSIP SUBSCRIBEリクエストを生成することを可能にするリソース・リスト・サーバ（RLS）の特定の場合[14]、です。
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.
そのようなサービスの別の例は、インスタント会議サービスです。クライアントは、SIPは、インスタンス会議サービスを表すURIにINVITEリクエストを送信した場合、会議サーバは、クライアントとユーザーの関連するグループを含む電話会議を作成します。
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.
これらのシステムの利用者は、これらのリソースリストにアクセスするサービスとは別に（一般的に、リソースリストと呼ばれる）は、ユーザまたはリソースのグループを定義することは非常に便利です。確かに、でも任意の関連するネットワークベースのサービスが存在しない場合にリソースリストの使用法があります。一例として、プレゼンス・リスト・サービスを使用するのではなく、クライアントは、個人がローカルに格納されたプレゼンスリスト内の各ユーザのプレゼンスを取得するSUBSCRIBE要求生成するかもしれません。そのような場合には、ディスク上にローカルリストを格納するためのフォーマットが必要です。さらに、ユーザーは友達とリストを共有したい、と友人たちにそれを電子メールで送信することを望むかもしれません。また、これは、リソースリストの標準フォーマットが必要です。
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.
そのようなものとして、この文書は、二つの拡張マークアップ言語（XML）ドキュメントフォーマットを定義します。最初は、任意の特定のサービスに依存しない、リソースリストを表すために使用されます。第二は、RLSのサービスURIを定義するために、サービスURIのリソースのリストを関連付けるために使用されます。この文書では、これら二つの文書のそれぞれを管理するための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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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良く形成しなければならないとXML文書にvalidaterに入手可能であり、適用可能な拡張スキーマを含むスキーマに従って有効でなければなりません[2]文書です。リソースリスト文書は、XML 1.0に基づいていなければならないとUTF-8を使用してエンコードされなければなりません。この仕様は、リソースリスト文書と文書の断片を識別するためのXML名前空間を使用しています。この仕様によって定義された要素の名前空間URIは、「IETF」ネームスペース識別子を使用してURN [3]は、RFC 2648によって定義された[6]、RFC 3688によって拡張[8]。このURNは以下のとおりです。
urn:ietf:params:xml:ns:resource-lists
URN：IETF：のparams：XML：NS：リソース・リスト
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.
リソースリスト文書は、文書のルート要素としての<resource-リスト>要素を持っています。この要素には属性がありません。その内容は、単一のリソースリストを定義各々がゼロ以上の<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.
各<リスト>要素には、オプションの「name」属性を含めることができます。この属性は、リストのハンドルです。存在する場合、それは、同じ親要素内の他のすべての<リスト>要素の中でユニークでなければなりません。 <リスト>要素は、拡張性の目的のために他の名前空間からの属性を含んでいてもよいです。
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>要素、<リスト>要素、<エントリ-ref>要素、または<外部にあってもよい各々がゼロ以上の要素の配列で構成されています>要素、拡張の目的のために他の名前空間からの要素の任意の数字が続きます。他の<リスト>要素が含まれているために、<リスト>要素の能力は、リソースリストを階層的に構造化することができることを意味しています。 <表示名>次に、階層内の各レベルに関連するヒトフレンドリー名を可能にします。 <entry>要素は、リストの一部であるURIによって定義される単一のリソースを、記載されています。 <entry-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.
<entry>要素は、単一のリソースについて説明します。 <entry>要素は、単一の必須属性、「URI」を持っています。この属性は、リソースにアクセスするために使用されるURIに等しいです。リソースリスト形式自体は使用することができURIの種類を制限しません。しかし、リソースリストを利用したサービスは、特定のURIスキームが必要な場合があります。例えば、RLSサービスはsubscribeableリソースを表すURIを必要とします。これは、SIPおよびPRES [15] URIを含みます。他のすべての「URI」は、同じ親の中の<entry>要素の属性の中で、「URI」属性は一意でなければなりません。一意性は、大文字と小文字を区別した文字列の比較によって決定されます。このように、二つの「URI」属性は大文字と小文字を区別文字列比較を使用して比較した場合、そのURIスキーム用に定義された機能的な平等のルールが、異なるものを使用して比較したときに同じURIを持つことも可能です。 <entry>要素は、拡張性の目的のために他の名前空間からの属性をも含むことができます。
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.
<entry>要素は、エントリに関する情報を提供する要素の配列を含みます。唯一のそのような要素は、<表示名>であり、この時点で定義されています。この要素は、リソースを記述する人間のユーザによって消費のためのものUTF-8エンコードされた文字列を、提供します。 <entry>要素、<表示名>の「name」属性とは異なり全く一意性要件はありません。表示名の言語を提供する属性、<表示-name>要素は、「LANG XML」を含めることができます。 <entry>要素は、他の名前空間から他の要素を含むことができます。これは、電話番号や住所などのエントリに関するその他の情報を含めることをサポートすることを意味します。
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.
<entry-ref>要素は、エントリが参照によってではなく、値によってリストに含まれることを可能にします。文書がXCAPによって得られたとき、この要素はのみ意味があります。このような場合には、参照エントリが同じXCAPルート内に存在しなければなりません。 <entry>要素は、単一の必須属性、「参照」を持っています。他のすべての「参照」は、同じ親の内部の<entry-ref>を要素の属性の中の「参照」属性は一意でなければなりません。一意性は、大文字と小文字を区別し、文字列の比較によって決定されます。 <entry-ref>要素はまた、拡張性のために、他の名前空間からの属性を可能にします。 <entry-ref>要素の内容は、拡張性の目的のために他の名前空間からの要素の任意の数字が続く任意の表示名です。表示名は、<entry>の中で定義された名前の代わりの<entry-ref>要素が参照するようにローカライズされたニックネームを提供するのに有用です。
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は、<エントリ-REF>が出現する文書のXCAPルートURIに等しい相対パス参照でなければなりません。この相対URIは、RFC 3986の手順に従って、絶対URIに解決した場合、リソースリスト文書内の<entry>要素に解決しなければなりません。例えば、特定の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
http://xcap.example.com/resource-lists/users/sip:bill@example.com/インデックス/ ~~ /リソース・リスト/リスト％5bの名前=％22list1％22％5D /エントリ％@ 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である場合は、このエントリを指すの<entry-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"/>
<エントリー-REF REF = "リソース・リスト/ユーザー/ SIP：インデックス/ ~~ /リソース・リスト/リストbill@example.com/％5bの名前=％22list1％22％5D /エントリ％@ 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.
"/"。相対URIは、URI、相対パスでなければなりません「参照」属性内で使用されるので、「/」の「参照」属性のコンテンツ内の最初の文字として存在することはありません。 「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.
<外部>要素は、<エントリ-ref>要素に似ています。 <エントリー-REF>のように、それはXCAPサーバから取得した文書にのみ意味があります。それはあまりにも他の場所に格納されたコンテンツへの参照です。しかし、全体のリストを参照し、さらに、そのリストは、別のサーバ上に存在することを可能にします。 <外部>要素は絶対HTTP URIにより外部のリストを指定し、「アンカー」とは、単一の必須属性を有しています。他のすべての「アンカー」は、同じ親の内部の<外部>要素の属性の中で「アンカー」属性は一意でなければなりません。一意性は、大文字と小文字を区別した文字列の比較によって決定されます。 <外部>要素は、拡張性の目的のために他の名前空間からの属性を含めることができます。 <外部>要素の内容は、拡張性の目的のために別の名前空間からの要素の任意の数、続くオプションの<表示名>です。 「アンカー」属性の値は、絶対的な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.
<エントリー-ref>要素と<外部>要素の両方のために、彼らの参照を解決する責任は、文書を利用しているエンティティに当たります。文書をXCAPと組み合わせて使用される場合、これは負担がXCAPクライアントに落ちることを意味します。 XCAPクライアントがプレゼンスリストとしてリソース・リストの文書を使用したPCベースのアプリケーションである場合、参照はおそらく、ユーザによる明示的な要求に応じて解決されるだろう。彼らは、当然のことながら、任意の時点で解決することができます。 XCAPクライアントがRLS自身である場合RLSは、これらの参考文献の1（下記参照）を含むリソースリストに関連付けられたRLSサービスのSUBSCRIBEリクエストを受信したときに、参照が解決されるだろう。この仕様で定義された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>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSの=の "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ "のxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS：インポートの名前空間=" のhttp：//www.w3。 ORG / XML / 1998 /名前空間」のschemaLocation = "http://www.w3.org/2001/xml.xsd" /> <XS：complexTypeの名= "listType（リストタイプ）"> <XS：シーケンス> <XS：要素名= "表示名" タイプ= "表示-NAMETYPE" のminOccurs = "0" /> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：選択> <XS：要素名= "リスト"> < XS：complexTypeの> <XS：complexContentを> <XS：増設ベース= "listType（リストタイプ）" /> </ XS：complexContentを> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "外部" タイプ=」 externalType "/> <XS：要素名=" エントリ」タイプ= "entryType" /> <XS：要素名= "エントリ-REF" タイプ= "エントリ-refType" /> </ XS：選択> </ XS：シーケンス> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "NA私の」タイプ= "XS：文字列" 使用= "オプション" /> <XS：anyAttributeは名前空間= "##他" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名= "entryType"> <XS：配列> <XS：要素名= "表示名" のminOccurs = "0"> <XS：complexTypeの> <XS：simpleContentを> <XS：増設ベース= "表示NAMETYPE" /> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：要素> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：使用= "必要" /> <XS：anyAttributeは名前空間= "##他" のprocessContents = "緩い" /> </ XS：complexTypeの>：= "anyURIのXS" 名前= "URI" 属性タイプ
<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>
<XS：complexTypeの名= "エントリrefType"> <XS：配列> <XS：要素名= "表示名" タイプ= "表示NAMETYPE" のminOccurs = "0" /> <XS：任意の名前空間= "＃ #other」のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：シーケンス> <XS：属性名= "参照" タイプ= "XS：anyURIの" 使用= "必須" /> < XS：anyAttributeは名前空間= "##他" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名前= "externalType"> <XS：シーケンス> <XS：要素名= "表示名" タイプ= "表示NAMETYPE" のminOccurs = "0" /> <XS：任意の名前空間= "##その他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS： /> <XS：名= "アンカー" タイプ= "anyURIのXS"：属性anyAttributeは名前空間を= "##その他" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：要素名= "リソースリスト" > <XS：complexTypeの> <XS：配列のminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "リスト" タイプ= "listType（リストタイプ）" /> </ XS：配列> </ XS：complexTypeの> < / XS：要素> <XS：complexTypeの名前= "表示NAMETYPE"> <XS：simpleContentを> <XS：増設ベース= "XS：文字列"> <XS：属性REF = "XML：LANG" /> </ XS：拡張> </ XS：simpleContentを> </ XS：complexTypeの> </ XS：スキーマ>
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <リソース・リストののxmlns = "壷：IETF：のparams：XML：NS：リソース・リスト" のxmlns：XSI = "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ・インスタンス "> <リスト名=" 友人 "> <エントリーのURI =" SIP：bill@example.com "> <表示名>ビル・ドウ</表示名> </ 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>
<エントリー-REF REF = "リソース・リスト/ユーザー/ SIP：5bをbill@example.com/index/~~/リソース・リスト/リスト％5bとの@名=％22list1％22％5D /エントリ％@ URI =％ 22sip：ペットri@example.com%22%5d "/> <リスト名=" クローズ友人 "> <表示名>を閉じるフレンズ</表示名> <エントリURI =" SIP：joe@example.com "> <表示名>ジョー・スミス</表示名> </ entry>の<エントリーのURI =" SIP：nancy@example.com "> <表示名>ナンシーグロス</表示名> </ entry>の<外部アンカー= "http://xcap.example.org/resource-lists/users/一口：@ example.org /インデックス/ ~~ /リソース・リスト/リスト％5bの名=％の22mktiのNG％22％@ 5D "> <表示名>マーケティング</表示名> </外部> </リスト> </リスト> </資源リスト>
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.
IETF：：のparams：XML：NS：リソース・リストのURIの拡大に使用されるデフォルトの名前空間は、URNです。
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:
スキーマに加えて、<リスト>要素の「name」属性、<外部>要素の「URI」属性、「REF」の属性の<entry-ref>を中に存在する値に制約があります要素、および<外部>要素の「アンカー」属性。これらの制約は、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.
<リスト>の「name」属性Oエレメントは、同じ親要素内の<リスト>要素の他のすべての「名前」の属性の中でユニークでなければなりません。一意性は、大文字と小文字を区別した文字列の比較により決定されます。
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.
<エントリー>で「URI」属性Oエレメントは、同じ親要素内の<entry>要素の他のすべての「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の<entry-ref>要素の「参照」属性におけるURIは、同じ親要素内の<entry-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が文書中の<リスト>要素に解決されることを検証する責任はないことに注意してください。 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>、<エントリ-ref>を、または<外部>要素を削除したいでしょう。このような場合には、<entry>要素、「REF」の<entry-ref>要素の属性、または<外部>要素の「アンカー」属性の「URI」属性を選択するためのインデックスとして使用されます時に動作させるための要素。 XCAPサーバーは、大文字と小文字を区別する文字列比較によって一意性を決定します。しかし、これらの各属性は、URIを含んでいて、そのスキームのURI平等ルールは、大文字と小文字を区別文字列の比較によって異なる場合であっても、2つのURIが同じことを可能にすることができます。このように、クライアントがPUTをしようとしたり変更したり、既存の要素を削除しようとする試みをで削除することも可能です。代わりに、PUTは、新しい要素を挿入してしまい、またはDELETEはエラー応答を返してしまいます。
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を正規化すべきです。 （<entry>要素の「URI」属性にしばしば存在）のSIP URIの場合、この正規化手順は、第5節で定義されている私たちは、リソースリスト文書に置かれるのSIP URIは通常の形式のものであろうことを期待一口：ユーザパラメータをユーザー@ドメイン、および可能性があります。正規化ルールは、これらの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 URIの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良く形成しなければならないとXML文書にvalidaterに入手可能であり、適用可能な拡張スキーマを含むスキーマに従って有効でなければなりません[2]文書です。 RLSサービス文書はXML 1.0に基づいていなければならないとUTF-8を使用してエンコードされなければなりません。この仕様は、RLSサービス文書と文書の断片を識別するためのXML名前空間を使用しています。この仕様によって定義された要素の名前空間URIは、「IETF」ネームスペース識別子を使用してURN [3]は、RFC 2648によって定義された[6]、RFC 3688によって拡張[8]。このURNは以下のとおりです。
urn:ietf:params:xml:ns:rls-services
URN：IETF：のparams：XML：NS：RLS-サービス
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-サービス>です。これは、RLSにおいて利用可能なサービスを定義してその各々の<service>要素の配列を含みます。
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>要素で定義されたサービスを取得します、です。 <サービス>要素は、拡張性の目的のために他の名前空間からの属性を含めることができます。 <サービス>要素は、サービスを定義する子要素が含まれています。 RLSサービスの場合、非常に少ないサービス定義が必要とされている：ちょうどリソースリストをサーバが仮想サブスクリプション[14]やサービスがサポートするイベントパッケージのセットを実行する先。前者は、次のいずれかの方法で搬送することができます。リソース・リストのドキュメント内の<リスト>要素を指すの<resource-list>の要素が存在し得る、または直接リソースリストが含まれ、<リスト>要素が存在し得ます。サポートパッケージは、<パッケージ>要素に含まれています。 <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.
<リスト>要素は、リソースリストのスキーマで定義されたリスト型です。これは、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で参照される要素は、リソース・リストの文書内の<リスト>要素でなければなりません。 （参照整合性制約である）後者を除き、これらの制約のすべては、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"/>
<？xml version = "1.0" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：RLS-サービス" のxmlns：XSの= "のhttp：//www.w3 .ORG / 2001 / XMLスキーマ」のxmlns = "壷：IETF：のparams：XML：NS：RLS-サービス" のxmlns：RL = "壷：IETF：のparams：XML：NS：リソース・リスト" のelementFormDefault = "資格" attributeFormDefault = "修飾されていない"> <XS：要素名= "RLS-サービス"> <XS：complexTypeの> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "サービス" タイプ= "サービス種別" /> </ XS：シーケンス> </ XS：complexTypeの> </ XS：要素> <XS：complexTypeの名前= "サービス種別"> <XS：シーケンス> <XS：選択> <XS：要素名= "リソースリスト"タイプ=" XS：anyURIの "/> <XS：要素名=" リスト」タイプ= "RL：listType（リストタイプ）" /> </ XS：選択> <XS：要素名= "パッケージ" タイプ= "packagesType" のminOccurs = "0" /> <XS：任意の名前空間= "##他" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" />
</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>
</ XS：シーケンス> <XS：属性名= "URI" タイプ= "XS：anyURIの" 使用= "必須" /> <XS：anyAttributeは名前空間= "##他" のprocessContents = "緩い" /> </ XS ：complexTypeの> <XS：complexTypeの名= "packagesType"> <XS：シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <XS：要素名= "パッケージ" タイプ= "packageType" /> <XS：任意の名前空間= "##他の" のprocessContents = "緩い" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> </ XS：complexTypeの> <XS：単純型名= "packageType"> <XS：制限塩基= "XS：文字列" /> </ XS：単純> </ XS：スキーマ>
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つのサービスを示しています。一つは一口です：mybuddies@example.com、もう一方は一口です：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>
<？xml version = "1.0" エンコード= "UTF-8"？> <RLS-サービスのxmlns = "壷：IETF：のparams：XML：NS：RLS-サービス" のxmlns：RL = "壷：IETF：のparams：XML ：NS：リソース・リスト」のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> <サービスURI = "SIP：mybuddies@example.com"> <リソース・リスト>のhttp： //xcap.example.com/resource-lists/user S / SIP：ジョー@ example.com /インデックス/ ~~ /リソース・リスト/リスト％5bとの@ナムE =％22L1％22％5dと</リソースリスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> <サービスURI = "SIP：marketing@example.com"> <リスト名= "マーケティング"> <RL：エントリーのURI = "一口：joe@example.com "/> <RL：エントリのuri =" 一口：sudhir@example.com "/> </リスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> < / RLS-サービス>
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.
IETF：：のparams：XML：NS：RLS-サービスのURIの拡大に使用されるデフォルトの名前空間は、URNです。
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:
スキーマに加えて、<サービス>と<リソース・リスト>要素内に存在するURI上の制約があります。これらの制約は、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.
<サービス>の「URI」属性でURI Oエレメントは、特定のサーバ上の任意のドキュメント内の任意の<service>要素の「URI」の要素内の他のすべてのURIの中でユニークでなければなりません。この一意性制約は、XCAP根にまたがります。さらに、URIは、URIのドメイン内の既存のリソースに対応してはいけません。サーバがすでに存在するものにURIを設定するように要求される場合、サーバは409で要求を拒否し、まだ割り当てられていない代替URIを提案する[10]で定義されたメカニズムを使用しなければなりません。
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.
<リソース・リスト>でURI Oエレメントは、絶対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サービス文書は、順番に含むことができ、<リスト>要素、<エントリ>、<エントリ-REF>、<リスト>、および<外部>要素を含むことができます。 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.
friends@example.com：Oいくつかのケースでは、XCAPクライアントは、新しいRLSサービスを作成し、それをSIPなどの「虚栄心URI」を、割り当てることを望むだろう。ただし、クライアントは、このURIは、上記で定義された一意性制約を満たしているかどうか分かりません。その場合には、それは単に作成操作を試みることができ、その結果は、<一意性障害>要素で、詳細な競合レポートが含まれている409の場合、クライアントは、URIを割り当てることができなかったことを知っています。その後、別の虚栄心URIを再試行するか、詳細な競合レポートで提案のいずれかを使用することができます。
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.
クライアントが新しいRLSサービスを作成したい、それはURIが何であるかを気にしない場合は、O、クライアントはランダムなものを作成し、作成操作をしようとします。 [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サービス文書にアクセスする二つの異なるXCAPクライアントがあります。最初は、システム内のエンドユーザーに代わって動作するクライアントです。このクライアントは、編集して、彼らが作成したか、エンドユーザーによって変更されるリソースリストとRLSサービス文書の両方を書き込みます。他のXCAPクライアントは、SUBSCRIBEリクエストを処理するために、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:
特定のURIのための<サービス>要素を見つけるためのRLSのためにそれを容易にするために、XCAPサーバーは、グローバルツリー、すべてが作成したすべての文書全体のすべての<サービス>要素の和集合を表す単一のRLSサービス文書内、維持します同じXCAPルート内のユーザー。そこ本書の単一のインスタンスであり、その名は「インデックス」です。ルートサービスURIがhttp://xcap.example.comであればこのように、次のURIは、RLSは、このインデックスを取得するために使用するということです。
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>要素には、同じXCAPルート内のユーザドキュメント内に存在します。
As an example, consider the RLS services document for user sip:joe@example.com:
例として、ユーザーのSIPのためのRLSサービス文書を考えてみます。joe@example.comを：
<?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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <RLS-サービス> <サービスURI = "SIP：mybuddies@example.com"> <リソース・リスト> http://xcap.example.com /リソース・リスト/ユーザー/ SI P：ジョー@ example.com /インデックス/ ~~ /リソース・リスト/リスト％5bを@名=％22L1％22％5D </リソース・リスト> <パッケージ> <パッケージ>プレゼンス</パッケージ> </パッケージ> </サービス> </ RLS-サービス>
And consider the RLS services document for user bob:
そして、ユーザ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>
<？xmlのバージョン= "1.0" エンコード= "UTF-8"> <RLS-サービス> <サービスURI = "SIP：marketing@example.com"> <リスト名= "マーケティング"> <RL：エントリーのURI = "SIP：joe@example.com" /> <RL：エントリのuri = "一口：sudhir@example.com" /> </リスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> </ RLS-サービス>
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <RLS-サービスのxmlns = "壷：IETF：のparams：XML：NS：RLS-サービス" のxmlns：RL = "壷：IETF：のparams：XML ：NS：リソース・リスト」のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> <サービスURI = "SIP：mybuddies@example.com"> <リソース・リスト>のhttp： //xcap.example.com/resource-lists/user S / SIP：ジョー@ example.com /インデックス/ ~~ /リソース・リスト/リスト％5bとの@ナムE =％22L1％22％5dと</リソースリスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> <サービスURI = "SIP：marketing@example.com"> <リスト名= "マーケティング"> <RL：エントリーのURI = "一口：joe@example.com "/> <RL：エントリのuri =" 一口：sudhir@example.com "/> </リスト> <パッケージ> <パッケージ>存在</パッケージ> </パッケージ> </サービス> < / RLS-サービス>
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.
<サービス>の「URI」属性の一意性制約は、グローバル文書には2つの<サービス>要素は、その属性の同じ値を持っていないことを確認します。
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は、SUBSCRIBEリクエストの受信時に、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に存在する）のためのSUBSCRIBEリクエストを受信すると、それは、そのuri属性（URI平等に基づいて）試合URI SUBSCRIBEリクエストで、<service>要素を取得します。この文書では、これが達成される可能性がありますどのように何の規範的な発言を行うものではありません。次の段落は一つの可能なアプローチを提供します。
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.
セクション5で説明したようにRLSがRequest URIを正規化しその後[形「RLS-サービス/サービスのノードセレクタとグローバルインデックスのドキュメントセレクタとXCAPルートを組み合わせることにより形成されたURIに対してXCAP GETオペレーションを実行します@ URI = <正規の-URI>]」、ここで<正規の-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
<サービス>要素が得られたら、それを調べています。 <パッケージ>要素が存在し、そしてイベントパッケージSUBSCRIBE要求は、<パッケージ>内<パッケージ>要素に記載されたものの中でない場合に説明したように、要求は、489（不良イベント）応答コードで拒否されなければなりません[13]です。それ以外の場合は、処理されるべきです。次のステップでは、クライアントがリソースへの加入を許可されていることを許可することです。これは、例えば、[12]で定義されたデータを用いて行うことができます。加入者を仮定することは許可されています
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.
そのリソースにサブスクライブするために、サブスクリプションが[14]で定義された手順に従って処理されます。この処理は、に加入することになっているURIのフラットリストを計算するためにRLSが必要です。 <サービス>要素は、<リスト>要素を持っていた場合、それが抽出されます。 <サービス>要素は、<リソース・リスト>要素を持っていた場合、そのURIの内容が逆参照されます。結果は、<リスト>要素でなければなりません。そうでない場合、要求は502（不正なゲートウェイ）で拒否されるべきです。それ以外の場合は、その<リスト>要素が抽出されます。
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のフラットリストを得ることです。これを行うには、それは、<リスト>要素に根ざした要素のツリーを横断します。トラバースが始まる前に、RLSは、二つのリストを初期化します。すでに持っている<外部>要素にHTTP URIのリストが含まれてトラバースした後、URIのフラットなリストが含まれます「フラットリスト」、および「トラバースリスト」、訪れました。両方のリストは最初は空です。次に、ツリートラバーサルが開始されます。サーバーは、深さ優先探索や幅優先探索として、それが好き発注任意のツリートラバーサルを使用することができます。ツリー内の各要素の処理は、要素の名前によって異なります。
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].
要素は、それが既に存在しない場合、要素の「URI」属性内の<entry>、URIがそのリストに（大文字と小文字を区別した文字列の平等に基づいて）平坦なリストに追加され、そして場合O URIスキームを表します。サービスSIPなどのサブスクリプション、[4]、PRESに使用できる1つ[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に解決される要素である場合。これは、ベースURIとしてRLSサービス文書のXCAPルートを使用して、[7] RFC 3986のセクション5.2で定義された手順を使用して行われます。この絶対的なURIが解決されます。結果は<entry>要素を含む200 OKでない場合、SUBSCRIBEリクエストは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（不正なゲートウェイ）とのSUBSCRIBEリクエストを拒否すべきです。 URIが横断リストにない場合、サーバは横断リストにURIを追加し、URIを逆参照します。結果は、<list>の要素を含む200 OKでない場合、SUBSCRIBEリクエストは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.
ツリーがトラバースされたら[14]で定義されるように、RLSは、フラットリスト内の各URIに仮想サブスクリプションを作成することができます。 <エントリ-REF>または<外部>要素は解決できないの参照を含む上記で概説処理工程において、要求が失敗すると、SHOULD強度です。いくつかのケースでは、RLSは、できなかったものを省略し、得られたフラットリストでURIに仮想サブスクリプションを作成することによって、より良いサービスを提供することができます。ケースのみでSHOULD勧告を無視する必要があります。
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の正規化のための技術を提供します。この正規化は、ほとんどの場合、（等式は、RFC 3261でURI比較ルールに基づいている）元のURIに等しい、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.
まず、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パラメータが並べ替えられます。文字の順序は、小さい数字が最初に来ると、その文字のUS-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.
URIの一つは、RFC 3261で定義されていないURIパラメータが含まれている場合は、O、他にもありません。
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.
この仕様は、拡張から新しい要素または属性を配置することができ、明示的な場所を定義します。これらは明示的に<任意>と<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手順に従って二つの新しい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リソースに対するSUBSCRIBEリクエストを受信し、リソースリストに向けてサブスクリプションを作成することにより、セッション開始プロトコル（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 3023でRFC 4288 [9]の手順およびガイドラインに従って、2つの新しいMIMEタイプの登録を要求する[5]。
MIME media type name: application
MIMEメディアタイプ名：application
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].
オプションのパラメータ：[5] RFC 3023で指定され、application / xmlのcharsetパラメータと同じです。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[5]。
Security considerations: See Section 10 of RFC 3023 [5] and Section 7 of RFC 4826.
セキュリティの考慮事項：RFC 3023のセクション10 [5]および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].
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、ユーザーのリストにサブスクリプションをサポートするために使用されている[14] SIPベースのプレゼンスのための[11]。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .rl
ファイル拡張子：.rl
Macintosh file type code: "TEXT"
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
詳しくは、個人やメールアドレス：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: The IETF.
著者/変更コントローラ：IETF。
MIME media type name: application
MIMEメディアタイプ名：application
MIME subtype name: rls-services+xml
MIMEサブタイプ名：RLS-サービス+ xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [5].
オプションのパラメータ：[5] RFC 3023で指定され、application / xmlのcharsetパラメータと同じです。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
符号化の考慮事項：アプリケーション/ XMLの符号化の考慮と同じRFC 3023に指定されている[5]。
Security considerations: See Section 10 of RFC 3023 [5] and Section 7 of RFC 4826.
セキュリティの考慮事項：RFC 3023のセクション10 [5]および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].
このメディアタイプを使用するアプリケーション：このドキュメントタイプは、ユーザーのリストにサブスクリプションをサポートするために使用されている[14] SIPベースのプレゼンスのための[11]。
Additional Information:
追加情報：
Magic Number: none
マジックナンバー：なし
File Extension: .rs
ファイル拡張子：.RS
Macintosh file type code: "TEXT"
Macintoshのファイルタイプコード：「TEXT」
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
詳しくは、個人やメールアドレス：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.net
Intended usage: COMMON
意図している用法：COMMON
Author/Change controller: The IETF.
著者/変更コントローラ：IETF。
This section registers two new XML namespaces, as per the guidelines in RFC 3688 [8].
このセクションでは、[8] RFC 3688のガイドラインに従って、二つの新しいXML名前空間を登録します。
URI: The URI for this namespace is urn:ietf:params:xml:ns:resource-lists.
URI：IETF：：のparams：XML：NS：リソース・リストこの名前空間のURIはURNです。
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>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
！XML：BEGIN <？xmlのバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/ XHTML-basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset =リソースリストのISO-8859-1" /> <タイトル>リソースリストの名前空間</ TITLE> </ HEAD> <BODY> <H1>名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：リソース - リスト</ H2> <P> <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：IETF：：のparams：XML：NS：RLS-サービスこの名前空間のURIはURNです。
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>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
！XML：BEGIN <？xmlのバージョン= "1.0"> <DOCTYPE用HTML PUBLIC " - // W3C // DTD XHTML Basicの1.0 // EN"「http://www.w3.org/TR/xhtml-basic/ XHTML-basic10.dtd "> <HTMLのxmlns =" http://www.w3.org/1999/xhtml "> <HEAD> <META HTTP-当量=" コンテンツタイプ "コンテンツ=" text / htmlの;のcharset = ISO-8859-1" /> <タイトル>リソースリストサーバ（RLS）サービス名前空間</ TITLE> </ HEAD> <BODY> <H1>リソースリストサーバ（RLS）サービスのための名前空間</ H1> <H2> URN ：IETF：のparams：XML：NS：RLS-サービス</ H2> <P> <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
URI：URN：IETF：のparams：XML：スキーマ：リソース・リスト
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（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
URI：URN：IETF：のparams：XML：スキーマ：RLS-サービス
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
登録者連絡先：IETF、SIMPLEワーキンググループ、（simple@ietf.org）、ジョナサン・ローゼンバーグ（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.
作者は彼らのコメントを入力するためにヒシャムKhartabil、ヤリUrpalainen、およびスペンサードーキンスに感謝したいと思います。この作品の彼の励ましと支援のためのテッド・ハーディーに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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]パオリ、J.、MALER、E.、ブレイ、T.、およびC. Sperberg-マックイーン、 "拡張マークアップ言語（XML）1.0（第二版）"、ワールドワイドウェブコンソーシアム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]堀、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[5] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[5]村田、M.、サンローラン、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
[6] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[6]堀、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、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]フリード、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]ローゼンバーグ、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]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
[12] Rosenberg, J., "Presence Authorization Rules", Work in Progress, October 2006.
[12]ローゼンバーグ、J.、 "プレゼンス認証ルール"、進歩、2006年10月に作業。
[13] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[13]ローチ、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]ローチ、A.、ローゼンバーグ、J.、およびB.キャンベル、 "リソースリストのAのセッション開始プロトコル（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
ジョナサン・ローゼンバーグシスコエジソン、NJ US
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
電子メール：jdrosen@cisco.com URI：http://www.jdrosen.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。