Network Working Group J. Rosenberg
Request for Comments: 4825 Cisco
Category: Standards Track May 2007
Network Working Group J. Rosenberg
Request for Comments: 4825 Cisco
Category: Standards Track May 2007
The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
可扩展标记语言（XML）配置访问协议（XCAP）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This specification defines the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP allows a client to read, write, and modify application configuration data stored in XML format on a server. XCAP maps XML document sub-trees and element attributes to HTTP URIs, so that these components can be directly accessed by HTTP.
本规范定义了可扩展标记语言（XML）配置访问协议（XCAP）。XCAP允许客户端读取、写入和修改以XML格式存储在服务器上的应用程序配置数据。XCAP将XML文档子树和元素属性映射到HTTP URI，以便HTTP可以直接访问这些组件。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Application Usages . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 7
5.2. Default Document Namespace . . . . . . . . . . . . . . . . 8
5.3. Data Validation . . . . . . . . . . . . . . . . . . . . . 9
5.4. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 11
5.6. Resource Interdependencies . . . . . . . . . . . . . . . . 11
5.7. Authorization Policies . . . . . . . . . . . . . . . . . . 12
5.8. Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
5.9. Documenting Application Usages . . . . . . . . . . . . . . 13
5.10. Guidelines for Creating Application Usages . . . . . . . . 13
6. URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Document Selector . . . . . . . . . . . . . . . . . . . . 16
6.3. Node Selector . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Namespace Bindings for the Selector . . . . . . . . . . . 23
7. Client Operations . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Create or Replace a Document . . . . . . . . . . . . . . . 26
7.2. Delete a Document . . . . . . . . . . . . . . . . . . . . 26
7.3. Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
7.4. Create or Replace an Element . . . . . . . . . . . . . . . 26
7.5. Delete an Element . . . . . . . . . . . . . . . . . . . . 29
7.6. Fetch an Element . . . . . . . . . . . . . . . . . . . . . 30
7.7. Create or Replace an Attribute . . . . . . . . . . . . . . 30
7.8. Delete an Attribute . . . . . . . . . . . . . . . . . . . 31
7.9. Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. POST Handling . . . . . . . . . . . . . . . . . . . . . . 35
8.2. PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
8.2.1. Locating the Parent . . . . . . . . . . . . . . . . . 35
8.2.2. Verifying Document Content . . . . . . . . . . . . . . 36
8.2.3. Creation . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.4. Replacement . . . . . . . . . . . . . . . . . . . . . 41
8.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . 42
8.2.6. Conditional Processing . . . . . . . . . . . . . . . . 43
8.2.7. Resource Interdependencies . . . . . . . . . . . . . . 44
8.3. GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. DELETE Handling . . . . . . . . . . . . . . . . . . . . . 45
8.5. Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Application Usages . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 7
5.2. Default Document Namespace . . . . . . . . . . . . . . . . 8
5.3. Data Validation . . . . . . . . . . . . . . . . . . . . . 9
5.4. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 10
5.5. Naming Conventions . . . . . . . . . . . . . . . . . . . . 11
5.6. Resource Interdependencies . . . . . . . . . . . . . . . . 11
5.7. Authorization Policies . . . . . . . . . . . . . . . . . . 12
5.8. Data Extensibility . . . . . . . . . . . . . . . . . . . . 12
5.9. Documenting Application Usages . . . . . . . . . . . . . . 13
5.10. Guidelines for Creating Application Usages . . . . . . . . 13
6. URI Construction . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. XCAP Root . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Document Selector . . . . . . . . . . . . . . . . . . . . 16
6.3. Node Selector . . . . . . . . . . . . . . . . . . . . . . 18
6.4. Namespace Bindings for the Selector . . . . . . . . . . . 23
7. Client Operations . . . . . . . . . . . . . . . . . . . . . . 24
7.1. Create or Replace a Document . . . . . . . . . . . . . . . 26
7.2. Delete a Document . . . . . . . . . . . . . . . . . . . . 26
7.3. Fetch a Document . . . . . . . . . . . . . . . . . . . . . 26
7.4. Create or Replace an Element . . . . . . . . . . . . . . . 26
7.5. Delete an Element . . . . . . . . . . . . . . . . . . . . 29
7.6. Fetch an Element . . . . . . . . . . . . . . . . . . . . . 30
7.7. Create or Replace an Attribute . . . . . . . . . . . . . . 30
7.8. Delete an Attribute . . . . . . . . . . . . . . . . . . . 31
7.9. Fetch an Attribute . . . . . . . . . . . . . . . . . . . . 31
7.10. Fetch Namespace Bindings . . . . . . . . . . . . . . . . . 32
7.11. Conditional Operations . . . . . . . . . . . . . . . . . . 32
8. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. POST Handling . . . . . . . . . . . . . . . . . . . . . . 35
8.2. PUT Handling . . . . . . . . . . . . . . . . . . . . . . . 35
8.2.1. Locating the Parent . . . . . . . . . . . . . . . . . 35
8.2.2. Verifying Document Content . . . . . . . . . . . . . . 36
8.2.3. Creation . . . . . . . . . . . . . . . . . . . . . . . 37
8.2.4. Replacement . . . . . . . . . . . . . . . . . . . . . 41
8.2.5. Validation . . . . . . . . . . . . . . . . . . . . . . 42
8.2.6. Conditional Processing . . . . . . . . . . . . . . . . 43
8.2.7. Resource Interdependencies . . . . . . . . . . . . . . 44
8.3. GET Handling . . . . . . . . . . . . . . . . . . . . . . . 44
8.4. DELETE Handling . . . . . . . . . . . . . . . . . . . . . 45
8.5. Managing Etags . . . . . . . . . . . . . . . . . . . . . . 46
9. Cache Control . . . . . . . . . . . . . . . . . . . . . . . . 47
10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
11. Detailed Conflict Reports . . . . . . . . . . . . . . . . . . 47
11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 50
12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
12.3. Default Document Namespace . . . . . . . . . . . . . . . . 56
12.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 56
12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 56
12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14. Security Considerations . . . . . . . . . . . . . . . . . . . 59
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
15.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 60
15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
15.2.1. application/xcap-el+xml MIME Type . . . . . . . . . . 61
15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
15.2.3. application/xcap-ns+xml MIME Type . . . . . . . . . . 63
15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
15.2.5. application/xcap-caps+xml MIME Type . . . . . . . . . 64
15.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 65
15.3.1. urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . 65
15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
15.4.2. XCAP Capabilities Schema Registration . . . . . . . . 67
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
17.1. Normative References . . . . . . . . . . . . . . . . . . . 67
17.2. Informative References . . . . . . . . . . . . . . . . . . 69
10. Namespace Binding Format . . . . . . . . . . . . . . . . . . . 47
11. Detailed Conflict Reports . . . . . . . . . . . . . . . . . . 47
11.1. Document Structure . . . . . . . . . . . . . . . . . . . . 48
11.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 50
12. XCAP Server Capabilities . . . . . . . . . . . . . . . . . . . 53
12.1. Application Unique ID (AUID) . . . . . . . . . . . . . . . 54
12.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 54
12.3. Default Document Namespace . . . . . . . . . . . . . . . . 56
12.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 56
12.5. Validation Constraints . . . . . . . . . . . . . . . . . . 56
12.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 56
12.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 56
12.8. Resource Interdependencies . . . . . . . . . . . . . . . . 56
12.9. Authorization Policies . . . . . . . . . . . . . . . . . . 56
13. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
14. Security Considerations . . . . . . . . . . . . . . . . . . . 59
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 60
15.1. XCAP Application Unique IDs . . . . . . . . . . . . . . . 60
15.2. MIME Types . . . . . . . . . . . . . . . . . . . . . . . . 61
15.2.1. application/xcap-el+xml MIME Type . . . . . . . . . . 61
15.2.2. application/xcap-att+xml MIME Type . . . . . . . . . . 62
15.2.3. application/xcap-ns+xml MIME Type . . . . . . . . . . 63
15.2.4. application/xcap-error+xml MIME Type . . . . . . . . . 64
15.2.5. application/xcap-caps+xml MIME Type . . . . . . . . . 64
15.3. URN Sub-Namespace Registrations . . . . . . . . . . . . . 65
15.3.1. urn:ietf:params:xml:ns:xcap-error . . . . . . . . . . 65
15.3.2. urn:ietf:params:xml:ns:xcap-caps . . . . . . . . . . . 66
15.4. XML Schema Registrations . . . . . . . . . . . . . . . . . 67
15.4.1. XCAP Error Schema Registration . . . . . . . . . . . . 67
15.4.2. XCAP Capabilities Schema Registration . . . . . . . . 67
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 67
17.1. Normative References . . . . . . . . . . . . . . . . . . . 67
17.2. Informative References . . . . . . . . . . . . . . . . . . 69
In many communications applications, such as Voice over IP, instant messaging, and presence, it is necessary for network servers to access per-user information in the process of servicing a request. This per-user information resides within the network, but is managed by the end user themselves. Its management can be done through a multiplicity of access points, including the web, a wireless handset, or a PC application.
在许多通信应用程序中，如IP语音、即时消息和状态，网络服务器必须在为请求提供服务的过程中访问每个用户的信息。此每用户信息驻留在网络中，但由最终用户自己管理。它的管理可以通过多种接入点来完成，包括web、无线手持设备或PC应用程序。
There are many examples of per-user information. One is presence [20] authorization policy, which defines rules about which watchers are allowed to subscribe to a presentity, and what information they are allowed to access. Another is presence lists, which are lists of users whose presence is desired by a watcher [26]. One way to obtain presence information for the list is to subscribe to a resource which represents that list [21]. In this case, the Resource List Server (RLS) requires access to this list in order to process a SIP [16] SUBSCRIBE [28] request for it. Another way to obtain presence for the users on the list is for a watcher to subscribe to each user individually. In that case, it is convenient to have a server store the list, and when the client boots, it fetches the list from the server. This would allow a user to access their resource lists from different clients.
每个用户的信息有很多例子。一个是presence[20]授权策略，它定义了关于允许哪些观察者订阅presence实体以及允许他们访问哪些信息的规则。另一种是状态列表，它是观察者需要其状态的用户列表[26]。获取列表状态信息的一种方法是订阅表示该列表的资源[21]。在这种情况下，资源列表服务器（RLS）需要访问该列表，以便为其处理SIP[16]订阅[28]请求。为列表上的用户获取状态的另一种方法是让观察者单独订阅每个用户。在这种情况下，让服务器存储列表是很方便的，当客户端启动时，它会从服务器获取列表。这将允许用户从不同的客户端访问其资源列表。
This specification describes a protocol that can be used to manipulate this per-user data. It is called the Extensible Markup Language (XML) Configuration Access Protocol (XCAP). XCAP is a set of conventions for mapping XML documents and document components into HTTP URIs, rules for how the modification of one resource affects another, data validation constraints, and authorization policies associated with access to those resources. Because of this structure, normal HTTP primitives can be used to manipulate the data. XCAP is based heavily on ideas borrowed from the Application Configuration Access Protocol (ACAP) [25], but it is not an extension of it, nor does it have any dependencies on it. Like ACAP, XCAP is meant to support the configuration needs for a multiplicity of applications, rather than just a single one.
本规范描述了一种协议，可用于处理此每用户数据。它被称为可扩展标记语言（XML）配置访问协议（XCAP）。XCAP是一组约定，用于将XML文档和文档组件映射到httpuri、修改一个资源如何影响另一个资源的规则、数据验证约束以及与访问这些资源相关的授权策略。由于这种结构，可以使用普通的HTTP原语来操作数据。XCAP在很大程度上借鉴了应用程序配置访问协议（ACAP）[25]的思想，但它不是它的扩展，也没有任何依赖性。与ACAP一样，XCAP旨在支持多种应用程序的配置需求，而不仅仅是单个应用程序。
XCAP was not designed as a general purpose XML search protocol, XML database update protocol, nor a general purpose, XML-based configuration protocol for network elements.
XCAP不是作为通用XML搜索协议、XML数据库更新协议设计的，也不是用于网络元素的基于XML的通用配置协议。
Each application (where an application refers to a use case that implies a collection of data and associated semantics) that makes use of XCAP specifies an application usage (Section 5). This application usage defines the XML schema [2] for the data used by the application, along with other key pieces of information. The principal task of XCAP is to allow clients to read, write, modify, create, and delete pieces of that data. These operations are supported using HTTP/1.1 [6]. An XCAP server acts as a repository for collections of XML documents. There will be documents stored for each application. Within each application, there are documents stored for each user. Each user can have a multiplicity of documents for a particular application. To access some component of one of those documents, XCAP defines an algorithm for constructing a URI that can be used to reference that component. Components refer to any element or attribute within the document. Thus, the HTTP URIs used by XCAP point to a document, or to pieces of information that are finer grained than the XML document itself. An HTTP resource that follows the naming conventions and validation constraints defined here is called an XCAP resource.
使用XCAP的每个应用程序（其中应用程序引用一个暗示数据和相关语义集合的用例）指定一个应用程序用法（第5节）。此应用程序用法为应用程序使用的数据以及其他关键信息定义XML模式[2]。XCAP的主要任务是允许客户端读取、写入、修改、创建和删除这些数据。使用HTTP/1.1[6]支持这些操作。XCAP服务器充当XML文档集合的存储库。将为每个应用程序存储文档。在每个应用程序中，都为每个用户存储了文档。对于特定的应用程序，每个用户可以有多个文档。为了访问其中一个文档的某个组件，XCAP定义了一个算法，用于构造可用于引用该组件的URI。组件是指文档中的任何元素或属性。因此，XCAP使用的HTTP URI指向一个文档，或者指向比XML文档本身更细粒度的信息片段。遵循此处定义的命名约定和验证约束的HTTP资源称为XCAP资源。
Since XCAP resources are also HTTP resources, they can be accessed using HTTP methods. Reading an XCAP resource is accomplished with HTTP GET, creating or modifying one is done with HTTP PUT, and removing one of the resources is done with an HTTP DELETE. XCAP resources do not represent processing scripts; as a result, POST operations to HTTP URIs representing XCAP resources are not defined. Properties that HTTP associates with resources, such as entity tags, also apply to XCAP resources. Indeed, entity tags are particularly useful in XCAP, as they allow a number of conditional operations to be performed.
由于XCAP资源也是HTTP资源，因此可以使用HTTP方法访问它们。读取XCAP资源是通过HTTP GET完成的，创建或修改资源是通过HTTP PUT完成的，删除一个资源是通过HTTP DELETE完成的。XCAP资源不代表处理脚本；因此，未定义表示XCAP资源的HTTP URI的POST操作。HTTP与资源关联的属性（如实体标记）也适用于XCAP资源。实际上，实体标记在XCAP中特别有用，因为它们允许执行许多条件操作。
XML documents that are equivalent for the purposes of many applications may differ in their physical representation. With XCAP resources, the canonical form with comments [19] of an XML document determines the logical equivalence. In other words, the canonical specification determines how significant whitespace MUST be processed. It also implies that, for example, new inserted attributes may appear in any order within the physical representation.
对于许多应用程序来说是等效的XML文档，其物理表示形式可能有所不同。对于XCAP资源，XML文档的带有注释[19]的规范形式决定了逻辑等价性。换句话说，规范化规范决定了必须处理多少重要的空白。它还意味着，例如，新插入的属性可能以任何顺序出现在物理表示中。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [7] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[7]中所述进行解释，并指明符合性实施的要求级别。
The following terms are used throughout this document:
本文件中使用了以下术语：
XCAP Resource: An HTTP resource representing an XML document, an element within an XML document, or an attribute of an element within an XML document that follows the naming and validation constraints of XCAP.
XCAP资源：表示XML文档、XML文档中的元素或遵循XCAP命名和验证约束的XML文档中元素的属性的HTTP资源。
XCAP Server: An HTTP server that understands how to follow the naming and validation constraints defined in this specification.
XCAP服务器：了解如何遵循本规范中定义的命名和验证约束的HTTP服务器。
XCAP Client: An HTTP client that understands how to follow the naming and validation constraints defined in this specification.
XCAP客户端：一个HTTP客户端，它了解如何遵循本规范中定义的命名和验证约束。
Application: A collection of software components within a network whose operation depends on data managed and stored on an XCAP server.
应用程序：网络中的软件组件集合，其操作依赖于XCAP服务器上管理和存储的数据。
Application Usage: Detailed information on the interaction of an application with the XCAP server.
应用程序用法：应用程序与XCAP服务器交互的详细信息。
Application Unique ID (AUID): A unique identifier within the namespace of application unique IDs created by this specification that differentiates XCAP resources accessed by one application from XCAP resources accessed by another.
应用程序唯一ID（AUID）：此规范创建的应用程序唯一ID命名空间中的唯一标识符，用于区分一个应用程序访问的XCAP资源与另一个应用程序访问的XCAP资源。
Naming Conventions: The part of an application usage that specifies well-known URIs used by an application, or more generally, specifies the URIs that are typically accessed by an application during its processing.
命名约定：应用程序用法中指定应用程序使用的已知URI的部分，或者更一般地说，指定应用程序在处理过程中通常访问的URI。
XCAP User Identifier (XUI): The XUI is a string, valid as a path element in an HTTP URI, that is associated with each user served by the XCAP server.
XCAP用户标识符（XUI）：XUI是一个字符串，作为HTTP URI中的path元素有效，与XCAP服务器服务的每个用户关联。
XCAP Root: A context that contains all the documents across all application usages and users that are managed by the server.
XCAP Root：包含服务器管理的所有应用程序使用和用户的所有文档的上下文。
Document Selector: A sequence of path segments, with each segment being separated by a "/", that identify the XML document within an XCAP root that is being selected.
文档选择器：一系列路径段，每个段用“/”分隔，用于标识所选XCAP根目录中的XML文档。
Node Selector: A sequence of path segments, with each segment being separated by a "/", that identify the XML node (element or attribute) being selected within a document.
节点选择器：一系列路径段，每个段用“/”分隔，标识文档中所选的XML节点（元素或属性）。
Node Selector Separator: A single path segment equal to two tilde characters "~~" that is used to separate the document selector from the node selector within an HTTP URI.
节点选择器分隔符：等于两个波浪号字符“~~”的单个路径段，用于在HTTP URI内将文档选择器与节点选择器分开。
Document URI: The HTTP URI containing the XCAP root and document selector, resulting in the selection of a specific document. As a result, performing a GET against the document URI would retrieve the document.
文档URI：包含XCAP根和文档选择器的HTTP URI，用于选择特定文档。因此，对文档URI执行GET将检索文档。
Node URI: The HTTP URI containing the XCAP root, document selector, node selector separator, and node selector, resulting in the selection of a specific XML node.
节点URI：包含XCAP根、文档选择器、节点选择器分隔符和节点选择器的HTTP URI，用于选择特定的XML节点。
XCAP Root URI: An HTTP URI that represents the XCAP root. Although a syntactically valid URI, the XCAP Root URI does not correspond to an actual resource on an XCAP server. Actual resources are created by appending additional path information to the XCAP Root URI.
XCAP根URI：表示XCAP根的HTTP URI。尽管XCAP根URI在语法上是有效的URI，但它并不对应于XCAP服务器上的实际资源。实际资源是通过向XCAP根URI追加额外的路径信息来创建的。
Global Tree: A URI that represents the parent for all global documents for a particular application usage within a particular XCAP root.
全局树：表示特定XCAP根中特定应用程序使用的所有全局文档的父级的URI。
Home Directory: A URI that represents the parent for all documents for a particular user for a particular application usage within a particular XCAP root.
主目录：表示特定XCAP根目录中特定应用程序使用的特定用户的所有文档的父级的URI。
Positional Insertion: A PUT operation that results in the insertion of a new element into a document such that its position, relative to other children of the same parent, is set by the client.
位置插入：一种PUT操作，将新元素插入到文档中，使其相对于同一父元素的其他子元素的位置由客户端设置。
Each XCAP resource on a server is associated with an application. In order for an application to use those resources, application specific conventions must be specified. Those conventions include the XML schema that defines the structure and constraints of the data, well-known URIs to bootstrap access to the data, and so on. All of those application specific conventions are defined by the application usage.
服务器上的每个XCAP资源都与一个应用程序相关联。为了让应用程序使用这些资源，必须指定特定于应用程序的约定。这些约定包括定义数据结构和约束的XML模式、用于引导数据访问的众所周知的URI，等等。所有这些特定于应用程序的约定都是由应用程序用法定义的。
Each application usage is associated with a name, called an Application Unique ID (AUID). This name uniquely identifies the application usage within the namespace of application usages, and is different from AUIDs used by other applications. AUIDs exist in one of two namespaces. The first namespace is the IETF namespace. This
每个应用程序使用都与一个名相关联，称为应用程序唯一ID（AUID）。该名称唯一地标识应用程序用法名称空间中的应用程序用法，并且与其他应用程序使用的AUID不同。AUID存在于两个名称空间之一。第一个名称空间是IETF名称空间。这
namespace contains a set of tokens, each of which is registered with IANA. These registrations occur with the publication of standards track RFCs [27], based on the guidelines in Section 15. The second namespace is the vendor-proprietary namespace. Each AUID in that namespace is prefixed with the reverse domain name of the organization creating the AUID, followed by a period, followed by any vendor defined token. As an example, the example.com domain can create an AUID with the value "com.example.foo" but cannot create one with the value "org.example.foo". AUIDs within the vendor namespace do not need to be registered with IANA. The vendor namespace is also meant to be used in lab environments where no central registry is needed. The syntax for AUIDs, expressed in ABNF [12] (and using some of the BNF defined in RFC 3986 [13]), is:
命名空间包含一组令牌，每个令牌都向IANA注册。根据第15节中的指南，这些注册随着标准跟踪RFC[27]的发布而发生。第二个名称空间是供应商专有名称空间。该名称空间中的每个AUID都以创建AUID的组织的反向域名作为前缀，后跟句点，后跟任何供应商定义的令牌。例如，example.com域可以创建值为“com.example.foo”的AUID，但不能创建值为“org.example.foo”的AUID。供应商名称空间中的AUID不需要向IANA注册。供应商名称空间也适用于不需要中央注册表的实验室环境。用ABNF[12]表示的AUID的语法（并使用RFC 3986[13]中定义的一些BNF）是：
AUID = global-a-uid / vendor-a-uid
global-a-uid = a-uid
a-uid = 1*a-uid-char
vendor-a-uid = rev-hostname "." a-uid
rev-hostname = toplabel *( "." domainlabel )
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
a-uid-char = a-uid-unreserved / pct-encoded / sub-delims
/ ":" / "@"
;pct-encoded from RFC 3986
;sub-delims from RFC 3986
alphanum = ALPHA / DIGIT
;DIGIT from RFC 4234
;ALPHA from RFC 4234
a-uid-unreserved = ALPHA / DIGIT / "-" / "_" / "~"
AUID = global-a-uid / vendor-a-uid
global-a-uid = a-uid
a-uid = 1*a-uid-char
vendor-a-uid = rev-hostname "." a-uid
rev-hostname = toplabel *( "." domainlabel )
domainlabel = alphanum
/ alphanum *( alphanum / "-" ) alphanum
toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum
a-uid-char = a-uid-unreserved / pct-encoded / sub-delims
/ ":" / "@"
;pct-encoded from RFC 3986
;sub-delims from RFC 3986
alphanum = ALPHA / DIGIT
;DIGIT from RFC 4234
;ALPHA from RFC 4234
a-uid-unreserved = ALPHA / DIGIT / "-" / "_" / "~"
The allowed characters for the auid production is a subset of the pchar production defined in RFC 3986. In particular, it omits the ".", which allows for the auid to be separated from the reverse hostname.
auid产品允许的字符是RFC 3986中定义的pchar产品的子集。特别是，它省略了“.”，这允许auid与反向主机名分开。
In order for the XCAP server to match a URI to an element or attribute of a document, any XML namespace prefixes used within the URI must be expanded [3]. This expansion requires a namespace binding context. That context maps namespace prefixes to namespace URIs. It also defines a default namespace that applies to elements in the URI without namespace prefixes. The namespace binding context comes from two sources. First, the mapping of namespace prefixes to namespace URIs is obtained from the URI itself (see Section 6.4). However, the default document namespace is defined by the application usage itself, and applies to all URIs referencing resources within
为了让XCAP服务器将URI与文档的元素或属性相匹配，必须扩展URI中使用的任何XML命名空间前缀[3]。此扩展需要命名空间绑定上下文。该上下文将名称空间前缀映射到名称空间URI。它还定义了一个默认名称空间，该名称空间应用于URI中没有名称空间前缀的元素。名称空间绑定上下文来自两个源。首先，命名空间前缀到命名空间URI的映射是从URI本身获得的（参见第6.4节）。但是，默认的文档名称空间由应用程序使用本身定义，并应用于其中引用资源的所有URI
that application usage. All application usages MUST define a namespace URI that represents the default document namespace to be used when evaluating URIs. The default document namespace does not apply to elements or attributes within the documents themselves -- it applies only to the evaluation of URIs within that application usage. Indeed, the term 'default document namespace' is distinct from the term 'default namespace'. The latter has the standard meaning within XML documents, and the former refers to the default used in evaluation of XCAP URIs. XCAP does not change in any way the mechanisms for determining the default namespace within XML documents. However, if a document contains a URI representing an XCAP resource, the default document namespace defined by the application usage applies to that URI as well.
应用程序的使用情况。所有应用程序使用都必须定义一个命名空间URI，该URI表示在评估URI时要使用的默认文档命名空间。默认文档名称空间不适用于文档本身中的元素或属性——它仅适用于该应用程序使用中的URI评估。实际上，术语“默认文档名称空间”与术语“默认名称空间”是不同的。后者在XML文档中具有标准含义，前者指的是评估XCAP URI时使用的默认值。XCAP不会以任何方式更改确定XML文档中默认名称空间的机制。但是，如果文档包含表示XCAP资源的URI，则应用程序用法定义的默认文档命名空间也将应用于该URI。
One of the responsibilities of an XCAP server is to validate the content of each XCAP resource when an XCAP client tries to modify one. This is done using two mechanisms. Firstly, all application usages MUST describe their document contents using XML schema [2]. The application usage MUST also identify the MIME type for documents compliant to that schema.
XCAP服务器的职责之一是在XCAP客户端尝试修改每个XCAP资源时验证其内容。这是通过两种机制实现的。首先，所有应用程序的使用都必须使用XML模式描述其文档内容[2]。应用程序使用还必须标识符合该架构的文档的MIME类型。
Unfortunately, XML schemas cannot represent every form of data constraint. As an example, one XML element may contain an integer that defines the maximum number of instances of another element. This constraint cannot be represented with XML schema. However, such constraints may be important to the application usage. The application usage defines any additional constraints beyond those in the schema.
不幸的是，XML模式不能表示每种形式的数据约束。例如，一个XML元素可能包含一个整数，该整数定义另一个元素的最大实例数。此约束不能用XML架构表示。但是，这些约束对于应用程序的使用可能很重要。应用程序使用定义了架构中约束之外的任何其他约束。
Of particular importance are uniqueness constraints. In many cases, an application will require that there be only one instance of some element or attribute within a particular scope. Each uniqueness constraint needs to be specified by identifying the field, or combinations of fields, that need to be unique, and then identifying the scope in which that uniqueness applies. One typical scope is the set of all elements of a certain name within the same parent. Another typical scope is the set of all URIs valid within a particular domain. In some cases, these constraints can be specified using XML schema, which provides the <unique> element for this purpose. Other uniqueness constraints, such as URI uniqueness across a domain, cannot be expressed by schema. Whether or not the schema is used to express some of the uniqueness requirements, the application usage MUST specify all uniqueness requirements when it defines its data validation needs.
特别重要的是唯一性约束。在许多情况下，应用程序将要求在特定范围内只有某个元素或属性的一个实例。每个唯一性约束都需要通过标识需要唯一的字段或字段组合来指定，然后标识唯一性应用的范围。一个典型的作用域是同一父级中某个名称的所有元素的集合。另一个典型的作用域是在特定域中有效的所有URI的集合。在某些情况下，可以使用XML模式指定这些约束，该模式为此提供<unique>元素。其他唯一性约束，例如跨域的URI唯一性，不能用模式表示。无论模式是否用于表示某些唯一性需求，应用程序使用必须在定义其数据验证需求时指定所有唯一性需求。
For example, the resource lists application usage [22] requires that each <list> element have a unique value for the "name" attribute within a single parent. As another example, the RLS services application usage [22] requires that the value of the "uri" attribute of the <service> element be a URI that is unique within the domain of the URI.
例如，资源列表应用程序用法[22]要求每个<list>元素在单个父元素中具有唯一的“name”属性值。作为另一个示例，RLS服务应用程序用法[22]要求<service>元素的“uri”属性的值是uri域内唯一的uri。
URI constraints represent another form of constraints. These are constraints on the scheme or structure of the scheme-specific part of the URI. These kinds of constraints cannot be expressed in an XML schema. If these constraints are important to an application usage, they need to be explicitly called out.
URI约束表示另一种形式的约束。这些是对URI中特定于方案的部分的方案或结构的约束。这些类型的约束不能在XML模式中表示。如果这些约束对应用程序的使用很重要，则需要显式调用它们。
Another important data constraint is referential integrity. Referential integrity is important when the name or value of an element or attribute is used as a key to select another element or attribute. An application usage MAY specify referential integrity constraints. However, XCAP servers are not a replacement for Relational Database Management Systems (RDBMS), and therefore clients MUST NOT depend on servers to maintain referential integrity. XCAP clients are responsible for making all the appropriate changes to documents in order to maintain referential integrity.
另一个重要的数据约束是引用完整性。当元素或属性的名称或值用作选择其他元素或属性的键时，引用完整性非常重要。应用程序使用可能指定引用完整性约束。但是，XCAP服务器不能替代关系数据库管理系统（RDBMS），因此客户端不能依赖服务器来维护引用完整性。XCAP客户端负责对文档进行所有适当的更改，以保持引用完整性。
Another constraint is character encoding. XML allows documents to be encoded using several different character sets. However, this specification mandates that all documents used with XCAP MUST be encoded using UTF-8. This cannot be changed by an application usage.
另一个限制是字符编码。XML允许使用几个不同的字符集对文档进行编码。但是，本规范要求与XCAP一起使用的所有文档必须使用UTF-8编码。这不能由应用程序使用情况更改。
The data validation information is consumed by both clients, which use them to make sure they construct requests that will be accepted by the server, and by servers, which validate the constraints when they receive a request (with the exception of referential integrity constraints, which are not validated by the server).
数据验证信息由客户端和服务器使用，客户端使用这些信息来确保它们构造的请求将被服务器接受，服务器在接收到请求时验证约束（引用完整性约束除外，这些约束未被服务器验证）。
For each application usage, the data present in the XML document has a well-defined semantic. The application usage defines that semantic, so that a client can properly construct a document in order to achieve the desired result. They are not used by the server, as it is purposefully unaware of the semantics of the data it is managing. The data semantics are expressed in English prose by the application usage.
对于每个应用程序的使用，XML文档中的数据都具有定义良好的语义。应用程序的使用定义了该语义，因此客户机可以正确地构造文档以获得所需的结果。服务器不使用它们，因为它故意不知道它所管理的数据的语义。数据语义通过应用程序用法以英文散文表示。
One particularly important semantic is the base URI that is to be used for the resolution of any relative URI references pointed to XCAP resources. As discussed below, relative URI references pointing to XCAP resources cannot be resolved using the retrieval URI as the
一个特别重要的语义是基本URI，用于解析指向XCAP资源的任何相对URI引用。正如下面所讨论的，不能使用检索URI作为索引来解析指向XCAP资源的相对URI引用
base URI. Therefore, it is up to the application usage to specify the base URI.
基本URI。因此，由应用程序使用情况来指定基本URI。
In addition to defining the meaning of the document in the context of a particular application, an application usage has to specify how the applications obtain the documents they need. In particular, it needs to define any well-known URIs used for bootstrapping purposes, and document any other conventions on the URIs used by an application. It should also document how documents reference each other. These conventions are called naming conventions.
除了在特定应用程序的上下文中定义文档的含义外，应用程序用法还必须指定应用程序如何获取所需的文档。特别是，它需要定义用于引导目的的任何已知URI，并记录应用程序使用的URI的任何其他约定。它还应记录文件如何相互引用。这些约定称为命名约定。
For many application usages, users need only a single document. In such a case, it is RECOMMENDED that the application usage require that this document be called "index" and exist within the user's home directory.
对于许多应用程序用途，用户只需要一个文档。在这种情况下，建议应用程序使用要求将此文档称为“索引”，并存在于用户的主目录中。
As an example, the RLS services application usage allows an RLS to obtain the contents of a resource list when the RLS receives a SUBSCRIBE request for a SIP URI identifying an RLS service. The application usage specifies that the list of service definitions is present within a specific document with a specific name within the global tree. This allows the RLS to perform a single XCAP request to fetch the service definition for the service associated with the SIP URI in a SUBSCRIBE request.
例如，RLS服务应用使用允许RLS在RLS接收到对标识RLS服务的SIP URI的订阅请求时获取资源列表的内容。应用程序用法指定服务定义列表存在于全局树中具有特定名称的特定文档中。这允许RLS执行单个XCAP请求，以获取订阅请求中与SIP URI关联的服务的服务定义。
Naming conventions are used by XCAP clients to construct their URIs. The XCAP server does not make use of them.
XCAP客户端使用命名约定来构造其URI。XCAP服务器不使用它们。
When a user modifies an XCAP resource, the content of many other resources is affected. For example, when a user deletes an XML element within a document, it does so by issuing a DELETE request against the URI for the element resource. However, deleting this element also deletes all child elements and their attributes, each of which is also an XCAP resource. As such, manipulation of one resource affects the state of other resources.
当用户修改XCAP资源时，许多其他资源的内容都会受到影响。例如，当用户删除文档中的XML元素时，它会对元素资源的URI发出删除请求。但是，删除此元素也会删除所有子元素及其属性，每个子元素都是一个XCAP资源。因此，对一种资源的操作会影响其他资源的状态。
For the most part, these interdependencies are fully specified by the XML schema used by the application usage. However, in some application usages, there is a need for the server to relate resources together, and such a relationship cannot be specified through a schema. This occurs when changes in one document will affect another document. Typically, this is the case when an application usage is defining a document that acts as a collection of information defined in other documents.
在大多数情况下，这些相互依赖关系完全由应用程序使用的XML模式指定。但是，在某些应用程序使用中，服务器需要将资源关联在一起，并且不能通过模式指定这种关系。当一个文档中的更改将影响另一个文档时，会发生这种情况。通常，当应用程序使用定义的文档充当其他文档中定义的信息集合时，就会出现这种情况。
As an example, when a user creates a new RLS service (that is, it creates a new <service> element within an RLS services document), the server adds that element to a read-only global list of services maintained by the server in the global tree. This read-only global list is accessed by the RLS when processing a SIP SUBSCRIBE request.
例如，当用户创建一个新的RLS服务（即，在RLS服务文档中创建一个新的<service>元素）时，服务器将该元素添加到全局树中由服务器维护的只读全局服务列表中。RLS在处理SIP订阅请求时访问该只读全局列表。
Resource interdependencies are used by both XCAP clients and servers.
XCAP客户端和服务器都使用资源相互依赖关系。
By default, each user is able to access (read, modify, and delete) all the documents below their home directory, and any user is able to read documents within the global directory. However, only trusted users, explicitly provisioned into the server, can modify global documents.
默认情况下，每个用户都可以访问（读取、修改和删除）其主目录下的所有文档，并且任何用户都可以读取全局目录中的文档。但是，只有显式配置到服务器中的受信任用户才能修改全局文档。
The application usage can specify a different authorization policy that applies to all documents associated with that application usage. An application usage can also specify whether another application usage is used to define the authorization policies. An application usage for setting authorization policies can also be defined subsequent to the definition of the main application usage. In such a case, the main application usage needs only to specify that such a usage will be defined in the future.
应用程序用法可以指定不同的授权策略，该策略适用于与该应用程序用法关联的所有文档。应用程序用法还可以指定是否使用其他应用程序用法来定义授权策略。用于设置授权策略的应用程序用法也可以在定义主应用程序用法之后进行定义。在这种情况下，主应用程序用法只需指定将来将定义这样的用法。
If an application usage does not wish to change the default authorization policy, it can merely state that the default policy is used.
如果应用程序使用不希望更改默认授权策略，它只能声明使用了默认策略。
The authorization policies defined by the application usage are used by the XCAP server during its operation.
XCAP服务器在其运行期间使用应用程序使用情况定义的授权策略。
An XCAP server MUST understand an application usage in order to process an HTTP request made against a resource for that particular application usage. However, it is not required for the server to understand all of the contents of a document used by an application usage. A server is required to understand the baseline schema defined by the application usage. However, those schemas can define points of extensibility where new content can be added from other namespaces and corresponding schemas. Sometimes, the server will understand those namespaces and therefore have access to their schemas. Sometimes, it will not.
XCAP服务器必须了解应用程序的使用情况，才能处理针对特定应用程序使用情况的资源发出的HTTP请求。但是，服务器不需要理解应用程序使用的文档的所有内容。服务器需要理解由应用程序使用定义的基线架构。但是，这些模式可以定义可扩展点，在这里可以从其他名称空间和相应的模式添加新内容。有时，服务器会理解这些名称空间，因此可以访问它们的模式。有时候，它不会。
A server MUST allow for documents that contain elements from namespaces not known to the server. In such a case, the server
服务器必须允许包含来自服务器未知名称空间的元素的文档。在这种情况下，服务器
cannot validate that such content is schema compliant; it will only verify that the XML is well-formed.
无法验证此类内容是否符合架构；它只会验证XML格式是否正确。
If a client wants to verify that a server supports a particular namespace before operating on a resource, it can query the server for its capabilities using the XCAP Capabilities application usage, discussed in Section 12.
如果客户机希望在对资源进行操作之前验证服务器是否支持特定命名空间，则可以使用第12节中讨论的XCAP capabilities应用程序用法查询服务器的功能。
Application usages are documented in specifications that convey the information described above. In particular, an application usage specification MUST provide the following information:
应用程序用法记录在传达上述信息的规范中。特别是，应用程序使用规范必须提供以下信息：
o Application Unique ID (AUID): If the application usage is meant for general use on the Internet, the application usage MUST register the AUID into the IETF tree using the IANA procedures defined in Section 15.
o 应用程序唯一ID（AUID）：如果应用程序的使用是为了在互联网上通用，应用程序的使用必须使用第15节中定义的IANA程序将AUID注册到IETF树中。
o XML Schema
o XML模式
o Default Document Namespace
o 默认文档名称空间
o MIME Type
o MIME类型
o Validation Constraints
o 验证约束
o Data Semantics
o 数据语义
o Naming Conventions
o 命名约定
o Resource Interdependencies
o 资源相互依赖性
o Authorization Policies
o 授权策略
The primary design task when creating a new application usage is to define the schema. Although XCAP can be used with any XML document, intelligent schema design will improve the efficiency and utility of the document when it is manipulated with XCAP.
创建新应用程序用法时的主要设计任务是定义模式。尽管XCAP可以用于任何XML文档，但使用XCAP操作文档时，智能模式设计将提高文档的效率和实用性。
XCAP provides three fundamental ways to select elements amongst a set of siblings: by the expanded name of the element, by its position, or by the value of a specific attribute. Positional selection always allows a client to get exactly what it wants. However, it requires a client to cache a copy of the document in order to construct the predicate. Furthermore, if a client performs a PUT, it requires the
XCAP提供了三种基本方法来从一组同级元素中选择元素：通过元素的扩展名称、位置或特定属性的值。位置选择总是允许客户机准确地获得它想要的东西。但是，它需要客户端缓存文档的副本以构造谓词。此外，如果客户机执行PUT，则需要
client to reconstruct the PUT processing that a server would follow in order to update its local cached copy. Otherwise, the client will be forced to re-GET the document after every PUT, which is inefficient. As such, it is a good idea to design schemas such that common operations can be performed without requiring the client to cache a copy of the document.
客户端重新构造服务器将遵循的PUT处理，以便更新其本地缓存副本。否则，客户机将被迫在每次放置后重新获取文档，这是低效的。因此，设计模式是一个好主意，这样可以在不需要客户端缓存文档副本的情况下执行常见操作。
Without positional selection, a client can pick the element at each step by its expanded name or the value of an attribute. Many schemas include elements that can be repeated within a parent (often, minOccurs equals zero or one, and maxOccurs is unbounded). As such, all of the elements have the same name. This leaves the attribute value as the only way to select an element. Because of this, if an application usage expects the user to manipulate elements or attributes that are descendants of an element that can repeat, that element SHOULD include, in its schema, an attribute that can be suitably used as a unique index. Furthermore, the naming conventions defined by that application usage SHOULD specify this uniqueness constraint explicitly.
在没有位置选择的情况下，客户机可以在每一步通过元素的扩展名称或属性值来选择元素。许多模式包含可以在父级中重复的元素（通常，minOccurs等于零或一，maxOccurs是无界的）。因此，所有元素都具有相同的名称。这使得属性值成为选择元素的唯一方法。因此，如果应用程序使用期望用户操作作为可以重复的元素的后代的元素或属性，那么该元素应该在其模式中包含一个可以适当用作唯一索引的属性。此外，该应用程序用法定义的命名约定应明确指定此唯一性约束。
URIs often make a good choice for such a unique index. They have fundamental uniqueness properties, and are also usually of semantic significance in the application usage. However, care must be taken when using a URI as an attribute value. URI equality is usually complex. However, attribute equality is performed by the server using XML rules, which are based on case sensitive string comparison. Thus, XCAP will match URIs based on lexical equality, not functional equality. In such cases, an application usage SHOULD consider these implications carefully.
URI通常是这样一个唯一索引的好选择。它们具有基本的唯一性属性，并且在应用程序使用中通常具有语义意义。但是，在使用URI作为属性值时必须小心。URI相等通常是复杂的。但是，属性相等由服务器使用基于区分大小写的字符串比较的XML规则执行。因此，XCAP将基于词法相等而不是函数相等来匹配URI。在这种情况下，应用程序使用应该仔细考虑这些含义。
XCAP provides the ability of a client to operate on a single element, attribute, or document at a time. As a result, it may be possible that common operations the client might perform will require a sequence of multiple requests. This is inefficient, and introduces the possibility of failure conditions when another client modifies the document in the middle of a sequence. In such a case, the client will be forced to detect this case using entity tags (discussed below in Section 7.11), and undo its previous changes. This is very difficult.
XCAP提供了客户端一次操作单个元素、属性或文档的能力。因此，客户机可能执行的常见操作可能需要一系列多个请求。这是低效的，并且当另一个客户端在序列中间修改文档时，引入了失败条件的可能性。在这种情况下，客户端将被迫使用实体标记（在下面的第7.11节中讨论）来检测这种情况，并撤消以前的更改。这是非常困难的。
As a result, the schemas SHOULD be defined so that common operations generally require a single request to perform. Consider an example. Let's say an application usage is defining permissions for users to perform certain operations. The schema can be designed in two ways. The top level of the tree can identify users, and within each user, there can be the permissions associated with the user. In an alternative design, the top level of the tree identifies each permission, and within that permission, the set of users who have it.
因此，应定义模式，以使常见操作通常需要执行单个请求。考虑一个例子。假设应用程序的用途是为用户定义执行某些操作的权限。模式可以用两种方式设计。树的顶层可以识别用户，在每个用户中，可以有与该用户关联的权限。在另一种设计中，树的顶层标识每个权限，并在该权限内标识拥有该权限的用户集。
If, in this application usage, it is common to change the permission for a user from one value to another, the former schema design is better for xcap; it will require a single PUT to make such a change. In the latter case, either the entire document needs to be replaced (which is a single operation), or two PUT operations need to occur -- one to remove the user from the old permission, and one to add the user to the new permission.
如果在此应用程序使用中，将用户的权限从一个值更改为另一个值是常见的，那么以前的模式设计更适合xcap；要做出这样的改变，需要一次看跌期权。在后一种情况下，要么需要替换整个文档（这是一个操作），要么需要执行两个PUT操作——一个从旧权限中删除用户，另一个将用户添加到新权限。
Naming conventions form another key part of the design of an application usage. The application usage should be certain that XCAP clients know where to "start" to retrieve and modify documents of interest. Generally, this will involve the specification of a well-known document at a well-known URI. That document can contain references to other documents that the client needs to read or modify.
命名约定是应用程序使用设计的另一个关键部分。应用程序的使用应该确保XCAP客户端知道从哪里“开始”检索和修改感兴趣的文档。通常，这将涉及在已知URI处指定已知文档。该文档可以包含对客户端需要阅读或修改的其他文档的引用。
In order to manipulate an XCAP resource, the data must be represented by an HTTP URI. XCAP defines a specific naming convention for constructing these URIs. The URI is constructed by concatenating the XCAP root with the document selector with the node selector separator with a percent-encoded form of the node selector. This is followed by an optional query component that defines namespace bindings used in evaluating the URI. The XCAP root is the enclosing context in which all XCAP resources live. The document selector is a path that identifies a document within the XCAP root. The node selector separator is a path segment with a value of double tilde ("~~"), and SHOULD NOT be percent-encoded, as advised in Section 2.3 of RFC 3986 [13]. URIs containing %7E%7E should be normalized to ~~ for comparison; they are equivalent. The node selector separator is a piece of syntactic sugar that separates the document selector from the node selector. The node selector is an expression that identifies a component of the document, such as an element or attribute. It is possible that a "~~" appears as part of the node selector itself; in such a case, the first "~~" in the URI is the node selector separator.
为了操作XCAP资源，数据必须由HTTP URI表示。XCAP为构造这些URI定义了特定的命名约定。URI是通过将XCAP根目录与文档选择器、节点选择器分隔符和节点选择器的百分比编码形式连接起来构建的。接下来是一个可选的查询组件，它定义了用于评估URI的命名空间绑定。XCAP根目录是所有XCAP资源所在的封闭上下文。文档选择器是在XCAP根目录中标识文档的路径。节点选择器分隔符是一个路径段，其值为双波浪号（“~”），不应按照RFC 3986[13]第2.3节的建议进行百分比编码。包含%7E%7E的URI应规范化为~~以进行比较；它们是等价的。节点选择器分隔符是一块语法糖，用于将文档选择器与节点选择器分开。节点选择器是标识文档组件（如元素或属性）的表达式。一个“~~”可能作为节点选择器本身的一部分出现；在这种情况下，URI中的第一个“~~”是节点选择器分隔符。
The sections below describe these components in more detail.
以下各节将更详细地描述这些组件。
The root of the XCAP hierarchy is called the XCAP root. It defines the context in which all other resources exist. The XCAP root is represented with an HTTP URI, called the XCAP Root URI. This URI is a valid HTTP URI; however, it doesn't point to any resource that actually exists on the server. Its purpose is to identify the root of the tree within the domain where all XCAP documents are stored.
XCAP层次结构的根称为XCAP根。它定义了所有其他资源存在的上下文。XCAP根用一个HTTP URI表示，称为XCAP根URI。此URI是有效的HTTP URI；但是，它并不指向服务器上实际存在的任何资源。其目的是在存储所有XCAP文档的域中标识树的根。
It can be any valid HTTP URI, but MUST NOT contain a query component (a complete XCAP URI may have a query component, but it is not part of the XCAP root URI). It is RECOMMENDED that it be equal to xcap.domain, where domain is the domain of the provider. As an example, "http://xcap.example.com" might be used as the XCAP root URI within the example.com domain. Typically, the XCAP root URI is provisioned into client devices. If not explicitly provisioned, clients SHOULD assume the form xcap.domain, where domain is the domain of their service provider (for SIP, this would be the domain part of their Address-of-Record (AOR)). A server or domain MAY support multiple XCAP root URIs. In such a case, it is effectively operating as if it were serving separate domains. There is never information carryover or interactions between resources in different XCAP root URIs.
它可以是任何有效的HTTP URI，但不能包含查询组件（完整的XCAP URI可能有查询组件，但它不是XCAP根URI的一部分）。建议它等于xcap.domain，其中domain是提供程序的域。例如，”http://xcap.example.com“可能用作example.com域中的XCAP根URI。通常，XCAP根URI被配置到客户端设备中。如果未明确设置，客户端应采用xcap.domain的形式，其中domain是其服务提供商的域（对于SIP，这将是其记录地址（AOR）的域部分）。服务器或域可能支持多个XCAP根URI。在这种情况下，它可以像服务于不同的域一样有效地运行。不同XCAP根URI中的资源之间永远不会有信息携带或交互。
When a client generates an HTTP request to a URI identifying an XCAP resource, RFC 2616 procedures for the construction of the Request-URI apply. In particular, the authority component of the URI may not be present in the Request-URI if the request is sent directly to the origin server.
当客户端生成对标识XCAP资源的URI的HTTP请求时，用于构造请求URI的RFC 2616过程适用。特别地，如果请求直接发送到源服务器，则URI的授权组件可能不存在于请求URI中。
The XCAP root URI can also be a relative HTTP URI. It is the responsibility of the application usage to specify the base URI for an HTTP URI representing an XCAP resource whenever such a URI appears within a document defined by that application usage. Generally speaking, it is unsafe to use the retrieval URI as the base URI. This is because any URI that points to an ancestor for a particular element or attribute can contain content including that element or attribute. If that element or attribute contained a relative URI reference, it would be resolved relative to whatever happened to be used to retrieve the content, and this will often not be the base URI defined by the application usage.
XCAP根URI也可以是相对HTTP URI。应用程序使用负责为表示XCAP资源的HTTP URI指定基本URI，只要此类URI出现在由该应用程序使用定义的文档中。一般来说，使用检索URI作为基本URI是不安全的。这是因为任何指向特定元素或属性的祖先的URI都可以包含包含该元素或属性的内容。如果该元素或属性包含一个相对URI引用，那么它将相对于用于检索内容的内容进行解析，而这通常不是应用程序用法定义的基本URI。
Each document within the XCAP root is identified by its document selector. The document selector is a sequence of path segments, separated by a slash ("/"). These path segments define a hierarchical structure for organizing documents within any XCAP root. The first path segment MUST be the XCAP AUID. So, continuing the example above, all of the documents used by the resource lists application would be under "http://xcap.example.com/resource-lists".
XCAP根目录中的每个文档都由其文档选择器标识。文档选择器是一系列路径段，由斜杠（“/”）分隔。这些路径段定义了在任何XCAP根目录中组织文档的层次结构。第一个路径段必须是XCAP AUID。因此，继续上面的示例，资源列表应用程序使用的所有文档都将处于“http://xcap.example.com/resource-lists".
o Implementors making use of HTTP servlets should be aware that XCAP may require them to get authorization from the server administrator to place resources within this specific subset of the URI namespace.
o 使用HTTP servlet的实现者应该知道，XCAP可能要求他们获得服务器管理员的授权，以便将资源放置在URI命名空间的这个特定子集中。
It is assumed that each application will have data that is set by users, and/or it will have global data that applies to all users. As a result, beneath each AUID, there are two sub-trees. One, called "users", holds the documents that are applicable to specific users, and the other, called "global", holds documents applicable to all users. The sub-tree beneath "global" is called the global tree. The path segment after the AUID MUST either be "global" or "users".
假设每个应用程序都有用户设置的数据，和/或有适用于所有用户的全局数据。因此，在每个AUID下，有两个子树。一个称为“用户”，保存适用于特定用户的文档，另一个称为“全局”，保存适用于所有用户的文档。“全局”下的子树称为全局树。AUID后面的路径段必须是“全局”或“用户”。
Within the "users" tree are zero or more sub-trees, each of which identifies documents that apply to a specific user. Each user known to the server is associated with a username, called the XCAP User Identifier (XUI). Typically, an endpoint is provisioned with the value of the XUI. For systems that support SIP applications, it is RECOMMENDED that the XUI be equal to the Address-of-Record (AOR) for the user (i.e., sip:joe@example.com). Since SIP endpoints generally know their AOR, they will also know their XUI. As a consequence, if no XUI is explicitly provisioned, a SIP User Agent SHOULD assume it is equal to their AOR. This XUI MUST be used as the path segment beneath the "users" segment. Since the SIP URI allows for characters that are not permitted in HTTP URI path segments (such as the '?' and '/' characters, which are permitted in the user part of the SIP URI), any such characters MUST be percent encoded. The sub-tree beneath an XUI for a particular user is called their home directory. "User" in this context should be interpreted loosely; a user might correspond to a device, for example.
在“用户”树中有零个或多个子树，每个子树标识应用于特定用户的文档。服务器已知的每个用户都与一个名为XCAP用户标识符（XUI）的用户名相关联。通常，使用XUI的值设置端点。对于支持SIP应用程序的系统，建议XUI等于用户的记录地址（AOR）（即SIP:joe@example.com). 因为SIP端点通常知道它们的AOR，所以它们也知道它们的XUI。因此，如果没有显式地配置XUI，SIP用户代理应该假定它等于它们的AOR。此XUI必须用作“用户”段下的路径段。由于SIP URI允许HTTP URI路径段中不允许的字符（例如在SIP URI的用户部分中允许的“？”和“/”字符），因此必须对任何此类字符进行百分比编码。特定用户的XUI下的子树称为其主目录。在这种情况下，“用户”应该被宽松地解释；例如，用户可能对应于设备。
XCAP does not itself define what it means for documents to "apply" to a user, beyond specification of a baseline authorization policy, described below in Section 8. Each application usage can specify additional authorization policies that depend on data used by the application itself.
XCAP本身并没有定义文档“应用”到用户的含义，超出了基线授权策略的规范，如下文第8节所述。每个应用程序使用都可以指定其他授权策略，这些策略取决于应用程序本身使用的数据。
The remainder of the document selector (the path following "global" or the XUI) points to specific documents for that application usage. Subdirectories are permitted, but are NOT RECOMMENDED. XCAP provides no way to create sub-directories or to list their contents, thus limiting their utility. If subdirectories are used, there MUST NOT be a document in a directory with the same name as a sub-directory.
文档选择器的其余部分（“全局”或XUI后面的路径）指向该应用程序使用的特定文档。允许使用子目录，但不建议使用。XCAP无法创建子目录或列出其内容，因此限制了其实用性。如果使用子目录，则目录中不得有与子目录同名的文档。
The final path segment in the document selector identifies the actual document in the hierarchy. This is equivalent to a filename, except that XCAP does not require that its document resources be stored as files in a file system. However, the term "filename" is used to describe the final path segment in the document selector. In traditional filesystems, the filename would have a filename extension, such as ".xml". There is nothing in this specification that requires or prevents such extensions from being used in the filename. In some cases, the application usage will specify a naming
文档选择器中的最终路径段标识层次结构中的实际文档。这相当于文件名，只是XCAP不要求其文档资源作为文件存储在文件系统中。但是，术语“文件名”用于描述文档选择器中的最终路径段。在传统的文件系统中，文件名将具有文件扩展名，如“.xml”。本规范中没有任何内容要求或阻止在文件名中使用此类扩展名。在某些情况下，应用程序的使用将指定一个命名
convention for documents, and those naming conventions may or may not specify a file extension. For example, in the RLS services application usage [22], documents in the user's home directory with the filename "index" will be used by the server to compute the global index, which is also a document with the filename "index". Barring specific guidelines in the application usage, if a user has a single document for a particular application usage, this SHOULD be called "index".
文档的命名约定，这些命名约定可以指定文件扩展名，也可以不指定文件扩展名。例如，在RLS服务应用程序用法[22]中，服务器将使用用户主目录中文件名为“index”的文档来计算全局索引，全局索引也是文件名为“index”的文档。除非应用程序使用中有特定的指导原则，否则如果用户有用于特定应用程序使用的单个文档，则应将其称为“索引”。
When the naming conventions in an application usage do not constrain the filename conventions (or, more generally, the document selector), an application will know the filename (or more generally, the document selector) because it is included as a reference in a document accessed by the client. As another example, within the index document defined by RLS services, the <service> element has a child element called <resource-list> whose content is a URI pointing to a resource list within the users home directory.
当应用程序使用中的命名约定不约束文件名约定（或者更一般地说，文档选择器）时，应用程序将知道文件名（或者更一般地说，文档选择器），因为它作为引用包含在客户端访问的文档中。作为另一个示例，在RLS服务定义的索引文档中，<service>元素具有名为<resource list>的子元素，其内容是指向用户主目录中的资源列表的URI。
As a result, if the user creates a new document, and then references that document from a well-known document (such as the index document above), it doesn't matter whether or not the user includes an extension in the filename, as long as the user is consistent and maintains referential integrity.
因此，如果用户创建了一个新文档，然后从一个已知文档（如上面的索引文档）引用该文档，则用户是否在文件名中包含扩展名无关紧要，只要用户一致并保持引用完整性即可。
As an example, the path segment "/resource-lists/users/sip:joe@example.com/index" is a document selector. Concatenating the XCAP root URI with the document selector produces the HTTP URI "http://xcap.example.com/resource-lists/users/ sip:joe@example.com/index". In this URI, the AUID is "resource-lists", and the document is in the user tree with the XUI "sip:joe@example.com" with filename "index".
例如，路径段“/资源列表/用户/sip：joe@example.com/“索引”是一个文档选择器。将XCAP根URI与文档选择器连接会生成HTTP URI“http://xcap.example.com/resource-lists/users/ 抿：joe@example.com/索引”。在此URI中，AUID是“资源列表”，文档位于用户树中，带有XUI“sip:joe@example.com文件名为“index”。
The node selector specifies specific nodes of the XML document that are to be accessed. A node refers to an XML element, an attribute of an element, or a set of namespace bindings. The node selector is an expression that identifies an element, attribute, or set of namespace bindings. Its grammar is:
节点选择器指定要访问的XML文档的特定节点。节点引用XML元素、元素的属性或一组命名空间绑定。节点选择器是标识元素、属性或命名空间绑定集的表达式。其语法是：
node-selector = element-selector ["/" terminal-selector]
terminal-selector = attribute-selector / namespace-selector /
extension-selector
element-selector = step *( "/" step)
step = by-name / by-pos / by-attr / by-pos-attr /
extension-selector
by-name = NameorAny
by-pos = NameorAny "[" position "]"
node-selector = element-selector ["/" terminal-selector]
terminal-selector = attribute-selector / namespace-selector /
extension-selector
element-selector = step *( "/" step)
step = by-name / by-pos / by-attr / by-pos-attr /
extension-selector
by-name = NameorAny
by-pos = NameorAny "[" position "]"
position = 1*DIGIT
attr-test = "@" att-name "=" att-value
by-attr = NameorAny "[" attr-test "]"
by-pos-attr = NameorAny "[" position "]" "[" attr-test "]"
NameorAny = QName / "*" ; QName from XML Namespaces
att-name = QName
att-value = AttValue ; from XML specification
attribute-selector = "@" att-name
namespace-selector = "namespace::*"
extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/"
position = 1*DIGIT
attr-test = "@" att-name "=" att-value
by-attr = NameorAny "[" attr-test "]"
by-pos-attr = NameorAny "[" position "]" "[" attr-test "]"
NameorAny = QName / "*" ; QName from XML Namespaces
att-name = QName
att-value = AttValue ; from XML specification
attribute-selector = "@" att-name
namespace-selector = "namespace::*"
extension-selector = 1*( %x00-2e / %x30-ff ) ; anything but "/"
The QName grammar is defined in the XML namespaces [3] specification, and the AttValue grammar is defined in the XML specification XML 1.0 [1].
QName语法在XML名称空间[3]规范中定义，AttValue语法在XML规范XML 1.0[1]中定义。
The extension-selector is included for purposes of extensibility. It can be composed of any character except the slash, which is the delimiter amongst steps. Any characters in an extension that cannot be represented in a URI MUST be percent-encoded before placement into a URI.
出于可扩展性的目的，包含了扩展选择器。它可以由除斜杠以外的任何字符组成，斜杠是步骤之间的分隔符。扩展名中不能在URI中表示的任何字符必须在放入URI之前进行百分比编码。
Note that the double quote, left square bracket and right square bracket characters, which are meaningful to XCAP, cannot be directly represented in the HTTP URI. As a result, they are percent-encoded when placed within the HTTP URI. In addition to these characters, an apostrophe (') character can be used as a delimiter within XPath expressions. Furthermore, since XML allows for non-ASCII characters, the names of elements and attributes may not be directly representable in a URI. Any such characters MUST be represented by converting them to an octet sequence corresponding to their representation in UTF-8, and then percent-encoding that sequence of octets.
请注意，对XCAP有意义的双引号、左方括号和右方括号字符不能直接在HTTP URI中表示。因此，当将它们放在HTTP URI中时，它们是百分比编码的。除了这些字符外，撇号（'）字符还可以用作XPath表达式中的分隔符。此外，由于XML允许非ASCII字符，元素和属性的名称可能无法在URI中直接表示。任何这样的字符都必须通过将其转换为与UTF-8中的表示相对应的八位字节序列来表示，然后对该八位字节序列进行百分比编码。
Similarly, the XML specification defines the QName production for the grammar for element and attribute names, and the AttValue production for the attribute values. Unfortunately, the characters permitted by these productions include some that are not allowed for pchar, which is the production for the allowed set of characters in path segments in the URI. The AttValue production allows many such characters within the US-ASCII set, including the space. Those characters MUST be percent-encoded when placed in the URI. Furthermore, QName and AttValue allow many Unicode characters, outside of US-ASCII. When these characters need to be represented in the HTTP URI, they are percent-encoded. To do this, the data should be encoded first as octets according to the UTF-8 character encoding [18], and then only those octets that do not correspond to characters in the pchar set should be percent-encoded. For example, the character A would be represented as "A", the character LATIN CAPITAL LETTER A WITH GRAVE
类似地，XML规范为元素和属性名称的语法定义了QName产品，为属性值定义了AttValue产品。不幸的是，这些产品允许的字符包括一些pchar不允许的字符，pchar是URI中路径段中允许的字符集的产品。AttValue生成允许在US-ASCII集合中使用许多这样的字符，包括空格。这些字符在放入URI时必须进行百分比编码。此外，QName和AttValue允许许多Unicode字符，US-ASCII除外。当这些字符需要在HTTP URI中表示时，它们是百分比编码的。为此，应首先根据UTF-8字符编码将数据编码为八位字节[18]，然后仅对与pchar集中的字符不对应的八位字节进行百分比编码。例如，字符A将表示为“A”，字符的拉丁文大写字母A带有GRAVE
would be represented as "%C3%80", and the character KATAKANA LETTER A would be represented as "%E3%82%A2".
将表示为“%C3%80”，而字符片假名字母A将表示为“%E3%82%A2”。
As a result, the grammar above represents the expressions processed by the XCAP server internally after it has decoded the URI. The on-the-wire format is dictated by RFC 3986 [13]. In the discussions and examples below, when the node selectors are not part of an HTTP URI, they are presented in their internal format prior to encoding. If an example includes a node selector within an HTTP URI, it is presented in its percent-encoded form.
因此，上面的语法表示XCAP服务器解码URI后在内部处理的表达式。在线格式由RFC 3986[13]规定。在下面的讨论和示例中，当节点选择器不是HTTP URI的一部分时，它们将在编码之前以内部格式显示。如果示例包含HTTP URI中的节点选择器，则它将以百分比编码形式显示。
The node selector is based on the concepts in XPath [10]. Indeed, the node selector expression, before it is percent-encoded for representation in the HTTP URI, happens to be a valid XPath expression. However, XPath provides a set of functionality far richer than is needed here, and its breadth would introduce much unneeded complexity into XCAP.
节点选择器基于XPath[10]中的概念。实际上，在对节点选择器表达式进行百分比编码以在HTTP URI中表示之前，它恰好是一个有效的XPath表达式。然而，XPath提供的功能远比这里需要的丰富，而且它的广度会给XCAP带来许多不必要的复杂性。
To determine the XML element, attribute, or namespace bindings selected by the node selector, processing begins at the root node of the XML document. The first step in the element selector is then taken. Each step chooses a single XML element within the current document context. The document context is the point within the XML document from which a specific step is evaluated. The document context begins at the root node of the document. When a step determines an element within that context, that element becomes the new context for evaluation of the next step. Each step can select an element by its name (expanded), by a combination of name and attribute value, by name and position, or by name, position and attribute. In all cases, the name can be wildcarded, so that all elements get selected.
要确定节点选择器选择的XML元素、属性或命名空间绑定，处理从XML文档的根节点开始。然后执行元素选择器中的第一步。每个步骤在当前文档上下文中选择一个XML元素。文档上下文是XML文档中用于计算特定步骤的点。文档上下文从文档的根节点开始。当步骤确定该上下文中的元素时，该元素将成为下一步评估的新上下文。每个步骤都可以通过名称（展开）、名称和属性值的组合、名称和位置或名称、位置和属性来选择元素。在所有情况下，都可以对名称进行通配符排序，以便选中所有元素。
The selection operation operates as follows. Within the current document context, the children of that context are enumerated in document order. If the context is the root node of the document, its child element is the root element of the document. If the context is an element, its children are all of the children of that element (naturally). Next, those elements whose name is not a match for NameorAny are discarded. An element name is a match if NameorAny is the wildcard, or if it is not a wildcard, the element name matches NameorAny. Matching is discussed below. The result is an ordered list of elements.
选择操作如下所示。在当前文档上下文中，将按文档顺序枚举该上下文的子级。如果上下文是文档的根节点，则其子元素是文档的根元素。如果上下文是一个元素，则其子元素是该元素的所有子元素（自然）。接下来，将丢弃那些名称与NameorAny不匹配的元素。如果NameorAny是通配符，则元素名是匹配的；如果不是通配符，则元素名与NameorAny匹配。下面讨论匹配。结果是元素的有序列表。
The elements in the list are further filtered by the predicates, which are the expressions in square brackets following NameorAny. Each predicate further prunes the elements from the current ordered list. These predicates are evaluated in order. If the content of the predicate is a position, the position-th element is selected
列表中的元素由谓词进一步过滤，谓词是NameorAny后面方括号中的表达式。每个谓词进一步从当前有序列表中删除元素。这些谓词是按顺序计算的。如果谓词的内容是位置，则选择位置th元素
(that is, treat "position" as a variable, and take the element whose position equals that variable), and all others are discarded. If there are fewer elements in the list than the value of position, the result is a no-match.
（也就是说，将“位置”视为一个变量，并取其位置等于该变量的元素），所有其他元素都将被丢弃。如果列表中的元素少于position的值，则结果为不匹配。
If the content of the predicate is an attribute name and value, all elements possessing an attribute with that name and value are selected, and all others are discarded. Note that, although a document can have namespace declarations within elements, those elements cannot be selected using a namespace declaration as a predicate. That is, a step like "el-name[@xmlns='namespace']" will never match an element, even if there is an element in the list that specifies a default namespace of "namespace". In other words, a namespace node is NOT an attribute. If the namespaces in scope for an element are needed, they can be selected using the namespace-selector described below. If there are no elements with attributes having the given name and value, the result is a no-match.
如果谓词的内容是属性名称和值，则将选择拥有具有该名称和值的属性的所有元素，并丢弃所有其他元素。注意，尽管文档可以在元素中包含名称空间声明，但不能使用名称空间声明作为谓词来选择这些元素。也就是说，像“el name[@xmlns='namespace']”这样的步骤永远不会匹配元素，即使列表中有一个元素指定了默认的名称空间“namespace”。换句话说，名称空间节点不是属性。如果需要元素作用域中的名称空间，可以使用下面描述的名称空间选择器来选择它们。如果没有具有给定名称和值的属性的元素，则结果为不匹配。
After the predicates have been applied, the result will be a no-match, one element, or multiple elements. If the result is multiple elements, the node selector is invalid. Each step in a node selector MUST produce a single element to form the context for the next step. This is more restrictive than general XPath expressions, which allow a context to contain multiple nodes. If the result is a no-match, the node selector is invalid. The node selector is only valid if a single element was selected. This element becomes the context for the evaluation of the next step in the node selector expression.
应用谓词后，结果将是不匹配、一个元素或多个元素。如果结果是多个元素，则节点选择器无效。节点选择器中的每一步都必须生成一个元素，以形成下一步的上下文。这比一般XPath表达式更具限制性，后者允许上下文包含多个节点。如果结果不匹配，则节点选择器无效。仅当选择了单个元素时，节点选择器才有效。此元素成为节点选择器表达式中下一步求值的上下文。
The last location step is either the previously described element selector or a "terminal selector". If the terminal selector is an attribute selector, the server checks to see if there is an attribute with the same expanded name in the current element context. If there is not, the result is considered a no-match. Otherwise, that attribute is selected. If the terminal selector is a namespace selector, the result is equal to the set of namespace bindings in scope for the element, including the possible default namespace declaration. This specification defines a syntax for representing namespace bindings, so they can be returned to the client in an HTTP response.
最后一个定位步骤是前面描述的元素选择器或“终端选择器”。如果终端选择器是属性选择器，服务器将检查当前元素上下文中是否存在具有相同扩展名的属性。如果没有，则认为结果不匹配。否则，将选择该属性。如果终端选择器是名称空间选择器，则结果等于元素范围内的名称空间绑定集，包括可能的默认名称空间声明。该规范定义了表示命名空间绑定的语法，因此可以在HTTP响应中将它们返回给客户机。
As a result, once the entire node selector is evaluated against the document, the result will either be a no-match, invalid, a single element, a single attribute, or a set of namespace bindings.
因此，一旦针对文档对整个节点选择器求值，结果将是不匹配、无效、单个元素、单个属性或一组命名空间绑定。
Matching of element names is performed as follows. The element being compared in the step has its name expanded as described in XML namespaces [3]. The element name in the step is also expanded. This
元素名称的匹配如下所示。步骤中要比较的元素的名称已按XML名称空间[3]中所述展开。步骤中的元素名称也将展开。这
expansion requires that any namespace prefix is converted to its namespace URI. Doing that requires a set of bindings from prefixes to namespace URIs. This set of bindings is obtained from the query component of the URI (see Section 6.4). If the prefix of the QName of an element is empty, the corresponding URI is then the default document namespace URI defined by the application usage, or null if not defined. Comparisons are then performed as described in XML namespaces [3]. Note that the namespace prefix expansions described here are different than those specified in the XPath 1.0 specification, but are closer to those currently defined by the XPath 2.0 specification [24].
扩展需要将任何名称空间前缀转换为其名称空间URI。这样做需要一组从前缀到命名空间URI的绑定。这组绑定是从URI的查询组件获得的（参见第6.4节）。如果元素的QName前缀为空，则相应的URI为应用程序用法定义的默认文档命名空间URI，如果未定义，则为null。然后按照XML名称空间[3]中的描述执行比较。注意，这里描述的名称空间前缀扩展不同于XPath 1.0规范中指定的扩展，但更接近XPath 2.0规范中当前定义的扩展[24]。
Matching of attribute names proceeds in a similar way. The attribute in the document has its name expanded as described in XML namespaces [3]. If the attribute name in the attribute selector has a namespace prefix, its name is expanded using the namespace bindings obtained from the query component of the URI. An unprefixed attribute QName is in no namespace.
属性名称的匹配以类似的方式进行。文档中的属性的名称已按XML名称空间[3]中所述展开。如果属性选择器中的属性名称具有名称空间前缀，则将使用从URI的查询组件获得的名称空间绑定来扩展其名称。不固定的属性QName不在命名空间中。
Comments, text content (including whitespace), and processing instructions can be present in a document, but cannot be selected by the expressions defined here. Of course, if such information is present in a document, and a user selects an XML element enclosing that data, that information would be included in a resulting GET, for example. Furthermore, whitespace is respected by XCAP. If a client PUTs an element or document that contains whitespace, the server retains that whitespace, and will return the element or document back to the client with exactly the same whitespace. Similarly, when an element is inserted, no additional whitespace is added around the inserted element, and the element gets inserted in a very specific location relative to any whitespace, comments, or processing instructions around it. Section 8.2.3 describes where the insertion occurs.
注释、文本内容（包括空白）和处理说明可以出现在文档中，但不能由此处定义的表达式选择。当然，如果此类信息存在于文档中，并且用户选择了包含该数据的XML元素，则该信息将包含在结果GET中。此外，XCAP尊重空格。如果客户机放置包含空格的元素或文档，服务器将保留该空格，并将使用完全相同的空格将元素或文档返回给客户机。类似地，当插入一个元素时，不会在插入的元素周围添加额外的空格，并且该元素会插入到相对于其周围的任何空格、注释或处理指令的非常特定的位置。第8.2.3节描述了插入的位置。
As an example, consider the following XML document:
举个例子，考虑下面的XML文档：
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:professor@example.net"
package="presence">
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
<watcher status="pending"
id="hh8juja87s997-ass7"
display-name="Mr. Subscriber"
event="subscribe">sip:userB@example.org</watcher>
</watcher-list>
</watcherinfo>
<?xml version="1.0"?>
<watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo"
version="0" state="full">
<watcher-list resource="sip:professor@example.net"
package="presence">
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
<watcher status="pending"
id="hh8juja87s997-ass7"
display-name="Mr. Subscriber"
event="subscribe">sip:userB@example.org</watcher>
</watcher-list>
</watcherinfo>
Figure 3: Example XML Document
图3：示例XML文档
Assuming that the default document namespace for this application usage is "urn:ietf:params:xml:ns:watcherinfo", the node selector watcherinfo/watcher-list/watcher[@id="8ajksjda7s"] would select the following XML element:
假设此应用程序使用的默认文档命名空间为“urn:ietf:params:xml:ns:watcherinfo”，则节点选择器watcherinfo/watcher list/watcher[@id=“8ajksjda7s”]将选择以下xml元素：
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
<watcher status="active"
id="8ajksjda7s"
duration-subscribed="509"
event="approved">sip:userA@example.net</watcher>
In order to expand the namespace prefixes used in the node selector, a set of bindings from those namespace prefixes to namespace URI must be used. Those bindings are contained in the query component of the URI. If no query component is present, it means that only the default document namespace (as identified by the application usage) is defined. The query component is formatted as a valid xpointer expression [5] after suitable URI encoding as defined in Section 4.1 of the Xpointer framework. This xpointer expression SHOULD only contain expressions from the xmlns() scheme [4]. A server compliant to this specification MUST ignore any xpointer expressions not from the xmlns() scheme. The xmlns() xpointer expressions define the set of namespace bindings in use for evaluating the URI.
为了扩展节点选择器中使用的名称空间前缀，必须使用从这些名称空间前缀到名称空间URI的一组绑定。这些绑定包含在URI的查询组件中。如果不存在查询组件，则表示只定义了默认文档名称空间（由应用程序使用情况标识）。按照xpointer框架第4.1节中定义的适当URI编码，将查询组件格式化为有效的xpointer表达式[5]。此xpointer表达式应仅包含xmlns（）方案[4]中的表达式。符合此规范的服务器必须忽略非xmlns（）方案中的任何xpointer表达式。xmlns（）xpointer表达式定义用于计算URI的命名空间绑定集。
Note that xpointer expressions were originally designed for usage within fragment identifiers of URIs. However, within XCAP, they are used within query components of URIs.
注意，xpointer表达式最初是为在URI的片段标识符中使用而设计的。但是，在XCAP中，它们在URI的查询组件中使用。
The following example shows a more complex matching operation, this time including the usage of namespace bindings. Consider the following document:
下面的示例显示了一个更复杂的匹配操作，这次包括名称空间绑定的使用。考虑以下文件：
<?xml version="1.0"?>
<foo xmlns="urn:test:default-namespace">
<ns1:bar xmlns:ns1="urn:test:namespace1-uri"
xmlns="urn:test:namespace1-uri">
<baz/>
<ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
</ns1:bar>
<ns3:hi xmlns:ns3="urn:test:namespace3-uri">
<there/>
</ns3:hi>
</foo>
<?xml version="1.0"?>
<foo xmlns="urn:test:default-namespace">
<ns1:bar xmlns:ns1="urn:test:namespace1-uri"
xmlns="urn:test:namespace1-uri">
<baz/>
<ns2:baz xmlns:ns2="urn:test:namespace2-uri"/>
</ns1:bar>
<ns3:hi xmlns:ns3="urn:test:namespace3-uri">
<there/>
</ns3:hi>
</foo>
Assume that this document has a document URI of "http://xcap.example.com/test/users/sip:joe@example.com/index", where "test" is the application usage. This application usage defines a default document namespace of "urn:test:default-namespace". The XCAP URI:
假设此文档的文档URI为“http://xcap.example.com/test/users/sip:joe@com/index”，其中“test”是应用程序使用情况。此应用程序用法定义了默认文档命名空间“urn:test:defaultnamespace”。XCAP URI：
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace1-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace1-uri)
will select the first <baz> child element of the <bar> element in the document. The XCAP URI:
将选择文档中<bar>元素的第一个子元素<baz>。XCAP URI：
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace2-uri)
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace2-uri)
will select the second <baz> child element of the <bar> element in the document. The following XCAP URI will also select the second <baz> child element of the <bar> element in the document:
将选择文档中<bar>元素的第二个<baz>子元素。下面的xcapuri还将选择文档中<bar>元素的第二个<baz>子元素：
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace2-uri)
xmlns(d=urn:test:default-namespace)
http://xcap.example.com/test/users/sip:joe@example.com/index/
~~/d:foo/a:bar/b:baz?xmlns(a=urn:test:namespace1-uri)
xmlns(b=urn:test:namespace2-uri)
xmlns(d=urn:test:default-namespace)
An XCAP client is an HTTP/1.1 compliant client. Specific data manipulation tasks are accomplished by invoking the right set of HTTP methods with the right set of headers on the server. This section describes those in detail.
XCAP客户端是符合HTTP/1.1的客户端。特定的数据操作任务是通过在服务器上使用正确的头集调用正确的HTTP方法集来完成的。本节将详细介绍这些内容。
In all cases where the client modifies a document, by deleting or inserting a document, element or attribute resource, the client SHOULD verify that, if the operation were to succeed, the resulting document would meet the data constraints defined by the application usage, including schema validation. For example, if the client performs a PUT operation to "http://xcap.example.com/rls-services/ users/sip:joe@example.com/mybuddies", rls-services is the application unique ID, and the constraints defined by it SHOULD be followed.
在客户机通过删除或插入文档、元素或属性资源来修改文档的所有情况下，客户机都应验证，如果操作成功，生成的文档将满足应用程序使用定义的数据约束，包括模式验证。例如，如果客户机对“”执行PUT操作http://xcap.example.com/rls-services/ 用户/sip：joe@example.com/mybuddies”，rls服务是应用程序唯一的ID，应该遵循它定义的约束。
The client will know what URI to use based on the naming conventions described by the application usage.
客户机将根据应用程序用法描述的命名约定知道要使用什么URI。
If the document, after modification, does not meet the data constraints, the server will reject it with a 409. The 409 response may contain an XML body, formatted according to the schema in Section 11.2, which provides further information on the nature of the error. The client MAY use this information to try and alter the request so that, this time, it might succeed. The client SHOULD NOT simply retry the request without changing some aspect of it.
如果修改后的文档不符合数据约束，服务器将以409拒绝该文档。409响应可能包含根据第11.2节中的模式格式化的XML正文，该正文提供了有关错误性质的进一步信息。客户机可能会使用此信息尝试并更改请求，以便这次可能成功。客户端不应该只是在不改变请求的某些方面的情况下重试请求。
In some cases, the application usage will dictate a uniqueness constraint that the client cannot guarantee on its own. One such example is that a URI has to be unique within a domain. Typically, the client is not the owner of the domain, and so it cannot be sure that a URI is unique. In such a case, the client can either generate a sufficiently random identifier, or it can pick a "vanity" identifier in the hopes that it is not taken. In either case, if the identifier is not unique, the server will reject the request with a 409 and suggest alternatives that the client can use to try again. If the server does not suggest alternatives, the client SHOULD attempt to use random identifiers with increasing amounts of randomness.
在某些情况下，应用程序的使用将规定客户机无法自行保证的唯一性约束。一个这样的例子是URI在域中必须是唯一的。通常，客户端不是域的所有者，因此无法确保URI是唯一的。在这种情况下，客户机可以生成一个足够随机的标识符，也可以选择一个“虚荣”标识符，希望它不会被采用。如果服务器的标识符是唯一的，则可以再次尝试使用409，如果服务器的标识符是唯一的，则可以拒绝。如果服务器不建议替代方案，客户端应尝试使用随机标识符，随机性增加。
HTTP also specifies that PUT and DELETE requests are idempotent. This means that, if the client performs a PUT on a document and it succeeds, it can perform the same PUT, and the resulting document will look the same. Similarly, when a client performs a DELETE, if it succeeds, a subsequent DELETE to the same URI will generate a 404; the resource no longer exists on the server since it was deleted by the previous DELETE operation. To maintain this property, the client SHOULD construct its URIs such that, after the modification has taken place, the URI in the request will point to the resource just inserted for PUT (i.e., the body of the request), and will point to nothing for DELETE. If this property is maintained, it is the case that GET to the URI in the PUT will return the same content (i.e., GET(PUT(X)) == x). This property implies idempotency. Although a request can still be idempotent if it does not possess this property, XCAP does not permit such requests. If the client's request does not
HTTP还指定PUT和DELETE请求是幂等的。这意味着，如果客户机对文档执行PUT并且成功，它可以执行相同的PUT，并且生成的文档看起来也一样。类似地，当客户机执行删除时，如果成功，对同一URI的后续删除将生成404；该资源在服务器上已不存在，因为它已被上一次删除操作删除。要维护此属性，客户端应构造其URI，以便在进行修改后，请求中的URI将指向刚刚插入以进行PUT的资源（即请求的主体），并将指向nothing以进行删除。如果维护此属性，则在这种情况下，GET到PUT中的URI将返回相同的内容（即GET（PUT（X））==X）。这个性质意味着幂等性。虽然如果请求不具有此属性，它仍然可以是幂等的，但XCAP不允许这样的请求。如果客户的请求没有
have this property, the server will reject the request with a 409 and indicate a cannot-insert error condition.
如果具有此属性，服务器将以409拒绝请求，并指示无法插入错误条件。
If the result of the PUT is a 200 or 201 response, the operation was successful. Other response codes to any request, such as a redirection, are processed as per RFC 2616 [6].
如果PUT的结果是200或201响应，则操作成功。根据RFC 2616[6]处理任何请求的其他响应代码，如重定向。
To create or replace a document, the client constructs a URI that references the location where the document is to be placed. This URI MUST be a document URI, and therefore contain the XCAP root and document selector. The client then invokes a PUT method on that URI.
要创建或替换文档，客户机将构造一个URI，该URI引用要放置文档的位置。此URI必须是文档URI，因此包含XCAP根和文档选择器。然后，客户机在该URI上调用PUT方法。
The MIME content type MUST be the type defined by the application usage. For example, it would be "application/rls-services+xml" for an RLS services [22] document, and not "application/xml".
MIME内容类型必须是应用程序用法定义的类型。例如，对于rls服务[22]文档，它将是“应用程序/rls服务+xml”，而不是“应用程序/xml”。
If the Request-URI identifies a document that already exists in the server, the PUT operation replaces that document with the content of the request. If the Request-URI does not identify an existing document, the document is created on the server at that specific URI.
如果请求URI标识服务器中已经存在的文档，则PUT操作将用请求的内容替换该文档。如果请求URI未标识现有文档，则在服务器上以该特定URI创建该文档。
To delete a document, the client constructs a URI that references the document to be deleted. This URI MUST be a document URI. The client then invokes a DELETE operation on the URI to delete the document.
要删除文档，客户端构造一个URI，该URI引用要删除的文档。此URI必须是文档URI。然后，客户端调用URI上的删除操作来删除文档。
As one would expect, fetching a document is trivially accomplished by performing an HTTP GET request with the Request URI set to the document URI.
正如人们所期望的，通过执行HTTP GET请求并将请求URI设置为文档URI，可以轻松地获取文档。
To create or replace an XML element within an existing document, the client constructs a URI whose document selector points to the document to be modified. The node selector MUST be present in the URI, delimited from the document selector with the node selector separator. The query component MUST be present if the node selector makes use of namespace prefixes, in which case, the xmlns() expressions in the query component MUST define those prefixes. To create this element within the document, the node selector is constructed such that it is a no-match against the current document, but if the element in the body of the request was added to the document as desired by the client, the node selector would select
为了在现有文档中创建或替换XML元素，客户机构造一个URI，其文档选择器指向要修改的文档。节点选择器必须存在于URI中，并用节点选择器分隔符与文档选择器分隔。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。要在文档中创建此元素，将构造节点选择器，使其与当前文档不匹配，但如果请求主体中的元素按照客户机的要求添加到文档中，则节点选择器将选择
that element. To replace an element in the document, the node selector is constructed so that it is a match against the element in the current document to be replaced, as well as a match to the new element (present in the body of the PUT request) that is to replace it.
这个元素。要替换文档中的元素，将构造节点选择器，使其与要替换的当前文档中的元素匹配，并与要替换它的新元素（位于PUT请求主体中）匹配。
Oftentimes, the client will wish to insert an element into a document in a certain position relative to other children of the same parent. This is called a positional insertion. They often arise because the schema constrains where the element can occur, or because ordering of elements is significant within the schema. To accomplish this, the client can use a node selector of the following form:
通常，客户机希望将元素插入到文档中的某个位置，相对于同一父级的其他子级。这称为位置插入。它们经常出现，因为模式限制了元素可以出现的位置，或者因为元素的顺序在模式中很重要。为此，客户端可以使用以下形式的节点选择器：
parent/*[position][unique-attribute-value]
父项/*[位置][唯一属性值]
Here, "parent" is an expression for the parent of the element to be inserted. "position" is the position amongst the existing child elements of this parent where the new element is to be inserted. "unique-attribute-value" is an attribute name and value for the element to be inserted, which is different from the current element in "position". The second predicate is needed so that the overall expression is a no-match when evaluated against the current children. Otherwise, the PUT would replace the existing element in that position. Note that in addition to wildcard "*" a QName can also be used as a node test. The insert logic is described in more detail in Section 8.2.3.
这里，“parent”是要插入的元素的父元素的表达式。“位置”是要插入新元素的父元素的现有子元素之间的位置。“唯一属性值”是要插入的元素的属性名称和值，与“位置”中的当前元素不同。需要第二个谓词，以便在对当前子级求值时，整个表达式是不匹配的。否则，PUT将替换该位置的现有元素。请注意，除了通配符“*”之外，QName还可以用作节点测试。第8.2.3节详细描述了插入逻辑。
Consider the example document in Figure 3. The client would like to insert a new <watcher> element as the second element underneath <watcher-list>. However, it cannot just PUT to a URI with the watcherinfo/watcher-list/*[2] node selector; this node selector would select the existing second child element of <watcher-list> and replace it. Thus, the PUT has to be made to a URI with watcherinfo/ watcher-list/*[2][@id="hhggff"] as the node selector, where "hhggff" is the value of the "id" attribute of the new element to be inserted. This node-selector is a no-match against the current document, and would be a match against the new element if it was inserted as the second child element of <watcher-list>.
考虑图3中的示例文档。客户端希望插入一个新的<watcher>元素作为<watcher list>下面的第二个元素。但是，它不能仅使用watcherinfo/watcher list/*[2]节点选择器将其放入URI；此节点选择器将选择<watcher list>的现有第二个子元素并替换它。因此，必须对一个URI进行PUT，其中watcherinfo/watcher list/*[2][@id=“hhggff”]作为节点选择器，其中“hhggff”是要插入的新元素的“id”属性的值。此节点选择器与当前文档不匹配，如果它作为<watcher list>的第二个子元素插入，则与新元素匹配。
The "*" indicates that all element children of <watcher-info> are to be considered when computing the position for insertion. If, instead of a wildcard *, an element name (QName) was present, the expression above would insert the new element as the position-th element amongst those with the same expanded name (see Section 8.2.3 for a discussion on insertion rules).
“*”表示在计算插入位置时要考虑<watcher info>的所有元素子元素。如果存在元素名（QName）而不是通配符*，则上述表达式将在具有相同扩展名的元素中插入新元素作为第th个元素的位置（有关插入规则的讨论，请参见第8.2.3节）。
Once the client constructs the URI, it invokes the HTTP PUT method. The content in the request MUST be an XML element. Specifically, it
一旦客户端构造URI，它就会调用HTTP PUT方法。请求中的内容必须是XML元素。具体来说
contains the element, starting with the opening bracket for the begin tag for that element, including the attributes and content of that element (whether it be text or other child elements), and ending with the closing bracket for the end tag for that element. The MIME type in the request MUST be "application/xcap-el+xml", defined in Section 15.2.1. If the node selector, when evaluated against the current document, results in a no-match, the server performs a creation operation. If the node selector, when evaluated against the current document, is a match for an element in the current document, the server replaces it with the content of the PUT request. This replacement is complete; that is, the old element (including its attributes, namespace declarations and content: text, element, comment and processing instruction nodes) are removed, and the new one, including its attributes, namespace declarations and content, is put in its place.
包含元素，从该元素的开始标记的开始括号开始，包括该元素的属性和内容（无论是文本还是其他子元素），并以该元素的结束标记的结束括号结束。请求中的MIME类型必须是第15.2.1节中定义的“application/xcap el+xml”。如果根据当前文档计算节点选择器时导致不匹配，则服务器将执行创建操作。如果对当前文档求值时，节点选择器与当前文档中的元素匹配，则服务器会将其替换为PUT请求的内容。此替换已完成；也就是说，旧元素（包括其属性、命名空间声明和内容：文本、元素、注释和处理指令节点）将被删除，而新元素（包括其属性、命名空间声明和内容）将被替换。
To be certain that element insertions have the GET(PUT(x))==x property, the client can check that the attribute predicates in the final path segment of the URI match the attributes of the element in the body of the request. As an example of a request that would not have this property, and therefore would not be idempotent, consider the following PUT request (URIs are line-folded for readability):
为了确保元素插入具有GET（PUT（x））==x属性，客户端可以检查URI的最终路径段中的属性谓词是否与请求主体中元素的属性匹配。作为不具有此属性的请求的示例，因此不会是幂等的，请考虑下面的PUT请求（URI是线性折叠的可读性）：
PUT
/rls-services/users/sip:bill@example.com/index/~~/rls-services/
service%5b@uri=%22sip:good-friends@example.com%22%5d
HTTP/1.1
Content-Type:application/xcap-el+xml
Host: xcap.example.com
PUT
/rls-services/users/sip:bill@example.com/index/~~/rls-services/
service%5b@uri=%22sip:good-friends@example.com%22%5d
HTTP/1.1
Content-Type:application/xcap-el+xml
Host: xcap.example.com
<service uri="sip:mybuddies@example.com">
<resource-list>http://xcap.example.com/resource-lists/users
/sip:joe@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
<service uri="sip:mybuddies@example.com">
<resource-list>http://xcap.example.com/resource-lists/users
/sip:joe@example.com/index/~~/resource-lists/list%5b@name=%22l1%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
This request will fail with a 409. The Request URI contains a final path segment with a predicate based on attributes: @uri="sip:good-friends@example.com". However, this will not match the value of the "uri" attribute in the element in the body (sip:mybuddies@example.com).
此请求将以409失败。请求URI包含一个最终路径段，该段带有一个基于属性的谓词：@URI=“sip:good”-friends@example.com". 但是，这与主体中元素的“uri”属性的值不匹配（sip:mybuddies@example.com).
The GET(PUT(x))==x property introduces some limitations on the types of operations possible. It will not be possible to replace an element with one that has a new value for an attribute that is the
GET（PUT（x））==x属性对可能的操作类型引入了一些限制。不可能将一个元素替换为一个具有新值的元素
sole unique element identifier, if the URI contained a node selector that was using the previous value of that attribute for purposes of selecting the element. This is exactly the use case in the example above. To get around this limitation, the selection can be done by position instead of attribute value, or the parent of the element to be replaced can be selected, and then the body of the PUT operation would contain the parent, the child to be replaced, and all other siblings.
唯一唯一的元素标识符，如果URI包含使用该属性的上一个值来选择元素的节点选择器。这正是上面示例中的用例。要绕过此限制，可以通过位置而不是属性值进行选择，或者选择要替换的元素的父元素，然后PUT操作的主体将包含父元素、要替换的子元素以及所有其他同级元素。
To delete an element from a document, the client constructs a URI whose document selector points to the document containing the element to be deleted. The node selector MUST identify a single element. The node selector MUST be present following the node selector separator, and identify the specific element to be deleted. Furthermore, the node selector MUST match no element after the deletion of the target element. This is required to maintain the idempotency property of HTTP deletions. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
要从文档中删除元素，客户端构造一个URI，其文档选择器指向包含要删除元素的文档。节点选择器必须标识单个元素。节点选择器必须位于节点选择器分隔符之后，并标识要删除的特定元素。此外，删除目标元素后，节点选择器不得与任何元素匹配。这是维护HTTP删除的幂等性属性所必需的。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
If the client wishes to delete an element in a specific position, this is referred to as a positional deletion. Like a positional insertion, the node selector has the following form:
如果客户端希望删除特定位置中的元素，这称为位置删除。与位置插入一样，节点选择器具有以下形式：
parent/*[position][unique-attribute-value]
父项/*[位置][唯一属性值]
Where "parent" is an expression for the parent of the element to be deleted, "position" is the position of the element to be deleted amongst the existing child elements of this parent, and "unique-attribute-value" is an attribute name and value for the element to be deleted, where this attribute name and value are different than any of the siblings of the element.
其中，“parent”是要删除的元素的父元素的表达式，“position”是要删除的元素在该父元素的现有子元素中的位置，“unique attribute value”是要删除的元素的属性名称和值，其中，该属性名称和值不同于元素的任何同级。
Positional deletions without using a unique attribute name and value are possible, but only in limited cases where idempotency is guaranteed. In particular, if a DELETE operation refers to an element by name and position alone (parent/elname[n]), this is permitted only when the element to be deleted is the last element amongst all its siblings with that name. Similarly, if a DELETE operation refers to an element by position alone (parent/*[n]), this is permitted only when the element to be deleted is the last amongst all sibling elements, regardless of name.
不使用唯一属性名称和值的位置删除是可能的，但只有在保证幂等性的有限情况下。特别是，如果删除操作仅按名称和位置（父/elname[n]）引用某个元素，则仅当要删除的元素是具有该名称的所有同级元素中的最后一个元素时，才允许这样做。类似地，如果删除操作仅按位置引用元素（parent/*[n]），则仅当要删除的元素是所有同级元素中的最后一个时，才允许这样做，而不管名称如何。
The client then invokes the HTTP DELETE method. The server will remove the element from the document (including its attributes,
然后，客户端调用HTTP DELETE方法。服务器将从文档中删除元素（包括其属性），
namespace declarations, and its descendant nodes, such as any children).
命名空间声明及其子节点（如任何子节点）。
To fetch an element of a document, the client constructs a URI whose document selector points to the document containing the element to be fetched. The node selector MUST be present following the node selector separator, and must identify the element to be fetched. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
为了获取文档的元素，客户机构造一个URI，其文档选择器指向包含要获取的元素的文档。节点选择器必须位于节点选择器分隔符之后，并且必须标识要提取的元素。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
The client then invokes the GET method. The 200 OK response will contain that XML element. Specifically, it contains the content of the XML document, starting with the opening bracket for the begin tag for that element, and ending with the closing bracket for the end tag for that element. This will, as a result, include all attributes, namespace declarations and descendant nodes: elements, comments, text, and processing instructions of that element.
然后，客户机调用GET方法。200OK响应将包含该XML元素。具体来说，它包含XML文档的内容，从该元素的开始标记的开始括号开始，到该元素的结束标记的结束括号结束。“处理”将包括“作为名称空间的所有元素”、“作为名称空间的所有元素”和“作为属性的所有元素”、“作为名称空间的所有元素”和“作为名称空间的所有元素”和“作为属性的处理”。
To create or replace an attribute in an existing element of a document, the client constructs a URI whose document selector points to the document to be modified. The node selector, following the node selector separator, MUST be present. The node selector MUST be constructed such that, if the attribute was created or replaced as desired, the node selector would select that attribute. If the node selector, when evaluated against the current document, results in a no-match, it is a creation operation. If it matches an existing attribute, it is a replacement operation. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
要在文档的现有元素中创建或替换属性，客户机构造一个URI，其文档选择器指向要修改的文档。节点选择器必须位于节点选择器分隔符之后。节点选择器的构造必须确保，如果根据需要创建或替换属性，则节点选择器将选择该属性。如果对当前文档求值时，节点选择器导致不匹配，则这是一个创建操作。如果它与现有属性匹配，则为替换操作。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
The client then invokes the HTTP PUT method. The content defined by the request MUST be the value of the attribute, compliant to the grammar for AttValue as defined in XML 1.0 [1]. Note that, unlike when AttValue is present in the URI, there is no percent-encoding of the body. This request MUST be sent with the Content-Type of "application/xcap-att+xml" as defined in Section 15.2.2. The server will add the attribute such that, if the node selector is evaluated on the resulting document, it will return the attribute present in the request.
然后，客户机调用HTTP PUT方法。请求定义的内容必须是属性的值，符合XML 1.0[1]中定义的AttValue语法。请注意，与URI中存在AttValue不同，主体没有百分比编码。此请求必须与第15.2.2节中定义的“应用程序/xcap att+xml”内容类型一起发送。服务器将添加属性，这样，如果节点选择器在结果文档上进行了计算，它将返回请求中存在的属性。
To be certain that attribute insertions have the GET(PUT(x))==x
property, the client can check that any attribute predicate in the
To be certain that attribute insertions have the GET(PUT(x))==x
property, the client can check that any attribute predicate in the
path segment that selects the element into which the attribute is inserted, matches a different attribute than the one being inserted by the request. As an example of a request that would not have this property, and therefore would not be idempotent, consider the following PUT request (URIs are line-folded for readability):
选择插入属性的元素的路径段与请求插入的属性不同。作为不具有此属性的请求的示例，因此不会是幂等的，请考虑下面的PUT请求（URI是线性折叠的可读性）：
PUT
/rls-services/users/sip:bill@example.com/index/~~/rls-services
/service%5b@uri=%22sip:good-friends@example.com%22%5d/@uri
HTTP/1.1
Content-Type:application/xcap-att+xml
Host: xcap.example.com
PUT
/rls-services/users/sip:bill@example.com/index/~~/rls-services
/service%5b@uri=%22sip:good-friends@example.com%22%5d/@uri
HTTP/1.1
Content-Type:application/xcap-att+xml
Host: xcap.example.com
"sip:bad-friends@example.com"
“啜：糟了-friends@example.com"
This request will fail with a 409.
此请求将以409失败。
As with element insertions and replacements, the GET(PUT(x))==x property introduces limitations on attribute replacements. It will not be possible to replace the attribute value of an attribute, when that attribute is the sole unique element identifier, and the URI contains a node selector that uses the previous value of the attribute to select the affected element. This is the use case in the example above. Instead, the element can be selected positionally, or its entire parent replaced.
与元素插入和替换一样，GET（PUT（x））==x属性引入了对属性替换的限制。如果某个属性是唯一唯一的元素标识符，并且URI包含一个节点选择器，该选择器使用该属性的上一个值来选择受影响的元素，则无法替换该属性的属性值。这是上面示例中的用例。相反，可以按位置选择图元，也可以替换其整个父图元。
To delete an attribute from the document, the client constructs a URI whose document selector points to the document containing the attribute to be deleted. The node selector MUST be present following the node selector separator, and evaluate to an attribute in the document to be deleted. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
要从文档中删除属性，客户端构造一个URI，其文档选择器指向包含要删除属性的文档。节点选择器必须位于节点选择器分隔符之后，并计算为要删除的文档中的属性。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
The client then invokes the HTTP DELETE method. The server will remove the attribute from the document.
然后，客户端调用HTTP DELETE方法。服务器将从文档中删除该属性。
To fetch an attribute of a document, the client constructs a URI whose document selector points to the document containing the attribute to be fetched. The node selector MUST be present following the node selector separator, containing an expression identifying the attribute whose value is to be fetched. The query component MUST be present if the node selector makes use of namespace prefixes, in
为了获取文档的属性，客户端构造一个URI，其文档选择器指向包含要获取的属性的文档。节点选择器必须位于节点选择器分隔符之后，包含一个表达式，用于标识要获取其值的属性。如果节点选择器使用名称空间前缀，则查询组件必须存在
which case the xmlns() expressions in the query component MUST define those prefixes.
在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
The client then invokes the GET method. The 200 OK response will contain an "application/xcap-att+xml" document with the specified attribute, formatted according to the grammar of AttValue as defined in the XML 1.0 specifications.
然后，客户机调用GET方法。200 OK响应将包含一个具有指定属性的“application/xcap att+xml”文档，该文档根据xml 1.0规范中定义的AttValue语法进行格式化。
If a client wishes to insert an element or attribute into a document, and that element or attribute is part of a namespace declared elsewhere in the document, the client will need to know the namespace bindings in order to construct the XML content in the request. If the client has a cached copy of the document, it will know the bindings. However, if it doesn't have the whole document cached, it can be useful to fetch just the bindings that are in scope for an element, in order to construct a subsequent PUT request.
如果客户机希望在文档中插入元素或属性，并且该元素或属性是文档中其他地方声明的命名空间的一部分，则客户机需要知道命名空间绑定，以便在请求中构造XML内容。如果客户端有文档的缓存副本，它将知道绑定。但是，如果它没有缓存整个文档，那么只获取元素范围内的绑定可能会很有用，以便构造后续的PUT请求。
To get those bindings, the client constructs a URI whose document selector points to the document containing the element whose namespace bindings are to be fetched. The node selector MUST be present following the node selector separator, containing an expression identifying the desired namespace bindings. The query component MUST be present if the node selector makes use of namespace prefixes, in which case the xmlns() expressions in the query component MUST define those prefixes.
为了获得这些绑定，客户机构造一个URI，其文档选择器指向包含要获取其命名空间绑定的元素的文档。节点选择器必须位于节点选择器分隔符之后，包含标识所需命名空间绑定的表达式。如果节点选择器使用名称空间前缀，则查询组件必须存在，在这种情况下，查询组件中的xmlns（）表达式必须定义这些前缀。
The client then invokes the GET method. The 200 OK response will contain an "application/xcap-ns+xml" document with the namespace definitions. The format for this document is defined in Section 10.
然后，客户机调用GET方法。200OK响应将包含一个带有名称空间定义的“application/xcap ns+xml”文档。本文件的格式见第10节。
A client cannot set the namespace prefixes in scope for an element. As such, a node selector that identifies namespace prefixes MUST NOT appear in a PUT or DELETE request.
客户端无法在元素的作用域中设置命名空间前缀。因此，标识命名空间前缀的节点选择器不得出现在PUT或DELETE请求中。
The HTTP specification defines several header fields that can be used by a client to make the processing of the request conditional. In particular, the If-None-Match and If-Match header fields allow a client to make them conditional on the current value of the entity tag for the resource. These conditional operations are particularly useful for XCAP resources.
HTTP规范定义了几个头字段，客户机可以使用这些头字段使请求的处理有条件。特别是，If None Match和If Match头字段允许客户端根据资源的实体标记的当前值设置条件。这些条件操作对于XCAP资源特别有用。
For example, it is anticipated that clients will frequently wish to cache the current version of a document. So, when the client starts up, it will fetch the current document from the server and store it.
例如，预计客户端经常希望缓存文档的当前版本。因此，当客户端启动时，它将从服务器获取当前文档并存储它。
When it does so, the GET response will contain the entity tag for the document resource. Each resource within a document maintained by the server will share the same value of the entity tag. As a result, the entity tag returned by the server for the document resource is applicable to element and attribute resources within the document.
执行此操作时，GET响应将包含文档资源的实体标记。服务器维护的文档中的每个资源将共享相同的实体标记值。因此，服务器为文档资源返回的实体标记适用于文档中的元素和属性资源。
If the client wishes to insert or modify an element or attribute within the document, but it wants to be certain that the document hasn't been modified since the client last operated on it, it can include an If-Match header field in the request, containing the value of the entity tag known to the client for all resources within the document. If the document has changed, the server will reject this request with a 412 response. In that case, the client will need to flush its cached version, fetch the entire document, and store the new entity tag returned by the server in the 200 OK to the GET request. It can then retry the request, placing the new entity tag in the If-Match header field. If this succeeds, the Etag header field in the response to PUT contains the entity tag for the resource that was just inserted or modified. Because all resources in a document share the same value for their entity tag, this entity tag value can be applied to the modification of other resources.
如果客户机希望在文档中插入或修改元素或属性，但希望确保自客户机上次对文档进行操作以来文档未被修改，则可以在请求中包含If Match头字段，该字段包含客户机已知的文档中所有资源的实体标记的值。如果文档已更改，服务器将以412响应拒绝此请求。在这种情况下，客户端将需要刷新其缓存版本，获取整个文档，并将服务器返回的新实体标记存储在200 OK to GET请求中。然后，它可以重试请求，将新的实体标记放在If Match头字段中。如果成功，PUT响应中的Etag头字段将包含刚刚插入或修改的资源的实体标记。由于文档中的所有资源共享其实体标记的相同值，因此此实体标记值可应用于其他资源的修改。
A client can also conditionally delete elements or attributes by including an If-Match header field in DELETE requests. Note that the 200 OK responses to a DELETE will contain an Etag header field, containing the entity tag for all of the other resources in the document, even though the resource identified by the DELETE request no longer exists.
客户端还可以通过在删除请求中包含If-Match头字段，有条件地删除元素或属性。请注意，对删除的200个OK响应将包含一个Etag头字段，其中包含文档中所有其他资源的实体标记，即使删除请求标识的资源不再存在。
When a client uses conditional PUT and DELETE operations, it can apply those changes to its local cached copy, and update the value of the entity tag for the locally cached copy based on the Etag header field returned in the response. As long as no other clients try to modify the document, the client will be able to perform conditional operations on the document without ever having to perform separate GET operations to synchronize the document and its entity tags with the server. If another client tries to modify the document, this will be detected by the conditional mechanisms, and the client will need to perform a GET to resynchronize its copy unless it has some other means to learn about the change.
当客户端使用条件PUT和DELETE操作时，它可以将这些更改应用于其本地缓存副本，并根据响应中返回的Etag头字段更新本地缓存副本的实体标记的值。只要没有其他客户机尝试修改文档，客户机就可以对文档执行条件操作，而无需执行单独的GET操作来将文档及其实体标记与服务器同步。如果另一个客户端尝试修改文档，则条件机制将检测到这一点，并且该客户端将需要执行GET以重新同步其副本，除非它有其他方法了解更改。
If a client does not perform a conditional operation, but did have a cached copy of the document, that cached copy will become invalid once the operation is performed (indeed, it may have become invalid even beforehand). Unconditional operations should only be performed by clients when knowledge of the entire document is not important for the operation to succeed.
如果客户机不执行条件操作，但确实拥有文档的缓存副本，那么一旦执行该操作，该缓存副本将变得无效（实际上，它甚至可能在之前就变得无效）。只有当对整个文档的了解对于操作的成功并不重要时，客户方才能执行无条件操作。
As another example, a when a client fetches a document, and there is an older version cached, it is useful for clients to use a conditional GET in order to reduce network usage if the cached copy is still valid. This is done by including, in the GET request, the If-None-Match header field with a value equal to the current etag held by the client for the document. The server will only generate a 200 OK response if the etag held by the server differs than that held by the client. If it doesn't differ, the server will respond with a 304 response.
另一个例子是，当客户机获取文档时，如果缓存的副本仍然有效，则客户机使用条件GET以减少网络使用量非常有用。这是通过在GET请求中包含If None Match header字段来完成的，该字段的值等于客户端为文档保留的当前etag。如果服务器持有的etag与客户端持有的etag不同，服务器将仅生成200 OK响应。如果没有差异，服务器将以304响应进行响应。
An XCAP server is an HTTP/1.1 compliant origin server. The behaviors mandated by this specification relate to the way in which the HTTP URI is interpreted and the content is constructed.
XCAP服务器是符合HTTP/1.1的源服务器。本规范规定的行为与解释HTTP URI和构造内容的方式有关。
An XCAP server MUST be explicitly aware of the application usage against which requests are being made. That is, the server must be explicitly configured to handle URIs for each specific application usage, and must be aware of the constraints imposed by that application usage.
XCAP服务器必须明确知道针对其发出请求的应用程序使用情况。也就是说，服务器必须显式配置为处理每个特定应用程序使用的URI，并且必须知道该应用程序使用所施加的约束。
When the server receives a request, the treatment depends on the URI. If the URI refers to an application usage not understood by the server, the server MUST reject the request with a 404 (Not Found) response. If the URI refers to a user (identified by an XUI) that is not recognized by the server, it MUST reject the request with a 404 (Not Found). If the URI includes extension-selectors that the server doesn't understand, it MUST reject the request with a 404 (Not Found).
当服务器收到请求时，处理取决于URI。如果URI指的是服务器不理解的应用程序用法，则服务器必须以404（未找到）响应拒绝该请求。如果URI引用的用户（由XUI标识）未被服务器识别，则它必须以404（未找到）拒绝请求。如果URI包含服务器不理解的扩展选择器，则必须使用404（未找到）拒绝请求。
Next, the server authenticates the request. All XCAP servers MUST implement HTTP Digest [11]. Furthermore, servers MUST implement HTTP over TLS, RFC 2818 [14]. It is RECOMMENDED that administrators use an HTTPS URI as the XCAP root URI, so that the digest client authentication occurs over TLS.
接下来，服务器对请求进行身份验证。所有XCAP服务器都必须实现HTTP摘要[11]。此外，服务器必须通过TLS实现HTTP，RFC 2818[14]。建议管理员使用HTTPS URI作为XCAP根URI，以便通过TLS进行摘要客户端身份验证。
Next, the server determines if the client has authorization to perform the requested operation on the resource. The application usage defines the authorization policies. An application usage may specify that the default is used. This default is described in Section 5.7.
接下来，服务器确定客户机是否有权对资源执行请求的操作。应用程序使用定义了授权策略。应用程序用法可能指定使用默认值。第5.7节描述了该默认值。
Next, the server makes sure that it can properly evaluate the request URI. The server MUST separate the document selector from the node selector, by splitting the URI at the first instance of the node selector separator ("~~"). The server MUST check the node selector in the request URI, if present. If any qualified names are present
接下来，服务器确保能够正确评估请求URI。服务器必须通过在节点选择器分隔符（~~）的第一个实例处拆分URI，将文档选择器与节点选择器分开。服务器必须检查请求URI中的节点选择器（如果存在）。如果存在任何限定名称
that use a namespace prefix, and that prefix is not defined in an xmlns() expression in the query component of the request URI, the server MUST reject the request with a 400 response.
如果使用名称空间前缀，并且该前缀未在请求URI的查询组件中的xmlns（）表达式中定义，则服务器必须以400响应拒绝该请求。
After checking the namespace prefix definitions, the specific behavior depends on the method and what the URI refers to.
检查名称空间前缀定义后，具体行为取决于方法和URI引用的内容。
XCAP resources do not represent processing scripts. As a result, POST operations to HTTP URIs representing XCAP resources are not defined. A server receiving such a request for an XCAP resource SHOULD return a 405.
XCAP资源不代表处理脚本。因此，未定义表示XCAP资源的HTTP URI的POST操作。接收到此类XCAP资源请求的服务器应返回405。
The behavior of a server in receipt of a PUT request is as specified in HTTP/1.1, Section 9.6 -- the content of the request is placed at the specified location. This section serves to define the notion of "placement" and "specified location" within the context of XCAP resources.
服务器在接收PUT请求时的行为如HTTP/1.1第9.6节所述——请求的内容被放置在指定的位置。本节用于定义XCAP资源上下文中的“放置”和“指定位置”的概念。
If the request URI contained a namespace-selector, the server MUST reject the request with a 405 (Method Not Allowed) and MUST include an Allow header field including the GET method.
如果请求URI包含名称空间选择器，则服务器必须使用405（不允许使用方法）拒绝请求，并且必须包含包含GET方法的Allow header字段。
The first step the server performs is to locate the parent, whether it is a directory or element, in which the resource is to be placed. To do that, the server removes the last path segment from the URI. The rest of the URI refers to the parent. This parent can be a document, element, or prefix of a document selector (called a directory, even though this specification does not mandate that documents are actually stored in a filesystem). This URI is called the parent URI. The path segment that was removed is called the target selector, and the node (element, document, or attribute) it describes is called the target node.
服务器执行的第一步是定位要放置资源的父级，无论它是目录还是元素。为此，服务器从URI中删除最后一个路径段。URI的其余部分引用父级。此父级可以是文档选择器的文档、元素或前缀（称为目录，尽管本规范并不要求文档实际存储在文件系统中）。此URI称为父URI。被删除的路径段称为目标选择器，它描述的节点（元素、文档或属性）称为目标节点。
If the parent URI has no node selector separator, it is referring to the directory into which the document should be inserted. In normal XCAP operations, this will be either the user's home directory or the global directory, which will always exist on the server. However, if an application usage is making use of subdirectories (despite the fact that this is not recommended), it is possible that the directory into which the document should be inserted does not exist. In this case, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. Detailed
如果父URI没有节点选择器分隔符，则它指的是应该插入文档的目录。在正常的XCAP操作中，这将是用户的主目录或全局目录，它们将始终存在于服务器上。但是，如果应用程序使用的是子目录（尽管不建议这样做），则文档应该插入的目录可能不存在。在这种情况下，服务器必须返回409响应，并且应该包含包含<no parent>元素的详细冲突报告。详细的
conflict reports are discussed in Section 11. If the directory does exist, the server checks to see if there is a document with the same filename as the target node. If there is, the operation is the replacement operation, discussed in Section 8.2.4. If it does not exist, it is the creation operation discussed in Section 8.2.3.
第11节讨论了冲突报告。如果目录确实存在，服务器将检查是否存在与目标节点具有相同文件名的文档。如果存在，则该操作为第8.2.4节中讨论的更换操作。如果不存在，则是第8.2.3节中讨论的创建操作。
If the parent URI has a node selector separator, the document selector is extracted, and that document is retrieved. If the document does not exist, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element. If it does exist, the node selector is extracted and decoded (recall that the node selector is percent-encoded). The node selector is applied to the document based on the matching operations discussed in Section 6.3. If the result is a no-match or invalid, the server MUST return a 409 response, and SHOULD include a detailed conflict report including the <no-parent> element.
如果父URI具有节点选择器分隔符，则提取文档选择器并检索该文档。如果文档不存在，服务器必须返回409响应，并且应该包含包含<no parent>元素的详细冲突报告。如果确实存在，则提取并解码节点选择器（回忆一下，节点选择器是百分比编码的）。根据第6.3节中讨论的匹配操作，将节点选择器应用于文档。如果结果不匹配或无效，服务器必须返回409响应，并应包含包含<no parent>元素的详细冲突报告。
If the node-selector is valid, the server examines the target selector, and evaluates it within the context of the parent node. If the target node exists within the parent, the operation is a replacement, as described in Section 8.2.4. If it does not exist, it is the creation operation, discussed in Section 8.2.3.
如果节点选择器有效，服务器将检查目标选择器，并在父节点的上下文中对其求值。如第8.2.4节所述，如果目标节点存在于父节点中，则该操作为替换。如果不存在，则为第8.2.3节中讨论的创建操作。
Before performing the replacement or creation, as determined based on the logic above, the server validates the content of the request as described in Section 8.2.2.
根据上述逻辑确定，在执行替换或创建之前，服务器将按照第8.2.2节所述验证请求的内容。
If the PUT request is for a document (the request URI had no node selector separator), the content of the request body has to be a well-formed XML document. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-well-formed> element. If the document is well-formed but not UTF-8 encoded, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element. If the MIME type in the Content-Type header field of the request is not equal to the MIME type defined for the application usage, the server MUST reject the request with a 415.
如果PUT请求是针对文档的（请求URI没有节点选择器分隔符），则请求正文的内容必须是格式良好的XML文档。如果不是，服务器必须以409响应代码拒绝请求。该响应应包括详细的冲突报告，包括<not well formed>元素。如果文档格式正确，但不是UTF-8编码的，则服务器必须使用409响应代码拒绝请求。该响应应包括详细的冲突报告，包括<not-utf-8>元素。如果请求的Content-type报头字段中的MIME类型不等于为应用程序使用定义的MIME类型，则服务器必须使用415拒绝该请求。
If the PUT request is for an element, the content of the request body has to be a well-balanced region of an XML document, also known as an XML fragment body in The XML Fragment Interchange [23] specification, including only a single element. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-xml-frag> element. If the fragment body is well-balanced but contains
如果PUT请求是针对一个元素的，那么请求主体的内容必须是XML文档的一个平衡良好的区域，在XML片段交换[23]规范中也称为XML片段主体，只包括一个元素。如果不是，服务器必须以409响应代码拒绝请求。该响应应该包括一个详细的冲突报告，其中包括<notxmlfrag>元素。如果碎片体平衡良好，但包含
characters outside of the UTF-8 character set, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element. If the MIME type in the Content-Type header field of the request is not equal to "application/xcap-el+xml", the server MUST reject the request with a 415.
在UTF-8字符集之外的字符，服务器必须使用409响应代码拒绝请求。该响应应包括详细的冲突报告，包括<not-utf-8>元素。如果请求的Content-type头字段中的MIME类型不等于“application/xcap el+xml”，则服务器必须使用415拒绝请求。
If the PUT request is for an attribute, the content of the request body has to be a sequence of characters that comply with the grammar for AttValue as defined above. If it is not, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-xml-att-value> element. If the attribute value is valid but contains characters outside of the UTF-8 character set, the server MUST reject the request with a 409 response code. That response SHOULD include a detailed conflict report including the <not-utf-8> element.If the MIME type in the Content-Type header field of the request is not equal to "application/xcap-att+xml", the server MUST reject the request with a 415.
如果PUT请求是针对属性的，则请求正文的内容必须是符合上述AttValue语法的字符序列。如果不是，服务器必须以409响应代码拒绝请求。该响应应该包括一个详细的冲突报告，其中包括<not xml att value>元素。如果属性值有效，但包含UTF-8字符集之外的字符，则服务器必须使用409响应代码拒绝请求。该响应应包括详细的冲突报告，包括<not-utf-8>元素。如果请求的Content-type头字段中的MIME类型不等于“application/xcap att+xml”，则服务器必须以415拒绝该请求。
The steps in this sub-section are followed if the PUT request will result in the creation of a new document, element, or attribute.
如果PUT请求将导致创建新文档、元素或属性，则遵循本小节中的步骤。
If the PUT request is for a document, the content of the request body is placed into the directory, and its filename is associated with the target node, which is a document.
如果PUT请求是针对文档的，则请求正文的内容将被放置到目录中，并且其文件名与目标节点（文档）相关联。
If the PUT request is for an element, the server inserts the content of the request body as a new child element of the parent element selected in Section 8.2.1. The insertion is done such that the request URI, when evaluated, would now point to the element that was inserted. There exist three possible ways in which new elements are positioned.
如果PUT请求是针对某个元素的，则服务器会将请求正文的内容作为在第8.2.1节中选择的父元素的新子元素插入。插入完成后，请求URI在计算时将指向插入的元素。新元素定位有三种可能的方式。
First, if there were no other sibling elements with the same expanded name, and the insertion is not positionally constrained, the new element is inserted such that it is the last element amongst all element siblings. Furthermore, if there were comment, text, or processing instruction nodes after the former last element, they MUST occur prior to the insertion of the new element. This case occurs when one of the following are true:
首先，如果没有具有相同扩展名的其他同级元素，并且插入不受位置约束，则插入新元素，使其成为所有同级元素中的最后一个元素。此外，如果在前一个元素之后有注释、文本或处理指令节点，则它们必须在插入新元素之前出现。当下列情况之一为真时，会发生这种情况：
o The element name in the target selector is not wildcarded. There could be an attribute selector (in which case, it would have to match an attribute of the element being inserted), and the position in the target selector will either be absent or have a
o 目标选择器中的元素名称不是通配符。可能有一个属性选择器（在这种情况下，它必须匹配要插入的元素的属性），并且目标选择器中的位置要么不存在，要么有一个
value of 1 (a value greater than 1 would always result in rejection of the request, since this is the first element with the given name underneath the parent).
值1（大于1的值将始终导致请求被拒绝，因为这是父项下具有给定名称的第一个元素）。
o The element name in the target selector is wildcarded, but there are no other elements underneath the same parent. There could be an attribute selector (in which case, it would have to match an attribute of the element being inserted), and the position in the target selector will either be absent or have a value of 1 (a value greater than 1 would always result in rejection of the request, since this is the first element underneath the parent).
o 目标选择器中的元素名称是通配符，但在同一父级下没有其他元素。可能有一个属性选择器（在这种情况下，它必须匹配要插入的元素的属性），目标选择器中的位置要么不存在，要么值为1（大于1的值将始终导致拒绝请求，因为这是父元素下的第一个元素）。
o The element name in the target selector is wildcarded, and there are other elements underneath the same parent. However, there is an attribute selector that matches none of the attributes in the other sibling elements underneath the parent, but does match an attribute of the element to be inserted. The position in the target selector is absent.
o 目标选择器中的元素名称是通配符，并且在同一父级下还有其他元素。但是，有一个属性选择器不匹配父元素下其他同级元素中的任何属性，而是匹配要插入的元素的属性。目标选择器中的位置不存在。
Secondly, if there were sibling elements with the same name already in the document, but the insertion is positionally unconstrained, the server MUST insert the element such that it is in the "earliest last" position. "Earliest last" means that the new element MUST be inserted so that there are no elements after it with the same expanded name, and for all insertion positions where this is true, it is inserted such that as many sibling nodes (element, comment, text, or processing instruction) appear after it as possible. This case occurs when the target selector is defined by a by-name or by-attr production, and there is no position indicated.
其次，如果文档中已有同名的同级元素，但插入位置不受限制，则服务器必须插入元素，使其位于“最早-最后”位置。“最早-最后一个”意味着必须插入新元素，以便新元素后面没有具有相同扩展名的元素，对于所有插入位置，如果这是真的，则插入新元素，以便尽可能多的同级节点（元素、注释、文本或处理指令）出现在新元素后面。当目标选择器由名称或attr production定义，并且没有指示位置时，就会发生这种情况。
Lastly, if the element is positionally constrained, the server MUST insert the element so that it is in the "earliest nth" position. When n>1 and NameofAny is not a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it with the same expanded name. If there are not n-1 sibling elements with the same expanded name, the request will fail. When n>1 and NameorAny is a wildcard, the element MUST be inserted so that there are n-1 sibling elements before it, each of which can have any expanded name. If there are not n-1 sibling elements in the document, the request will fail. In both of these cases, the new element is inserted such that as many sibling nodes appear after it as possible. When n=1 and
最后，如果元素受位置约束，服务器必须插入元素，使其处于“最早的第n个”位置。当n>1且NameofAny不是通配符时，必须插入元素，以便在其前面有n-1个具有相同扩展名的同级元素。如果不存在具有相同扩展名的n-1个同级元素，则请求将失败。当n>1且NameorAny是通配符时，必须插入元素，以便在其前面有n-1个同级元素，每个同级元素都可以有任何扩展名称。如果文档中没有n-1个同级元素，则请求将失败。在这两种情况下，都会插入新元素，以便尽可能多的同级节点出现在新元素之后。当n=1且
NameorAny is not a wildcard, the insertion is positionally constrained when an element with the same expanded name already appears as a child of the same parent. In this case, the new element MUST appear just before the existing first element with this same expanded name. When n=1 and NameorAny is wildcarded, the insertion is positionally constrained when there is also an attribute selector
NameorAny不是通配符，当具有相同扩展名的元素已显示为同一父元素的子元素时，插入将受到位置约束。在这种情况下，新元素必须出现在具有相同扩展名的现有第一个元素之前。当n=1且NameorAny为通配符时，如果还有属性选择器，则插入将受到位置约束
that didn't match the first sibling of the parent (if it did match, or was absent, this wouldn't have been an insertion). In this case, the new element MUST appear just before all existing elements, regardless of their expanded name.
这与父代的第一个兄弟姐妹不匹配（如果它匹配或不存在，则不会是插入）。在这种情况下，新元素必须出现在所有现有元素之前，而不管它们的展开名称如何。
In practice, this insertion logic keeps elements with the same expanded names closely together. This simplifies the application logic when the content model is described by XML schema with <sequence> rules and maxOccurs="unbounded" cardinalities, like:
实际上，这种插入逻辑将具有相同扩展名的元素紧密地放在一起。当内容模型由带有<sequence>规则和maxOccurs=“unbounded”基数的XML模式描述时，这简化了应用程序逻辑，如：
<xs:element name="foobar">
<xs:complexType>
<xs:sequence>
<xs:element ref="foo" maxOccurs="unbounded" />
<xs:element ref="bar" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="foobar">
<xs:complexType>
<xs:sequence>
<xs:element ref="foo" maxOccurs="unbounded" />
<xs:element ref="bar" maxOccurs="unbounded" />
</xs:sequence>
</xs:complexType>
</xs:element>
Based on this schema, the document contains some number of <foo> elements followed by some number of <bar> elements. Either <bar> or <foo> elements may easily be added without wildcards and positional constraints. Note that if "minOccurs" cardinality of <foo> element were zero and <foo> elements do not yet exist, a positional predicate with the * wildcard must be used.
基于此模式，文档包含一定数量的<foo>元素，后跟一定数量的<bar>元素。可以轻松添加<bar>或<foo>元素，而无需通配符和位置约束。请注意，如果<foo>元素的“minOccurs”基数为零且<foo>元素尚不存在，则必须使用带*通配符的位置谓词。
The whole insert logic is best described by complete examples. Consider the following document:
完整的示例最好地描述了整个插入逻辑。考虑以下文件：
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
A PUT request whose content is <el1 att="third"/> and whose node selector is root/el1[@att="third"] would result in the following document:
内容为<el1 att=“third”/>且节点选择器为root/el1[@att=“third”]的PUT请求将生成以下文档：
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/><el1 att="third"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/><el1 att="third"/>
<!-- comment -->
<el2 att="first"/>
</root>
Notice how it has been inserted as the third <el1> element in the document, and just before the comment and whitespace nodes. It would have been inserted in exactly the same place if the node selector had been root/el1[3][@att="third"] or root/*[3][@att="third"].
请注意，它是如何作为文档中的第三个<el1>元素插入的，就在comment和whitespace节点之前。如果节点选择器是root/el1[3][@att=“third”]或root/*[3][@att=“third”]，则它将被插入到完全相同的位置。
If the content of the request had been <el3 att="first"/> and the node selector was root/el3, it would result in the following document:
如果请求的内容为<el3 att=“first”/>且节点选择器为root/el3，则会生成以下文档：
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
<el3 att="first"/></root>
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
<el3 att="first"/></root>
A PUT request whose content is <el2 att="2"/> and whose node selector is root/el2[@att="2"] would result in the following document:
内容为<el2 att=“2”/>且节点选择器为root/el2[@att=“2”]的PUT请求将生成以下文档：
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/><el2 att="2"/>
</root>
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/><el2 att="2"/>
</root>
It would have been inserted in exactly the same place if the node selector had been root/el2[2][@att="2"]. However, a selector root/ *[2][@att="2"] would result in the following document:
如果节点选择器是root/el2[2][@att=“2”]，则它将被插入到完全相同的位置。但是，选择器root/*[2][@att=“2”]将生成以下文档：
<?xml version="1.0"?>
<root>
<el1 att="first"/><el2 att="2"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
<?xml version="1.0"?>
<root>
<el1 att="first"/><el2 att="2"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="first"/>
</root>
Lastly, if the node selector had been root/el2[1][@att="2"] the result would be:
最后，如果节点选择器是root/el2[1][@att=“2”]，结果将是：
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="2"/><el2 att="first"/>
</root>
<?xml version="1.0"?>
<root>
<el1 att="first"/>
<el1 att="second"/>
<!-- comment -->
<el2 att="2"/><el2 att="first"/>
</root>
It is possible that the element cannot be inserted such that the request URI, when evaluated, returns the content provided in the request. Such a request is not allowed for PUT. This happens when the element in the body is not described by the expression in the target selector. An example of this case is described in Section 7.4. If this happens, the server MUST NOT perform the insertion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element. It is important to note that schema compliance does not play a role while performing the insertion. That is, the decision of where the element gets inserted is dictated entirely by the structure of the request-URI, the current document, and the rules in this specification.
可能无法插入元素，从而在计算请求URI时返回请求中提供的内容。此类请求不允许用于PUT。当主体中的元素未由目标选择器中的表达式描述时，会发生这种情况。第7.4节描述了这种情况的一个例子。如果发生这种情况，服务器不能执行插入，必须以409响应拒绝请求。响应的主体应该包含一个详细的冲突报告，其中包含<cannot insert>元素。需要注意的是，在执行插入时，模式遵从性不起作用。也就是说，插入元素的位置完全由请求URI的结构、当前文档和本规范中的规则决定。
If the element being inserted (or any of its children) contain namespace declarations, those declarations are retained when the element is inserted, even if those same declarations exist in a parent element after insertion. The XCAP server MUST NOT remove redundant namespace declarations or otherwise change the namespace declarations that were present in the element being inserted.
如果要插入的元素（或其任何子元素）包含命名空间声明，则在插入元素时将保留这些声明，即使插入后父元素中存在相同的声明。XCAP服务器不得删除冗余的命名空间声明，或以其他方式更改正在插入的元素中存在的命名空间声明。
If the PUT request is for an attribute, the server inserts the content of the request body as the value of the attribute. The name of the attribute is equal to the att-name from the attribute-selector in the target selector.
如果PUT请求是针对属性的，则服务器将插入请求正文的内容作为属性的值。属性的名称等于目标选择器中属性选择器中的att名称。
Assuming that the insertion can be accomplished, the server verifies that the insertion results in a document that meets the constraints of the application usage. This is discussed in Section 8.2.5.
假设可以完成插入，服务器将验证插入是否生成满足应用程序使用约束的文档。第8.2.5节对此进行了讨论。
The steps in this sub-section are followed if the PUT request will result in the replacement of a document, element, or attribute with the contents of the request.
如果PUT请求将导致用请求内容替换文档、元素或属性，则遵循本小节中的步骤。
If the PUT request is for a document, the content of the request body is placed into the directory, replacing the document with the same filename.
如果PUT请求是针对文档的，则将请求正文的内容放入目录中，并用相同的文件名替换文档。
If the PUT request is for an element, the server replaces the target node with the content of the request body. As in the creation case, it is possible that, after replacement, the request URI does not select the element that was just inserted. If this happens, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
如果PUT请求是针对某个元素的，则服务器将用请求正文的内容替换目标节点。与创建情况一样，在替换之后，请求URI可能不会选择刚刚插入的元素。如果发生这种情况，服务器不得执行替换，并且必须以409响应拒绝请求。响应的主体应该包含一个详细的冲突报告，其中包含<cannot insert>元素。
As with creation, replacement of an element does not result in the changing or elimination of namespace declarations within the newly modified element.
与创建一样，替换元素不会导致更改或删除新修改元素中的命名空间声明。
If the PUT request is for an attribute, the server sets the value of the selected attribute to the content of the request body. It is possible in the replacement case (but not in the creation case), that, after replacement of the attribute, the request URI no longer selects the attribute that was just replaced. The scenario in which this can happen is discussed in Section 7.7. If this is the case, the server MUST NOT perform the replacement, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-insert> element.
如果PUT请求是针对属性的，则服务器将所选属性的值设置为请求正文的内容。在替换情况下（但不是在创建情况下），在替换属性之后，请求URI可能不再选择刚被替换的属性。第7.7节讨论了可能发生这种情况的场景。如果是这种情况，服务器不能执行替换，必须以409响应拒绝请求。响应的主体应该包含一个详细的冲突报告，其中包含<cannot insert>元素。
Once the document, element, or attribute has been tentatively inserted, the server needs to verify that the resulting document meets the data constraints outlined by the application usage.
暂时插入文档、元素或属性后，服务器需要验证生成的文档是否满足应用程序使用概述的数据约束。
First, the server checks that the final document is compliant with the schema. If it is not, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <schema-validation-error> element. If a schema allows for elements or attributes from other namespaces, and the new document contains elements or attributes from an unknown namespace, the server MUST allow the change. In other words, it is not necessary for an XCAP server to understand the namespaces and corresponding schemas for elements and attributes within a document, as long as the schema itself allows for such elements or attributes to be included. Of course, such unknown namespaces would not be advertised by the server in its XCAP capabilities document, discussed in Section 12.
首先，服务器检查最终文档是否符合模式。如果不是，则服务器不得执行插入。它必须以409响应拒绝请求。该响应应包含包含<schema validation error>元素的详细冲突报告。如果模式允许来自其他名称空间的元素或属性，并且新文档包含来自未知名称空间的元素或属性，则服务器必须允许更改。换句话说，XCAP服务器不需要了解文档中元素和属性的名称空间和对应模式，只要模式本身允许包含这些元素或属性。当然，服务器不会在第12节讨论的XCAP功能文档中公布此类未知名称空间。
If the final document contains elements or attributes from a namespace that the server does understand (and has consequently
如果最终文档包含来自名称空间的元素或属性，并且服务器确实理解该名称空间（因此
advertised in its XCAP capabilities document), but the server does not have the schema for that particular element or attribute, the server MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <schema-validation-error> element.
在其XCAP能力文档中公布），但服务器没有该特定元素或属性的架构，服务器必须使用409响应拒绝该请求。该响应应包含包含<schema validation error>元素的详细冲突报告。
Next, the server checks for any uniqueness constraints identified by the application usage. If the application usage required that a particular element or attribute had a unique value within a specific scope, the server would check that this uniqueness property still exists. If the application usage required that a URI within the document was unique within the domain, the server checks whether it is the case. If any of these uniqueness constraints are not met, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <uniqueness-failure> element. That element can contain suggested values that the client can use to retry. These SHOULD be values that, at the time the server generates the 409, would meet the uniqueness constraints.
接下来，服务器检查应用程序使用情况标识的任何唯一性约束。如果应用程序使用要求特定元素或属性在特定范围内具有唯一值，则服务器将检查此唯一性属性是否仍然存在。如果应用程序使用要求文档中的URI在域中是唯一的，则服务器会检查是否是唯一的。如果不满足这些唯一性约束中的任何一个，则服务器不得执行插入。它必须以409响应拒绝请求。该响应应包含包含<university failure>元素的详细冲突报告。该元素可以包含客户端可用于重试的建议值。这些值应该在服务器生成409时满足唯一性约束。
The server also checks for URI constraints and other non-schema data constraints. If the document fails one of these constraints, the server MUST NOT perform the insertion. It MUST reject the request with a 409 response. That response SHOULD contain a detailed conflict report containing the <constraint-failure> element. That element indicates that the document failed non-schema data constraints explicitly called out by the application usage.
服务器还检查URI约束和其他非架构数据约束。如果文档未通过这些约束之一，则服务器不得执行插入。它必须以409响应拒绝请求。该响应应包含包含<constraint failure>元素的详细冲突报告。该元素表示文档未通过应用程序使用明确调用的非架构数据约束。
Element or attribute removals have similar constraints. The server checks the document for schema validity and compliance to constraints defined by the application usage, and rejects the request as described above, if either check fails.
元素或属性删除具有类似的约束。服务器将检查文档的模式有效性以及是否符合应用程序使用情况定义的约束，如果其中一项检查失败，服务器将如上所述拒绝请求。
A PUT request for an XCAP resource, like any other HTTP resource, can be made conditional through usage of the If-Match and If-None-Match header fields. For a replacement, these are processed as defined in [6]. For an insertion of an element or attribute, conditional operations are permitted. The entity tag that is used for the procedures in [6] is the one for all of the resources within the same document as the parent of the element or attribute being inserted. One way to think of this is that, logically speaking, upon receipt of the PUT request, the XCAP server instantiates the etag for the resource referenced by the request, and then applies the processing of the request. Because of this behavior, it is not possible to perform a conditional insert on an attribute or element that is conditioned on the operation being an insertion and not a
与任何其他HTTP资源一样，对XCAP资源的PUT请求可以通过使用If-Match和If-None-Match头字段来设置条件。对于替换，按照[6]中的定义进行处理。对于元素或属性的插入，允许进行条件操作。[6]中用于过程的实体标记是同一文档中所有资源的实体标记，与插入的元素或属性的父级相同。考虑这一点的一种方法是，从逻辑上讲，在收到PUT请求时，XCAP服务器为请求引用的资源实例化etag，然后应用对请求的处理。由于这种行为，不可能对以操作为插入而不是插入为条件的属性或元素执行条件插入
replacement. In other words, a conditional PUT of an element or attribute with an If-None-Match: * will always fail.
替换换句话说，如果元素或属性的条件PUT与If None匹配：*将始终失败。
Because XCAP resources include elements, attributes, and documents, each of which has its own HTTP URI, the creation or modification of one resource affects the state of many others. For example, insertion of a document creates resources on the server for all of the elements and attributes within that document. After the server has performed the insertion associated with the PUT, the server MUST create and/or modify those resources affected by that PUT. The structure of the document completely defines the inter-relationship between those resources.
由于XCAP资源包括元素、属性和文档，每个元素、属性和文档都有自己的HTTP URI，因此一个资源的创建或修改会影响其他许多资源的状态。例如，插入文档会在服务器上为该文档中的所有元素和属性创建资源。服务器执行与PUT关联的插入后，服务器必须创建和/或修改受该PUT影响的资源。文档的结构完全定义了这些资源之间的相互关系。
However, the application usage can specify other resource inter-dependencies. The server MUST create or modify the resources specified by the application usage.
但是，应用程序使用情况可以指定其他资源相互依赖关系。服务器必须创建或修改应用程序使用情况指定的资源。
If the creation or replacement was successful, and the resource interdependencies are resolved, the server returns a 201 Created or 200 OK, respectively. Note that a 201 Created is generated for creation of new documents, elements, or attributes. A 200 OK response to PUT MUST not contain any content. Per the recommendations of RFC 2616, the 201 can contain a Location header field and entity that identify the resource that was created. An entity tag MUST be included in all successful responses to a PUT.
如果创建或替换成功，并且解决了资源的相互依赖关系，则服务器将分别返回201 Created或200 OK。请注意，将生成一个用于创建新文档、元素或属性的已创建文档。对PUT的200 OK响应不得包含任何内容。根据RFC 2616的建议，201可以包含一个位置头字段和实体，用于标识所创建的资源。实体标记必须包含在对PUT的所有成功响应中。
The semantics of GET are as specified in RFC 2616. This section clarifies the specific content to be returned for a particular URI that represents an XCAP resource.
GET的语义如RFC2616所述。本节阐明了为表示XCAP资源的特定URI返回的特定内容。
If the request URI contains only a document selector, the server returns the document specified by the URI if it exists, else returns a 404 response. The MIME type of the body of the 200 OK response MUST be the MIME type defined by that application usage (i.e., "application/resource-lists+xml").
如果请求URI仅包含一个文档选择器，则服务器返回URI指定的文档（如果存在），否则返回404响应。200OK响应主体的MIME类型必须是该应用程序用法定义的MIME类型（即“应用程序/资源列表+xml”）。
If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid, the server returns a 404 response. Otherwise, the server returns a 200 OK response. If the node selector identifies an XML element, that element is returned in the 200 OK response as an XML fragment body containing the selected element. The server MUST NOT add namespace
如果请求URI包含节点选择器，服务器将获取文档选择器指定的文档，如果找到该文档，则对该文档中的节点选择器进行求值。如果没有找到文档，或者节点选择器不匹配或无效，服务器将返回404响应。否则，服务器将返回200 OK响应。如果节点选择器标识一个XML元素，那么该元素将在200OK响应中作为包含所选元素的XML片段体返回。服务器不能添加命名空间
bindings representing namespaces used by the element or its children, but declared in ancestor elements; the client will either know these bindings already (since it has a cached copy of the whole document), or it can learn them by explicitly querying for the bindings. The MIME type of the response MUST be "application/xcap-el+xml". If the node selector identifies an XML attribute, the value of that attribute is returned in the body of the response. The MIME type of the response MUST be "application/xcap-att+xml". If the node selector identifies a set of namespace bindings, the server computes the set of namespace bindings in scope for the element (including the default) and encodes it using the "application/xcap-ns+xml" format defined in Section 10. That document is then returned in the body of the response.
表示元素或其子元素使用但在祖先元素中声明的名称空间的绑定；客户机要么已经知道这些绑定（因为它有整个文档的缓存副本），要么可以通过显式查询绑定来了解它们。响应的MIME类型必须是“application/xcap el+xml”。如果节点选择器标识XML属性，则该属性的值将在响应体中返回。响应的MIME类型必须是“application/xcap att+xml”。如果节点选择器标识一组名称空间绑定，服务器将计算元素范围内的名称空间绑定集（包括默认值），并使用第10节中定义的“application/xcap ns+xml”格式对其进行编码。然后在响应的主体中返回该文档。
GET operations can be conditional, and follow the procedures defined in [6].
GET操作可以是有条件的，并遵循[6]中定义的过程。
Note that the GET of a resource that was just PUT might not be octet-for-octet equivalent to what was PUT, due to XML normalization and equivalency rules.
注意，由于XML规范化和等价性规则，刚放入的资源的GET可能不是与放入的内容等效的八位字节对八位字节。
A successful response to a GET MUST include an entity tag.
对GET的成功响应必须包含实体标记。
The semantics of DELETE are as specified in RFC 2616. This section clarifies the specific content to be deleted for a particular URI that represents an XCAP resource.
DELETE的语义如RFC 2616所述。本节阐明了要为表示XCAP资源的特定URI删除的特定内容。
If the request URI contained a namespace-selector, the server MUST reject the request with a 405 (Method Not Allowed) and MUST include an Allow header field including the GET method.
如果请求URI包含名称空间选择器，则服务器必须使用405（不允许使用方法）拒绝请求，并且必须包含包含GET方法的Allow header字段。
If the request URI contains only a document selector, the server deletes the document specified by the URI if it exists and returns a 200 OK, else returns a 404 response.
如果请求URI仅包含一个文档选择器，服务器将删除URI指定的文档（如果存在），并返回200 OK，否则返回404响应。
If the request URI contains a node selector, the server obtains the document specified by the document selector, and if it is found, evaluates the node-selector within that document. If no document is found, or if the node-selector is a no-match or invalid (note that it will be invalid if multiple elements or attributes are selected), the server returns a 404 response. Otherwise, the server removes the specified element or attribute from the document and performs the validation checks defined in Section 8.2.5. Note that this deletion does not include any white space around the element that was deleted; the XCAP server MUST preserve surrounding whitespace. It is possible that, after deletion, the request URI selects another element in the
如果请求URI包含节点选择器，服务器将获取文档选择器指定的文档，如果找到该文档，则对该文档中的节点选择器进行求值。如果没有找到文档，或者如果节点选择器不匹配或无效（请注意，如果选择了多个元素或属性，则该选择器将无效），服务器将返回404响应。否则，服务器将从文档中删除指定的元素或属性，并执行第8.2.5节中定义的验证检查。请注意，此删除不包括删除的元素周围的任何空白；XCAP服务器必须保留周围的空白。删除后，请求URI可能会选择
document. If this happens, the server MUST NOT perform the deletion, and MUST reject the request with a 409 response. The body of the response SHOULD contain a detailed conflict report containing the <cannot-delete> element. If the deletion will cause a failure of one of the constraints, the deletion MUST NOT take place. The server follows the procedures in Section 8.2.5 for computing the 409 response. If the deletion results in a document that is still valid, the server MUST perform the deletion, process the resource interdependencies defined by the application usage, and return a 200 OK response.
文件如果发生这种情况，服务器不得执行删除，并且必须以409响应拒绝请求。响应的主体应该包含一个详细的冲突报告，其中包含<cannotdelete>元素。如果删除将导致其中一个约束失效，则不得进行删除。服务器按照第8.2.5节中的程序计算409响应。如果删除导致文档仍然有效，则服务器必须执行删除，处理由应用程序使用情况定义的资源相关性，并返回200 OK响应。
DELETE operations can be conditional, and follow the procedures defined in [6].
删除操作可以是有条件的，并遵循[6]中定义的过程。
Before the server returns the 200 OK response to a DELETE, it MUST process the resource interdependencies as defined in Section 8.2.7. As long as the document still exists after the delete operation, any successful response to DELETE MUST include the entity tag of the document.
在服务器返回对删除的200 OK响应之前，它必须处理第8.2.7节中定义的资源相互依赖关系。只要文档在删除操作后仍然存在，任何成功的删除响应都必须包含文档的实体标记。
An XCAP server MUST maintain entity tags for all resources that it maintains. This specification introduces the additional constraint that when one resource within a document (including the document itself) changes, that resource is assigned a new etag, and all other resources within that document MUST be assigned the same etag value. Effectively, there is a single etag for the entire document. An XCAP server MUST include the Etag header field in all 200 or 201 responses to PUT, GET, and DELETE, assuming the document itself still exists after the operation. In the case of a DELETE, the entity tag refers to the value of the entity tag for the document after the deletion of the element or attribute.
XCAP服务器必须维护其维护的所有资源的实体标记。本规范引入了一个附加约束，即当文档中的一个资源（包括文档本身）发生更改时，将为该资源分配一个新的etag，并且必须为该文档中的所有其他资源分配相同的etag值。实际上，整个文档只有一个etag。XCAP服务器必须在所有200或201个PUT、GET和DELETE响应中包含Etag头字段，前提是操作后文档本身仍然存在。在删除的情况下，实体标记是指删除元素或属性后文档的实体标记的值。
XCAP resources do not introduce new requirements on the strength of the entity tags.
XCAP资源不会对实体标记的强度提出新的要求。
As a result of this constraint, when a client makes a change to an element or attribute within a document, the response to that operation will convey the entity tag of the resource that was just affected. Since the client knows that this entity tag value is shared by all of the other resources in the document, the client can make conditional requests against other resources using that entity tag.
由于此约束，当客户端对文档中的元素或属性进行更改时，对该操作的响应将传递刚刚受影响的资源的实体标记。由于客户端知道该实体标记值由文档中的所有其他资源共享，因此客户端可以使用该实体标记对其他资源发出有条件的请求。
An XCAP resource is a valid HTTP resource, and therefore, it can be cached by clients and network caches. Network caches, however, will not be aware of the interdependencies between XCAP resources. As such, a change to an element in a document by a client will invalidate other XCAP resources affected by the change. For application usages containing data that is likely to be dynamic or written by clients, servers SHOULD indicate a no-cache directive.
XCAP资源是有效的HTTP资源，因此可以由客户端和网络缓存缓存。但是，网络缓存不会知道XCAP资源之间的相互依赖关系。因此，客户端对文档中元素的更改将使受此更改影响的其他XCAP资源无效。对于包含可能是动态数据或由客户端写入的数据的应用程序使用，服务器应指示no cache指令。
A node-selector can identify a set of namespace bindings that are in scope for a particular element. In order to convey these bindings in a GET response, a way is needed to encode them.
节点选择器可以标识特定元素范围内的一组命名空间绑定。为了在GET响应中传递这些绑定，需要对它们进行编码。
Encoding is trivially done by including a single XML element in an XML fragment body. This element has the same local-name as the element whose namespace bindings are desired, and also the same namespace-prefix. The element has an xmlns attribute identifying the default namespace in scope, and an xmlns:prefix declaration for each prefix that is in scope.
编码是通过在XML片段体中包含单个XML元素来完成的。此元素与需要名称空间绑定的元素具有相同的本地名称，并且具有相同的名称空间前缀。元素有一个xmlns属性，标识作用域中的默认名称空间，并为作用域中的每个前缀声明一个xmlns:prefix。
For example, consider the XML document in Section 6.4. The node-selector df:foo/df2:bar/df2:baz/namespace::* will select the namespaces in scope for the <baz> element in the document, assuming the request is accompanied by a query component that contains xmlns(df=urn:test:default-namespace) and xmlns(df2=urn:test:namespace1-uri). A GET containing this node selector and namespace bindings will produce the following result:
例如，在第6.4节中考虑XML文档。节点选择器df:foo/df2:bar/df2:baz/namespace:：*将为文档中的<baz>元素选择范围内的名称空间，假设请求伴随一个包含xmlns（df=urn:test:default namespace）和xmlns（df2=urn:test:namespace1uri）的查询组件。包含此节点选择器和命名空间绑定的GET将生成以下结果：
<baz xmlns="urn:test:namespace1-uri"
xmlns:ns1="urn:tes:namespace1-uri"/>
<baz xmlns="urn:test:namespace1-uri"
xmlns:ns1="urn:tes:namespace1-uri"/>
It is important to note that the client does not need to know the actual namespace bindings in order to construct the URI. It does need to know the namespace URI for each element in the node-selector. The namespace bindings present in the query component are defined by the client, mapping those URIs to a set of prefixes. The bindings returned by the server are the actual bindings used in the document.
需要注意的是，客户端不需要知道实际的命名空间绑定就可以构造URI。它确实需要知道节点选择器中每个元素的名称空间URI。查询组件中存在的命名空间绑定由客户端定义，将这些URI映射到一组前缀。服务器返回的绑定是文档中使用的实际绑定。
In cases where the server returns a 409 error response, that response will usually include a document in the body of the response which provides further details on the nature of the error. This document is an XML document, formatted according to the schema of
在服务器返回409错误响应的情况下，该响应通常会在响应正文中包含一个文档，该文档提供有关错误性质的进一步详细信息。此文档是一个XML文档，根据
Section 11.2. Its MIME type, registered by this specification, is "application/xcap-error+xml".
第11.2节。其MIME类型由本规范注册，为“application/xcap error+xml”。
The document structure is simple. It contains the root element <xcap-error>. The content of this element is a specific error condition. Each error condition is represented by a different element. This allows for different error conditions to provide different data about the nature of the error. All error elements support a "phrase" attribute, which can contain text meant for rendering to a human user.
文档结构很简单。它包含根元素<xcap error>。此元素的内容是特定的错误条件。每个错误条件由不同的元素表示。这允许不同的错误条件提供有关错误性质的不同数据。所有错误元素都支持“短语”属性，该属性可以包含用于呈现给人类用户的文本。
The following error elements are defined by this specification:
本规范定义了以下错误元素：
<not-well-formed>: This indicates that the body of the request was not a well-formed XML document.
<not well format>：这表示请求主体不是格式良好的XML文档。
<not-xml-frag>: This indicates that the request was supposed to contain a valid XML fragment body, but did not. Most likely this is because the XML in the body was malformed or not balanced.
<not xml frag>：这表示请求应该包含有效的xml片段主体，但没有。这很可能是因为正文中的XML格式不正确或不平衡。
<no-parent>: This indicates that an attempt to insert a document, element, or attribute failed because the directory, document, or element into which the insertion was supposed to occur does not exist. This error element can contain an optional <ancestor> element, which provides an HTTP URI that represents the closest parent that would be a valid point of insertion. This HTTP URI MAY be a relative URI, relative to the document itself. Because this is a valid HTTP URI, its node selector component MUST be percent-encoded.
<no parent>：这表示插入文档、元素或属性的尝试失败，因为应该插入的目录、文档或元素不存在。此错误元素可以包含可选的<祖先>元素，该元素提供一个HTTP URI，该URI表示最接近的父级，该父级将是有效的插入点。此HTTP URI可能是相对于文档本身的相对URI。因为这是一个有效的HTTP URI，所以它的节点选择器组件必须进行百分比编码。
<schema-validation-error>: This element indicates that the document was not compliant to the schema after the requested operation was performed.
<schema validation error>：此元素表示执行请求的操作后文档不符合架构。
<not-xml-att-value>: This indicates that the request was supposed to contain a valid XML attribute value, but did not.
<not xml att value>：这表示请求应该包含有效的xml属性值，但没有。
<cannot-insert>: This indicates that the requested PUT operation could not be performed because a GET of that resource after the PUT would not yield the content of the PUT request.
<cannot insert>：这表示无法执行请求的PUT操作，因为PUT之后对该资源的GET不会生成PUT请求的内容。
<cannot-delete>: This indicates that the requested DELETE operation could not be performed because it would not be idempotent.
<无法删除>：这表示无法执行请求的删除操作，因为它不是幂等的。
<uniqueness-failure>: This indicates that the requested operation would result in a document that did not meet a uniqueness constraint defined by the application usage. For each URI, element, or attribute specified by the client that is not unique, an <exists> element is present as the content of the error element. Each <exists> element has a "field" attribute that contains a relative URI identifying the XML element or attribute whose value needs to be unique, but wasn't. The relative URI is relative to the document itself, and will therefore start with the root element. The query component of the URI MUST be present if the node selector portion of the URI contains namespace prefixes. Since the "field" node selector is a valid HTTP URI, it MUST be percent-encoded. The <exists> element can optionally contain a list of <alt-value> elements. Each one is a suggested alternate value that does not currently exist on the server.
<university failure>：这表示请求的操作将导致文档不满足应用程序用法定义的唯一性约束。对于客户端指定的每个非唯一URI、元素或属性，<exists>元素作为错误元素的内容存在。每个<exists>元素都有一个“field”属性，该属性包含一个相对URI，用于标识XML元素或属性，该元素或属性的值必须是唯一的，但不是唯一的。相对URI是相对于文档本身的，因此将从根元素开始。如果URI的节点选择器部分包含名称空间前缀，则必须存在URI的查询组件。由于“字段”节点选择器是有效的HTTP URI，因此必须对其进行百分比编码。<exists>元素可以选择包含<alt value>元素的列表。每个值都是服务器上当前不存在的建议备用值。
<constraint-failure>: This indicates that the requested operation would result in a document that failed a data constraint defined by the application usage, but not enforced by the schema or a uniqueness constraint.
<constraint failure>：这表示请求的操作将导致文档未通过应用程序使用情况定义的数据约束，但架构或唯一性约束未强制执行。
<extension>: This indicates an error condition that is defined by an extension to XCAP. Clients that do not understand the content of the extension element MUST discard the xcap-error document and treat the error as an unqualified 409.
<extension>：这表示由XCAP的扩展定义的错误条件。不理解扩展元素内容的客户端必须丢弃xcap错误文档，并将错误视为不合格的409。
<not-utf-8>: This indicates that the request could not be completed because it would have produced a document not encoded in UTF-8.
<not-utf-8>：这表示请求无法完成，因为它将生成一个未编码为utf-8的文档。
As an example, the following document indicates that the user attempted to create an RLS service using the URI sip:friends@example.com, but that URI already exists:
例如，以下文档表示用户试图使用URI sip创建RLS服务：friends@example.com，但该URI已存在：
<?xml version="1.0" encoding="UTF-8"?>
<xcap-error xmlns="urn:ietf:params:xml:ns:xcap-error">
<uniqueness-failure>
<exists field="rls-services/service/@uri">
<alt-value>sip:mybuddies@example.com</alt-value>
</exists>
</uniqueness-failure>
</xcap-error>
<?xml version="1.0" encoding="UTF-8"?>
<xcap-error xmlns="urn:ietf:params:xml:ns:xcap-error">
<uniqueness-failure>
<exists field="rls-services/service/@uri">
<alt-value>sip:mybuddies@example.com</alt-value>
</exists>
</uniqueness-failure>
</xcap-error>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error"
xmlns="urn:ietf:params:xml:ns:xcap-error"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-error"
xmlns="urn:ietf:params:xml:ns:xcap-error"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:element name="error-element" abstract="true"/>
<xs:element name="xcap-error">
<xs:annotation>
<xs:documentation>Indicates the reason for the error.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="error-element"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="error-element" abstract="true"/>
<xs:element name="xcap-error">
<xs:annotation>
<xs:documentation>Indicates the reason for the error.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element ref="error-element"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extension" substitutionGroup="error-element">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extension" substitutionGroup="error-element">
<xs:complexType>
<xs:sequence>
<xs:any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="schema-validation-error"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This element indicates
that the document was not compliant to the schema after the requested
operation was performed.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="schema-validation-error"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This element indicates
that the document was not compliant to the schema after the requested
operation was performed.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-xml-frag" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the request was supposed to
contain a valid XML fragment body, but did not.</xs:documentation>
</xs:annotation>
<xs:element name="not-xml-frag" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the request was supposed to
contain a valid XML fragment body, but did not.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="no-parent" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that an attempt to insert
an element, attribute, or document failed because the document or
element into which the insertion was
supposed to occur does not exist.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ancestor" type="xs:anyURI" minOccurs="0">
<xs:annotation>
<xs:documentation>Contains an HTTP URI that points to the
element that is the closest ancestor that does exist.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="no-parent" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that an attempt to insert
an element, attribute, or document failed because the document or
element into which the insertion was
supposed to occur does not exist.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="ancestor" type="xs:anyURI" minOccurs="0">
<xs:annotation>
<xs:documentation>Contains an HTTP URI that points to the
element that is the closest ancestor that does exist.
</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="cannot-insert" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the requested
PUT operation could not be performed because a GET of that resource
after the PUT would not yield the content of the PUT request.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="cannot-insert" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the requested
PUT operation could not be performed because a GET of that resource
after the PUT would not yield the content of the PUT request.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-xml-att-value"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
request was supposed to contain a valid XML attribute value, but did
not.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
<xs:element name="not-xml-att-value"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
request was supposed to contain a valid XML attribute value, but did
not.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:element>
<xs:element name="uniqueness-failure"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
requested operation would result in a document that did not meet a
uniqueness constraint defined by the application usage.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="exists" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>For each URI,
element, or attribute specified by the client that is not unique,
one of these is present.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:element name="alt-value" type="xs:string"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An optional set of alternate values can be
provided.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="field" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="uniqueness-failure"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
requested operation would result in a document that did not meet a
uniqueness constraint defined by the application usage.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="exists" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>For each URI,
element, or attribute specified by the client that is not unique,
one of these is present.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0">
<xs:element name="alt-value" type="xs:string"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>An optional set of alternate values can be
provided.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
<xs:attribute name="field" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-well-formed"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the body of the request was
not a well-formed document.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-well-formed"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the body of the request was
not a well-formed document.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="constraint-failure"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
requested operation would result in a document that failed a data
constraint defined by the application usage, but not enforced by the
schema or a uniqueness constraint.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="constraint-failure"
substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the
requested operation would result in a document that failed a data
constraint defined by the application usage, but not enforced by the
schema or a uniqueness constraint.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="cannot-delete" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the requested DELETE
operation could not be performed because it would not be
idempotent.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="cannot-delete" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the requested DELETE
operation could not be performed because it would not be
idempotent.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
<xs:element name="not-utf-8" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the request could not be
completed because it would have produced a document not
encoded in UTF-8.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:element name="not-utf-8" substitutionGroup="error-element">
<xs:annotation>
<xs:documentation>This indicates that the request could not be
completed because it would have produced a document not
encoded in UTF-8.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:attribute name="phrase" type="xs:string" use="optional"/>
</xs:complexType>
</xs:element>
</xs:schema>
XCAP can be extended through the addition of new application usages and extensions to the core protocol. Application usages may define MIME types with XML schemas that allow new extension nodes from new namespaces. It will often be necessary for a client to determine what extensions, application usages, or namespaces a server supports before making a request. To enable that, this specification defines an application usage with the AUID "xcap-caps". All XCAP servers MUST support this application usage. This usage defines a single
XCAP可以通过向核心协议添加新的应用程序用法和扩展来扩展。应用程序使用可以使用XML模式定义MIME类型，允许新名称空间中的新扩展节点。在发出请求之前，客户端通常需要确定服务器支持哪些扩展、应用程序用途或名称空间。为了实现这一点，本规范使用AUID“xcap caps”定义了一个应用程序用法。所有XCAP服务器都必须支持此应用程序使用。此用法定义了单个
document within the global tree that lists the capabilities of the server. Clients can read this well-known document, and therefore learn the capabilities of the server.
全局树中列出服务器功能的文档。客户机可以阅读这个众所周知的文档，从而了解服务器的功能。
The structure of the document is simple. The root element is <xcap-caps>. Its children are <auids>, <extensions>, and <namespaces>. Each of these contain a list of AUIDs, extensions, and namespaces supported by the server. Extensions are named by tokens defined by the extension, and typically define new selectors. Namespaces are identified by their namespace URI. To 'support' a namespace, the server must have the schemas for all elements within that namespace, and be able to validate them if they appear within documents. Since all XCAP servers support the "xcap-caps" AUID, it MUST be listed in the <auids> element, and the "urn:ietf:params:xml:ns:xcap-caps" namespace MUST be listed in the <namespaces> element.
文件的结构很简单。根元素是<xcaps>。它的子项是<auid>、<extensions>和<namespace>。其中每一个都包含服务器支持的AUID、扩展和名称空间的列表。扩展名由扩展名定义的标记命名，通常定义新的选择器。名称空间由其名称空间URI标识。要“支持”名称空间，服务器必须具有该名称空间中所有元素的架构，并且如果它们出现在文档中，则能够验证它们。由于所有XCAP服务器都支持“XCAP caps”AUID，因此它必须列在<auids>元素中，并且“urn:ietf:params:xml:ns:xcaps”命名空间必须列在<namespaces>元素中。
The following sections provide the information needed to define this application usage.
以下各节提供了定义此应用程序用法所需的信息。
This specification defines the "xcap-caps" AUID within the IETF tree, via the IANA registration in Section 15.
本规范通过第15节中的IANA注册，定义IETF树中的“xcap caps”AUID。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-caps"
xmlns="urn:ietf:params:xml:ns:xcap-caps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="xcap-caps">
<xs:annotation>
<xs:documentation>Root element for xcap-caps</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="auids">
<xs:annotation>
<xs:documentation>List of supported AUID.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="auid" type="auidType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extensions" minOccurs="0">
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:xcap-caps"
xmlns="urn:ietf:params:xml:ns:xcap-caps"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="xcap-caps">
<xs:annotation>
<xs:documentation>Root element for xcap-caps</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:element name="auids">
<xs:annotation>
<xs:documentation>List of supported AUID.</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="auid" type="auidType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="extensions" minOccurs="0">
<xs:annotation>
<xs:documentation>List of supported extensions.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="extension" type="extensionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="namespaces">
<xs:annotation>
<xs:documentation>List of supported namespaces.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="namespace" type="namespaceType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="auidType">
<xs:annotation>
<xs:documentation>AUID Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="extensionType">
<xs:annotation>
<xs:documentation>Extension Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="namespaceType">
<xs:annotation>
<xs:documentation>Namespace type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema>
<xs:annotation>
<xs:documentation>List of supported extensions.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="extension" type="extensionType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="namespaces">
<xs:annotation>
<xs:documentation>List of supported namespaces.
</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="namespace" type="namespaceType"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="auidType">
<xs:annotation>
<xs:documentation>AUID Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="extensionType">
<xs:annotation>
<xs:documentation>Extension Type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="namespaceType">
<xs:annotation>
<xs:documentation>Namespace type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema>
The default document namespace used in evaluating a URI is urn:ietf:params:xml:ns:xcap-caps.
评估URI时使用的默认文档命名空间是urn:ietf:params:xml:ns:xcap。
Documents conformant to this schema are known by the MIME type "application/xcap-caps+xml", registered in Section 15.2.5.
符合此模式的文档由MIME类型“application/xcaps+xml”所知，该类型在第15.2.5节中注册。
There are no additional validation constraints associated with this application usage.
没有与此应用程序使用相关的其他验证约束。
Data semantics are defined above.
上面定义了数据语义。
A server MUST maintain a single instance of the document in the global tree, using the filename "index". There MUST NOT be an instance of this document in the user's tree.
服务器必须使用文件名“index”在全局树中维护文档的单个实例。用户树中不得有此文档的实例。
There are no resource interdependencies in this application usage beyond those defined by the schema.
此应用程序使用中没有超出架构定义的资源依赖关系。
This application usage does not change the default authorization policy defined by XCAP.
此应用程序使用不会更改XCAP定义的默认授权策略。
This section goes through several examples, making use of the resource-lists and rls-services [22] XCAP application usages.
本节将介绍几个示例，使用资源列表和rls服务[22]XCAP应用程序用法。
First, a user Bill creates a new document (see Section 7.1). This document is a new resource-list, initially with a single list, called friends, with no users in it:
首先，用户账单创建一个新文档（参见第7.1节）。此文档是一个新的资源列表，最初只有一个名为friends的列表，其中没有用户：
PUT
/resource-lists/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/resource-lists+xml
Host: xcap.example.com
PUT
/resource-lists/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/resource-lists+xml
Host: xcap.example.com
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
</list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
</list>
</resource-lists>
Figure 24: New Document
图24：新文档
Next, Bill creates an RLS services document defining a single RLS service referencing this list. This service has a URI of sip:myfriends@example.com (URIs are line-folded for readability):
接下来，Bill创建一个RLS服务文档，定义引用此列表的单个RLS服务。此服务的URI为sip:myfriends@example.com（为了便于阅读，URI是折线的）：
PUT
/rls-services/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/rls-services+xml
Host: xcap.example.com
PUT
/rls-services/users/sip:bill@example.com/index HTTP/1.1
Content-Type:application/rls-services+xml
Host: xcap.example.com
<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services">
<service uri="sip:myfriends@example.com">
<resource-list>http://xcap.example.com/resource-lists/users/
sip:bill@example.com/index/~~/resource-lists/
list%5b@name=%22friends%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
<?xml version="1.0" encoding="UTF-8"?>
<rls-services xmlns="urn:ietf:params:xml:ns:rls-services">
<service uri="sip:myfriends@example.com">
<resource-list>http://xcap.example.com/resource-lists/users/
sip:bill@example.com/index/~~/resource-lists/
list%5b@name=%22friends%22%5d
</resource-list>
<packages>
<package>presence</package>
</packages>
</service>
</rls-services>
Figure 25: RLS Services Example
图25:RLS服务示例
Next, Bill creates an element in the resource-lists document (Section 7.4). In particular, he adds an entry to the list:
接下来，Bill在资源列表文档中创建一个元素（第7.4节）。特别是，他在列表中添加了一个条目：
PUT
/resource-lists/users/sip:bill@example.com/index
/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
Content-Type:application/xcap-el+xml
Host: xcap.example.com
PUT
/resource-lists/users/sip:bill@example.com/index
/~~/resource-lists/list%5b@name=%22friends%22%5d/entry HTTP/1.1
Content-Type:application/xcap-el+xml
Host: xcap.example.com
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry>
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry>
Figure 26: Resource Lists Document
图26：资源列表文档
Next, Bill fetches the document (Section 7.3):
接下来，Bill获取文档（第7.3节）：
GET
/resource-lists/users/sip:bill@example.com/index HTTP/1.1
GET
/resource-lists/users/sip:bill@example.com/index HTTP/1.1
Figure 27: Fetch Operation
图27：获取操作
And the result is (note how white space text nodes appear in the document):
结果是（注意文档中空白文本节点的显示方式）：
HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/resource-lists+xml
HTTP/1.1 200 OK
Etag: "wwhha"
Content-Type: application/resource-lists+xml
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry></list>
</resource-lists>
<?xml version="1.0" encoding="UTF-8"?>
<resource-lists xmlns="urn:ietf:params:xml:ns:resource-lists">
<list name="friends">
<entry uri="sip:bob@example.com">
<display-name>Bob Jones</display-name>
</entry></list>
</resource-lists>
Figure 28: Results of Fetch
图28：获取的结果
Next, Bill adds another entry to the list, which is another list that has three entries. This is another element creation (Section 7.4):
接下来，Bill向列表中添加另一个条目，这是另一个包含三个条目的列表。这是另一个元素创建（第7.4节）：
PUT
/resource-lists/users/sip:bill@example.com/index/~~/
resource-lists/list%5b@name=%22friends%22%5d/
list%5b@name=%22close-friends%22%5d HTTP/1.1
Content-Type: application/xcap-el+xml
Host: xcap.example.com
PUT
/resource-lists/users/sip:bill@example.com/index/~~/
resource-lists/list%5b@name=%22friends%22%5d/
list%5b@name=%22close-friends%22%5d HTTP/1.1
Content-Type: application/xcap-el+xml
Host: xcap.example.com
<list name="close-friends">
<entry uri="sip:joe@example.com">
<display-name>Joe Smith</display-name>
</entry>
<entry uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name>
</entry>
<entry uri="sip:petri@example.com">
<display-name>Petri Aukia</display-name>
</entry>
</list>
<list name="close-friends">
<entry uri="sip:joe@example.com">
<display-name>Joe Smith</display-name>
</entry>
<entry uri="sip:nancy@example.com">
<display-name>Nancy Gross</display-name>
</entry>
<entry uri="sip:petri@example.com">
<display-name>Petri Aukia</display-name>
</entry>
</list>
Figure 29: Adding an Entry
图29：添加条目
Then, Bill decides he doesn't want Petri on the list, so he deletes the entry (Section 7.5):
然后，Bill决定他不想让Petri出现在列表中，因此他删除了条目（第7.5节）：
DELETE
/resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/
entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1
Host: xcap.example.com
DELETE
/resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/
entry%5b@uri=%22sip:petri@example.com%22%5d HTTP/1.1
Host: xcap.example.com
Figure 30: Deleting an Entry
图30：删除条目
Bill decides to check on the URI for Nancy, so he fetches a particular attribute (Section 7.6):
Bill决定检查Nancy的URI，因此他获取一个特定属性（第7.6节）：
GET
/resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1
Host: xcap.example.com
GET
/resource-lists/users/sip:bill@example.com/index/
~~/resource-lists/list/list/entry%5b2%5d/@uri HTTP/1.1
Host: xcap.example.com
Figure 31: Fetching an Attribute
图31：获取属性
and the server responds:
服务器响应：
HTTP/1.1 200 OK
Etag: "ad88"
Content-Type:application/xcap-att+xml
HTTP/1.1 200 OK
Etag: "ad88"
Content-Type:application/xcap-att+xml
"sip:nancy@example.com"
“sip：nancy@example.com"
Figure 32: Results of Fetch
图32：获取的结果
Frequently, the data manipulated by XCAP contains sensitive information. To avoid eavesdroppers from seeing this information, it is RECOMMENDED that an administrator hand out an HTTPS URI as the XCAP root URI. This will result in TLS-encrypted communications between the client and server, preventing any eavesdropping. Clients MUST implement TLS, assuring that such URIs will be usable by the client.
通常，XCAP处理的数据包含敏感信息。为了避免窃听者看到此信息，建议管理员将HTTPS URI作为XCAP根URI分发。这将导致客户机和服务器之间的TLS加密通信，防止任何窃听。客户机必须实现TLS，以确保此类URI可供客户机使用。
Client and server authentication are also important. A client needs to be sure it is talking to the server it believes it is contacting. Otherwise, it may be given false information, which can lead to denial-of-service attacks against a client. To prevent this, a client SHOULD attempt to upgrade [15] any connections to TLS. Similarly, authorization of read and write operations against the data is important, and this requires client authentication. As a
客户端和服务器身份验证也很重要。客户端需要确保它正在与它认为正在联系的服务器通信。否则，可能会向其提供虚假信息，从而导致针对客户端的拒绝服务攻击。为了防止这种情况，客户端应尝试升级[15]到TLS的任何连接。类似地，对数据进行读写操作的授权也很重要，这需要客户端身份验证。作为一个
result, a server SHOULD challenge a client using HTTP Digest [11] to establish its identity, and this SHOULD be done over a TLS connection. Clients MUST implement digest authentication, assuring interoperability with servers that challenge the client. Servers MUST NOT perform basic authentication without a TLS connection to the client.
结果，服务器应该使用HTTP摘要[11]向客户机发起挑战以建立其标识，这应该通过TLS连接完成。客户端必须实现摘要身份验证，以确保与挑战客户端的服务器的互操作性。没有与客户端的TLS连接，服务器不得执行基本身份验证。
Because XCAP is a usage of HTTP and not a separate protocol, it runs on the same port numbers as HTTP traffic normally does. This makes it difficult to apply port-based filtering rules in firewalls to separate the treatment of XCAP traffic from other HTTP traffic.
因为XCAP是HTTP的一种用法，而不是一种单独的协议，所以它与HTTP流量通常在相同的端口号上运行。这使得很难在防火墙中应用基于端口的过滤规则来将XCAP流量的处理与其他HTTP流量分开。
However, this problem exists broadly today because HTTP is used to access a wide breadth of content, all on the same port, and XCAP views application configuration documents as just another type of HTTP content. As such, separate treatment of XCAP traffic from other HTTP traffic requires firewalls to examine the URL itself. There is no foolproof way to identify a URL as pointing to an XCAP resource. However, the presence of the double tilde (~~) is a strong hint that the URL points to an XML element or attribute. As always, care must be taken in looking for the double-tilde due to the breadth of ways in which a URI can be encoded on-the-wire [29] [13].
然而，这个问题现在广泛存在，因为HTTP用于访问广泛的内容，所有内容都在同一个端口上，并且XCAP将应用程序配置文档视为另一种类型的HTTP内容。因此，将XCAP流量与其他HTTP流量分开处理需要防火墙检查URL本身。没有简单的方法可以将URL标识为指向XCAP资源。但是，双波浪号（~~）的存在强烈暗示URL指向XML元素或属性。与往常一样，由于URI可以在线路上进行编码的方式非常广泛，因此在寻找双瓷砖时必须小心[29][13]。
There are several IANA considerations associated with this specification.
与本规范相关的IANA注意事项有几个。
Per this specification's instructions, IANA created a new registry for XCAP application unique IDs (AUIDs). This registry is defined as a table that contains three columns:
根据本规范的说明，IANA为XCAP应用程序唯一ID（AUID）创建了一个新的注册表。此注册表定义为包含三列的表：
AUID: This will be a string provided in the IANA registrations into the registry.
AUID：这将是IANA注册表中提供的字符串。
Description: This is text that is supplied by the IANA registration into the registry.
描述：这是IANA注册到注册表中提供的文本。
Reference: This is a reference to the RFC containing the registration.
参考：这是对包含注册的RFC的参考。
Per this specification's instructions, IANA created this table with an initial entry. The resulting table looks like:
根据本规范的说明，IANA使用初始条目创建了此表。生成的表如下所示：
Application Unique
ID (AUID) Description Reference
-------------------- ------------------------------- ---------
xcap-caps Capabilities of an XCAP server RFC 4825
Application Unique
ID (AUID) Description Reference
-------------------- ------------------------------- ---------
xcap-caps Capabilities of an XCAP server RFC 4825
XCAP AUIDs are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication.
XCAP AUID在标准跟踪RFC中发布时由IANA注册。RFC的IANA注意事项部分必须包括以下信息，这些信息与出版物的RFC编号一起出现在IANA注册表中。
o Name of the AUID. The name MAY be of any length, but SHOULD be no more than 20 characters long. The name MUST consist of alphanum and mark [16] characters only.
o AUID的名称。名称可以是任意长度，但长度不得超过20个字符。名称只能由alphanum和mark[16]字符组成。
o Descriptive text that describes the application usage.
o 描述应用程序用法的描述性文本。
This specification requests the registration of several new MIME types according to the procedures of RFC 4288 [8] and guidelines in RFC 3023 [9].
本规范要求根据RFC 4288[8]的程序和RFC 3023[9]中的指南注册几种新的MIME类型。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-el+xml
MIME子类型名称：xcap el+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
可选参数：与RFC 3023[9]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
编码注意事项：与RFC 3023[9]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [9].
安全注意事项：见RFC 3023[9]第10节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4825
已发布规范：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML fragment bodies in RFC 4825, the XML Configuration Access Protocol (XCAP).
使用此媒体类型的应用程序：此文档类型已用于支持RFC4825（XML配置访问协议（XCAP））中XML片段体的传输。
Additional Information:
其他信息：
Magic Number: none
神奇数字：无
File Extension: .xel
文件扩展名：.xel
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-att+xml
MIME子类型名称：xcap att+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
可选参数：与RFC 3023[9]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
编码注意事项：与RFC 3023[9]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [9].
Security considerations: See Section 10 of RFC 3023 [9].translate error, please retry
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4825
已发布规范：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML attribute values in RFC 4825, the XML Configuration Access Protocol (XCAP).
使用此媒体类型的应用程序：此文档类型已用于支持RFC 4825（XML配置访问协议（XCAP））中XML属性值的传输。
Additional Information:
其他信息：
Magic Number: none
神奇数字：无
File Extension: .xav
文件扩展名：.xav
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-ns+xml
MIME子类型名称：xcap ns+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
可选参数：与RFC 3023[9]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].translate error, please retry
Security considerations: See Section 10 of RFC 3023 [9].
安全注意事项：见RFC 3023[9]第10节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4825
已发布规范：RFC 4825
Applications that use this media type: This document type has been used to support transport of XML fragment bodies in RFC 4825, the XML Configuration Access Protocol (XCAP).
使用此媒体类型的应用程序：此文档类型已用于支持RFC4825（XML配置访问协议（XCAP））中XML片段体的传输。
Additional Information:
其他信息：
Magic Number: none
神奇数字：无
File Extension: .xns
文件扩展名：.xns
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-error+xml
MIME子类型名称：xcap错误+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
可选参数：与RFC 3023[9]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
编码注意事项：与RFC 3023[9]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [9].
安全注意事项：见RFC 3023[9]第10节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4825
已发布规范：RFC 4825
Applications that use this media type: This document type conveys error conditions defined in RFC 4825
使用此媒体类型的应用程序：此文档类型传递RFC 4825中定义的错误条件
Additional Information:
其他信息：
Magic Number: none
神奇数字：无
File Extension: .xer
文件扩展名：.xer
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: xcap-caps+xml
MIME子类型名称：xcaps+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter application/xml as specified in RFC 3023 [9].
可选参数：与RFC 3023[9]中指定的字符集参数application/xml相同。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [9].
编码注意事项：与RFC 3023[9]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [9].
安全注意事项：见RFC 3023[9]第10节。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 4825
已发布规范：RFC 4825
Applications that use this media type: This document type conveys capabilities of an XML Configuration Access Protocol (XCAP) server, as defined in RFC 4825.
使用此媒体类型的应用程序：此文档类型传递RFC 4825中定义的XML配置访问协议（XCAP）服务器的功能。
Additional Information:
其他信息：
Magic Number: none
神奇数字：无
File Extension: .xca
文件扩展名：.xca
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jonathan Rosenberg, jdrosen@jdrosen.net
更多信息的个人和电子邮件地址：Jonathan Rosenberg，jdrosen@jdrosen.net
Intended usage: COMMON
预期用途：普通
Author/Change controller: The IETF.
作者/变更控制者：IETF。
This specification registers several new XML namespaces, as per the guidelines in RFC 3688 [17].
根据RFC3688[17]中的指南，本规范注册了几个新的XML名称空间。
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Error Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Error Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Error Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Error Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-error</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps
URI: The URI for this namespace is urn:ietf:params:xml:ns:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Capabilities Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Capability Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-caps</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>XCAP Capabilities Namespace</title>
</head>
<body>
<h1>Namespace for XCAP Capability Documents</h1>
<h2>urn:ietf:params:xml:ns:xcap-caps</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4825.txt">
RFC4825</a></p>
</body>
</html>
END
This section registers two XML schemas per the procedures in [17].
本节按照[17]中的过程注册两个XML模式。
URI: urn:ietf:params:xml:schema:xcap-error
URI: urn:ietf:params:xml:schema:xcap-error
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML Schema: The XML for this schema can be found as the sole content of Section 11.2.
XML模式：此模式的XML可作为第11.2节的唯一内容找到。
URI: urn:ietf:params:xml:schema:xcap-caps
URI: urn:ietf:params:xml:schema:xcap-caps
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
XML Schema: The XML for this schema can be found as the sole content of Section 12.2.
XML模式：此模式的XML可作为第12.2节的唯一内容找到。
The author would like to thank Jari Urpalainen, who has contributed many important comments and has assisted with edit passes in the document. The author would also like to thank Ben Campbell, Eva-Maria Leppanen, Hisham Khartabil, Chris Newman, Joel Halpern, Lisa Dusseault, Tim Bray, Pete Cordell, Jeroen van Bemmel, Christian Schmidt, and Spencer Dawkins for their input and comments. A special thanks to Ted Hardie for his input and support.
作者要感谢Jari Urpalainen，他提供了许多重要评论，并协助编辑了文档中的通行证。作者还要感谢本·坎贝尔、伊娃·玛丽亚·莱普潘、希沙姆·哈塔比尔、克里斯·纽曼、乔尔·哈尔佩恩、丽莎·杜肖奥、蒂姆·布雷、皮特·科德尔、杰伦·范·贝梅尔、克里斯蒂安·施密特和斯宾塞·道金斯的投入和评论。特别感谢特德·哈迪的投入和支持。
[1] Maler, E., Yergeau, F., Paoli, J., Bray, T., and C. Sperberg-McQueen, "Extensible Markup Language (XML) 1.0 (Third Edition)", World Wide Web Consortium FirstEdition REC-xml-20040204, February 2004, <http://www.w3.org/TR/2004/REC-xml-20040204>.
[1] Maler，E.，Yergeau，F.，Paoli，J.，Bray，T.，和C.Sperberg McQueen，“可扩展标记语言（XML）1.0（第三版）”，万维网联盟第一版REC-XML-200402042004年2月<http://www.w3.org/TR/2004/REC-xml-20040204>.
[2] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[2] Thompson，H.，Maloney，M.，Mendelsohn，N.，和D.Beech，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[3] Layman, A., Hollander, D., and T. Bray, "Namespaces in XML", World Wide Web Consortium FirstEdition REC-xml-names-19990114, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] Layman，A.，Hollander，D.，和T.Bray，“XML中的名称空间”，万维网联盟第一版REC-XML-NAME-19990114，1999年1月<http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[4] Daniel, R., DeRose, S., Maler, E., and J. Marsh, "XPointer xmlns() Scheme", World Wide Web Consortium Recommendation REC-xptr-xmlns-20030325, March 2003, <http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325>.
[4] Daniel，R.，DeRose，S.，Maler，E.，和J.Marsh，“XPointer xmlns（）方案”，万维网联盟建议REC-xptr-xmlns-200303252003年3月<http://www.w3.org/TR/2003/REC-xptr-xmlns-20030325>.
[5] Grosso, P., Marsh, J., Maler, E., and N. Walsh, "XPointer Framework", World Wide Web Consortium Recommendation REC-xptr-framework-20030325, March 2003, <http://www.w3.org/TR/2003/REC-xptr-framework-20030325>.
[5] Grosso，P.，Marsh，J.，Maler，E.，和N.Walsh，“XPointer框架”，万维网联盟建议REC-xptr-Framework-200303252003年3月<http://www.w3.org/TR/2003/REC-xptr-framework-20030325>.
[6] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[6] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，1999年6月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[8] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[8] Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[9] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[9] Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[10] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 1.0", World Wide Web Consortium Recommendation REC-xpath-19991116, November 1999, <http://www.w3.org/TR/1999/REC-xpath-19991116>.
[10] Clark，J.和S.DeRose，“XML路径语言（XPath）1.0版”，万维网联盟建议REC-XPath-19991116，1999年11月<http://www.w3.org/TR/1999/REC-xpath-19991116>.
[11] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[11] Franks，J.，Hallam Baker，P.，Hostetler，J.，Lawrence，S.，Leach，P.，Lootonen，A.，和L.Stewart，“HTTP认证：基本和摘要访问认证”，RFC 26171999年6月。
[12] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[12] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[13] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[13] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[14] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[15] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000.
[15] Khare，R.和S.Lawrence，“在HTTP/1.1中升级到TLS”，RFC 28172000年5月。
[16] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[16] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[17] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[17] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[18] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[18] Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，2003年11月。
[19] Boyer, J., "Canonical XML Version 1.0", World Wide Web Consortium Recommendation REC-xml-c14n-20010315, March 2001, <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[19] Boyer，J.，“规范XML版本1.0”，万维网联盟建议REC-XML-c14n-20010315，2001年3月<http://www.w3.org/TR/2001/REC-xml-c14n-20010315>.
[20] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[20] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[21] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[21] Roach，A.，Campbell，B.，和J.Rosenberg，“资源列表的会话启动协议（SIP）事件通知扩展”，RFC 4662，2006年8月。
[22] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[22] Rosenberg，J.，“表示资源列表的可扩展标记语言（XML）格式”，RFC4826，2007年5月。
[23] Grosso, P. and D. Veillard, "XML Fragment Interchange", World Wide Web Consortium CR CR-xml-fragment-20010212, February 2001, <http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[23] Grosso，P.和D.Veillard，“XML片段交换”，万维网联盟CR-XML-Fragment-20010212，2001年2月<http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[24] Berglund, A., Boag, S., Chamberlin, D., Fernandez, M., Kay, M., Robie, J., and J. Simeon, "XML Path Language (XPath) 2.0", World Wide Web Consortium CR http://www.w3.org/TR/2005/CR-xpath20-20051103, November 2005.
[24] Berglund，A.，Boag，S.，Chamberlin，D.，Fernandez，M.，Kay，M.，Robie，J.，和J.Simeon，“XML路径语言（XPath）2.0”，万维网联盟CRhttp://www.w3.org/TR/2005/CR-xpath20-20051103，2005年11月。
[25] Newman, C. and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997.
[25] Newman，C.和J.Myers，“ACAP——应用程序配置访问协议”，RFC22441997年11月。
[26] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[26] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[27] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[27] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[28] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[28] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[29] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[29] Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
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编辑功能的资金目前由互联网协会提供。