Network Working Group M. Isomaki
Request for Comments: 4827 E. Leppanen
Category: Standards Track Nokia
May 2007
Network Working Group M. Isomaki
Request for Comments: 4827 E. Leppanen
Category: Standards Track Nokia
May 2007
An Extensible Markup Language (XML) Configuration Access Protocol (XCAP) Usage for Manipulating Presence Document Contents
用于操作状态文档内容的可扩展标记语言（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 document describes a usage of the Extensible Markup Language (XML) Configuration Access Protocol (XCAP) for manipulating the contents of Presence Information Data Format (PIDF) based presence documents. It is intended to be used in Session Initiation Protocol (SIP) based presence systems, where the Event State Compositor can use the XCAP-manipulated presence document as one of the inputs on which it builds the overall presence state for the presentity.
本文档描述了可扩展标记语言（XML）配置访问协议（XCAP）的用法，用于操作基于状态信息数据格式（PIDF）的状态文档的内容。它旨在用于基于会话发起协议（SIP）的呈现系统中，其中事件状态合成器可以使用XCAP操纵的呈现文档作为输入之一，在其上为呈现实体构建整体呈现状态。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Relationship with Presence State Published Using SIP
PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Application Usage ID . . . . . . . . . . . . . . . . . . . . . 6
5. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Structure of Manipulated Presence Information . . . . . . . . . 6
7. Additional Constraints . . . . . . . . . . . . . . . . . . . . 6
8. Resource Interdependencies . . . . . . . . . . . . . . . . . . 6
9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 6
10. Authorization Policies . . . . . . . . . . . . . . . . . . . . 6
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
13.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1. Normative References . . . . . . . . . . . . . . . . . . . 9
15.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Relationship with Presence State Published Using SIP
PUBLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Application Usage ID . . . . . . . . . . . . . . . . . . . . . 6
5. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Structure of Manipulated Presence Information . . . . . . . . . 6
7. Additional Constraints . . . . . . . . . . . . . . . . . . . . 6
8. Resource Interdependencies . . . . . . . . . . . . . . . . . . 6
9. Naming Conventions . . . . . . . . . . . . . . . . . . . . . . 6
10. Authorization Policies . . . . . . . . . . . . . . . . . . . . 6
11. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
12. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9
13.1. XCAP Application Usage ID . . . . . . . . . . . . . . . . 9
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
15.1. Normative References . . . . . . . . . . . . . . . . . . . 9
15.2. Informative References . . . . . . . . . . . . . . . . . . 9
The Session Initiation Protocol (SIP) for Instant Messaging and Presence (SIMPLE) specifications allow a user, called a watcher, to subscribe to another user, called a presentity, in order to learn its presence information [7]. The presence data model has been specified in [10]. The data model makes a clean separation between person-, service-, and device-related information.
即时消息和状态（简单）规范的会话发起协议（SIP）允许称为观察者的用户订阅称为状态实体的另一用户，以了解其状态信息[7]。[10]中规定了状态数据模型。数据模型在人员、服务和设备相关信息之间进行了清晰的分离。
A SIP-based mechanism, SIP PUBLISH method, has been defined for publishing presence state [4]. Using SIP PUBLISH, a Presence User Agent (PUA) can publish its view of the presence state, independently of and without the need to learn about the states set by other PUAs. However, SIP PUBLISH has a limited scope and does not address all the requirements for setting presence state. The main issue is that SIP PUBLISH creates a soft state that expires after the negotiated lifetime unless it is refreshed. This makes it unsuitable for cases where the state should prevail without active devices capable of refreshing the state.
基于SIP的机制SIP PUBLISH method已被定义用于发布状态[4]。通过使用SIP发布，状态用户代理（PUA）可以发布其状态视图，而不需要了解其他PUA设置的状态。但是，SIP PUBLISH的范围有限，不能满足设置状态的所有要求。主要问题是SIP PUBLISH会创建一个软状态，除非刷新，否则该状态将在协商的生存期之后过期。这使得它不适用于在没有能够刷新状态的活动设备的情况下状态应占优势的情况。
There are three main use cases where setting of permanent presence state that is independent of activeness of any particular device is useful. The first case concerns setting person-related state. The presentity would often like to set its presence state even for periods when it has no active devices capable of publishing available. Good examples are traveling, vacations, and so on. The second case is about setting state for services that are open for communication, even if the presentity does not have a device running that service online. Examples of these kinds of services include e-mail, Multimedia Messaging Service (MMS), and Short Message Service (SMS). In these services, the presentity is provisioned with a server that makes the service persistently available, at least in certain forms, and it would be good to be able to advertise this to the watchers. Since it is not realistic to assume that all e-mail, MMS, or SMS servers can publish presence state on their own (and even if this were possible, such state would almost never change), this has to be done by some other device. And since the availability of the service is not dependent on that device, it would be impractical to require that device to be constantly active just to publish such availability. The third case concerns setting the default state of any person, service, or device in the absence of any device capable of actively publishing such state. For instance, the presentity might want to advertise that his or her voice service is currently closed, just to let the watchers know that such service might be open at some point. Again, this type of default state is independent of any particular device and can be considered rather persistent.
有三种主要的使用情形，其中设置与任何特定设备的活动性无关的永久存在状态是有用的。第一种情况涉及设置与人有关的状态。存在实体通常希望设置其存在状态，即使在其没有能够发布的活动设备时也是如此。旅游、度假等都是很好的例子。第二种情况是为开放通信的服务设置状态，即使存在实体没有在线运行该服务的设备。此类服务的示例包括电子邮件、彩信服务（MMS）和短消息服务（SMS）。在这些服务中，存在实体被配置了一个服务器，该服务器至少以某种形式使服务持久可用，并且能够向观察者公布这一点是很好的。由于假设所有电子邮件、彩信或SMS服务器都可以自己发布状态（即使这是可能的，这种状态几乎永远不会改变）是不现实的，因此必须由其他设备来完成。而且，由于服务的可用性并不依赖于该设备，因此要求该设备持续处于活动状态以发布此类可用性是不切实际的。第三种情况涉及在没有能够主动发布任何个人、服务或设备的情况下设置其默认状态。例如，存在实体可能想要公布他或她的语音服务当前已关闭，只是为了让观察者知道，此类服务可能会在某个时候打开。同样，这种类型的默认状态独立于任何特定设备，可以认为是相当持久的。
Even though SIP PUBLISH remains the main way of publishing presence state in SIMPLE-based presence systems and is especially well-suited for publishing dynamic state (which presence mainly is), it needs to be complemented by the mechanism described in this document to address the use cases presented above.
尽管SIP PUBLISH仍然是在基于简单的呈现系统中发布呈现状态的主要方式，并且特别适合发布动态状态（呈现主要是动态状态），但它需要通过本文档中描述的机制来补充，以解决上述用例。
XML Configuration Access Protocol (XCAP) [2] allows a client to read, write, and modify application configuration data stored in XML format on a server. The data has no expiration time, so it must be explicitly inserted and deleted. The protocol allows multiple clients to manipulate the data, provided that they are authorized to do so. XCAP is already used in SIMPLE-based presence systems for manipulation of presence lists and presence authorization policies. This makes XCAP an ideal choice for doing device-independent presence document manipulation.
XML配置访问协议（XCAP）[2]允许客户端读取、写入和修改服务器上以XML格式存储的应用程序配置数据。数据没有过期时间，因此必须显式插入和删除数据。该协议允许多个客户机操作数据，前提是他们有权这样做。XCAP已经在基于简单的状态系统中用于操作状态列表和状态授权策略。这使得XCAP成为执行独立于设备的状态文档操作的理想选择。
This document defines an XML Configuration Access Protocol (XCAP) application usage for manipulating the contents of presence document. Presence Information Document Format (PIDF) [3] is used as the presence document format, since the event state compositor already has to support it, as it is used in SIP PUBLISH.
本文档定义了用于操作状态文档内容的XML配置访问协议（XCAP）应用程序用法。状态信息文档格式（PIDF）[3]用作状态文档格式，因为事件状态合成器已经支持它，因为它在SIP发布中使用。
Section 3 describes in detail how the presence document manipulated with XCAP is related to soft state publishing done with SIP PUBLISH.
第3节详细描述了使用XCAP操作的状态文档如何与使用SIP PUBLISH完成的软状态发布相关。
XCAP requires application usages to standardize several pieces of information, including a unique application usage ID (AUID) and an XML schema for the manipulated data. These are specified starting from Section 4.
XCAP需要应用程序使用来标准化多条信息，包括一个唯一的应用程序使用ID（AUID）和一个用于处理数据的XML模式。这些是从第4节开始规定的。
In this document, the key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可能”和“可选”将按照RFC 2119[1]中的描述进行解释，并指明符合性实施的要求级别。
Comprehensive terminology of presence and event state publishing is provided in "Session Initiation Protocol (SIP) Extension for Event State Publication" [4].
“事件状态发布的会话启动协议（SIP）扩展”中提供了状态和事件状态发布的综合术语[4]。
The framework for publishing presence state is described in Figure 1. A central part of the framework is the event state compositor element, whose function is to compose presence information received from several sources into a single coherent presence document.
发布状态的框架如图1所示。该框架的核心部分是事件状态合成器元素，其功能是将从多个源接收的状态信息合成为一个一致的状态文档。
The presence state manipulated with XCAP can be seen as one of the information sources for the compositor to be combined with the soft state information published using SIP PUBLISH. This is illustrated in Figure 1. It is expected that, in the normal case, there can be several PUAs publishing their separate views with SIP PUBLISH, but only a single XCAP manipulated presence document. As shown in the figure, multiple XCAP clients (for instance, in different physical devices) can manipulate the same document on the XCAP server, but this still creates only one input to the event state compositor. The XCAP server stores the XCAP manipulated presence document under the "users" tree in the XCAP document hierarchy. See Section 9 for details and Section 11 for an example.
使用XCAP操纵的存在状态可以看作合成器的信息源之一，与使用SIP PUBLISH发布的软状态信息相结合。这如图1所示。预计在正常情况下，可能会有多个PUA使用SIP PUBLISH发布各自的视图，但只有一个XCAP操纵的状态文档。如图所示，多个XCAP客户端（例如，在不同的物理设备中）可以在XCAP服务器上操作同一文档，但这仍然只为事件状态合成器创建一个输入。XCAP服务器将XCAP操纵的状态文档存储在XCAP文档层次结构中的“用户”树下。详情见第9节，示例见第11节。
As individual inputs, the presence states set by XCAP and SIP PUBLISH are completely separated, and it is not possible to directly manipulate the state set by one mechanism with the other. How the compositor treats XCAP-based inputs with respect to SIP PUBLISH-based inputs is a matter of compositor policy, which is beyond the scope of this specification. Since the SIP PUBLISH specification already mandates the compositor to be able to construct the overall presence state from multiple inputs, which may contain non-orthogonal (or in some ways even conflicting) information, this XCAP usage does not impose any new requirements on the compositor functionality.
作为单独的输入，XCAP和SIP PUBLISH设置的存在状态是完全分离的，不可能直接将一种机制设置的状态与另一种机制一起操作。合成器如何相对于基于SIP发布的输入处理基于XCAP的输入是合成器策略的问题，这超出了本规范的范围。由于SIP PUBLISH规范已经要求合成器能够从多个输入（可能包含非正交（或在某些方面甚至冲突）信息来构造整体存在状态，因此此XCAP使用不会对合成器功能提出任何新要求。
+---------------+ +------------+
| Event State | | Presence |<-- SIP SUBSCRIBE
| Compositor +---------+ Agent |--> SIP NOTIFY
| | | (PA) |
+-------+-------+ +------------+
^ ^ ^
| | |
| | | +---------------+
+--------+ | +-------| XCAP server |
| | +-------+-------+
| | ^ ^
| SIP Publish | | XCAP |
| | | |
+--+--+ +--+--+ +-------+ +-------+
| PUA | | PUA | | XCAP | | XCAP |
| | | | | client| | client|
+-----+ +-----+ +-------+ +-------+
+---------------+ +------------+
| Event State | | Presence |<-- SIP SUBSCRIBE
| Compositor +---------+ Agent |--> SIP NOTIFY
| | | (PA) |
+-------+-------+ +------------+
^ ^ ^
| | |
| | | +---------------+
+--------+ | +-------| XCAP server |
| | +-------+-------+
| | ^ ^
| SIP Publish | | XCAP |
| | | |
+--+--+ +--+--+ +-------+ +-------+
| PUA | | PUA | | XCAP | | XCAP |
| | | | | client| | client|
+-----+ +-----+ +-------+ +-------+
Figure 1: Framework for Presence Publishing and Event State Composition
图1：状态发布和事件状态组合框架
The protocol interface between XCAP server and the event state compositor is not specified here.
此处未指定XCAP服务器和事件状态合成器之间的协议接口。
XCAP requires application usages to define a unique application usage ID (AUID) in either the IETF tree or a vendor tree. This specification defines the 'pidf-manipulation' AUID within the IETF tree, via the IANA registration in Section 13.
XCAP要求应用程序使用在IETF树或供应商树中定义唯一的应用程序使用ID（AUID）。本规范通过第13节中的IANA注册，定义了IETF树中的“pidf操纵”AUID。
The MIME type for this application usage is 'application/pidf+xml'.
此应用程序用法的MIME类型为“application/pidf+xml”。
The XML Schema of the presence information is defined in the Presence Information Data Format (PIDF) [3]. The PIDF also defines a mechanism for extending presence information. See [8], [9], [11], and [12] for currently defined PIDF extensions and their XML Schemas.
状态信息的XML模式在状态信息数据格式（PIDF）[3]中定义。PIDF还定义了一种扩展状态信息的机制。有关当前定义的PIDF扩展及其XML模式，请参见[8]、[9]、[11]和[12]。
The namespace URI for PIDF is 'urn:ietf:params:xml:ns:pidf' which is also the XCAP default document namespace.
PIDF的名称空间URI是“urn:ietf:params:xml:ns:PIDF”，这也是XCAP默认的文档名称空间。
There are no constraints on the document beyond those described in the XML schemas (PIDF and its extensions) and in the description of PIDF [3].
除了XML模式（PIDF及其扩展）和PIDF的描述[3]中描述的约束之外，对文档没有任何约束。
There are no resource interdependencies beyond the possible interdependencies defined in PIDF [3] and XCAP [2] that need to be defined for this application usage.
除了在PIDF[3]和XCAP[2]中定义的可能的相互依赖关系之外，没有任何资源相互依赖关系需要为此应用程序使用定义。
The XCAP server MUST store only a single XCAP manipulated presence document for each user. The presence document MUST be located under the "users" tree, using filename "index". See an example in Section 11.
XCAP服务器必须为每个用户仅存储一个XCAP操作的状态文档。状态文档必须位于“用户”树下，使用文件名“索引”。参见第11节中的示例。
This application usage does not modify the default XCAP authorization policy, which allows only a user (owner) to read, write, or modify their own documents. A server can allow privileged users to modify documents that they do not own, but the establishment and indication of such policies is outside the scope of this document.
此应用程序使用不会修改默认的XCAP授权策略，该策略只允许用户（所有者）读取、写入或修改自己的文档。服务器可以允许特权用户修改他们不拥有的文档，但此类策略的建立和指示超出了本文档的范围。
The section provides an example of a presence document provided by an XCAP Client to an XCAP Server. The presence document illustrates the situation where a (human) presentity has left for vacation, and before that, has set his presence information so that he is only available via e-mail. In the absence of any published soft state information, this would be the sole input to the compositor forming the presence document. The example document contains PIDF extensions specified in "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)" [8] and "CIPID: Contact Information in Presence Information Data Format" [9].
本节提供了由XCAP客户端向XCAP服务器提供的状态文档的示例。状态文档说明了（人类）状态实体离开去度假的情况，在此之前，状态信息已设置为只能通过电子邮件访问。在没有任何发布的软状态信息的情况下，这将是构成状态文档的合成器的唯一输入。示例文档包含在“RPID：状态信息数据格式（PIDF）的丰富状态扩展”[8]和“CIPID：状态信息数据格式中的联系人信息”[9]中指定的PIDF扩展。
It is assumed that the presentity is a SIP user with Address-of-Record (AOR) sip:someone@example.com. The XCAP root URI for example.com is assumed to be http://xcap.example.com. The XCAP User Identifier (XUI) is assumed to be identical to the SIP AOR, according to XCAP recommendations. In this case, the presence document would be located at http://xcap.example.com/pidf-manipulation/users/ sip:someone@example.com/index.
假设存在实体是具有记录地址（AOR）SIP的SIP用户：someone@example.com. 假设example.com的XCAP根URI为http://xcap.example.com. 根据XCAP建议，假设XCAP用户标识符（XUI）与SIP AOR相同。在这种情况下，状态文档将位于http://xcap.example.com/pidf-manipulation/users/ 抿：someone@example.com/索引。
The presence document is created with the following XCAP operation:
使用以下XCAP操作创建状态文档：
PUT /pidf-manipulation/users/sip:someone@example.com/index HTTP/1.1 Host: xcap.example.com Content-Type: application/pidf+xml ...
PUT/pidf操作/users/sip：someone@example.com/索引HTTP/1.1主机：xcap.example.com内容类型：application/pidf+xml。。。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
entity="sip:someone@example.com">
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
entity="sip:someone@example.com">
<tuple id="x8eg92m">
<status>
<basic>closed</basic>
</status>
<rp:user-input>idle</rp:user-input>
<rp:class>auth-1</rp:class>
<contact priority="0.5">sip:user@example.com</contact>
<note>I'm available only by e-mail.</note>
<timestamp>2004-02-06T16:49:29Z</timestamp>
</tuple>
<tuple id="x8eg92m">
<status>
<basic>closed</basic>
</status>
<rp:user-input>idle</rp:user-input>
<rp:class>auth-1</rp:class>
<contact priority="0.5">sip:user@example.com</contact>
<note>I'm available only by e-mail.</note>
<timestamp>2004-02-06T16:49:29Z</timestamp>
</tuple>
<tuple id="x8eg92n">
<status>
<tuple id="x8eg92n">
<status>
<basic>open</basic>
</status>
<rp:class>auth-1</rp:class>
<contact priority="1.0">mailto:someone@example.com</contact>
<note>I'm reading mail a couple of times a week</note>
</tuple>
<basic>open</basic>
</status>
<rp:class>auth-1</rp:class>
<contact priority="1.0">mailto:someone@example.com</contact>
<note>I'm reading mail a couple of times a week</note>
</tuple>
<dm:person id="p1">
<rp:class>auth-A</rp:class>
<ci:homepage>http://www.example.com/~someone</ci:homepage>
<rp:activities>
<rp:vacation/>
</rp:activities>
</dm:person>
<dm:person id="p1">
<rp:class>auth-A</rp:class>
<ci:homepage>http://www.example.com/~someone</ci:homepage>
<rp:activities>
<rp:vacation/>
</rp:activities>
</dm:person>
</presence>
</presence>
When the user wants to change the note related to e-mail service, it is done with the following XCAP operation:
当用户想要更改与电子邮件服务相关的便笺时，可通过以下XCAP操作完成：
PUT /pidf-manipulation/users/sip:someone@example.com/index/ ~~/presence/tuple%5b@id='x8eg92n'%5d/note HTTP/1.1 If-Match: "xyz" Host: xcap.example.com Content-Type: application/xcap-el+xml ...
PUT/pidf操作/users/sip：someone@example.com/索引/~~~/presence/tuple%5b@id='x8eg92n'%5d/注意HTTP/1.1如果匹配：“xyz”主机：xcap.example.com内容类型：application/xcap el+xml。。。
<note>I'm reading mails on Tuesdays and Fridays</note>
<note>I'm reading mails on Tuesdays and Fridays</note>
A presence document may contain information that is highly sensitive. Its delivery to watchers needs to happen strictly according to the relevant authorization policies. It is also important that only authorized clients are able to manipulate the presence information.
状态文档可能包含高度敏感的信息。必须严格按照相关授权政策将其交付给观察者。同样重要的是，只有经过授权的客户端才能操作状态信息。
The XCAP base specification mandates that all XCAP servers MUST implement HTTP Digest authentication specified in RFC 2617 [5]. Furthermore, XCAP servers MUST implement HTTP over TLS [6]. It is recommended that administrators of XCAP servers use an HTTPS URI as the XCAP root services' URI, so that the digest client authentication occurs over TLS. By using these means, XCAP client and server can ensure the confidentiality and integrity of the XCAP presence document manipulation operations, and that only authorized clients are allowed to perform them.
XCAP基本规范要求所有XCAP服务器必须实现RFC 2617[5]中指定的HTTP摘要身份验证。此外，XCAP服务器必须通过TLS实现HTTP[6]。建议XCAP服务器的管理员使用HTTPS URI作为XCAP根服务的URI，以便通过TLS进行摘要客户端身份验证。通过使用这些方法，XCAP客户端和服务器可以确保XCAP状态文档操纵操作的机密性和完整性，并且只允许授权客户端执行这些操作。
There is an IANA consideration associated with this specification.
本规范涉及IANA考虑因素。
This section registers a new XCAP Application Usage ID (AUID) according to the IANA procedures defined in [2].
本节根据[2]中定义的IANA过程注册新的XCAP应用程序使用ID（AUID）。
Name of the AUID: pidf-manipulation
AUID的名称：pidf操纵
Description: Pidf-manipulation application usage defines how XCAP is used to manipulate the contents of PIDF-based presence documents.
描述：Pidf操纵应用程序用法定义如何使用XCAP操纵基于Pidf的状态文档的内容。
The authors would like to thank Jari Urpalainen, Jonathan Rosenberg, Hisham Khartabil, Aki Niemi, Mikko Lonnfors, Oliver Biot, Alex Audu, Krisztian Kiss, Jose Costa-Requena, George Foti, and Paul Kyzivat for their comments.
作者要感谢贾里·乌帕莱宁、乔纳森·罗森博格、希沙姆·哈塔比尔、阿基·尼米、米科·隆弗斯、奥利弗·比奥、亚历克斯·奥杜、克里斯蒂安·基斯、何塞·科斯塔·雷克纳、乔治·福蒂和保罗·基齐瓦特的评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[2] Rosenberg，J.，“可扩展标记语言（XML）配置访问协议（XCAP）”，RFC4825，2007年5月。
[3] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[3] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[4] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[4] Niemi，A.，“事件状态发布的会话启动协议（SIP）扩展”，RFC 3903，2004年10月。
[5] Franks, J., "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] Franks，J.，“HTTP认证：基本和摘要访问认证”，RFC26171999年6月。
[6] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[6] Rescorla，E.，“TLS上的HTTP”，RFC 2818，2000年5月。
[7] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[7] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[8] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[8] Schulzrinne，H.，Gurbani，V.，Kyzivat，P.，和J.Rosenberg，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，RFC 44802006年7月。
[9] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006.
[9] Schulzrinne，H.，“CIPID：状态信息数据格式的联系信息”，RFC 4482，2006年7月。
[10] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[10] Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[11] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, July 2006.
[11] Lonnfors，M.和K.Kiss，“会话启动协议（SIP）用户代理能力扩展到状态信息数据格式（PIDF）”，正在进行的工作，2006年7月。
[12] Schulzrinne, H., "Timed Presence Extensions to the Presence Information Data Format (PIDF) to Indicate Status Information for Past and Future Time Intervals", RFC 4481, July 2006.
[12] Schulzrinne，H.，“状态信息数据格式（PIDF）的定时状态扩展，用于指示过去和未来时间间隔的状态信息”，RFC 4481，2006年7月。
Authors' Addresses
作者地址
Markus Isomaki Nokia P.O. BOX 100 00045 NOKIA GROUP Finland
Markus Isomaki诺基亚邮政信箱100 00045诺基亚集团芬兰
EMail: markus.isomaki@nokia.com
EMail: markus.isomaki@nokia.com
Eva Leppanen Nokia P.O. BOX 785 33101 Tampere Finland
Eva Leppanen诺基亚邮政信箱785 33101坦佩雷芬兰
EMail: eva-maria.leppanen@nokia.com
EMail: eva-maria.leppanen@nokia.com
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编辑功能的资金目前由互联网协会提供。