Network Working Group J. Rosenberg
Request for Comments: 4826 Cisco
Category: Standards Track May 2007
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）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).
在多媒体通信、状态和即时消息系统中，需要定义表示与一组用户相关联的服务的统一资源标识符（URI）。一个例子是资源列表服务。如果用户向表示资源列表服务的URI发送会话发起协议（SIP）订阅消息，服务器将获取相关组中用户的状态，并将其提供给发送方。为了便于定义这些服务，本规范定义了两个可扩展标记语言（XML）文档。一个文档包含服务URI，以及它们的服务定义和对关联用户组的引用。第二个文档包含从第一个文档引用的用户列表。此用户列表可供其他应用程序和服务使用。这两个文档都可以使用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
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
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). SIPURI还可以表示服务，例如语音邮件、会议或状态列表。跨此类SIP服务的一种常见模式是定义服务并将其与URI关联。为了运行，该服务需要使用用户列表（或者更一般地说，资源列表）。当SIP请求发送到服务URI时，提供服务的服务器读取该列表，然后对列表上的每个资源执行某种操作。这如图1所示。
/---\
| |
\---/ Resource
+----| | List
| | |
| \---/
|
|
|
|
V
+-------------+
| | -------->
| SIP |
---------------> | Service | -------->
service | |
URI | | -------->
+-------------+
/---\
| |
\---/ 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
这种服务的一个重要示例是存在[11]列表服务。状态列表服务允许客户端生成SIP订阅请求，以请求用户列表的状态信息。状态列表服务器为列表上的用户获取状态，并将其返回给客户端。出席名单
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.
服务器是资源列表服务器（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.
这种服务的另一个例子是即时会议服务。如果客户端向表示实例会议服务的URI发送SIP 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.
对于这些系统的用户来说，与访问这些资源列表的服务分开定义用户或资源组（通常称为资源列表）是非常有用的。事实上，即使在没有任何相关的基于网络的服务的情况下，也存在资源列表的用法。例如，客户机可能会生成单独的订阅请求，以获取本地存储的状态列表中每个用户的状态，而不是使用状态列表服务。在这种情况下，需要一种将列表本地存储在磁盘上的格式。此外，用户可能希望与朋友共享该列表，并希望通过电子邮件将其发送给这些朋友。这还需要资源列表的标准格式。
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.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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
资源列表文档是一个XML[2]文档，它必须格式良好，并且根据模式（包括扩展模式）必须有效，可供验证程序使用，并且适用于XML文档。资源列表文档必须基于XML 1.0，并且必须使用UTF-8进行编码。该规范使用XML名称空间来标识资源列表文档和文档片段。此定义的元素的命名空间URI
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:
规范是一个URN[3]，它使用由RFC 2648[6]定义并由RFC 3688[8]扩展的名称空间标识符“ietf”。这个骨灰盒是：
urn:ietf:params:xml:ns:resource-lists
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.
资源列表文档具有<resource lists>元素作为文档的根元素。此元素没有属性。它的内容是由零个或多个<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>元素都可以包含可选的“name”属性。此属性是列表的句柄。当存在时，它必须在同一父元素中的所有其他<list>元素中唯一。出于可扩展性的目的，<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.
每个<list>元素由一个可选的显示名称、一系列零个或多个元素组成，每个元素可以是<entry>元素、<list>元素、<entry ref>元素或<external>元素，然后是来自其他名称空间的任意数量的元素，以实现可扩展性。<list>元素包含其他<list>元素的能力意味着资源列表可以是层次结构的。然后，<display name>允许人类友好的名称与层次结构中的每个级别相关联。元素描述由URI定义的单个资源，该资源是列表的一部分。<entry ref>元素允许通过引用而不是通过值包含同一XCAP根目录中文档中的条目。<external>元素包含对存储在此或其他服务器上的列表的引用。
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服务将需要表示可订阅资源的URI。这包括SIP和pres[15]URI。“uri”属性在同一父元素的<entry>元素中的所有其他“uri”属性中必须是唯一的。唯一性由区分大小写的字符串比较确定。因此，当使用为该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
<entry>元素包含一系列元素，这些元素提供有关该条目的信息。此时仅定义了一个这样的元素
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.
这次是<display name>。该元素提供一个UTF-8编码的字符串，用于描述资源，供人类用户使用。与<entry>元素的“name”属性不同，<display name>没有唯一性要求。<display name>元素可以包含“xml:lang”属性，该属性提供显示名称的语言。<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>元素有一个强制属性“ref”。“ref”属性必须在同一父元素的<entry ref>元素中的所有其他“ref”属性中唯一。唯一性由区分大小写的字符串比较确定。出于可扩展性的目的，<entry ref>元素还允许来自其他名称空间的属性。出于可扩展性的目的，<entry ref>元素的内容是一个可选的显示名称，后跟来自其他名称空间的任意数量的元素。显示名称可用于提供本地化昵称，作为<entry ref>引用的<entry>中定义的名称的替代。
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等于出现<entry ref>的文档的XCAP根URI。如果根据RFC3986中的过程将此相对URI解析为绝对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/
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，那么指向该条目的<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"/>
<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.
<external>元素类似于<entry ref>元素。与<entry ref>类似，它仅在从XCAP服务器获取的文档中有意义。它也是对存储在别处的内容的引用。但是，它引用了一个完整的列表，而且，它允许该列表出现在另一台服务器上。<external>元素有一个强制属性“anchor”，它通过一个绝对HTTP URI指定外部列表。“锚定”属性必须在同一父元素的<external>元素中的所有其他“锚定”属性中唯一。唯一性由区分大小写的字符串比较确定。出于可扩展性的目的，<external>元素还可以包含来自其他名称空间的属性。出于可扩展性的目的，<external>元素的内容是可选的<display name>，后跟来自另一名称空间的任意数量的元素。“anchor”属性的值必须是绝对HTTP URI。此URI必须标识一个XCAP资源，特别是它必须表示资源列表文档中的<list>元素。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>和<external>元素，解决其引用的责任落在使用文档的实体身上。当文档与XCAP一起使用时，这意味着负担落在XCAP客户机上。如果XCAP客户端是一个基于PC的应用程序，使用resource list文档作为状态列表，则引用可能会在用户明确请求时解析。当然，它们可以在任何时候得到解决。如果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>
<?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>
<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>
<?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>
<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 list。
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:
除了模式之外，<list>元素的“name”属性、<external>元素的“uri”属性、<entry ref>元素的“ref”属性和<external>元素的“anchor”属性中存在的值也有约束。这些约束在第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>元素中的“name”属性在同一父元素中的<list>元素的所有其他“name”属性中必须是唯一的。唯一性由区分大小写的字符串比较确定。
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 <entry>元素中的“uri”属性必须在同一父元素中<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>元素的“ref”属性中的URI在同一父元素中的<entry 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 <external>元素的“锚定”属性中的URI必须在同一父元素中的<external>元素的所有其他“锚定”属性中唯一。唯一性由区分大小写的字符串比较确定。该属性的值必须是绝对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>、<entry ref>或<external>元素。在这种情况下，<entry>元素的“uri”属性、<entry ref>元素的“ref”属性或<external>元素的“anchor”属性被用作选择要操作的元素的索引。XCAP服务器将通过区分大小写的字符串比较来确定唯一性。但是，这些属性中的每一个都包含URI，并且它们的方案的URI相等规则可能允许两个URI相同，即使它们通过区分大小写的字符串比较不同。因此，客户机可能会尝试放置或删除以修改或删除现有元素。相反，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。对于SIPURI（通常出现在<entry>元素的“URI”属性中），此规范化过程在第5节中定义。我们预计，将放入资源列表文档中的SIP URI通常采用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 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服务文档用于定义URI，这些URI表示[14]中定义的资源列表服务器（RLS）提供的服务。RLS服务文档是一个XML[2]文档，它必须格式良好，并且根据模式（包括扩展模式）必须有效，可供验证程序使用，并且适用于XML文档。RLS服务文档必须基于XML 1.0，并且必须使用UTF-8进行编码。本规范使用XML名称空间来标识RLS服务文档和文档片段。本规范定义的元素的名称空间URI是一个URN[3]，它使用RFC 2648[6]定义并由RFC 3688[8]扩展的名称空间标识符“ietf”。这个骨灰盒是：
urn:ietf:params:xml:ns:rls-services
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]和服务支持的事件包集。前者可以通过两种方式之一传达。可以有一个<resource list>元素，它指向资源列表文档中的<list>元素，也可以有一个<list>元素，它直接包含资源列表。受支持的包包含在<packages>元素中。出于可扩展性的目的，<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服务定义中变得“隐藏”，并且不可由其他应用程序使用。由于这个原因，<resource list>元素作为一个替代元素存在。它可以引用资源列表文档中的<list>元素。由于该列表与服务定义分离，因此其他应用程序可以轻松地重用它。
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.
<resource list>元素包含一个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.
<packages>元素包含一系列<package>元素。每个<package>元素的内容是SIP事件包的名称[13]。出于可扩展性的目的，<packages>元素还可以包含来自其他名称空间的元素。<packages>元素是可选的。如果不存在，则表示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" 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>
</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.
本文档显示了两个服务。一个是sip：mybuddies@example.com，另一个是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>
<?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（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服务。
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>和<resource list>元素中还存在对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.
o <service>元素的“URI”属性中的URI必须在特定服务器上任何文档中任何<service>元素的“URI”元素中的所有其他URI中唯一。此唯一性约束跨越XCAP根。此外，URI不能对应于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
o <resource list>元素中的URI必须是绝对URI。服务器必须验证URI路径在与AUID对应的路径段中是否包含“资源列表”。如果RLS服务文档位于XCAP用户树（与全局树相反）内，则服务器必须验证路径中的XUI是否相同
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中的XUI添加到RLS服务文档。这些检查是通过检查URI值进行的，而不是取消对URI的引用。服务器不负责验证URI是否实际指向有效资源列表文档中的<list>元素。
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服务文档可以包含<list>元素，而该元素又可以包含<entry>、<entry ref>、<list>和<external>元素。必须执行第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服务，并希望为其分配一个“虚拟URI”，例如sip：friends@example.com. 但是，客户端不知道此URI是否满足上面定义的唯一性约束。在这种情况下，它可以简单地尝试创建操作，如果结果是一个409，其中包含一个带有<university failure>元素的详细冲突报告，那么客户端知道无法分配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.
o 如果客户端希望创建一个新的RLS服务，并且它不关心URI是什么，那么客户端将创建一个随机的RLS服务，并尝试创建操作。如[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.
通常，有两个不同的XCAP客户端访问RLS服务文档。第一个是代表系统中最终用户的客户端。此客户端在最终用户创建或修改资源列表和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
为了让RLS更容易找到特定URI的<service>元素，XCAP服务器在全局树中维护一个RLS服务文档，表示所有用户在同一XCAP根目录中创建的所有文档中所有<service>元素的联合。此文档只有一个实例，其名称为“索引”。因此，如果根服务URI是
http://xcap.example.com, the following is the URI that an RLS would use to fetch this index:
http://xcap.example.com，以下是RLS用于获取此索引的URI：
http://xcap.example.com/rls-services/global/index
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:
如下文所述，此索引是从用户树中名称为“index”的所有文档创建的。这意味着代表用户操作的客户端应该在名为“index”的文档中定义其RLS服务。如果根服务URI为http://xcap.example.com，对于用户“sip:joe@example.com“此文档的URI为：
http://xcap.example.com/rls-services/users/sip:joe@example.com/index
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.
此应用程序用法定义了全局树中的单个文档与名为“index”的用户树中的所有文档之间的额外资源相互依赖关系。此全局文档由同一XCAP根目录中所有用户的所有索引文档的联合组成。在这种情况下，union操作意味着用户文档中的每个<service>元素也将作为<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 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:
并考虑用户鲍伯的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 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>
<?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”属性上的唯一性约束将确保全局文档中没有两个<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.
全局树中维护的索引文档表示敏感信息，因为它包含服务器上所有用户的所有信息的联合。因此，必须将其访问权限限制为服务器域内的受信任元素。通常，这将限于需要访问此文档的RLS。
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相等）的<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.
RLS规范化请求URI，如第5节所述。然后，它对通过将XCAP根目录与全局索引的文档选择器与形式为“rls services/service[@URI=<canonical URI>]”的节点选择器相结合而形成的URI执行XCAP GET操作，其中<canonical URI>是请求URI的规范化版本。如果响应是200OK，它将包含该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
一旦获得<service>元素，就会对其进行检查。如果存在<packages>元素，并且订阅请求中的事件包不在<packages>中的<package>元素中，则必须使用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]中定义的过程处理订阅。此处理要求RL计算要订阅的URI的平面列表。如果<service>元素具有<list>元素，则将提取该元素。如果<service>元素具有<resource 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拥有一个<list>元素。下一步是从该元素获取URI的平面列表。为此，它遍历<list>元素中的根元素树。在遍历开始之前，RLS初始化两个列表：“平面列表”将包含遍历后URI的平面列表，“遍历列表”包含已访问的<external>元素中的httpuri列表。两个列表最初都是空的。接下来，开始树遍历。服务器可以使用它喜欢的任何树遍历顺序，例如深度优先搜索或广度优先搜索。树中每个元素的处理取决于元素的名称：
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 如果元素是<entry>，则如果元素的“URI”属性中的URI在该列表中不存在（基于区分大小写的字符串相等），则该URI将添加到平面列表中，并且URI方案表示可用于服务订阅的URI方案，例如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。这是使用RFC 3986[7]第5.2节中定义的过程完成的，使用RLS服务文档的XCAP根作为基本URI。此绝对URI已解析。如果结果不是包含<entry>元素的200ok，则应使用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 如果元素是<external>元素，则检查构成元素“anchor”属性值的绝对URI。如果URI在遍历列表上，服务器必须停止遍历树，并应使用502（坏网关）拒绝订阅请求。如果URI不在遍历列表中，服务器会将URI添加到遍历列表中，并取消对URI的引用。如果结果不是包含<list>元素的200ok，则应使用502（坏网关）拒绝订阅请求。否则，RLS将用返回的<list>元素替换树的本地副本中的<external>元素，并继续树遍历。
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.
由于<external>元素用于动态构造树，因此有可能对引用进行递归计算。遍历列表用于防止发生这种情况。
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就可以创建对平面列表中每个URI的虚拟订阅，如[14]中所定义。在上面概述的处理步骤中，当<entry ref>或<external>元素包含无法解析的引用时，请求失败的可能性很大。在某些情况下，RLS可以通过在平面列表中创建可以获得的uri的虚拟订阅来提供更好的服务，而忽略那些不能获得的。只有在这些情况下，才应忽略该建议。
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规范化的技术。这种规范化生成的URI在大多数情况下与原始URI相等（其中相等性基于RFC3261中的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.
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参数进行重新排序，以便它们根据参数名按词法顺序出现。字符的顺序由该字符的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:
如果两个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包含RFC3261中未定义的URI参数，那么另一个URI也包含该参数。
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过程注册两个新的XCAP应用程序唯一ID（AUID）。
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]中的指南注册两种新的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]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
编码注意事项：与RFC 3023[5]中指定的应用程序/xml的编码注意事项相同。
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]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [5].
编码注意事项：与RFC 3023[5]中指定的应用程序/xml的编码注意事项相同。
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].
本节根据RFC3688[8]中的指南注册了两个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:resource-lists.
URI：此命名空间的URI是urn:ietf:params:xml:ns:resource list。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(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 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服务。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(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 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]中的过程注册两个XML模式。
URI: urn:ietf:params:xml:schema:resource-lists
URI: urn:ietf:params:xml:schema:resource-lists
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(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:schema:rls-services
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(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.
作者要感谢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（第二版）”，万维网联盟第一版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.，“瓮语法”，RFC 21411997年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：会话启动协议”，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媒体类型”，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）：通用语法”，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）”，RFC4825，2007年5月。
[11] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[11] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，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）-特定事件通知”，RFC3265，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
Jonathan Rosenberg Cisco Edison，美国新泽西州
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。