Network Working Group M. Lonnfors
Request for Comments: 5262 Nokia
Category: Standards Track E. Leppanen
Individual
H. Khartabil
Ericsson Australia
J. Urpalainen
Nokia
September 2008
Network Working Group M. Lonnfors
Request for Comments: 5262 Nokia
Category: Standards Track E. Leppanen
Individual
H. Khartabil
Ericsson Australia
J. Urpalainen
Nokia
September 2008
Presence Information Data Format (PIDF) Extension for Partial Presence
部分状态信息数据格式（PIDF）扩展
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）。本备忘录的分发不受限制。
Abstract
摘要
The Presence Information Document Format (PIDF) specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network. This document introduces a new MIME type that enables transporting of either only the changed parts or the full PIDF-based presence information.
状态信息文档格式（PIDF）指定用于描述状态信息的基于XML的基线格式。PIDF的一个特点是，文档始终需要携带可用于呈现实体的所有呈现信息。在某些可能存在低带宽和高延迟链路的环境中，限制通过网络传输的信息量通常是有益的。本文档引入了一种新的MIME类型，它可以仅传输更改的部分或基于PIDF的完整状态信息。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Structure of PIDF Diff Documents ................................3
3.1. 'version' Attribute ........................................4
3.2. 'entity' Attribute .........................................4
4. Usage of 'application/pidf-diff+xml' ............................4
5. IANA Considerations .............................................5
5.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf-diff' .........................5
5.2. application/pidf-diff+xml MIME Type ........................6
5.3. XML Schema Registration ....................................7
6. Examples ........................................................8
7. XML Schema .....................................................11
8. Interoperability Considerations ................................12
9. Security Considerations ........................................13
10. Internationalization Considerations ...........................13
11. Error Handling ................................................13
12. Acknowledgments ...............................................13
13. References ....................................................13
13.1. Normative references .....................................13
13.2. Informative references ...................................14
1. Introduction ....................................................2
2. Conventions .....................................................3
3. Structure of PIDF Diff Documents ................................3
3.1. 'version' Attribute ........................................4
3.2. 'entity' Attribute .........................................4
4. Usage of 'application/pidf-diff+xml' ............................4
5. IANA Considerations .............................................5
5.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf-diff' .........................5
5.2. application/pidf-diff+xml MIME Type ........................6
5.3. XML Schema Registration ....................................7
6. Examples ........................................................8
7. XML Schema .....................................................11
8. Interoperability Considerations ................................12
9. Security Considerations ........................................13
10. Internationalization Considerations ...........................13
11. Error Handling ................................................13
12. Acknowledgments ...............................................13
13. References ....................................................13
13.1. Normative references .....................................13
13.2. Informative references ...................................14
The Presence Information Document Format (PIDF) [RFC3863] specifies the baseline XML-based format for describing presence information. One of the characteristics of the PIDF is that the document always needs to carry all presence information available for the presentity. In some environments where low bandwidth and high latency links can exist, it is often beneficial to limit the amount of transported information over the network.
状态信息文档格式（PIDF）[RFC3863]指定用于描述状态信息的基于XML的基线格式。PIDF的一个特点是，文档始终需要携带可用于呈现实体的所有呈现信息。在某些可能存在低带宽和高延迟链路的环境中，限制通过网络传输的信息量通常是有益的。
This document introduces a new MIME-Type 'application/pidf-diff+xml', which enables transporting of either only the changed parts or the full PIDF based presence information. The root element of the document distinguishes whether the partial or full PIDF document content was transported.
本文档介绍了一种新的MIME类型“application/pidf diff+xml”，它只支持传输更改的部分或基于pidf的完整状态信息。文档的根元素区分是传输部分还是完整的PIDF文档内容。
Note: With this new MIME-Type, applications can easily negotiate the support of partial updates of presence by using the Accept header. If PIDF had initially been designed for partial updates, a new separate MIME-Type would have been unnecessary.
注意：使用这种新的MIME类型，应用程序可以通过使用Accept头轻松协商对部分状态更新的支持。如果PIDF最初是为部分更新而设计的，那么就不需要新的单独MIME类型。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释，并指出符合性实施的要求级别。
This memo makes use of the vocabulary defined in RFC 2778 [RFC2778]. In addition, the following terms are defined:
本备忘录使用了RFC 2778[RFC2778]中定义的词汇表。此外，定义了以下术语：
Full presence document: A presence document that contains all the presentity's presence information that is available to a particular watcher.
完整状态文档：包含特定观察者可用的所有状态实体状态信息的状态文档。
Partial presence document: A presence document that represents a fragment of the full presence document. A partial presence document can only be understood in the context of the full presence document, i.e., a partial presence document modifies a cached copy of the full presence document.
部分状态文档：表示完整状态文档片段的状态文档。部分呈现文档只能在完整呈现文档的上下文中理解，即，部分呈现文档修改完整呈现文档的缓存副本。
The MIME type 'application/pidf-diff+xml' defines the new content type for partial PIDF documents.
MIME类型“application/pidf diff+xml”为部分pidf文档定义了新的内容类型。
The XML Schema imports the PIDF [RFC3863] schema so that the full PIDF document content with the addition of a 'version' attribute can be transported. The root element of the document is then <pidf-full>, and the 'version' attribute information can be included within it. Otherwise, the content of <pidf-full> element is exactly the same as what would have been if 'application/pidf+xml' content type had been used. Although the XML Schema also allows using <presence> as the document root element, it is disallowed from applications utilizing this document format.
XML模式导入PIDF[RFC3863]模式，以便可以传输添加了“版本”属性的完整PIDF文档内容。然后，文档的根元素是<pidf full>，其中可以包含“version”属性信息。否则，<pidf full>元素的内容与使用“application/pidf+xml”内容类型时的内容完全相同。尽管XML模式还允许使用<presence>作为文档根元素，但使用此文档格式的应用程序不允许使用它。
When only the changes of the presence document are transported, the model described in XML patch operations [RFC5261] is used. The root element of the document is then <pidf-diff>. The patch operation elements: <add>, <remove>, and <replace> allow changing the partial content of the cached local copy of the full presence document. The <add> element is used to add new content, the <replace> element updates, and the <remove> element removes existing content.
当仅传输状态文档的更改时，使用XML修补程序操作[RFC5261]中描述的模型。然后，文档的根元素是<pidf diff>。修补程序操作元素：<add>、<remove>和<replace>允许更改完整状态文档的缓存本地副本的部分内容。元素用于添加新内容，<replace>元素更新，<remove>元素删除现有内容。
The optional 'version' attribute within the two possible document root elements contains a sequence number which is incremented by one between subsequent document updates, i.e., a more recent document update has a higher 'version' value than the previous one. This number can be used to ensure consistent updates as the recipient of
两个可能的文档根元素中的可选“version”属性包含一个序列号，该序列号在后续文档更新之间递增一，即，较新的文档更新的“version”值高于前一个。此号码可用于确保作为的收件人进行一致的更新
the document can use the 'version' number to properly order received documents and to ensure that updates have not been lost. The usage of this attribute thus allows "state delta" processing described in [RFC3265]. Partial notification [RFC5263] uses a similar model. This number increments independently regardless of whether the <pidf-full> or the <pidf-diff> content is transported. In other words, a single version counter is maintained across <pidf-full> and <pidf-diff> documents.
文档可以使用“版本”编号对收到的文档进行正确排序，并确保更新未丢失。因此，该属性的使用允许[RFC3265]中描述的“状态增量”处理。部分通知[RFC5263]使用类似的模型。无论是传输<pidf full>还是<pidf diff>内容，该数字都会独立增加。换句话说，跨<pidf full>和<pidf diff>文档维护一个版本计数器。
Implementations using this document format MUST follow guidelines specified in the PIDF [RFC3863] and PIDF extension formats, for example, DataModel [RFC4479], Rich Presence Information Data (RPID) [RFC4480], and Contact Information in PIDF (CIPID) [RFC4482] MUST support the usage of the XML schema data type ID [W3C.REC-xmlschema-2-20041028] of these listed RFCs. Specifically, the XML document MUST be well formed and SHOULD be valid. This specification makes use of XML namespaces for identifying presence documents and document fragments. The namespace URI for elements defined by this specification is a URN [RFC2141], using the namespace identifier 'ietf' specified in RFC 2648 [RFC2648] and extended by RFC 3688 [RFC3688]. This URN is:
使用此文档格式的实现必须遵循PIDF[RFC3863]和PIDF扩展格式中指定的准则，例如，数据模型[RFC4479]、丰富状态信息数据（RPID）[RFC4480]和PIDF中的联系信息（CIPID）[RFC4482]必须支持XML模式数据类型ID的使用[W3C.REC-xmlschema-2-20041028]在这些列出的RFC中。具体来说，XML文档必须格式良好，并且应该是有效的。本规范使用XML名称空间来标识状态文档和文档片段。本规范定义的元素的名称空间URI是URN[RFC2141]，使用RFC 2648[RFC2648]中指定并由RFC 3688[RFC3688]扩展的名称空间标识符“ietf”。这个骨灰盒是：
urn:ietf:params:xml:ns:pidf-diff
urn:ietf:params:xml:ns:pidf-diff
Every presence document compliant with this specification MAY contain a 'version' attribute within the <pidf-diff> and <pidf-full> element.
符合本规范的每个状态文档可以在<pidf diff>和<pidf full>元素中包含一个“version”属性。
Every presence document compliant with this specification MAY contain an 'entity' attribute within the <pidf-diff> element. Its content, a presentity URI, MUST then be the same as the 'entity' attribute value of the <presence> element described in [RFC3863]. The usage of this presentity URI is described in more detail in Section 3.1 of [RFC4479].
符合本规范的每个状态文档都可以在<pidf diff>元素中包含一个“entity”属性。它的内容（一个presentity URI）必须与[RFC3863]中描述的<presence>元素的“entity”属性值相同。[RFC4479]第3.1节更详细地描述了此实体URI的用法。
The partial presence document SHOULD only contain those elements or attributes that have changed. However, when there are a lot of changes, the full presence document content can then be transported instead.
部分状态文档应仅包含已更改的元素或属性。但是，当有很多更改时，可以传输完整的状态文档内容。
IANA has performed the following actions:
IANA已执行以下操作：
o registered a new XML namespace URN per [RFC3688].
o 根据[RFC3688]注册了新的XML命名空间URN。
o registered a new MIME type 'application/pidf-diff+xml' according to the procedures of RFC 4288 [RFC4288] and guidelines in RFC 3023 [RFC3023].
o 根据RFC 4288[RFC4288]的程序和RFC 3023[RFC3023]中的指南注册了一个新的MIME类型“application/pidf diff+xml”。
o registered a new XML Schema according to the procedures of RFC 3688 [RFC3688].
o 根据RFC 3688[RFC3688]的过程注册了一个新的XML模式。
5.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf-diff'
5.1. URN Sub-Namespace Registration for
'urn:ietf:params:xml:ns:pidf-diff'
This specification registers a new XML namespace, as per the guidelines in RFC 3688 [RFC3688].
根据RFC 3688[RFC3688]中的指南，本规范注册了一个新的XML名称空间。
URI:
urn:ietf:params:xml:ns:pidf-diff
URI:
urn:ietf:params:xml:ns:pidf-diff
Description: This is the XML namespace for XML elements defined by RFC 5262 to describe the 'application/pidf-diff+xml' content type for partial PIDF.
描述：这是RFC 5262定义的XML元素的XML名称空间，用于描述部分pidf的“application/pidf diff+XML”内容类型。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org) Jari Urpalainen, (jari.urpalainen@nokia.com)
注册人联系人：IETF，简单工作组(simple@ietf.org)贾里·乌帕莱宁（贾里。urpalainen@nokia.com)
XML:
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>PIDF extension for partial PIDF</title>
</head>
<body>
<h1>Namespace for PIDF extension for partial
notifications</h1>
<h2>urn:ietf:params:xml:ns:pidf-diff</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5262.txt">
RFC5262</a>.</p>
</body>
</html>
END
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>PIDF extension for partial PIDF</title>
</head>
<body>
<h1>Namespace for PIDF extension for partial
notifications</h1>
<h2>urn:ietf:params:xml:ns:pidf-diff</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc5262.txt">
RFC5262</a>.</p>
</body>
</html>
END
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pidf-diff+xml
MIME子类型名称：pidf diff+xml
Mandatory parameters: none
强制参数：无
Optional parameters: Same as charset parameter of application/xml as specified in RFC 3023 [RFC3023]. Default value is UTF-8.
可选参数：与RFC 3023[RFC3023]中指定的application/xml的字符集参数相同。默认值为UTF-8。
Encoding considerations: Same as encoding considerations of application/xml as specified in RFC 3023 [RFC3023].
编码注意事项：与RFC 3023[RFC3023]中指定的应用程序/xml的编码注意事项相同。
Security considerations: See Section 10 of RFC 3023 [RFC3023]. This content type is designed to carry presence data, which may be considered private information. Appropriate precautions should be adopted to limit disclosure of this information.
安全注意事项：参见RFC 3023[RFC3023]第10节。此内容类型旨在承载状态数据，这些数据可能被视为私人信息。应采取适当的预防措施来限制该信息的披露。
Interoperability considerations: none
互操作性注意事项：无
Published specification: RFC 5262
已发布规范：RFC 5262
Applications that use this media type: SIP-based presence systems
使用此媒体类型的应用程序：基于SIP的呈现系统
Additional information:
其他信息：
Magic Number: None
神奇数字：无
File Extension: .xml
文件扩展名：.xml
Macintosh file type code: "TEXT"
Macintosh文件类型代码：“文本”
Personal and email address for further information: Jari Urpalainen, jari.urpalainen@nokia.com
更多信息的个人和电子邮件地址：Jari Urpalainen，Jari。urpalainen@nokia.com
Intended usage: LIMITED USE
预期用途：有限用途
Restrictions on usage: Presence [RFC3863] based systems.
使用限制：基于状态[RFC3863]的系统。
Author: This specification is a work item of the IETF SIMPLE working group, with mailing list address <simple@ietf.org>.
作者：本规范是IETF简单工作组的工作项，具有邮件列表地址<simple@ietf.org>.
Author/Change controller: the IETF.
作者/变更控制者：IETF。
This section calls for IANA to register a new XML Schema, the sole content of which can be found in Section 7.
本节要求IANA注册一个新的XML模式，其唯一内容见第7节。
URI:
urn:ietf:params:xml:schema:pidf-diff
URI:
urn:ietf:params:xml:schema:pidf-diff
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
Registrant Contact:
IETF, SIMPLE working group, <simple@ietf.org>
Jari Urpalainen, <jari.urpalainen@nokia.com>
An 'application/pidf-diff+xml' document that contains the full state presence information:
包含完整状态状态信息的“应用程序/pidf diff+xml”文档：
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="567">
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="567">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:message>true</c:message>
<c:video>false</c:video>
</c:servcaps>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:message>true</c:message>
<c:video>false</c:video>
</c:servcaps>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">im:pep@example.com</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">im:pep@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>closed</basic>
</status>
<ci:homepage>http://example.com/~pep/</ci:homepage>
<ci:icon>http://example.com/~pep/icon.gif</ci:icon>
<ci:card>http://example.com/~pep/card.vcd</ci:card>
<contact priority="0.9">sip:pep@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>closed</basic>
</status>
<ci:homepage>http://example.com/~pep/</ci:homepage>
<ci:icon>http://example.com/~pep/icon.gif</ci:icon>
<ci:card>http://example.com/~pep/card.vcd</ci:card>
<contact priority="0.9">sip:pep@example.com</contact>
</tuple>
<note xml:lang="en">Full state presence document</note>
<note xml:lang="en">Full state presence document</note>
<dm:person id="p123">
<r:activities>
<dm:person id="p123">
<r:activities>
<r:on-the-phone/>
<r:busy/>
</r:activities>
</dm:person>
<dm:device id="u600b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>urn:esn:600b40c7</dm:deviceID>
</dm:device>
<r:on-the-phone/>
<r:busy/>
</r:activities>
</dm:person>
<dm:device id="u600b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>urn:esn:600b40c7</dm:deviceID>
</dm:device>
</p:pidf-full>
</p:pidf-full>
An example partial update document with the <pidf-diff> root element:
带有<pidf diff>根元素的部分更新文档示例：
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:d="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="568">
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff
xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:d="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="568">
<p:add sel="presence/note" pos="before">
<tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:pep@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and person element</note>
</tuple>
</p:add>
<p:add sel="presence/note" pos="before">
<tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:pep@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and person element</note>
</tuple>
</p:add>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
<p:remove sel="*/d:person/r:activities/r:busy" ws="after"/>
<p:remove sel="*/d:person/r:activities/r:busy" ws="after"/>
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
</p:pidf-diff>
</p:pidf-diff>
An updated local composition presence document after applying the patches:
应用补丁后更新的本地合成状态文档：
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="568">
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:ci="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="pres:someone@example.com"
version="568">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:message>true</c:message>
<c:video>false</c:video>
</c:servcaps>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:message>true</c:message>
<c:video>false</c:video>
</c:servcaps>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="0.7">im:pep@example.com</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="0.7">im:pep@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>open</basic>
</status>
<ci:homepage>http://example.com/~pep/</ci:homepage>
<ci:icon>http://example.com/~pep/icon.gif</ci:icon>
<ci:card>http://example.com/~pep/card.vcd</ci:card>
<contact priority="0.9">sip:pep@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>open</basic>
</status>
<ci:homepage>http://example.com/~pep/</ci:homepage>
<ci:icon>http://example.com/~pep/icon.gif</ci:icon>
<ci:card>http://example.com/~pep/card.vcd</ci:card>
<contact priority="0.9">sip:pep@example.com</contact>
</tuple>
<tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:pep@example.com</contact>
<tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:pep@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and note element</note>
</tuple>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and note element</note>
</tuple>
<note xml:lang="en">Full state presence document</note>
<note xml:lang="en">Full state presence document</note>
<dm:person id="p123">
<r:activities>
<r:on-the-phone/>
</r:activities>
</dm:person>
<dm:person id="p123">
<r:activities>
<r:on-the-phone/>
</r:activities>
</dm:person>
<dm:device id="u600b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>urn:esn:600b40c7</dm:deviceID>
</dm:device>
<dm:device id="u600b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>urn:esn:600b40c7</dm:deviceID>
</dm:device>
</p:pidf-full>
</p:pidf-full>
The XML schema for the 'application/pidf-diff+xml' data format. The included schema "urn:ietf:params:xml:schema:xml-patch-ops" is defined in [RFC5261], and the PIDF Schema "pidf.xsd" is imported from [RFC3863].
“应用程序/pidf diff+XML”数据格式的XML架构。[RFC5261]中定义了包含的模式“urn:ietf:params:xml:schema:xml patch ops”，并从[RFC3863]导入了PIDF模式“PIDF.xsd”。
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:pidf-diff"
xmlns:tns="urn:ietf:params:xml:ns:pidf-diff"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema
targetNamespace="urn:ietf:params:xml:ns:pidf-diff"
xmlns:tns="urn:ietf:params:xml:ns:pidf-diff"
xmlns:pidf="urn:ietf:params:xml:ns:pidf"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<!-- include patch-ops type definitions -->
<xsd:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- include patch-ops type definitions -->
<xsd:include
schemaLocation="urn:ietf:params:xml:schema:patch-ops"/>
<!-- import PIDF definitions -->
<xsd:import namespace="urn:ietf:params:xml:ns:pidf"
schemaLocation="pidf.xsd"/>
<!-- import PIDF definitions -->
<xsd:import namespace="urn:ietf:params:xml:ns:pidf"
schemaLocation="pidf.xsd"/>
<!-- partial updates -->
<xsd:element name="pidf-diff">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="add" type="tns:add"/>
<xsd:element name="replace" type="tns:replace"/>
<xsd:element name="remove" type="tns:remove"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="xsd:unsignedInt"/>
<xsd:attribute name="entity" type="xsd:anyURI"/>
</xsd:complexType>
</xsd:element>
<!-- partial updates -->
<xsd:element name="pidf-diff">
<xsd:complexType>
<xsd:sequence minOccurs="0" maxOccurs="unbounded">
<xsd:choice>
<xsd:element name="add" type="tns:add"/>
<xsd:element name="replace" type="tns:replace"/>
<xsd:element name="remove" type="tns:remove"/>
</xsd:choice>
</xsd:sequence>
<xsd:attribute name="version" type="xsd:unsignedInt"/>
<xsd:attribute name="entity" type="xsd:anyURI"/>
</xsd:complexType>
</xsd:element>
<!-- full PIDF in addition to optional version -->
<xsd:element name="pidf-full">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="pidf:presence">
<xsd:attribute name="version" type="xsd:unsignedInt"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
<!-- full PIDF in addition to optional version -->
<xsd:element name="pidf-full">
<xsd:complexType>
<xsd:complexContent>
<xsd:extension base="pidf:presence">
<xsd:attribute name="version" type="xsd:unsignedInt"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</xsd:schema>
Systems compliant with Common Profile for Presence (CPP) [RFC3859] will not be by default able to use this specification. However, this will not cause any interoperability problems because all endpoints and gateways must support the default MIME type (application/pidf+xml) regardless of if they support this specification. Thus, if a gateway or another end point does not understand this specification it will not be used. In SIMPLE-based systems, use of this MIME type is negotiated using SIP content type negotiation mechanism as specified in partial notification [RFC5263].
默认情况下，符合通用状态配置文件（CPP）[RFC3859]的系统将无法使用此规范。但是，这不会导致任何互操作性问题，因为所有端点和网关都必须支持默认MIME类型（应用程序/pidf+xml），无论它们是否支持此规范。因此，如果网关或另一个端点不理解此规范，则不会使用它。在基于简单的系统中，使用部分通知[RFC5263]中指定的SIP内容类型协商机制协商此MIME类型的使用。
Other CPP-compliant (other than SIP-based) systems can also support this specification if they have a mechanism to indicate support for it. If they do, it is possible to build a gateway that will preserve end-to-end integrity with usage of partial PIDF.
其他符合CPP（基于SIP的系统除外）的系统也可以支持该规范，前提是它们具有表示支持该规范的机制。如果他们这样做，就有可能构建一个网关，通过使用部分PIDF来保持端到端的完整性。
All security considerations identified for PIDF [RFC3863] apply unchanged for this document as presence information may contain highly sensitive information. Furthermore, the protocol SHOULD provide authorization policies what presence information can be given to which watchers, and when, see [RFC5025].
为PIDF[RFC3863]确定的所有安全注意事项对本文档的适用不变，因为状态信息可能包含高度敏感的信息。此外，该协议应提供授权策略，以确定哪些状态信息可以提供给哪些观察者，以及何时提供，请参见[RFC5025]。
The PIDF [RFC3863] format is represented in XML that performs all character processing in terms of the Universal Character Set (UCS). Conformant XML processors MUST support both UTF-8 and UTF-16 encodings of the UCS. UTF-8 is the RECOMMENDED encoding of this partial presence format.
PIDF[RFC3863]格式用XML表示，它根据通用字符集（UCS）执行所有字符处理。一致性XML处理器必须同时支持UCS的UTF-8和UTF-16编码。UTF-8是此部分存在格式的推荐编码。
If the character set of the initial <pidf-full> document has been accepted by a receiving application, it MUST continue to accept the same character set with the subsequent <pidf-diff> documents. However, it MUST NOT need to accept a possible character set change.
如果接收应用程序已接受初始<pidf full>文档的字符集，则它必须继续接受与后续<pidf diff>文档相同的字符集。但是，它不需要接受可能的字符集更改。
Error conditions MAY be indicated by errors defined in [RFC5261]. This document doesn't define any additional error elements. If the 'version' or 'entity' attributes have incorrect content, it MAY be indicated by the <invalid-attribute-value> error element.
错误条件可由[RFC5261]中定义的错误指示。本文档未定义任何其他错误元素。如果“版本”或“实体”属性包含不正确的内容，则可能由<invalid attribute value>错误元素指示。
The authors would like to thank Jose Costa-Requena, Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Miguel Garcia, Krisztian Kiss, Ben Cambell, Robert Sparks, Anders Kristenssen, Aki Niemi, Jon Peterson, Gonzalo Camarillo, Lars Eggert, Lakshminath Dondeti, and Chris Newman for their valuable comments and contributions.
作者要感谢Jose Costa Requena、Jyrki Aarnos、Jonathan Rosenberg、Dean Willis、Miguel Garcia、Kristian Kiss、Ben Cambell、Robert Sparks、Anders Kristensen、Aki Niemi、Jon Peterson、Gonzalo Camarillo、Lars Eggert、Lakshminath Dondeti和Chris Newman的宝贵评论和贡献。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3863] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[RFC3863]Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC2141]Moats，R.，“瓮语法”，RFC 21411997年5月。
[RFC2648] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[RFC2648]Moats，R.，“IETF文档的URN名称空间”，RFC 26481999年8月。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[RFC3688]Mealling，M.“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[RFC3023] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[RFC3023]Murata，M.，St.Laurent，S.，和D.Kohn，“XML媒体类型”，RFC 3023，2001年1月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479, July 2006.
[RFC4479]Rosenberg，J.，“存在的数据模型”，RFC 4479，2006年7月。
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[RFC4480]Schulzrinne，H.，Gurbani，V.，Kyzivat，P.，和J.Rosenberg，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，RFC 44802006年7月。
[RFC4482] Schulzrinne, H., "CIPID: Contact Information for the Presence Information Data Format", RFC 4482, July 2006.
[RFC4482]Schulzrinne，H.，“CIPID：状态信息数据格式的联系信息”，RFC 4482，2006年7月。
[RFC5261] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[RFC5261]Urpalainen，J.，“利用XML路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 52612008年9月。
[W3C.REC-xmlschema-2-20041028] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-2-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[W3C.REC-xmlschema-2-20041028]Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，万维网联盟建议REC-xmlschema-2-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
[RFC2778] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[RFC2778]Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]彼得森，J.，“存在的共同特征（CPP）”，RFC3859，2004年8月。
[RFC5025] Rosenberg, J., "Presence Authorization Rules", RFC 5025, December 2007.
[RFC5025]Rosenberg，J.，“在场授权规则”，RFC 50252，2007年12月。
[RFC5263] Lonnfors, M., "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008.
[RFC5263]Lonnfors，M.，“存在信息部分通知的会话启动协议（SIP）扩展”，RFC 5263，2008年9月。
Authors' Addresses
作者地址
Mikko Lonnfors Nokia Itamerenkatu 11-13 00180 Helsinki Finland
Mikko Lonnfors诺基亚意大利专利11-13 00180芬兰赫尔辛基
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Eva Leppanen Individual Lempaala Finland
Eva Leppanen芬兰伦帕拉个体酒店
EMail: eva.leppanen@saunalahti.fi
EMail: eva.leppanen@saunalahti.fi
Hisham Khartabil Ericsson Australia P.O. Box 256c Melbourne, VIC 3001 Australia
Hisham Khartabil Ericsson Australia邮政信箱256c澳大利亚维多利亚州墨尔本3001
EMail: hisham.khartabil@gmail.com
EMail: hisham.khartabil@gmail.com
Jari Urpalainen Nokia Itamerenkatu 11-13 00180 Helsinki Finland
芬兰赫尔辛基诺基亚伊塔梅伦卡图11-13 00180
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Phone: +358 7180 37686
EMail: jari.urpalainen@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.