Network Working Group H. Sugano
Request for Comments: 3863 S. Fujimoto
Category: Standards Track Fujitsu
G. Klyne
Nine by Nine
A. Bateman
VisionTech
W. Carr
Intel
J. Peterson
NeuStar
August 2004
Network Working Group H. Sugano
Request for Comments: 3863 S. Fujimoto
Category: Standards Track Fujitsu
G. Klyne
Nine by Nine
A. Bateman
VisionTech
W. Carr
Intel
J. Peterson
NeuStar
August 2004
Presence Information Data Format (PIDF)
状态信息数据格式（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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This memo specifies the Common Profile for Presence (CPP) Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant Presence protocols, and also defines a new media type "application/pidf+xml" to represent the XML MIME entity for PIDF.
此备忘录将状态通用配置文件（CPP）状态信息数据格式（PIDF）指定为符合CPP的状态协议的通用状态数据格式，并定义了一种新的媒体类型“application/PIDF+xml”，以表示PIDF的xml MIME实体。
Table of Content
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Conventions. . . . . . . . . . . . . . . 3
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Minimal Model. . . . . . . . . . . . . . . . . . . . . . 3
2.2. Added Features . . . . . . . . . . . . . . . . . . . . . 4
2.3. XML Encoding Decision. . . . . . . . . . . . . . . . . . 5
3. Overview of Presence Information Data Format . . . . . . . . . 5
3.1. The 'application/pidf+xml' Content Type. . . . . . . . . 5
3.2. Presence Information Contents. . . . . . . . . . . . . . 5
4. XML-encoded Presence Data Format . . . . . . . . . . . . . . . 6
4.1. XML Format Definitions . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology and Conventions. . . . . . . . . . . . . . . 3
2. Design Decisions . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Minimal Model. . . . . . . . . . . . . . . . . . . . . . 3
2.2. Added Features . . . . . . . . . . . . . . . . . . . . . 4
2.3. XML Encoding Decision. . . . . . . . . . . . . . . . . . 5
3. Overview of Presence Information Data Format . . . . . . . . . 5
3.1. The 'application/pidf+xml' Content Type. . . . . . . . . 5
3.2. Presence Information Contents. . . . . . . . . . . . . . 5
4. XML-encoded Presence Data Format . . . . . . . . . . . . . . . 6
4.1. XML Format Definitions . . . . . . . . . . . . . . . . . 6
4.1.1. The <presence> element. . . . . . . . . . . . . . 6
4.1.2. The <tuple> element . . . . . . . . . . . . . . . 7
4.1.3. The <status> element. . . . . . . . . . . . . . . 8
4.1.4. The <basic> element . . . . . . . . . . . . . . . 8
4.1.5. The <contact> element . . . . . . . . . . . . . . 8
4.1.6. The <note> element. . . . . . . . . . . . . . . . 9
4.1.7. The <timestamp> element . . . . . . . . . . . . . 9
4.2. Presence Information Extensibility . . . . . . . . . . . 10
4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
4.2.2. XML Namespaces In Presence Information. . . . . . 11
4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
4.2.5. Standardizing Status Extensions . . . . . . . . . 13
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Default Namespace with Status Extensions. . . . . 14
4.3.2. Presence with Other Extension Elements. . . . . . 15
4.3.3. Example Mandatory To Understand Elements. . . . . 16
4.4. XML Schema Definitions . . . . . . . . . . . . . . . . . 16
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
5.1. Content-type registration for 'application/pidf+xml' . . 18
5.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . 19
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . 20
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
7. Internationalization Considerations. . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28
4.1.1. The <presence> element. . . . . . . . . . . . . . 6
4.1.2. The <tuple> element . . . . . . . . . . . . . . . 7
4.1.3. The <status> element. . . . . . . . . . . . . . . 8
4.1.4. The <basic> element . . . . . . . . . . . . . . . 8
4.1.5. The <contact> element . . . . . . . . . . . . . . 8
4.1.6. The <note> element. . . . . . . . . . . . . . . . 9
4.1.7. The <timestamp> element . . . . . . . . . . . . . 9
4.2. Presence Information Extensibility . . . . . . . . . . . 10
4.2.1. XML Namespaces Background . . . . . . . . . . . . 10
4.2.2. XML Namespaces In Presence Information. . . . . . 11
4.2.3. Handling Of Unrecognized Element Names. . . . . . 12
4.2.4. Status Value Extensibility. . . . . . . . . . . . 12
4.2.5. Standardizing Status Extensions . . . . . . . . . 13
4.3. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
4.3.1. Default Namespace with Status Extensions. . . . . 14
4.3.2. Presence with Other Extension Elements. . . . . . 15
4.3.3. Example Mandatory To Understand Elements. . . . . 16
4.4. XML Schema Definitions . . . . . . . . . . . . . . . . . 16
5. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 18
5.1. Content-type registration for 'application/pidf+xml' . . 18
5.2. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf'. . . . . . . . . . . . . . 19
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status' . . . . . . . . . . 20
6. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
7. Internationalization Considerations. . . . . . . . . . . . . . 22
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
8.1. Normative References . . . . . . . . . . . . . . . . . . 22
8.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Document Type Definitions. . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 28
The Common Profiles for Instant Messaging (CPIM) [CPIM] and Presence (CPP) [CPP] specifications define a set of operations and parameters to achieve interoperability between different Instant Messaging and Presence protocols which meet RFC 2779 [RFC2779].
即时消息（CPIM）[CPIM]和状态（CPP）[CPP]规范的通用配置文件定义了一组操作和参数，以实现满足RFC 2779[RFC2779]的不同即时消息和状态协议之间的互操作性。
This memo further defines the Presence Information Data Format (PIDF) as a common presence data format for CPP-compliant presence protocols, allowing presence information to be transferred across CPP-compliant protocol boundaries without modification, with attendant benefits for security and performance.
本备忘录进一步将状态信息数据格式（PIDF）定义为符合CPP的状态协议的通用状态数据格式，允许状态信息在不经修改的情况下跨符合CPP的协议边界传输，从而提高安全性和性能。
The format specified in this memo defines the base presence format and extensibility required by RFC 2779. It defines a minimal set of presence status values defined by the IMPP Model document [RFC2778]. However, a presence application is able to define its own status values using the extensibility framework provided by this memo. Defining such extended status values is beyond the scope of this memo.
本备忘录中指定的格式定义了RFC 2779所需的基本存在格式和扩展性。它定义了IMPP模型文档[RFC2778]定义的一组最小状态值。但是，状态应用程序可以使用本备忘录提供的扩展性框架定义自己的状态值。定义此类扩展状态值超出了本备忘录的范围。
Note also that this memo defines only the format for a presence data payload and the extensibility framework for it. How the presence data is transferred within a specific protocol frame would be defined separately in a protocol specification.
还请注意，此备忘录仅定义状态数据有效负载的格式及其扩展性框架。如何在特定协议帧内传输存在数据将在协议规范中单独定义。
This memo makes use of the vocabulary defined in the IMPP Model document [RFC2778]. Terms such as CLOSED, INSTANT MESSAGE, OPEN, PRESENCE SERVICE, PRESENTITY, WATCHER, and WATCHER USER AGENT in the memo are used in the same meaning as defined therein.
本备忘录使用IMPP模型文件[RFC2778]中定义的词汇表。备忘录中的术语（如关闭、即时消息、打开、状态服务、状态实体、观察者和观察者用户代理）的含义与备忘录中的定义相同。
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应该”、“不应该”、“建议”、“可能”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
We have adopted the IMPP Model and Requirements documents [RFC2778, RFC2779] as the starting point of our discussion. The two RFCs contain a number of statements about presence information, which can be regarded as a basic set of constraints for the format design. Also, we took the minimalist approach to the design based on them. Starting from the minimal model, only the features that are necessary to solve particular problems have been included.
我们采用IMPP模型和需求文件[RFC2778，RFC2779]作为讨论的起点。这两个RFC包含许多关于状态信息的语句，可以将其视为格式设计的一组基本约束。此外，我们采用了基于它们的极简主义设计方法。从最小模型开始，只包含解决特定问题所需的功能。
This specification is based on the minimal model extracted from the IMPP Model and Requirements documents. The model consists of the following items. Each of them is accompanied with the corresponding RFCs and their section numbers as its grounds, e.g., (RFC2778:Sec.2.4) refers to Section 2.4 of RFC 2778.
本规范基于从IMPP模型和需求文档中提取的最小模型。该模型由以下项目组成。每一个都附有相应的RFC及其章节号作为其依据，例如，（RFC2778：第2.4节）参考RFC 2778第2.4节。
(a) PRESENCE INFORMATION consists of one or more PRESENCE TUPLES, where a PRESENCE TUPLE consists of a STATUS, an optional COMMUNICATION ADDRESS, and optional OTHER PRESENCE MARKUP. Note that the CONTACT ADDRESS in a COMMUNICATIONS ADDRESS is understood in this document to refer only to a URI (RFC2778:Sec.3).
(a) 状态信息由一个或多个状态元组组成，其中状态元组由状态、可选通信地址和可选的其他状态标记组成。注意，通信地址中的联系人地址在本文档中理解为仅指URI（RFC2778：第3节）。
(b) STATUS has at least the mutually-exclusive values OPEN and CLOSED, which have meaning for the acceptance of INSTANT MESSAGES, and may have meaning for other COMMUNICATION MEANS. There may be other values of STATUS that do not imply anything about INSTANT MESSAGE acceptance. These other values of STATUS may be combined with OPEN and CLOSED or they may be mutually-exclusive with those values (RFC2778:Sec.3, RFC2779:Sec.4.4.1- 4.4.3).
(b) 状态至少具有互斥的值OPEN和CLOSED，它们对即时消息的接受具有意义，并且可能对其他通信手段具有意义。可能还有其他状态值并不意味着即时消息的接受。这些其他状态值可以与打开和关闭组合，也可以与这些值相互排斥（RFC2778:第3节，RFC2779:第4.4.1-4.4.3节）。
(c) STATUS may consist of single or multiple values.(RFC2778:Sec.2.4)
(c) 状态可以由单个或多个值组成。（RFC2778:第2.4节）
(d) There must be a means of extending the common presence format to represent additional information not included in the common format. The extension and registration mechanisms must be defined for presence information schema, including new STATUS conditions and new forms for OTHER PRESENCE MARKUP (RFC2779:Sec.3.1.4-3.1.5).
(d) 必须有一种扩展通用存在格式的方法来表示通用格式中未包含的其他信息。必须为状态信息模式定义扩展和注册机制，包括其他状态标记的新状态条件和新表单（RFC2779：第3.1.4-3.1.5节）。
(e) The common presence format must include a means to uniquely identify the PRESENTITY whose PRESENCE INFORMATION is reported (RFC2779:Sec.3.1.2).
(e) 通用存在格式必须包括唯一标识其存在信息被报告的存在实体的方法（RFC2779：第3.1.2节）。
(f) The common presence format must allow the PRESENTITY to secure presence information sent to a WATCHER. The format must allow integrity, confidentiality and authentication properties to be applied to presence information (RFC2779:Sec5.2.1, 5.2.4, 5.3.1, 5.3.3).
(f) 公共存在格式必须允许存在实体保护发送给观察者的存在信息。格式必须允许完整性、机密性和身份验证属性应用于状态信息（RFC2779:Sec5.2.1、5.2.4、5.3.1、5.3.3）。
In addition to the minimal model described above, the format specified in this specification has the following features.
除上述最小型号外，本规范中规定的格式还具有以下特点。
(a) Relative priorities of contact addresses are specifiable in order to allow the source of PRESENCE INFORMATION to tell the receiver (WATCHER USER AGENTS) its preference over multiple contact means.
(a) 联系人地址的相对优先级是可指定的，以便允许存在信息源告知接收者（观察者用户代理）其相对于多个联系人手段的偏好。
(b) The presence format is able to contain the timestamp of the creation of the PRESENCE INFORMATION. The timestamp in the presence document lets the receiver know the time of the creation of the data even if the message containing it is delayed. It can also be used to detect a replay attack, independent of the underlying signature mechanism. Note that this mechanism does not assume any global time synchronization system for watchers and presentities (see Appendix A of RFC2779, 8.1.4 A7), but rather assumes that the minimum length of time that might pass before presence information is considered stale
(b) 存在格式能够包含存在信息的创建的时间戳。存在文档中的时间戳让接收者知道创建数据的时间，即使包含数据的消息被延迟。它还可用于检测重播攻击，与底层签名机制无关。请注意，该机制不假设观察者和存在实体的任何全局时间同步系统（见RFC2779附录A，8.1.4 A7），而是假设存在信息被视为过时之前可能经过的最小时间长度
is long enough that minor variations among system clocks will not lead to misjudgments of the freshness of presence information.
足够长，系统时钟之间的微小变化不会导致对状态信息新鲜度的错误判断。
The Presence Information Data Format encodes presence information in XML (eXtensible Markup Language [XML]). Regarding the features of PRESENCE INFORMATION discussed above, such that it has a hierarchical structure and it should be fully extensible, XML is considered as the most desirable framework over other candidates such as vCard [vCard].
状态信息数据格式以XML（可扩展标记语言[XML]）对状态信息进行编码。关于上面讨论的状态信息的特征，例如它具有层次结构并且应该是完全可扩展的，XML被认为是比其他候选框架（如vCard[vCard]）更理想的框架。
This section describes an overview of the presence data format defined in this memo.
本节概述了本备忘录中定义的状态数据格式。
This memo defines a new content type "application/pidf+xml" for an XML MIME entity that contains presence information. This specification follows the recommendations and conventions described in [RFC3023], including the naming convention of the type ('+xml' suffix) and the usage of the 'charset' parameter.
此备忘录为包含状态信息的xml MIME实体定义了一个新的内容类型“application/pidf+xml”。本规范遵循[RFC3023]中描述的建议和约定，包括类型（“+xml”后缀）的命名约定和“charset”参数的使用。
Although it is defined as optional, use of the 'charset' parameter is RECOMMENDED. If the 'charset' parameter is not specified, conforming XML processors MUST follow the requirements in section 4.3.3 of [XML].
尽管定义为可选，但建议使用“charset”参数。如果未指定“字符集”参数，则符合要求的XML处理器必须遵守[XML]第4.3.3节的要求。
This subsection outlines the information in an "application/pidf+xml" document. A full definition of the PIDF content is in Section 4.
本小节概述了“应用程序/pidf+xml”文档中的信息。PIDF内容的完整定义见第4节。
o PRESENTITY URL: specifies the "pres" URL of the PRESENTITY. o List of PRESENCE TUPLES - Identifier: token to identify this tuple within the presence information. - STATUS: OPEN/CLOSED and/or extension status values. - COMMUNICATION ADDRESS: COMMUNICATION MEANS and CONTACT ADDRESS of this tuple. (optional) - Relative priority: numerical value specifying the priority of this COMMUNICATION ADDRESS. (optional) - Timestamp: timestamp of the change of this tuple.(optional) - Human readable comment: free text memo about this tuple (optional)
o PRESENTITY URL：指定PRESENTITY的“pres”URL。o状态元组列表-标识符：在状态信息中标识此元组的令牌。-状态：打开/关闭和/或扩展状态值。-通讯地址：此元组的通讯方式和联系地址。（可选）-相对优先级：指定此通信地址优先级的数值。（可选）-时间戳：此元组更改的时间戳。（可选）-人类可读注释：关于此元组的自由文本备忘录（可选）
o PRESENTITY human readable comment: free text memo about the PRESENTITY (optional).
o PRESENTITY人类可读注释：关于PRESENTITY的自由文本备忘录（可选）。
This section defines an XML-encoded presence information data format (PIDF) for use with CPP compliant systems. A presence payload in this format is expected to be produced by the PRESENTITY (the source of the PRESENCE INFORMATION) and transported to the WATCHERS by the presence servers or gateways without any interpretation or modification.
本节定义了用于符合CPP的系统的XML编码的状态信息数据格式（PIDF）。这种格式的存在有效载荷预计由存在实体（存在信息的来源）产生，并由存在服务器或网关传输给观察者，而无需任何解释或修改。
A PIDF object is a well formed XML document.
PIDF对象是格式良好的XML文档。
It MUST have the XML declaration and it SHOULD contain an encoding declaration in the XML declaration, e.g., "<?xml version='1.0' encoding='UTF-8'?>". If the charset parameter of the MIME content type declaration is present and it is different from the encoding declaration, the charset parameter takes precedence.
它必须具有XML声明，并且应该在XML声明中包含编码声明，例如“<？XML version='1.0'encoding='UTF-8'？>”。如果MIME内容类型声明的charset参数存在并且与编码声明不同，则charset参数优先。
Every application conformant to this specification MUST accept the UTF-8 character encoding to ensure the minimal interoperability.
符合本规范的每个应用程序都必须接受UTF-8字符编码，以确保最小的互操作性。
PIDF elements are associated with the XML namespace name 'urn:ietf:params:xml:ns:pidf', declared using an xmlns attribute, per [XML-NS]. The namespace may be a default namespace, or may be associated with some namespace prefix (see section 4.2.2 for examples).
PIDF元素与XML命名空间名称“urn:ietf:params:XML:ns:PIDF”关联，该名称是根据[XML-ns]使用xmlns属性声明的。名称空间可以是默认名称空间，也可以与某些名称空间前缀相关联（示例见第4.2.2节）。
The root of an "application/pidf+xml" object is a <presence> element associated with the presence information namespace. This contains any number (including 0) of <tuple> elements, followed by any number (including 0) of <note> elements, followed by any number of OPTIONAL extension elements from other namespaces.
“application/pidf+xml”对象的根是与状态信息命名空间关联的<presence>元素。它包含任意数量（包括0）的<tuple>元素，后跟任意数量（包括0）的<note>元素，后跟任意数量的来自其他名称空间的可选扩展元素。
The <presence> element MUST have an 'entity' attribute. The value of the 'entity' attribute is the 'pres' URL of the PRESENTITY publishing this presence document.
<presence>元素必须具有“entity”属性。“实体”属性的值是发布此状态文档的状态实体的“pres”URL。
The <presence> element MUST contain a namespace declaration ('xmlns') to indicate the namespace on which the presence document is based. The presence document compliant to this specification MUST have the namespace 'urn:ietf:params:xml:ns:pidf:'.
<presence>元素必须包含名称空间声明（'xmlns'），以指示状态文档所基于的名称空间。符合此规范的状态文档必须具有名称空间“urn:ietf:params:xml:ns:pidf:”。
It MAY contain other namespace declarations for the extensions used in the presence XML document.
它可能包含存在XML文档中使用的扩展的其他命名空间声明。
The <tuple> element carries a PRESENCE TUPLE, consisting of a mandatory <status> element, followed by any number of OPTIONAL extension elements (possibly from other namespaces), followed by an OPTIONAL <contact> element, followed by any number of OPTIONAL <note> elements, followed by an OPTIONAL <timestamp> element.
<tuple>元素携带一个PRESENCE元组，由一个强制性的<status>元素组成，后跟任意数量的可选扩展元素（可能来自其他名称空间），后跟一个可选的<contact>元素，后跟任意数量的可选的<note>元素，后跟一个可选的<timestamp>元素。
Tuples provide a way of segmenting presence information. Protocols or applications may choose to segment the presence information associated with a presentity for any number of reasons - for example, because components of the full presence information for a presentity have come from distinct devices or different applications on the same device, or have been generated at different times. Tuples should be preferred over other manners of segmenting presence information such as creating multiple PIDF instances.
元组提供了一种分割存在信息的方法。协议或应用程序可以出于任何数量的原因选择分割与存在实体相关联的存在信息——例如，因为存在实体的完整存在信息的组件来自不同的设备或同一设备上的不同应用程序，或者在不同的时间生成。元组应该优先于分割存在信息的其他方式，如创建多个PIDF实例。
The <tuple> element MUST contain an 'id' attribute which is used to distinguish this tuple from other tuples in the same PRESENTITY. The value of an 'id' attribute MUST be unique within 'id' attribute values of other tuples for the same PRESENTITY. An 'id' value is used by applications processing the presence document to identify the corresponding tuple in the previously acquired PRESENCE INFORMATION of the same PRESENTITY. The value of the 'id' attribute is an arbitrary string, and has no significance beyond providing a means to distinguish <tuple> values, as noted above.
<tuple>元素必须包含一个“id”属性，该属性用于将此元组与同一实体中的其他元组区分开来。“id”属性的值在同一实体的其他元组的“id”属性值中必须是唯一的。处理呈现文档的应用程序使用“id”值来标识相同呈现实体的先前获取的呈现信息中的对应元组。“id”属性的值是一个任意字符串，除了提供一种区分<tuple>值的方法外，没有任何意义，如上所述。
The <contact> element is OPTIONAL because a PRESENTITY might need to hide its COMMUNICATION ADDRESS or there might be tuples not related to any COMMUNICATION MEANS. Tuples that contain a <basic> status element SHOULD contain a <contact> address. Tuples MAY contain conflicting presence status - one <tuple> might provide a <basic> <status> of OPEN, and another <tuple> in the same PIDF could contain a <basic> <status> of CLOSED, even if they both contain the same <contact> address.
<contact>元素是可选的，因为存在实体可能需要隐藏其通信地址，或者可能存在与任何通信方式无关的元组。包含<basic>状态元素的元组应包含<contact>地址。元组可能包含冲突的状态-一个<tuple>可能提供打开的<basic><status>，而同一PIDF中的另一个<tuple>可能包含关闭的<basic><status>，即使它们都包含相同的<contact>地址。
The manner in which segmented presence information is understood by the WATCHER USER AGENT is highly dependent on the capabilities of the WATCHER USER AGENT and the presence application in question. In the absence of any application-specific or protocol-specific understanding of the meaning of tuples, WATCHER USER AGENTS MAY obey the following guidelines. WATCHER USER AGENTS should note which tuples in the PIDF have changed their state since the last
观察者用户代理理解分段存在信息的方式高度依赖于观察者用户代理和所述存在应用的能力。在对元组的含义没有任何特定于应用程序或特定于协议的理解的情况下，观察者用户代理可以遵守以下准则。观察者用户代理应该注意PIDF中的哪些元组自上次事件以来已更改其状态
notification by correlating the 'id' of each <tuple> with those received in previous notifications and comparing both <status> values and <timestamp> elements in the tuples, if any are present.
通过将每个<tuple>的“id”与以前的通知中接收到的“id”相关联，并比较<status>值和<timestamp>元组中的元素（如果存在的话）。
The <status> element contains one OPTIONAL <basic> element, followed by any number of OPTIONAL extension elements (possibly from other namespaces), under the restriction that at least one child element appears in the <status> element. These children elements of <status> contain status values of this tuple. By allowing multiple status values in a single <tuple> element, different types of status values, e.g., reachability and location, can be represented by a <tuple>. See Section 4.3 for an example with multiple status values.
<status>元素包含一个可选的<basic>元素，后面是任意数量的可选扩展元素（可能来自其他名称空间），限制是在<status>元素中至少出现一个子元素。<status>的这些子元素包含此元组的状态值。通过在单个<tuple>元素中允许多个状态值，不同类型的状态值（例如可达性和位置）可以用<tuple>表示。有关多个状态值的示例，请参见第4.3节。
This memo only defines the <basic> status value element. Other status values may be included using the standard extensibility framework (see Section 4.2.4). Applications encountering unrecognized elements within <status> may ignore them, unless they carry a mustUnderstand="true" or mustUnderstand="1" attribute (see section 4.2.3).
此备注仅定义<basic>状态值元素。使用标准扩展性框架可以包括其他状态值（参见第4.2.4节）。在<status>中遇到无法识别元素的应用程序可能会忽略这些元素，除非它们带有mustUnderstand=“true”或mustUnderstand=“1”属性（参见第4.2.3节）。
Note that, while the <status> element MUST have at least one status value element, this status value might not be the <basic> element.
请注意，虽然<status>元素必须至少有一个status value元素，但此status值可能不是<basic>元素。
The <basic> element contains one of the following strings: "open" or "closed".
<basic>元素包含以下字符串之一：“打开”或“关闭”。
The values "open" and "closed" indicate availability to receive INSTANT MESSAGES if the <tuple> is for an instant messaging address. They also indicate general availability for other communication means, but this memo does not specify these in detail.
如果<tuple>用于即时消息地址，则值“open”和“closed”表示可接收即时消息。它们还表明了其他通信手段的普遍可用性，但本备忘录并未详细说明。
open: In the context of INSTANT MESSAGES, this value means that the associated <contact> element, if any, corresponds to an INSTANT INBOX that is ready to accept an INSTANT MESSAGE.
打开：在即时消息上下文中，此值表示关联的<contact>元素（如果有）对应于准备接受即时消息的即时收件箱。
closed: In the context of INSTANT MESSAGES, this value means that the associated <contact> element, if any, corresponds to an INSTANT INBOX that is unable to accept an INSTANT MESSAGE.
关闭：在即时消息上下文中，此值表示关联的<contact>元素（如果有）对应于无法接受即时消息的即时收件箱。
The <contact> element contains a URL of the contact address. It optionally has a 'priority' attribute, whose value means a relative priority of this contact address over the others. The value of the
<contact>元素包含联系人地址的URL。它可选地具有“优先级”属性，其值表示此联系人地址相对于其他地址的相对优先级。价值
attribute MUST be a decimal number between 0 and 1 inclusive with at most 3 digits after the decimal point. Higher values indicate higher priority. Examples of priority values are 0, 0.021, 0.5, 1.00. If the 'priority' attribute is omitted, applications MUST assign the contact address the lowest priority. If the 'priority' value is out of the range, applications just SHOULD ignore the value and process it as if the attribute was not present.
属性必须是介于0和1之间（包括0和1）的十进制数，小数点后最多有3位数字。值越高表示优先级越高。优先级值的示例为0、0.021、0.5、1.00。如果省略了“优先级”属性，应用程序必须为联系人地址分配最低优先级。如果“priority”值超出范围，应用程序应该忽略该值，并像处理不存在的属性一样对其进行处理。
Applications SHOULD handle contacts with a higher priority as they have precedence over those with lower priorities. How they are actually treated is beyond this specification. Also, how to handle contacts with the same priority is up to implementations.
应用程序应处理优先级较高的联系人，因为他们的优先级高于优先级较低的联系人。如何实际处理它们超出了本规范。此外，如何处理具有相同优先级的联系人取决于实现。
The <note> element contains a string value, which is usually used for a human readable comment. A <note> element MAY appear as a child element of <presence> or as a child element of the <tuple> element. In the former case the comment is about the PRESENTITY and in the latter case the comment is regarding the particular tuple.
元素包含一个字符串值，通常用于人类可读的注释。<note>元素可以显示为<presence>的子元素或<tuple>元素的子元素。在前一种情况下，注释是关于存在实体的，在后一种情况下，注释是关于特定元组的。
Note that, wherever it appears, a <note> element SHOULD NOT be used, and interpreted, as a non-interoperable substitute for status of its parent element.
请注意，<Note>元素无论出现在何处，都不应被使用，也不应被解释为其父元素状态的不可互操作替代。
The <note> element SHOULD have a special attribute 'xml:lang' to specify the language used in the contents of this element as defined in Section 2.12 of [XML]. The value of this attribute is the language identifier as defined by [RFC3066]. It MAY be omitted when the language used is implied by the larger context such as the encoding information of the contents, such as an xml:lang attribute on an enclosing XML element, or a Content-language header [RFC3282] on an enclosing MIME wrapper.
<note>元素应具有一个特殊属性“xml:lang”，以指定[xml]第2.12节中定义的该元素内容中使用的语言。此属性的值是[RFC3066]定义的语言标识符。当所使用的语言由更大的上下文（例如内容的编码信息）暗示时，可以省略它，例如封闭的xml元素上的xml:lang属性，或封闭的MIME包装上的内容语言头[RFC3282]。
The <timestamp> element contains a string indicating the date and time of the status change of this tuple. The value of this element MUST follow the IMPP datetime format [RFC3339]. Timestamps that contain 'T' or 'Z' MUST use the capitalized forms.
<timestamp>元素包含一个字符串，指示此元组状态更改的日期和时间。此元素的值必须遵循IMPP datetime格式[RFC3339]。包含“T”或“Z”的时间戳必须使用大写形式。
As a security measure, the <timestamp> element SHOULD be included in all tuples unless the exact time of the status change cannot be determined. For security guidelines for watchers receiving presence information with timestamps, see the Security Considerations.
作为安全措施，<timestamp>元素应包含在所有元组中，除非无法确定状态更改的确切时间。有关接收带有时间戳的状态信息的观察者的安全指南，请参阅安全注意事项。
A PRESENTITY MUST NOT generate successive <presence> elements containing the same timestamp.
存在实体不得生成包含相同时间戳的连续<presence>元素。
The presence information extensibility framework is based on XML namespaces [XML-NS].
状态信息可扩展性框架基于XML名称空间[XML-NS]。
RFC 2779 requires that PIDF have a means of extending <status> values beyond <basic>. These extensions MUST NOT modify how <basic> is to be understood, nor change the structure or semantics of PIDF bodies themselves. These extensions merely allow protocols and applications to define richer presence data.
RFC 2779要求PIDF具有将<status>值扩展到<basic>之外的方法。这些扩展不能修改<basic>的理解方式，也不能改变PIDF体本身的结构或语义。这些扩展只允许协议和应用程序定义更丰富的状态数据。
All elements and some attributes are associated with a "namespace", which is in turn associated with a globally unique URI. Any developer can introduce their own element names, avoiding conflict by choosing an appropriate namespace URI.
所有元素和一些属性都与一个“名称空间”相关联，该名称空间又与一个全局唯一的URI相关联。任何开发人员都可以引入自己的元素名，通过选择适当的名称空间URI来避免冲突。
Within the presence data, element or attribute names are associated with a particular namespace by a namespace prefix, which is a leading part of the name, followed by a colon (":"); e.g.,
在状态数据中，元素或属性名称通过名称空间前缀与特定名称空间相关联，名称空间前缀是名称的前导部分，后跟冒号（“：”）；例如。，
<prefix:element-name ...> ... </prefix:element-name>
<prefix:element-name ...> ... </prefix:element-name>
Where, 'prefix' is the header name prefix, 'element-name' is a name which is scoped by the namespace associated with 'prefix'. Note that the choice of 'prefix' is quite arbitrary; it is the corresponding URI that defines the naming scope. Two different prefixes associated with the same namespace URI refer to the same namespace.
其中，“prefix”是标题名称前缀，“element name”是一个名称，其范围由与“prefix”关联的命名空间确定。注意，“前缀”的选择非常随意；定义命名范围的是相应的URI。与同一命名空间URI关联的两个不同前缀引用同一命名空间。
A default namespace can be declared for XML elements without a namespace prefix. The default namespace does NOT apply to attribute names, but interpretation of an unprefixed attribute can be determined by the containing element.
可以为没有名称空间前缀的XML元素声明默认名称空间。默认名称空间不适用于属性名称，但非固定属性的解释可以由包含的元素确定。
A namespace is identified by a URI. In this usage, the URI is used simply as a globally unique identifier, and there is no requirement that it can be used to retrieve a web resource, or for any other purpose. Any legal globally unique URI MAY be used to identify a namespace. (By "globally unique", we mean constructed according to some set of rules so that it is reasonable to expect that nobody else will use the same URI for a different purpose.)
命名空间由URI标识。在这种用法中，URI仅用作全局唯一标识符，不要求它可用于检索web资源或用于任何其他目的。可以使用任何合法的全局唯一URI来标识命名空间。（所谓“全局唯一性”，我们指的是根据一组规则构造的，这样就可以合理地预期没有其他人会将相同的URI用于不同的目的。）
For further details, see the XML namespace specification [XML-NS].
有关更多详细信息，请参阅XML名称空间规范[XML-NS]。
A URI used as a namespace identifier in PRESENCE INFORMATION data MUST be a full absolute-URI, per RFC 2396 [URI]. (Relative URIs and URI-references containing fragment identifiers MUST NOT be used for this purpose.)
根据RFC 2396[URI]，在状态信息数据中用作命名空间标识符的URI必须是完全绝对URI。（包含片段标识符的相对URI和URI引用不得用于此目的。）
The namespace URI for elements defined by this specification is a URN [URN], using the namespace identifier 'ietf' defined by [URN-NS-IETF] and extended by [XML-Registry]:
本规范定义的元素的命名空间URI是URN[URN]，使用由[URN-NS-ietf]定义并由[XML注册表]扩展的命名空间标识符“ietf”：
urn:ietf:params:xml:ns:pidf
urn:ietf:params:xml:ns:pidf
Thus, simple presence data might be thus:
因此，简单存在数据可能是：
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<impp:tuple id="sg89ae">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple>
</impp:presence>
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<impp:tuple id="sg89ae">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="0.8">tel:+09012345678</impp:contact>
</impp:tuple>
</impp:presence>
, using a default XML namespace:
，使用默认的XML命名空间：
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:someone@example.com">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<contact priority="0.8">tel:+09012345678</contact>
</tuple>
</presence>
As is generally the case in XML with namespaces, the xmlns attribute can be used on any element in the presence information to define either the default namespace or a namespace associated with a namespace prefix.
与具有名称空间的XML中的一般情况一样，xmlns属性可用于状态信息中的任何元素，以定义默认名称空间或与名称空间前缀关联的名称空间。
Except as noted below, a processor of PRESENCE INFORMATION MUST ignore any XML element with an unrecognized name (i.e., having an unrecognized namespace URI, or an unrecognized local name within that namespace). This includes all of the element content, even if it appears to contain elements with recognized names.
除下文所述外，状态信息的处理者必须忽略任何名称不可识别的XML元素（即，名称空间URI不可识别，或名称空间中的本地名称不可识别）。这包括所有元素内容，即使它似乎包含具有可识别名称的元素。
Extensions to PIDF are informational in nature - they provide additional information beyond <basic> status. However, in order to understand a complex extension, nested elements within an extension element might need to be marked as mandatory. In such cases, the element name is qualified with a mustUnderstand='true' or mustUnderstand='1' attribute. See section 4.3.3 for an example.
PIDF的扩展本质上是信息性的-它们提供了<basic>状态之外的附加信息。但是，为了理解复杂的扩展，可能需要将扩展元素中的嵌套元素标记为必填项。在这种情况下，元素名由mustUnderstand='true'或mustUnderstand='1'属性限定。示例见第4.3.3节。
NOTE: a mustUnderstand='true' or mustUnderstand='1' attribute within an element that is being ignored is itself ignored. The writer of nested mandatory-to-understand information is responsible for ensuring that any enclosing element is also labelled with a mustUnderstand='true' or mustUnderstand='1' attribute, if necessary.
注意：被忽略的元素中的mustUnderstand='true'或mustUnderstand='1'属性本身被忽略。必要时，嵌套必需理解信息的编写者负责确保任何封闭元素也标有mustUnderstand='true'或mustUnderstand='1'属性。
This specification defines (section 4.1) elements within the 'urn:ietf:params:xml:ns:pidf' namespace that MUST be recognized in CPP presence data. Processors MUST handle these as described, even if they do not carry a mustUnderstand attribute. The XML Schema Definition (section 4.4) indicates those elements that MUST be present in a valid presence information document.
本规范定义了（第4.1节）“urn:ietf:params:xml:ns:pidf”命名空间中必须在CPP状态数据中识别的元素。处理器必须按照描述处理这些数据，即使它们没有mustUnderstand属性。XML模式定义（第4.4节）指出了必须存在于有效状态信息文档中的元素。
If an agent receives PRESENCE INFORMATION with a <status> block containing an unrecognized element with a mustUnderstand='true' (or '1') attribute, it should treat that entire element and any content as unrecognized and not attempt to process it.
如果代理接收到带有<status>块且包含mustUnderstand='true'（或'1'）属性的未识别元素的状态信息，则应将整个元素和任何内容视为未识别，而不尝试对其进行处理。
In order to ensure that minimal implementations can correctly process basic PIDF information the mustUnderstand attribute MUST be used only within optional elements nested in a <status> element. This will ensure that problems processing an extension are restricted to that extension and do not affect the processing of the basic PIDF information defined in this specification.
为了确保最小实现能够正确处理基本PIDF信息，mustUnderstand属性只能在嵌套在<status>元素中的可选元素中使用。这将确保处理扩展的问题仅限于该扩展，不会影响本规范中定义的基本PIDF信息的处理。
This memo defines only the <basic> status value with values of "open" and "closed". Other status values are possible using the standard namespace-based extensibility rules defined above.
本备忘录仅定义了具有“打开”和“关闭”值的<basic>状态值。其他状态值可以使用上面定义的基于标准命名空间的扩展性规则。
For example, a location status value might be included thus:
例如，可能包括位置状态值，因此：
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:local="urn:example-com:pidf-status-type"
entity="pres:someone@example.com">
<tuple id="ub93s3">
<status>
<basic>open</basic>
<local:location>home</local:location>
</status>
<contact>im:someone@example.com</contact>
</tuple>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:local="urn:example-com:pidf-status-type"
entity="pres:someone@example.com">
<tuple id="ub93s3">
<status>
<basic>open</basic>
<local:location>home</local:location>
</status>
<contact>im:someone@example.com</contact>
</tuple>
</presence>
Some new status values will 'extend' the value of the <basic> element. For example, a status value defined for use with instant messaging may include values such as 'away', 'busy' and 'offline'. In order that some level of interoperability be maintained with user agents that don't recognize the new extension, the <basic> status value must also be included. This means that extensions are not obligated to define a mapping from each of their values to OPEN or CLOSED.
一些新的状态值将“扩展”<basic>元素的值。例如，定义用于即时消息传递的状态值可能包括诸如“离开”、“忙碌”和“脱机”等值。为了与不识别新扩展的用户代理保持一定程度的互操作性，还必须包括<basic>状态值。这意味着扩展没有义务定义从每个值到打开或关闭的映射。
Although the existing PIDF definition allows arbitrary elements to appear in the <status> element, it may be sometimes desirable to standardize extension status elements and their semantics (the meanings of particular statuses, how they should be interpreted). The URN 'urn:ietf:params:xml:ns:pidf:status' has been specified as an umbrella namespace under which extensions to the <status> PIDF element should be specified (e.g., urn:ietf:params:xml:ns:pidf:status:my-extension). New values under this namespace MUST be defined by a standards-track RFC.
尽管现有的PIDF定义允许任意元素出现在<status>元素中，但有时可能需要标准化扩展状态元素及其语义（特定状态的含义，它们应该如何解释）。URN'URN:ietf:params:xml:ns:pidf:status'已指定为伞式命名空间，在该命名空间下应指定对<status>pidf元素的扩展（例如，URN:ietf:params:xml:ns:pidf:status:my extension）。此命名空间下的新值必须由标准跟踪RFC定义。
The following example XML Schema defines an extension for <location> presence information, which can have the values of 'home', 'office', or 'car'. If the <location> element were standardized, this document would be made available in an RFC along with information about the use of the extension. These extensions should use the namespace 'urn:ietf:params:xml:ns:pidf:status', and each RFC defining an extension should register an extension name within that namespace with IANA.
下面的示例XML模式为<location>状态信息定义了一个扩展，它的值可以是“home”、“office”或“car”。如果<location>元素被标准化，则此文档将在RFC中提供，并提供有关扩展使用的信息。这些扩展应该使用名称空间“urn:ietf:params:xml:ns:pidf:status”，每个定义扩展的RFC应该在该名称空间中向IANA注册扩展名。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:status"
xmlns:tns="urn:ietf:params:xml:ns:pidf:status"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:simpleType name="location">
<xs:restriction base="xs:string">
<xs:enumeration value="home"/>
<xs:enumeration value="office"/>
<xs:enumeration value="car"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="location">
<xs:restriction base="xs:string">
<xs:enumeration value="home"/>
<xs:enumeration value="office"/>
<xs:enumeration value="car"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
</xs:schema>
In addition to the XML Schema to validate the extension, registration of the extension name with IANA, RFCs defining extensions MUST discuss:
除了验证扩展的XML模式外，向IANA注册扩展名、定义扩展的RFC还必须讨论：
- The domain of applicability of the extension. Is this extension exclusively valuable to IM clients, telephones, geolocators, etc? What sorts of presence applications would use this extension and under what circumstances?
- 扩展的适用范围。此扩展是否仅对IM客户端、电话、地理定位器等有价值？什么类型的状态应用程序会使用此扩展？在什么情况下？
- Semantics for the presence states defined in the extension. What disposition provokes an automated presentity to declare that it is in state X, or does a human select X from a drag-down menu? Is there any general guidance for watchers of presence information with state Y (for example, how they should best attempt to communicate with the presentity, if at all, when the principal is in state Y).
- 扩展中定义的存在状态的语义。什么样的配置会促使自动呈现实体声明它处于状态X，或者人类是否从下拉菜单中选择X？对于状态为Y的在场信息的观察者是否有任何一般性指导（例如，当主体处于状态Y时，他们应该如何最好地尝试与在场实体沟通（如果有）。
Extensions SHOULD also discuss:
延期还应讨论：
- How, if at all, any presence states defined in the extension related to <basic>, or to any relevant extension previously published in an RFC. For example, "state Z implies OPEN, so it MUST NOT be used if a basic state of CLOSED is expressed", or "you should use the extension in this document, not the extension in RFC QQQQ, if your circumstances are as follows...."
- 如何（如果有的话）在扩展中定义与<basic>相关的任何存在状态，或与先前在RFC中发布的任何相关扩展相关的存在状态。例如，“状态Z表示打开，因此如果表示关闭的基本状态，则不得使用该状态”，或“如果您的情况如下，则应使用本文档中的扩展名，而不是RFC QQQ中的扩展名……”
The following instance document uses a hypothetical 'pidf:im' XML namespace as an example of the sort of status extension that might be developed for PIDF.
下面的实例文档使用一个假设的“pidf:im”XML名称空间作为可能为pidf开发的状态扩展的示例。
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
<im:im>busy</im:im>
<myex:location>home</myex:location>
</status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I'll be in Tokyo next week</note>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:im="urn:ietf:params:xml:ns:pidf:im"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<tuple id="bs35r9">
<status>
<basic>open</basic>
<im:im>busy</im:im>
<myex:location>home</myex:location>
</status>
<contact priority="0.8">im:someone@mobilecarrier.net</contact>
<note xml:lang="en">Don't Disturb Please!</note>
<note xml:lang="fr">Ne derangez pas, s'il vous plait</note>
<timestamp>2001-10-27T16:49:29Z</timestamp>
</tuple>
<tuple id="eg92n8">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">mailto:someone@example.com</contact>
</tuple>
<note>I'll be in Tokyo next week</note>
</presence>
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="ck38g9">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:mytupletag>Extended value in tuple</myex:mytupletag>
<impp:contact priority="0.65">tel:+09012345678</impp:contact>
</impp:tuple>
<impp:tuple id="md66je">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="1.0">
im:someone@mobilecarrier.net</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.example.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="ck38g9">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:mytupletag>Extended value in tuple</myex:mytupletag>
<impp:contact priority="0.65">tel:+09012345678</impp:contact>
</impp:tuple>
<impp:tuple id="md66je">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<impp:contact priority="1.0">
im:someone@mobilecarrier.net</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.mycompany.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="tj25ds">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:complexExtension>
<myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
<myex:ex2>val2</myex:ex2>
</myex:complexExtension>
<impp:contact priority="0.725">tel:+09012345678</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
<?xml version="1.0" encoding="UTF-8"?>
<impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf"
xmlns:myex="http://id.mycompany.com/presence/"
entity="pres:someone@example.com">
<impp:tuple id="tj25ds">
<impp:status>
<impp:basic>open</impp:basic>
</impp:status>
<myex:complexExtension>
<myex:ex1 impp:mustUnderstand="1">val1</myex:ex1>
<myex:ex2>val2</myex:ex2>
</myex:complexExtension>
<impp:contact priority="0.725">tel:+09012345678</impp:contact>
</impp:tuple>
<myex:mytag>My extended presentity information</myex:mytag>
</impp:presence>
Here, <myex:ex1> must be understood and, if it is not recognized, <myex:complexExtension> MUST be ignored. <myex:mytag> and <myex:ex2> MAY be ignored if they are not recognized.
在这里，必须理解<myex:ex1>，如果无法识别，则必须忽略<myex:complexExtension><如果无法识别myex:mytag>和<myex:ex2>，则可以忽略它们。
This section gives the XML Schema Definition [XMLSchema1] of the "application/pidf+xml" format. This is presented as a formal definition of the "application/pidf+xml" format. Note that the XML Schema definition is not intended to be used with on-the-fly validation of the presence XML document.
本节给出了“application/pidf+XML”格式的XML模式定义[XMLSchema1]。这是“应用程序/pidf+xml”格式的正式定义。请注意，XML模式定义不打算用于对状态XML文档进行动态验证。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf"
xmlns:tns="urn:ietf:params:xml:ns:pidf"
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:pidf"
xmlns:tns="urn:ietf:params:xml:ns:pidf"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:element name="presence" type="tns:presence"/>
<xs:element name="presence" type="tns:presence"/>
<xs:complexType name="presence">
<xs:sequence>
<xs:element name="tuple" type="tns:tuple" minOccurs="0"
maxOccurs="unbounded"/>
<xs:complexType name="presence">
<xs:sequence>
<xs:element name="tuple" type="tns:tuple" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="entity" type="xs:anyURI" use="required"/>
</xs:complexType>
<xs:complexType name="tuple">
<xs:sequence>
<xs:element name="status" type="tns:status"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="contact" type="tns:contact" minOccurs="0"/>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
<xs:complexType name="tuple">
<xs:sequence>
<xs:element name="status" type="tns:status"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="contact" type="tns:contact" minOccurs="0"/>
<xs:element name="note" type="tns:note" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="xs:dateTime" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
<xs:complexType name="status">
<xs:sequence>
<xs:element name="basic" type="tns:basic" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="basic">
<xs:restriction base="xs:string">
<xs:enumeration value="open"/>
<xs:enumeration value="closed"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="status">
<xs:sequence>
<xs:element name="basic" type="tns:basic" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="basic">
<xs:restriction base="xs:string">
<xs:enumeration value="open"/>
<xs:enumeration value="closed"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="contact">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="priority" type="tns:qvalue"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="contact">
<xs:simpleContent>
<xs:extension base="xs:anyURI">
<xs:attribute name="priority" type="tns:qvalue"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:complexType name="note">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
<xs:complexType name="note">
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:simpleContent>
</xs:complexType>
<xs:simpleType name="qvalue">
<xs:restriction base="xs:decimal">
<xs:pattern value="0(.[0-9]{0,3})?"/>
<xs:pattern value="1(.0{0,3})?"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="qvalue">
<xs:restriction base="xs:decimal">
<xs:pattern value="0(.[0-9]{0,3})?"/>
<xs:pattern value="1(.0{0,3})?"/>
</xs:restriction>
</xs:simpleType>
<!-- Global Attributes -->
<xs:attribute name="mustUnderstand" type="xs:boolean" default="0">
<xs:annotation>
<xs:documentation>
This attribute may be used on any element within an optional
PIDF extension to indicate that the corresponding element must
be understood by the PIDF processor if the enclosing optional
element is to be handled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:schema>
<!-- Global Attributes -->
<xs:attribute name="mustUnderstand" type="xs:boolean" default="0">
<xs:annotation>
<xs:documentation>
This attribute may be used on any element within an optional
PIDF extension to indicate that the corresponding element must
be understood by the PIDF processor if the enclosing optional
element is to be handled.
</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:schema>
This memo calls for IANA to:
本备忘录要求IANA：
- register a new MIME content-type application/pidf+xml, per [MIME],
- 按照[MIME]注册新的MIME内容类型应用程序/pidf+xml，
- register a new XML namespace URN per [XML-Registry].
- 按照[XML注册表]注册新的XML命名空间URN。
- register a new XML namespace URN for status extensions per [XML-Registry].
- 根据[XML注册表]为状态扩展注册新的XML命名空间URN。
The registration templates for these are below. For more information on status extensions, see section 4.2.5.
下面是这些的注册模板。有关状态扩展的更多信息，请参阅第4.2.5节。
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pidf+xml
To: ietf-types@iana.org
Subject: Registration of MIME media type application/pidf+xml
MIME media type name: application
MIME媒体类型名称：应用程序
MIME subtype name: pidf+xml
MIME子类型名称：pidf+xml
Required parameters: (none)
所需参数：（无）
Optional parameters: charset Indicates the character encoding of enclosed XML. Default is UTF-8.
可选参数：字符集表示封闭XML的字符编码。默认值为UTF-8。
Encoding considerations: Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [RFC 3023], section 3.2.
编码注意事项：使用XML，它可以使用8位字符，具体取决于所使用的字符编码。参见RFC 3023[RFC 3023]，第3.2节。
Security considerations: 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.
安全注意事项：此内容类型旨在承载状态数据，这些数据可能被视为私人信息。应采取适当的预防措施来限制该信息的披露。
Interoperability considerations: This content type provides a common format for exchange of presence information across different CPP compliant protocols.
互操作性注意事项：此内容类型提供了跨不同CPP兼容协议交换状态信息的通用格式。
Published specification: RFC 3863
已发布规范：RFC 3863
Applications which use this media type: Presence and instant messaging systems.
使用此媒体类型的应用程序：状态和即时消息系统。
Additional information: Magic number(s): File extension(s): Macintosh File Type Code(s):
其他信息：幻数：文件扩展名：Macintosh文件类型代码：
Person & email address to contact for further information: Hiroyasu Sugano EMail: sugano.h@jp.fujitsu.com
联系人和电子邮件地址以获取更多信息：Hiroyasu Sugano电子邮件：Sugano。h@jp.fujitsu.com
Intended usage: LIMITED USE
预期用途：有限用途
Author/Change controller: This specification is a work item of the IETF IMPP working group, with mailing list address <impp@iastate.edu>.
作者/变更控制者：本规范是IETF IMPP工作组的一个工作项，具有邮件列表地址<impp@iastate.edu>.
Other information: This media type is a specialization of application/xml [RFC 3023], and many of the considerations described there also apply to application/pidf+xml.
其他信息：此媒体类型是application/xml[RFC 3023]的一种专门化，其中描述的许多注意事项也适用于application/pidf+xml。
URI
urn:ietf:params:xml:ns:pidf
URI
urn:ietf:params:xml:ns:pidf
Description: This is the XML namespace URI for XML elements defined by RFC 3863 to describe CPP presence information in application/pidf+xml content type.
描述：这是RFC 3863定义的XML元素的XML名称空间URI，用于描述应用程序/pidf+XML内容类型中的CPP存在信息。
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
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=utf-8"/>
<title>Namespace for CPP presence information</title>
</head>
<body>
<h1>Namespace for CPP presence information</h1>
<h2>urn:ietf:params:xml:ns:pidf</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</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=utf-8"/>
<title>Namespace for CPP presence information</title>
</head>
<body>
<h1>Namespace for CPP presence information</h1>
<h2>urn:ietf:params:xml:ns:pidf</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</a>.</p>
</body>
</html>
END
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status'
5.3. URN sub-namespace registration for
'urn:ietf:params:xml:ns:pidf:status'
URI
urn:ietf:params:xml:ns:pidf:status
URI
urn:ietf:params:xml:ns:pidf:status
Description: This is the XML namespace URI for XML elements defined by RFC 3863 to describe extensions to the status of CPP presence information in application/pidf+xml content type.
描述：这是RFC 3863定义的XML元素的XML名称空间URI，用于描述对application/pidf+XML内容类型中CPP状态信息的扩展。
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
Registrant Contact
IETF, IMPP working group, <impp@iastate.edu>
Hiroyasu Sugano, <sugano.h@jp.fujitsu.com>
XML BEGIN <?xml version="1.0"?>
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=utf-8"/>
<title>Namespace for CPP status extensions</title>
</head>
<body>
<h1>Namespace for CPP presence information extensions</h1>
<h2>urn:ietf:params:xml:ns:pidf:status</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</a>.</p>
</body>
</html>
END
<!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=utf-8"/>
<title>Namespace for CPP status extensions</title>
</head>
<body>
<h1>Namespace for CPP presence information extensions</h1>
<h2>urn:ietf:params:xml:ns:pidf:status</h2>
<p>See <a
href="[[[ftp://ftp.rfc-editor.org/in-notes/rfc3863.txt]]]">
RFC3863</a>.</p>
</body>
</html>
END
Because presence is very privacy-sensitive information, the protocol for the presence information MUST have capabilities to protect PIDF from possible threats, such as eavesdropping, corruption, tamper and replay attacks. These security mechanisms must be able to be used end-to-end between presentities and watchers, even if the watcher and the presentity employ different presence protocols and communicate through a CPP gateway. Since the 'application/pidf+xml' MIME type is defined for this PIDF document, staging security for PIDF at the MIME level (with S/MIME [RFC3851]) seems appropriate. Therefore, PIDF should follow the normative recommendations for the use of S/MIME (including minimum ciphersuites) given in the core CPP specification.
由于存在是非常隐私敏感的信息，因此存在信息的协议必须能够保护PIDF免受可能的威胁，如窃听、损坏、篡改和重放攻击。这些安全机制必须能够在存在实体和观察者之间端到端地使用，即使观察者和存在实体采用不同的存在协议并通过CPP网关进行通信。由于“application/pidf+xml”MIME类型是为此pidf文档定义的，因此在MIME级别（使用S/MIME[RFC3851]）对pidf进行分级安全似乎是合适的。因此，PIDF应遵循核心CPP规范中给出的S/MIME（包括最小密码套件）使用规范性建议。
Note that the use of timestamps in PIDF (see section 4.1.7) can provide some rudimentary protection against replay attacks. If a watcher receives presence information that is outdated, it SHOULD be ignored. A watcher can determine that presence information is outdated in a number of fashions. Most significantly, if the newest timestamp in presence information is older than the newest timestamp in the last received presence information, it should be considered outdated. Applications and protocols also are advised to adopt their own rules for determining how frequently presence information should be refreshed. For example, if presence information appears to be more than one hour old, it could be considered outdated (a notification generated for this presence information will not take such a long time to reach a watcher, and if a presentity has not refreshed its presence state in the last hour, it is probably offline).
注意，在PIDF中使用时间戳（见第4.1.7节）可以提供一些基本的保护，防止重放攻击。如果观察者收到过期的状态信息，则应忽略该信息。观察者可以确定存在信息在许多时尚中已经过时。最重要的是，如果存在信息中的最新时间戳早于上次接收到的存在信息中的最新时间戳，则应将其视为过时。还建议应用程序和协议采用它们自己的规则来确定刷新状态信息的频率。例如，如果状态信息出现时间超过一小时，则可能会被视为过时（为该状态信息生成的通知不会花费很长时间到达观察者，并且如果状态实体在过去一小时内未刷新其状态，则可能处于脱机状态）。
All the processors conformant to this specification MUST be able to generate and accept UTF-8 encoding, this being one of the mandatory character encodings for XML conforming processors, and also required by the policies set out in RFC 2277 [RFC2277].
符合本规范的所有处理器必须能够生成并接受UTF-8编码，这是符合XML的处理器的强制性字符编码之一，也是RFC 2277[RFC2277]中规定的策略所要求的。
Other character encodings MAY be accepted (but CPP compliant processors are strongly discouraged from emitting anything other than UTF-8).
可以接受其他字符编码（但强烈建议符合CPP的处理器不要发出UTF-8以外的任何信号）。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 2119，BCP 14，1997年3月。
[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月。
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E.
Maler, "Extensible Markup Language (XML) 1.0 (Second
Edition)", W3C Recommendation, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[MIME]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
Freed，N.，Klensin，J.，和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第五部分：一致性标准和示例”，RFC 2049，1996年11月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, March 1995.
[RFC3066]Alvestrand，H.，“语言识别标签”，BCP 47，RFC 3066，1995年3月。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne，G.和C.Newman，“互联网上的日期和时间：时间戳”，RFC 3339，2002年7月。
[XML-NS] Bray, T., Hollander, D., and A. Layman "Namespaces in
XML", W3C recommendation: xml-names, 14 January 1999,
<http://www.w3.org/TR/REC-xml-names>
[XML-NS] Bray, T., Hollander, D., and A. Layman "Namespaces in
XML", W3C recommendation: xml-names, 14 January 1999,
<http://www.w3.org/TR/REC-xml-names>
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[URN] Moats, R., "URN Syntax", RFC 2141, May 1997.
[瓮]护城河，右，“瓮语法”，RFC 21411997年5月。
[URN-NS-IETF] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[URN-NS-IETF]Moats，R.，“IETF文档的URN名称空间”，RFC 26481999年8月。
[XML-Registry] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004.
[XML注册表]Mealling，M.，“IETF XML注册表”，RFC3682004年1月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277]Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[XMLSchema1] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures", W3C REC-xmlschema-1, May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[XMLSchema1]Thompson，H.，Beech，D.，Maloney，M.，和N.Mendelsohn，“XML模式第1部分：结构”，W3C REC-xmlschema-1，2001年5月<http://www.w3.org/TR/xmlschema-1/>.
[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月。
[RFC2779] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[RFC2779]Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息/存在协议要求”，RFC 27792000年2月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC3860，2004年8月。
[CPP] Peterson, J., "Common Presence for Presence (CPP)", RFC 3859, August 2004.
[CPP]Peterson，J.，“在场的共同在场（CPP）”，RFC 38592004年8月。
[vCard] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[vCard]Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC24261998年9月。
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
[RFC3851]Ramsdell，B.，编辑，“安全/多用途Internet邮件扩展（S/MIME）版本3.1消息规范”，RFC 38512004年7月。
[RFC3282] Alvestrand, H., "Content Language Headers", RFC 3282, May 2002.
[RFC3282]Alvestrand，H.，“内容语言标题”，RFC 3282，2002年5月。
The Document Type Definition for the "application/pidf+xml" format is described. The DTD here is presented only for informational for those who may not familiar with the XML Schema definition.
描述了“应用程序/pidf+xml”格式的文档类型定义。这里的DTD仅供不熟悉XML模式定义的人参考。
Note: the DTD does not show where extension elements can be added. See the XML Schema for that information.
注意：DTD没有显示可以添加扩展元素的位置。有关该信息，请参见XML模式。
<!ENTITY % URL "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % TUPLEID "CDATA">
<!ENTITY % DATETIME "CDATA">
<!ENTITY % VALUETYPE "CDATA">
<!ENTITY % PRIORITY "CDATA">
<!ENTITY % NOTE "CDATA">
<!ENTITY % URL "CDATA">
<!ENTITY % URI "CDATA">
<!ENTITY % TUPLEID "CDATA">
<!ENTITY % DATETIME "CDATA">
<!ENTITY % VALUETYPE "CDATA">
<!ENTITY % PRIORITY "CDATA">
<!ENTITY % NOTE "CDATA">
<!ELEMENT presence ((tuple*),note?)>
<!ATTLIST presence
xmlns %URI; #REQUIRED
entity %URL; #REQUIRED
>
<!ELEMENT presence ((tuple*),note?)>
<!ATTLIST presence
xmlns %URI; #REQUIRED
entity %URL; #REQUIRED
>
<!ELEMENT tuple (status,contact?,note?,timestamp?)>
<!ATTLIST tuple
id %TUPLEID; #REQUIRED
>
<!ELEMENT tuple (status,contact?,note?,timestamp?)>
<!ATTLIST tuple
id %TUPLEID; #REQUIRED
>
<!ELEMENT status (basic?)>
<!ELEMENT basic CDATA>
<!ELEMENT status (basic?)>
<!ELEMENT basic CDATA>
<!ELEMENT contact %URL;>
<!ATTLIST contact
priority %PRIORITY; #IMPLIED
>
<!ELEMENT contact %URL;>
<!ATTLIST contact
priority %PRIORITY; #IMPLIED
>
<!ELEMENT note %NOTE;>
<!ELEMENT note %NOTE;>
<!ELEMENT timestamp %DATETIME;>
<!ELEMENT timestamp %DATETIME;>
Authors' Addresses
作者地址
Hiroyasu Sugano Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
杉野广康富士通实验室有限公司，日本西华町大久保町明石64号，674-8555
EMail: sugano.h@jp.fujitsu.com
EMail: sugano.h@jp.fujitsu.com
Shingo Fujimoto Fujitsu Laboratories Ltd. 64, Nishiwaki Ohkubo-cho Akashi 674-8555 Japan
藤本信吾富士通实验室有限公司，地址：日本西华町大久保町明石64号，邮编：674-8555
EMail: shingo_fujimoto@jp.fujitsu.com
EMail: shingo_fujimoto@jp.fujitsu.com
Graham Klyne Nine by Nine
格雷厄姆·克莱恩九乘九
EMail: GK@ninebynine.org
EMail: GK@ninebynine.org
Adrian Bateman VisionTech Limited Colton, Staffordshire, WS15 3LD United Kingdom
Adrian Batman VisionTech Limited Colton，斯塔福德郡，WS15 3LD英国
EMail: bateman@acm.org
EMail: bateman@acm.org
Wayne Carr Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 USA
韦恩·卡尔英特尔公司美国希尔斯堡东北25大道2111号，邮编：97124
EMail: wayne.carr@intel.com
EMail: wayne.carr@intel.com
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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编辑功能的资金目前由互联网协会提供。