Network Working Group J. Rosenberg
Request for Comments: 4479 Cisco Systems
Category: Standards Track July 2006
Network Working Group J. Rosenberg
Request for Comments: 4479 Cisco Systems
Category: Standards Track July 2006
A Data Model for Presence
存在性的数据模型
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 (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document defines the underlying presence data model used by Session Initiation Protocol (SIP) for Instant Messaging and Presence Leveraging Extensions (SIMPLE) presence agents. The data model provides guidance on how to map various communications systems into presence documents in a consistent fashion.
本文档定义了会话启动协议（SIP）用于即时消息和利用状态扩展（简单）状态代理的状态数据模型。数据模型为如何以一致的方式将各种通信系统映射到状态文档提供了指导。
Table of Contents
目录
1. Introduction ....................................................2
2. Definitions .....................................................3
3. The Model .......................................................5
3.1. Presentity URI .............................................6
3.2. Person .....................................................7
3.3. Service ....................................................8
3.3.1. Characteristics .....................................9
3.3.2. Reach Information ..................................10
3.3.3. Relative Information ...............................13
3.3.4. Status .............................................13
3.4. Device ....................................................15
3.5. Modeling Ambiguity ........................................17
3.6. The Meaning of Nothing ....................................19
3.7. Status vs. Characteristics ................................19
3.8. Presence Document Properties ..............................20
4. Motivation for the Model .......................................21
5. Encoding .......................................................22
5.1. XML Schemas ...............................................24
5.1.1. Common Schema ......................................24
5.1.2. Data Model .........................................25
6. Extending the Presence Model ...................................26
7. Example Presence Document ......................................26
7.1. Basic IM Client ...........................................27
8. Security Considerations ........................................29
9. Internationalization Considerations ............................29
10. IANA Considerations ...........................................30
10.1. URN Sub-Namespace Registration ...........................30
10.2. XML Schema Registrations .................................31
10.2.1. Common Schema .....................................31
10.2.2. Data Model ........................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
1. Introduction ....................................................2
2. Definitions .....................................................3
3. The Model .......................................................5
3.1. Presentity URI .............................................6
3.2. Person .....................................................7
3.3. Service ....................................................8
3.3.1. Characteristics .....................................9
3.3.2. Reach Information ..................................10
3.3.3. Relative Information ...............................13
3.3.4. Status .............................................13
3.4. Device ....................................................15
3.5. Modeling Ambiguity ........................................17
3.6. The Meaning of Nothing ....................................19
3.7. Status vs. Characteristics ................................19
3.8. Presence Document Properties ..............................20
4. Motivation for the Model .......................................21
5. Encoding .......................................................22
5.1. XML Schemas ...............................................24
5.1.1. Common Schema ......................................24
5.1.2. Data Model .........................................25
6. Extending the Presence Model ...................................26
7. Example Presence Document ......................................26
7.1. Basic IM Client ...........................................27
8. Security Considerations ........................................29
9. Internationalization Considerations ............................29
10. IANA Considerations ...........................................30
10.1. URN Sub-Namespace Registration ...........................30
10.2. XML Schema Registrations .................................31
10.2.1. Common Schema .....................................31
10.2.2. Data Model ........................................31
11. Acknowledgements ..............................................31
12. References ....................................................32
12.1. Normative References .....................................32
12.2. Informative References ...................................32
Presence conveys the ability and willingness of a user to communicate across a set of devices. RFC 2778 [10] defines a model and terminology for describing systems that provide presence information. RFC 3863 [1] defines an XML [5] [6] [7] document format for representing presence information. In these specifications, presence information is modeled as a series of tuples, each of which contains a status, communications address, and other markup. However, neither specification gives guidance on exactly what a tuple is meant to model, or how to map real-world communications systems (and in
存在传达了用户跨一组设备进行通信的能力和意愿。RFC 2778[10]定义了用于描述提供状态信息的系统的模型和术语。RFC 3863[1]定义了用于表示状态信息的XML[5][6][7]文档格式。在这些规范中，状态信息被建模为一系列元组，每个元组包含状态、通信地址和其他标记。然而，这两个规范都没有给出关于元组到底要建模什么，或者如何映射真实世界的通信系统（以及
particular, those built around the Session Initiation Protocol (SIP) [11]) into a presence document.
特别是，那些围绕会话启动协议（SIP）[11]）构建到状态文档中的。
In particular, several important concepts are not clearly modeled or well delineated by RFCs 2778 and 3863. These are the following:
特别是，RFCs 2778和3863没有清楚地建模或描述几个重要概念。这些措施如下：
Service: A communications service, such as instant messaging (IM) or telephony, is a system for interaction between users that provides certain modalities or content.
服务：通信服务，如即时消息（IM）或电话，是提供特定模式或内容的用户之间交互的系统。
Device: A communications device is a physical component that a user interacts with in order to make or receive communications. Examples are a phone, PDA, or PC.
设备：通信设备是用户为了进行或接收通信而与之交互的物理组件。例如电话、PDA或PC。
Person: A person is the end user, and for the purposes of presence, is characterized by states, such as "busy" or "sad", that impact their ability and willingness to communicate.
人：一个人是最终用户，出于在场的目的，其特征是状态，如“忙碌”或“悲伤”，影响其沟通能力和意愿。
This specification defines these concepts more fully by means of a presence data model, and concretely defines how to take real-world systems and map them into presence documents using that model. This data model is defined in terms of an extension to RFC 3863.
本规范通过状态数据模型更全面地定义了这些概念，并具体定义了如何使用该模型将真实世界的系统映射到状态文档中。该数据模型是根据RFC 3863的扩展定义的。
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 [9].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[9]中所述进行解释。
This document makes use of many additional terms beyond those defined in RFC 2778 and RFC 3863. These new terms are as follows:
本文件使用了RFC 2778和RFC 3863定义之外的许多附加术语。这些新条款如下：
Device: A device models the physical environment in which services manifest themselves for users. Devices have characteristics that are useful in allowing a user to make a choice about which communications service to use.
设备：设备为物理环境建模，在该环境中，服务为用户显示自己。设备具有允许用户选择使用哪种通信服务的有用特性。
Service: A service models a form of communication that can be used to interact with the user.
服务：服务模拟了一种可用于与用户交互的通信形式。
Person: A person models the human user and their states that are relevant to presence systems.
Person：一个人对与状态系统相关的人类用户及其状态进行建模。
Occurrence: A single description of a particular service, a particular device, or a person. There may be multiple occurrences for a particular service or device, or multiple person occurrences in a Presence Information Data Format (PIDF) document, in cases where there is ambiguity that is best resolved by the watcher.
事件：对特定服务、特定设备或人员的单一描述。在存在由观察者最好解决的歧义的情况下，特定服务或设备可能会多次出现，或者在存在信息数据格式（PIDF）文档中可能会出现多个人出现。
Presentity: A presentity combines devices, services, and person information for a complete picture of a user's presence status on the network.
Presentity：Presentity将设备、服务和个人信息结合起来，以获得用户在网络上的状态的完整图片。
Presentity URI: A URI that acts as a unique identifier for a presentity and provides a handle for obtaining presence information about that presentity.
Presentity URI：充当Presentity的唯一标识符并提供获取该Presentity的状态信息的句柄的URI。
Data Component: One of the device, service, or person parts of a presence document.
数据组件：状态文档的设备、服务或人员部分之一。
Status: Presence information about a service, person, or device that typically changes over time, in contrast to characteristics, which are generally static.
状态：关于服务、人员或设备的状态信息，通常随时间而变化，而特征通常是静态的。
Characteristics: Presence information about a service, person, or device that is usually fixed over time, and descriptive in nature. Characteristics are useful in providing context that identifies the service or device as different from another service or device.
特征：关于服务、人员或设备的状态信息，通常随时间固定且具有描述性。特征在提供将服务或设备标识为不同于另一服务或设备的上下文时非常有用。
Attribute: A status or characteristic. It represents a single piece of presence information.
属性：状态或特征。它表示一个单独的状态信息。
Presence Attribute: A synonym for attribute.
状态属性：属性的同义词。
Composition: The act of combining a set of presence and event data about a presentity into a coherent picture of the state of that presentity.
合成：将一组关于存在实体的存在和事件数据组合成该存在实体状态的连贯图像的行为。
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
| \ / \ |
| V V V |
| +----------------+ +----------------+ |
| +----------------+| +----------------+| |
| | || | || |
| | || | || |
| | Device || | Device || |
| | || | || |
| | |+ | |+ |
| +----------------+ +----------------+ |
| |
| |
| Presentity (URI) |
+----------------------------------------------------------------+
+----------------------------------------------------------------+
| |
| +----------------+ |
| +----------------+| |
| | || |
| | || |
| | Person || |
| | ||\ |
| /| |+ \ |
| / +----------------+ \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| / | \ |
| V V V |
| +----------------+ +----------------+ +----------------+ |
| +----------------+| +----------------+| +----------------+| |
| | || | || | || |
| | || | || | || |
| | Service || | Service || | Service || |
| | || | || | || |
| | |+ | |+ | |+ |
| +----------------+ +----------------+ +----------------+ |
| \ / \ |
| \ / \ |
| \ / \ |
| V V V |
| +----------------+ +----------------+ |
| +----------------+| +----------------+| |
| | || | || |
| | || | || |
| | Device || | Device || |
| | || | || |
| | |+ | |+ |
| +----------------+ +----------------+ |
| |
| |
| Presentity (URI) |
+----------------------------------------------------------------+
Figure 1
图1
The data model for presence is shown in Figure 1. The model seeks to describe the presentity, identified by a presentity URI. There are three components in the model: the person, the service, and the device. These three data components contain information (called attributes) that provide a description of some aspect of the service, person, or device. It is central to this model that each attribute is affiliated with the service, person, or device because they describe that service, presentity, or device. This is in contrast to a model whereby the attributes are associated with the service, presentity, or device because they were reported by that service, presentity, or device. As an example, if a cell phone reports that a user is in a meeting, this would be done by including an attribute as part of the person information, indicating a status of "in-a-meeting". The presence information may also include information on the cell phone as a device. However, even though it is the device that is reporting that the user is in a meeting, "in a meeting" is a fact that describes the human user, not their physical device. Consequently, this attribute is placed in the person component of the document.
存在的数据模型如图1所示。该模型试图描述由存在实体URI标识的存在实体。模型中有三个组件：人员、服务和设备。这三个数据组件包含信息（称为属性），这些信息提供服务、人员或设备某些方面的描述。该模型的核心是，每个属性都与服务、人员或设备相关联，因为它们描述了该服务、存在实体或设备。这与模型不同，模型中的属性与服务、存在实体或设备关联，因为它们是由该服务、存在实体或设备报告的。例如，如果移动电话报告用户正在开会，这将通过将属性作为人员信息的一部分来完成，指示“开会中”的状态。存在信息还可以包括作为设备的移动电话上的信息。然而，即使是设备报告用户正在开会，“开会”是描述人类用户的事实，而不是他们的物理设备。因此，该属性被放置在文档的person组件中。
The identifier for the presentity is a URI. For each unique presentity in the network, there is one or more presentity URIs. A presentity may have multiple URIs because they are identified by both a URI from the Presence (pres) scheme [12] and a protocol-specific URI, such as a SIP URI [11] or an Extensible Messaging and Presence Protocol Internationalized Resource Identifier (XMPP IRI) [13]. Or, it can be because a user has several aliases in a domain, all of which are equivalent identifiers for the presentity.
存在实体的标识符是URI。对于网络中的每个唯一存在实体，都有一个或多个存在实体URI。存在实体可以具有多个URI，因为它们由来自存在（pres）方案[12]的URI和特定于协议的URI（例如SIP URI[11]或可扩展消息传递和存在协议国际化资源标识符（XMPP-IRI）[13]来标识。或者，这可能是因为一个用户在一个域中有几个别名，所有这些别名都是存在实体的等效标识符。
When a document is constructed, the presentity URI is ideally set to the identifier used to request the document in the first place. For example, if a document was requested through a SIP SUBSCRIBE request, the presentity URI would match the Request URI of the SUBSCRIBE request. This follows the principle of least surprise, since the entity requesting the document may not be aware of the other identifiers for the presentity.
构建文档时，理想情况下，presentityURI设置为用于首先请求文档的标识符。例如，如果通过SIP SUBSCRIBE请求请求文档，则表示实体URI将与SUBSCRIBE请求的请求URI匹配。这遵循最小意外原则，因为请求文档的实体可能不知道存在实体的其他标识符。
Irrespective of the scheme from which the URI is taken, the presentity URI is independent of any of the services or devices that the presentity possesses. However, the URI is not just a name - it represents a resource that can be subscribed to, in order to find out the status of the user. When the URI is a SIP URI, it will often be the Address of Record for the user, to which SIP calls can be directed. This equivalence is not mandated by this specification, but is a recommended configuration for easing the burden of remembering and storing identifiers for users.
无论URI来自哪个方案，存在实体URI都独立于存在实体所拥有的任何服务或设备。然而，URI不仅仅是一个名称——它代表一个可以订阅的资源，以便了解用户的状态。当URI是SIPURI时，它通常是用户的记录地址，SIP调用可以定向到该地址。本规范不强制要求这种等价性，但推荐使用这种配置来减轻用户记忆和存储标识符的负担。
The person data component models information about the user whom the presence data is trying to describe. This information consists of characteristics of the user, and their status.
person数据组件对状态数据试图描述的用户的信息进行建模。此信息包括用户的特征及其状态。
Characteristics of a person are the static information about a user that does not change under normal circumstances. Such information might include physical characteristics, such as age and height. Another example of a person characteristic is an alias. An alias is a URI that identities the same user, but with a different presentity URI. For example, a presentity "sip:bob@example.com" might have a presence document with a person component that indicates an alias of "sip:robert@example.com" and "sip:r.smith@example.com".
人的特征是关于用户的静态信息，在正常情况下不会改变。这些信息可能包括身体特征，如年龄和身高。人员特征的另一个示例是别名。别名是标识同一用户但具有不同presentity URI的URI。例如，存在实体“sip:bob@example.com“可能有一个状态文档，其中包含指示别名为“sip:robert@example.com和“sip:r。smith@example.com".
Status information about a presentity represents the dynamic information about a user. This typically consists of things the *user* is doing, places the *user* is at, feelings the *user* has, and so on. Examples of typical person status are "in a meeting", "on the phone", "out to lunch", "happy", and "writing Internet Drafts". The line between static status information and dynamic status information is fuzzy, and it is not important that a line be drawn. The model does not differentiate in a syntactically or semantically meaningful way between these two types of attributes.
关于存在实体的状态信息表示关于用户的动态信息。这通常包括*用户*正在做的事情、*用户*所在的位置、*用户*的感受等等。典型的个人状态有“开会”、“打电话”、“出去吃午饭”、“开心”和“写网络草稿”。静态状态信息和动态状态信息之间的界限是模糊的，因此画一条线并不重要。该模型没有以语法或语义上有意义的方式区分这两种类型的属性。
In the model, there can be only one person component per presentity. In other words, the person component models a single human being, and includes characteristics and statuses that are related to the communication states for a single human being. Of course, the system has no way to verify that the human described by the person component is actually a single human being, as opposed to a group of users, or even a dog for that matter. As the saying goes, "on the Internet, no one knows you are a dog", and the same is true here. The person component is a facade for a single person; anything that can be made to look like a single person can be modeled with that facade.
在模型中，每个存在实体只能有一个人组件。换句话说，person组件为单个人建模，并包括与单个人的通信状态相关的特征和状态。当然，系统无法验证person组件所描述的人实际上是一个人，而不是一组用户，甚至是一只狗。俗话说，“在互联网上，没有人知道你是一条狗”，在这里也是如此。人员组件是单个人员的外观；任何看起来像一个人的东西都可以用这个外观来建模。
As an example, consider the task of using a presence document to describe a customer support help desk. The person component can be considered to be "busy" if none of the support staff are available, and "at lunch" if the help desk department has a group lunch together. The watcher that receives the document will consider the help desk to be a single person; nothing in the document (except perhaps the note element, should its value be "help desk" or something similar) conveys information that would indicate that the person in question is actually a help desk.
作为一个例子，考虑使用存在文档来描述客户支持帮助台的任务。如果没有任何支持人员，则人员组件可以被视为“忙碌”，如果服务台部门一起共进午餐，则人员组件可以被视为“午餐时”。接收文档的观察者会认为帮助台是一个人；文档中的任何内容（除了note元素，如果其值为“help desk”或类似值）都不会传递表明相关人员实际上是help desk的信息。
However, there can be multiple occurrences of the person component. This happens in cases where the state of the person component is ambiguous, as discussed in Section 3.5.
但是，person组件可以多次出现。如第3.5节所述，在人员组件的状态不明确的情况下会发生这种情况。
Each presentity has access to a number of services. Each of these represents a point of reachability for communications that can be used to interact with the user. Examples of services are telephony (that is, traditional circuit-based telephone service), push-to-talk, instant messaging, Short Message Service (SMS), and Multimedia Message Service (MMS).
每个实体都有权获得许多服务。其中每一个都代表了可用于与用户交互的通信的可达性点。服务的示例包括电话（即传统的基于电路的电话服务）、按键通话、即时消息、短消息服务（SMS）和彩信服务（MMS）。
It is difficult to give a precise definition for service. One reasonable approach is to model each software or hardware agent in the system as a service. If a user starts a softphone application on their PC, then that represents a service. If a user has a videophone device, then that represents another service. This is effectively a physical view of services. This definition, however, starts to fall apart when a service is spread across multiple software agents or devices. For example, a SIP URI representing an address-of-record can be routed to a softphone or a videophone, or both. In that case, one might attempt instead to define a service based on its address on the network. This definition also falls apart when modeling devices or applications that receive calls and dispatch them to different "helpers" based on potentially complex logic. For example, a cellular telephone might house multiple SIP applications, each of which can "register" different handlers based on the method or even body type of the request. Each of those applications or handlers can rightfully be considered a service, but it doesn't have an address on the network distinct from the others.
很难给服务下一个精确的定义。一种合理的方法是将系统中的每个软件或硬件代理建模为服务。如果用户在其PC上启动软电话应用程序，则表示服务。如果用户有可视电话设备，则表示另一种服务。这实际上是服务的物理视图。然而，当一项服务跨多个软件代理或设备传播时，该定义开始崩溃。例如，表示记录地址的SIP URI可以路由到软电话或可视电话，或两者。在这种情况下，可以尝试根据服务在网络上的地址定义服务。当根据潜在的复杂逻辑对接收呼叫并将其分派给不同“助手”的设备或应用程序进行建模时，此定义也会出现分歧。例如，蜂窝电话可能包含多个SIP应用程序，每个应用程序都可以根据请求的方法甚至主体类型“注册”不同的处理程序。这些应用程序或处理程序中的每一个都可以被正确地视为一个服务，但它在网络上没有与其他应用程序或处理程序不同的地址。
Because of this inherent difficulty in precisely defining a service, the data model doesn't try to constrain what can be considered a service. Rather, anything can be considered a service so long as it exhibits a set of key properties defined by this model. In particular, each service is associated with characteristics that identify the nature and capabilities of that service, with reach information that indicates how to connect to the service, with status information representing the state of that service, and relative information that describes the ways in which that service relates to others associated with the presentity.
由于精确定义服务存在固有的困难，因此数据模型不试图约束可以被视为服务的内容。相反，任何东西都可以被视为服务，只要它展示了由该模型定义的一组关键属性。具体而言，每个服务都与标识该服务的性质和能力的特征相关联，具有指示如何连接到该服务的reach信息，以及表示该服务状态的状态信息，以及描述该服务与与存在实体相关联的其他服务的方式的相关信息。
As a consequence, in this model, services are not explicitly enumerated. There is no central registry where one finds identifiers for each service. Consequently, each service does not have a single "service" attribute with values such as "ptt" or "telephony". That doesn't mean that these consolidated monikers aren't useful; indeed,
因此，在这个模型中，服务没有被显式枚举。没有一个中央注册中心可以为每个服务找到标识符。因此，每个服务都没有一个值为“ptt”或“telephony”的“service”属性。这并不意味着这些统一的名字是无用的；的确
they represent an essential summary of what the service is. Such summarization is useful in creating icons that allow a user to choose one service over another. A watcher is free to create such summarization information from any of the information associated with a service. The reach information often provides valuable information for creating such a summarization. Oftentimes, the scheme of the URI is synonymous with the view of what a service is. An "sms" URI [14] clearly indicates SMS, for example. For some URIs, there may be many services available, for example, SIP or tel [15], in which case the scheme is less meaningful as a way of creating a summary. The reach information could also indicate that certain application software has to be invoked (such as a videogame), in which case that aspect of the reach information would be useful for generating an iconic representation of the game.
它们代表了服务内容的基本摘要。这样的摘要在创建允许用户选择一项服务而不是另一项服务的图标时非常有用。观察者可以根据与服务相关联的任何信息自由地创建此类摘要信息。reach信息通常为创建此类摘要提供有价值的信息。通常，URI的模式与服务的视图是同义的。例如，“sms”URI[14]清楚地指示sms。对于某些URI，可能有许多可用的服务，例如SIP或tel[15]，在这种情况下，该方案作为创建摘要的方式意义不大。reach信息还可以指示必须调用某些应用软件（例如视频游戏），在这种情况下，reach信息的这一方面对于生成游戏的图标表示非常有用。
Each service is adorned with characteristics that describe the nature and capabilities of the service that will be experienced when a watcher invokes that URI. The nature of a service is a set of properties that are relatively static across communication sessions established to that service. The nature of a service tends to be descriptive. Examples of the nature of a service are that it represents an interactive voice response or voicemail server, that it is an automaton, or that it is a telephony service used for the purposes of work. Capabilities, on the other hand, represent properties that might be exhibited, and whether they are exhibited depends on negotiation and other dynamic functions that take place during session establishment. Examples of such capabilities are the type of media that might be used, the directionality of communications that are permitted, the SIP extensions supported, and so on. Capabilities can be very complex; for example, RFC 2533 [16] describes a model for representing capabilities through N-ary boolean functions. It is difficult to differentiate a capability with one modality (e.g., this service only does voice) from a characteristic that represents the nature of a service. However, it is not important to do so.
每个服务都有一些特征，这些特征描述了观察者调用该URI时将体验到的服务的性质和功能。服务的本质是一组在为该服务建立的通信会话中相对静态的属性。服务的性质往往是描述性的。服务性质的示例包括：它表示交互式语音响应或语音邮件服务器，它是一个自动机，或者它是用于工作目的的电话服务。另一方面，功能表示可能显示的属性，它们是否显示取决于会话建立期间发生的协商和其他动态功能。此类功能的示例包括可能使用的媒体类型、允许的通信方向性、支持的SIP扩展等。能力可能非常复杂；例如，RFC 2533[16]描述了一个通过N元布尔函数表示能力的模型。很难将具有一种模态（例如，该服务仅提供语音）的功能与表示服务性质的特征区分开来。然而，这样做并不重要。
Characteristics are important when multiple services are indicated. That is because the purpose of listing multiple services in a presence document is to give the watcher a *choice*. That is, the presentity is explicitly offering the watcher an opportunity to contact them using a multiplicity of different services. To help the watcher make a decision, the presence document includes characteristics of each service that help differentiate the services from each other and give the watcher the context in which to make a choice.
当指示多个服务时，特征很重要。这是因为在状态文档中列出多个服务的目的是给观察者一个*选择*。也就是说，存在实体明确地为观察者提供了使用多种不同服务联系他们的机会。为了帮助观察者做出决策，状态文档包括每个服务的特征，这些特征有助于区分彼此的服务，并为观察者提供做出选择的上下文。
Because their purpose is primarily to facilitate choice, capabilities do not impose a requirement on the way in which a user reaches that service. For example, if a presence document includes two services, and one supports audio only while the other supports only video, this does not mean that, when contacting the first service, a user has to offer only an audio stream, or when contacting the second service, a user has to offer only a video stream. A user can use local policy at its discretion in determining what capabilities or communications modalities are offered when they choose to connect with a service. It is not necessary for a watcher to add SIP caller preferences [2] to request routing of the request to a service with the characteristics described in the presence document.
因为这些功能主要是为了方便选择，所以它们不会对用户访问该服务的方式提出要求。例如，如果存在文档包括两个服务，其中一个仅支持音频，而另一个仅支持视频，这并不意味着在联系第一个服务时，用户必须仅提供音频流，或者在联系第二个服务时，用户必须仅提供视频流。当用户选择连接某项服务时，可以自行决定使用本地策略来确定提供哪些功能或通信方式。观察者无需添加SIP呼叫者首选项[2]以请求将请求路由到具有存在文档中描述的特征的服务。
If, in order to reach a service, the user agent must generate a request that exhibits a particular capability or contains a specific header, then this is indicated separately in the reach information, described below.
如果为了到达服务，用户代理必须生成显示特定功能或包含特定头的请求，则这将在下文描述的到达信息中单独指示。
One important characteristic of each service is the list of devices on which that service executes. Each device is identified uniquely by a device ID. As such, the service characteristics can include a list of device IDs. A presence document might also contain information on each device, but this is a separate part of the document. Indeed, the information on each device might not even be present in the document. In that case, the device IDs listed for each service are nothing more than correlation identifiers, useful for determining when two services run on the same device. The benefit of this model is that information on the devices can be filtered out of a presence document, yet the service information, which includes the device IDs, remains useful and meaningful.
每个服务的一个重要特征是执行该服务的设备列表。每个设备由设备ID唯一标识。因此，服务特征可以包括设备ID列表。状态文档也可能包含每个设备的信息，但这是文档的一个单独部分。事实上，每个设备上的信息甚至可能没有出现在文档中。在这种情况下，为每个服务列出的设备ID只不过是相关标识符，用于确定两个服务何时在同一设备上运行。此模型的好处是，可以从状态文档中过滤出设备上的信息，但服务信息（包括设备ID）仍然有用且有意义。
It is perfectly valid for a presence document to contain just a single service. This is permitted even if the presentity actually has multiple services at their disposal. The lack of multiple services in the document merely means that the presentity is not offering a choice to the watcher. In such a case, the service characteristics are less important, but may be helpful in allowing a watcher to decide if they wish to communicate at all.
一个状态文档只包含一个服务是完全有效的。即使存在实体实际上有多种服务可供其使用，这也是允许的。文档中缺少多种服务仅仅意味着存在实体没有向观察者提供选择。在这种情况下，服务特性不太重要，但可能有助于让观察者决定他们是否希望通信。
The reach information for a service provides the instructions for the recipient of a document on how to correctly contact that service.
服务的reach信息为文档收件人提供了有关如何正确联系该服务的说明。
When a service is accessible over a communications network, reach information includes a URI that can be "hit" to access the service. This URI is called the service URI. However, some services are not
当通过通信网络访问服务时，reach信息包括一个URI，可以通过“点击”来访问该服务。这个URI称为服务URI。但是，有些服务不是
accessible over a communications network (such as in-person communications or a written letter), and as such, may not utilize a URI.
可通过通信网络（例如面对面通信或书面信函）访问，因此不可使用URI。
Even for services reachable over a communications network, the URI alone may not be sufficient. For example, two applications may be running within a cellular telephone, both of which are reachable through the user's SIP Address of Record. However, one application is launched when the INVITE request contains a body of a particular type, and the other is launched for other body types. As another example, a service may provide complex application logic that operates correctly only when contacted from matching application software. In such a case, even though the communications between instances utilizes a standard protocol (such as SIP), the user experience will not be correct unless the applications are matched.
即使对于可通过通信网络访问的服务，仅URI也可能不够。例如，两个应用程序可以在蜂窝电话内运行，这两个应用程序都可以通过用户的SIP记录地址访问。但是，当INVITE请求包含特定类型的主体时，将启动一个应用程序，而另一个应用程序将针对其他主体类型启动。作为另一个示例，服务可以提供复杂的应用程序逻辑，该逻辑仅在与匹配的应用程序软件联系时才能正确运行。在这种情况下，即使实例之间的通信使用标准协议（例如SIP），除非应用程序匹配，否则用户体验将不正确。
When the URI is not sufficient, additional attributes of the service can be present that define the instructions on how the service is to be reached. These attributes must be understood for the service to be utilized. If a watcher receives a presence document containing reach information it does not understand, it should discard the service information.
当URI不够时，可以提供服务的其他属性，这些属性定义如何访问服务的说明。必须了解这些属性，才能使用服务。如果观察者收到包含其不理解的reach信息的状态文档，则应丢弃该服务信息。
The reach information is an important part of the service. When the watcher makes a decision about which service of the presentity they wish to access, the watcher utilizes the reach information for that service. For this reason, each service has to have a unique set of reach information. If this was not the case, the user would have no way to choose between the services. This means that the reach information represents a unique identifier for the service. However, a presence document can contain multiple occurrences of a particular service, each of which contains the same reach information, but differs in its occurrence identifier. Multiple occurrences of a service exist in a document when the state of the service is ambiguous, as discussed in Section 3.5.
reach信息是服务的重要组成部分。当观察者决定他们希望访问存在实体的哪个服务时，观察者利用该服务的到达信息。因此，每个服务都必须有一组唯一的reach信息。如果不是这样，用户将无法在服务之间进行选择。这意味着reach信息表示服务的唯一标识符。但是，状态文档可以包含特定服务的多个事件，每个事件包含相同的到达信息，但其事件标识符不同。如第3.5节所述，当服务状态不明确时，文档中存在多个服务实例。
Because the reach information serves as an identifier for a service, it also serves as a way to figure out whether a communications capability should be represented as one service or more. Something cannot be a service unless there is a way to reach it separately from another service. As an example, consider a softphone application that is capable of audio and video. It is not possible to describe this softphone as two services - one capable of just audio, and one capable of just video. That's because there is no way to reach the video-only service; for example, sending a SIP INVITE with just a video stream doesn't suffice, since one can always add the audio stream later and it will work. Video and audio, in this case, represent capabilities for a single service.
由于到达信息用作服务的标识符，因此它还用作确定通信能力是否应表示为一个或多个服务的方法。某些东西不能成为服务，除非有一种方法可以从另一个服务中单独获得它。作为一个例子，考虑一个能够进行音频和视频的软电话应用程序。无法将此软电话描述为两种服务—一种仅支持音频，另一种仅支持视频。那是因为没有办法获得仅视频服务；例如，仅使用视频流发送SIP INVITE是不够的，因为可以在以后添加音频流，这样就可以了。在本例中，视频和音频表示单个服务的功能。
The reach information represents a weak form of contract; the presentity tells the watcher that, if the watcher utilizes the reach information included in the presence document, the watcher might be connected to a service described by the characteristics included in the presence document. It is important to stress that this is not a guarantee in any way. It cannot be a guarantee for two reasons. First, the service in the document might actually be modelling a number of actual services used by the user, and it may not be possible to connect the watcher to a service with all of the characteristics described in the presence document. Second, the preferences of the presentity always take precedence. The caller might ask to be connected to the video service, but it is permissible to connect them to a different service if that is the wish of the presentity.
reach信息代表一种弱合同形式；存在实体告诉观察者，如果观察者利用存在文档中包括的到达信息，则观察者可以连接到存在文档中包括的特征所描述的服务。必须强调的是，这并不是任何形式的保证。它不能成为一种保证，原因有二。首先，文档中的服务实际上可能正在模拟用户使用的许多实际服务，并且可能不可能将观察者连接到具有存在文档中描述的所有特征的服务。第二，存在实体的偏好总是优先。呼叫者可能要求连接到视频服务，但如果存在实体希望连接到其他服务，则允许将其连接到其他服务。
This loose contract also provides some guidance on the type of URI that is most ideally suited for the service URI. A URN [3] can be used as the service URI. However, since a URN could be resolved to potentially any number of different URIs, the characteristics, status, and relative information need to be sensible for all of the URIs that can be resolved from the URN. As the URN becomes increasingly "vague" in terms of the service it identifies, the number of presence attributes that can be included decreases correspondingly.
这个松散的契约还提供了一些关于最适合服务URI的URI类型的指导。URN[3]可用作服务URI。但是，由于URN可以解析为可能的任意数量的不同URI，因此对于可以从URN解析的所有URI，特性、状态和相关信息都需要是合理的。随着URN在其识别的服务方面变得越来越“模糊”，可以包含的状态属性的数量相应减少。
The tel URI [11] shares similar properties with a URN, and the same considerations apply. If, for example, the telephone number exists in ENUM [18] and multiple ENUM services are defined, including voice and messaging, it is likely that very little characteristic information can be included in that service. If, however, a tel URI has only a single ENUM service defined, and it refers to a telephone service on the Public Switched Telephone Network (PSTN), more can be said about its characteristics, status, and relative priority.
tel URI[11]与URN共享类似的属性，并且应用相同的注意事项。例如，如果电话号码存在于ENUM[18]中，并且定义了多个ENUM服务，包括语音和消息传递，则该服务中可能包含很少的特征信息。然而，如果teluri仅定义了一个ENUM服务，并且它指的是公共交换电话网（PSTN）上的电话服务，则可以更多地说明其特征、状态和相对优先级。
It is important to point out that there can be a many-to-one mapping of reach information to a service. That is, a particular service can potentially be reachable through an infinite number of reach information sets. This is true even if the reach information is just the service URI; it is permissible for multiple service URIs to reach the same service. Within any particular document, for a particular service, there will be a single service URI. However, it is allowed and even valuable to provide different service URIs to different watchers, or to change the service URIs provided to a particular watcher over time. Doing so affords many benefits, in fact. It can allow the recipient of a communications attempt to determine the context for that attempt - that the attempt was made as a result of
需要指出的是，reach信息与服务之间可能存在多对一映射。也就是说，一个特定的服务可以通过无限多的到达信息集潜在地到达。即使到达信息只是服务URI，这也是正确的；允许多个服务URI访问同一个服务。在任何特定文档中，对于特定服务，都将有一个服务URI。然而，向不同的观察者提供不同的服务URI，或者随时间改变向特定观察者提供的服务URI是允许的，甚至是有价值的。事实上，这样做有很多好处。它可以允许通信尝试的接收者确定该尝试的上下文-该尝试是由于
trying to reach a particular service in a particular presence document. This can be used as a technique for preventing communications spam, for example [19].
试图访问特定状态文档中的特定服务。例如，这可以用作防止通信垃圾邮件的技术[19]。
It is also possible for a presence document to contain a service that has no reach information at all. In such a case, the presentity is indicating that the service exists, but is electing not to offer the watcher the opportunity to connect to it. One such example would be to let a watcher know that a user has a telephony service, and that they are busy, but in order to avoid receipt of a call, no reach information is provided.
状态文档也可能包含完全没有reach信息的服务。在这种情况下，存在实体表示服务存在，但选择不向观察者提供连接到服务的机会。一个这样的例子是让观察者知道用户有电话服务，并且他们很忙，但是为了避免收到呼叫，没有提供到达信息。
In an ideal system, the URI alone would represent sufficient reach information for each service. A URI is supposed to provide sufficient context for reaching the resource associated with the URI, and thus in theory there is no need for additional context. However, sometimes, additional information is needed. Since the reach information has to be understood in order for the service to be utilized, reach information beyond the URI should be defined and used sparingly. Extensions to PIDF that define attributes that are reach information should clearly call those attributes out as such.
在理想的系统中，URI本身就可以表示每个服务的足够到达信息。URI应该提供足够的上下文来访问与URI关联的资源，因此理论上不需要额外的上下文。然而，有时需要额外的信息。由于为了使用服务，必须理解reach信息，因此应该定义并谨慎使用URI之外的reach信息。定义reach信息属性的PIDF扩展应该清楚地调用这些属性。
Each service is also associated with a priority, which represents the preference that the user has for usage of one service over another. This does not mean that, when a watcher wishes to communicate with the presentity, that they should always use the service with the highest priority. If that were the case, there would be no point in including multiple services in the presence document. Rather, the priority says, "If you, the watcher, cannot decide which of these to use, or if it is not important to you, this is the order in which I would like you to contact me. However, I am giving you a choice." The priorities are relative to each other, and have no meaning as absolute numbers. If there are two services, and they have priorities of 1 and .5, respectively, this is identical to giving them priorities of .2 and .1, respectively.
每个服务还与一个优先级相关联，该优先级表示用户对使用一个服务而不是另一个服务的偏好。这并不意味着，当观察者希望与存在实体通信时，他们应该始终使用具有最高优先级的服务。如果是这样，那么在状态文档中包含多个服务就没有意义了。相反，优先级表示，“如果你，观察者，不能决定使用哪一个，或者它对你来说不重要，这是我希望你联系我的顺序。但是，我给你一个选择。”优先级是相对的，没有绝对数的意义。如果有两个服务，并且它们的优先级分别为1和.5，则这与分别为它们指定.2和.1的优先级相同。
Each service also has a status. Status represents generally dynamic information about the availability of communications using that service. This is in contrast to characteristics, which describe fairly static properties of the various services. The simplest form of status is the basic status, which is a binary indicator of availability for communications using that service. It can have values of either "closed" or "open". "Closed" means that communication to the service will, in all likelihood, fail, will not
每个服务也有一个状态。状态通常表示有关使用该服务的通信可用性的动态信息。这和描述各种服务相当静态的属性的特征形成对比。最简单的状态形式是基本状态，它是使用该服务的通信可用性的二进制指示器。它可以具有“关闭”或“打开”的值。“关闭”意味着与服务的通信很可能会失败，但不会
reach the intended party, or will not result in communications as described by the characteristics of the service. As an example, if a call is forwarded to voicemail if the user is busy or unavailable, the service is marked as "closed". Similarly, a presentity may include a hotel phone number as a service URI. After checkout, the phone number will still ring, but reach the chambermaid or the next guest. Thus, it would be declared "closed" by that presentity. As another example, if a user has a SIP URI as their service URI that points to a SIP softphone application, and the PC shuts down, calls to that SIP URI will return a 480 response code. This service would also be declared "closed". "Open" implies the opposite - that communications to this service will likely succeed and reach the desired target.
到达预定方，或不会导致服务特征所述的通信。例如，如果在用户忙或不可用时将呼叫转发到语音邮件，则服务将标记为“已关闭”。类似地，存在实体可以包括酒店电话号码作为服务URI。结账后，电话号码仍会响，但会传到女服务员或下一位客人。因此，该实体将宣布其“关闭”。作为另一个示例，如果用户将SIP URI作为其指向SIP软电话应用程序的服务URI，并且PC关闭，则对该SIP URI的呼叫将返回480响应代码。这项服务也将被宣布为“关闭”。“开放”意味着相反的情况——与此服务的通信可能会成功并达到预期目标。
It is also possible to have status information that is dependent on the characteristics of the communications session that eventually gets set up. For example, a status attribute can be defined that indicates that a softphone service is available if instant messaging is used, but unavailable if audio is used.
还可以根据最终设置的通信会话的特征来获取状态信息。例如，可以定义一个状态属性，该属性指示如果使用即时消息，则软电话服务可用，但是如果使用音频，则软电话服务不可用。
Other status information might indicate more details on why the service is available or unavailable. For example, a telephony service might have additional status to indicate that the user is on the phone, or that the user is handling 3 calls for that service.
其他状态信息可能指示有关服务可用或不可用原因的更多详细信息。例如，电话服务可能具有其他状态，以指示用户正在使用电话，或者用户正在为该服务处理3个呼叫。
Services inherently have a lot of dynamic state associated with them. For example, consider a wireless telephony service (i.e., a cell phone). There are many dynamic statuses of this service - whether or not the phone is registered, whether or not it is roaming, which provider it has roamed into, its signal strength, how many calls it has, what the state of those calls are, how long the user has been in a call, and so on. As another example, consider an IM service. The statuses in this service include whether the user is registered, how long they have been registered, whether they have an IM conversation in progress, how many IM conversations are in progress, whether the user is typing, to whom they are typing, and so on.
服务本质上有很多与之相关联的动态状态。例如，考虑无线电话服务（即，蜂窝电话）。这项服务有许多动态状态-手机是否注册、是否漫游、漫游到哪个提供商、信号强度、呼叫次数、呼叫状态、用户通话时间等。作为另一个例子，考虑IM服务。他们是否在聊天中注册，是否在聊天中注册了多少人，是否在聊天中注册了多少人，是否在聊天中注册了多少人，是否在聊天中进行。
However, not all of this dynamic state is appropriate to include within a service data component of a presence document. Information is included only when it has a bearing on helping the watcher decide whether to initiate communications with that service, or helping the watcher decide when to initiate it, if not now. As an example, whether a cell phone has strong signal strength or just good signal strength does not pass the litmus test. Knowing this is not likely to have an impact on a decision to use this service.
然而，并非所有这些动态状态都适合包含在状态文档的服务数据组件中。仅当信息与帮助观察者决定是否启动与该服务的通信，或帮助观察者决定何时启动该服务（如果不是现在）有关时，才会包含该信息。举个例子，不管一部手机的信号强度强还是好，都不能通过石蕊测试。知道这一点可能不会对使用此服务的决策产生影响。
Devices model the physical operating environment in which services execute. Examples of devices include cell phones, PCs, laptops, PDAs, consumer telephones, enterprise PBX extensions, and operator dispatch consoles.
设备为执行服务的物理操作环境建模。设备示例包括手机、PC、笔记本电脑、PDA、消费电话、企业PBX扩展和操作员调度控制台。
The mapping of services to devices are many to many. A single service can execute in multiple devices. Consider a SIP telephony service. Two SIP phones can register against a single Address of Record for this service. As a result, the SIP service is associated with two devices. Similarly, a single device can support a multiplicity of services. A cell phone can support a SIP telephony service, an SMS service, and an MMS service. Similarly, a PC can support a SIP telephony service and a SIP videophone service.
服务到设备的映射是多对多的。单个服务可以在多个设备中执行。考虑SIP电话服务。两个SIP电话可以针对该服务的单个记录地址进行注册。因此，SIP服务与两个设备相关联。类似地，单个设备可以支持多种服务。手机可以支持SIP电话服务、SMS服务和MMS服务。类似地，PC可以支持SIP电话服务和SIP可视电话服务。
Furthermore, a single device can support no services. In such a case, the device has no useful presence information by itself. However, when composed with other documents that describe this same device in relation to a service, a richer presence document can be created. For example, consider a Radio Frequency ID (RFID) tag as a device. This device does not execute any services. However, as a device, it has properties, such as location, and it may have network connectivity with which it can report its status and characteristics. If a video telephone were to report that it was running a video service, and one of its properties was that it was tagged with that RFID, a compositor could combine the two documents together, and use the location of the RFID to say something about the location of the video telephony device.
此外，单个设备不支持任何服务。在这种情况下，设备本身没有有用的存在信息。但是，当与描述与服务相关的相同设备的其他文档组合时，可以创建更丰富的状态文档。例如，考虑射频ID（RFID）标签作为设备。此设备不执行任何服务。但是，作为一个设备，它具有诸如位置之类的属性，并且它可能具有网络连接，可以报告其状态和特征。如果视频电话报告它正在运行视频服务，并且它的属性之一是使用该RFID标记，则合成器可以将两个文档组合在一起，并使用RFID的位置来说明视频电话设备的位置。
Devices are identified with a device ID. A device ID is a URI that is a globally and temporally unique identifier for the device. In particular, a device ID is a URN. The URN has to be unique across all other devices for a particular presentity. However, it is also highly desirable that it be persistent across time, globally unique, and computable in a fashion so that different systems are likely to refer to the device using the same ID. With these properties, differing sources of presence information based on device status can be combined. The last of these three properties - readily computable - is particularly useful. It allows for a compositor to combine disparate sources of information about a device, all linked by a common device ID that each source has independently used to identify the device in question.
设备由设备ID标识。设备ID是一个URI，是设备的全局和时间唯一标识符。具体而言，设备ID是URN。对于特定的实体，URN必须在所有其他设备中都是唯一的。然而，还非常希望它能够跨时间持久、全局唯一并且以某种方式可计算，以便不同的系统可能使用相同的ID来引用设备。利用这些属性，可以组合基于设备状态的不同存在信息源。这三个属性中的最后一个（易于计算）特别有用。它允许合成器组合关于一个设备的不同信息源，所有信息源都由一个公共设备ID链接，每个源都独立使用该ID来识别所讨论的设备。
Unfortunately, due to the variety of different devices in existence, it is difficult for a single URN scheme to be used that will have these properties. It is anticipated that multiple schemes will be defined, with different ones appropriate for different types of
不幸的是，由于存在各种不同的设备，很难使用具有这些特性的单个URN方案。预计将定义多个方案，不同的方案适用于不同类型的项目
devices. For cellular telephones, the Electronic Serial Number (ESN), for example, is a good identifier. For IP devices, the MAC address is another good one. The MAC address has the property of being readily computable, but lacks persistence across time (it would change if the interface card on a device were to change). In any case, neither of these are associated with URN schemes at this time. In the interim, the Universally Unique IDentifier (UUID) URN [20] can be used. For devices with a MAC address, version 1 UUIDs are RECOMMENDED, as they result in a time-based identifier that makes use of the MAC address. For devices without a MAC, a version 4 UUID is RECOMMENDED. This is a purely random identifier, providing uniqueness. The UUID for a device would typically be chosen at the time of fabrication in the device, and then persisted in the device within flash or some other kind of non-volatile storage. The UUID URN has the properties of being globally and temporally unique, but because of its random component, it is not at all readily computable, and therefore useless as a correlation ID with other presence sources on a network. It is anticipated that future specifications will be developed that provide additional, superior device IDs.
设备。例如，对于蜂窝电话，电子序列号（ESN）是一个很好的标识符。对于IP设备，MAC地址是另一个好的地址。MAC地址具有易于计算的特性，但缺乏跨时间的持久性（如果设备上的接口卡发生变化，它将发生变化）。在任何情况下，目前这两个方案都与URN方案无关。在此期间，可以使用通用唯一标识符（UUID）URN[20]。对于具有MAC地址的设备，建议使用版本1 UUID，因为它们会产生一个基于时间的标识符，使用MAC地址。对于没有MAC的设备，建议使用版本4 UUID。这是一个纯粹的随机标识符，提供唯一性。设备的UUID通常在设备中制造时选择，然后保存在闪存或某种其他类型的非易失性存储器中的设备中。UUID URN具有全局和时间唯一的特性，但由于其随机成分，它根本不容易计算，因此作为与网络上其他存在源的相关ID是无用的。预计将制定未来规范，以提供额外的、优越的设备ID。
Though each device is identified by a unique device ID, there can be multiple occurrences of a particular device represented in a document. Each one will share the same device ID, but differ in its occurrence identifier. Multiple occurrences of a device exist in a document when the state of the device is ambiguous, as discussed in Section 3.5.
尽管每个设备都由唯一的设备ID标识，但文档中表示的特定设备可能会多次出现。每一个都将共享相同的设备ID，但其出现标识符不同。如第3.5节所述，当设备状态不明确时，文档中存在多个设备实例。
Though this document does not mandate a particular implementation approach, the device ID is most useful when all of the services on the device have a way to obtain the device ID and get the same value for it. This would argue for its placement as an operating system feature. Operating system developers interested in implementing this specification are encouraged to provide APIs that allow applications to obtain the device ID. Absent such APIs, applications that report presence information about their devices will have to generate their own device IDs. This leads to the possibility that the applications may choose different device IDs, using different algorithms or data. In the worst case, these may mean that two services that run on the same device, do not appear to.
尽管本文档没有规定特定的实现方法，但当设备上的所有服务都有办法获得设备ID并获得相同的值时，设备ID最有用。这将有助于将其作为操作系统功能进行定位。鼓励对实施本规范感兴趣的操作系统开发人员提供允许应用程序获取设备ID的API。如果没有此类API，报告其设备状态信息的应用程序将不得不生成自己的设备ID。这导致应用程序可能使用不同的算法或数据选择不同的设备ID。在最坏的情况下，这可能意味着在同一设备上运行的两个服务似乎不存在。
Like services and person data components, device data components have generally static characteristics and generally dynamic status. Characteristics of a device include its physical dimensions and capabilities - the size of its display, the speed of its CPU, and the amount of memory. Status information includes dynamic information about the device. This includes whether the device is powered on or off, the amount of battery power that remains in the device, the geographic location of the device, and so on.
与服务和个人数据组件一样，设备数据组件通常具有静态特性和动态状态。设备的特性包括其物理尺寸和功能—显示器的大小、CPU的速度和内存量。状态信息包括有关设备的动态信息。这包括设备是否通电、设备中剩余的电池电量、设备的地理位置等。
The characteristics and status information reported about a device are for the purposes of choice - to allow the user to choose the service based on knowledge of what the device is. The device characteristics and status cannot, in any reliable way, be used to extract information about the nature of the service that will be received on the device. For example, if the device characteristics include the speed of the CPU, and the speed is sufficient to support high-quality video compression, this cannot be interpreted to mean that video quality would be good for a video service on that device. Other constraints on the system may reduce the amount of CPU available to that service. If there is a desire to indicate that higher-quality video is available on a device, that should be done by including service characteristics that say just that. The speed of the CPU might be useful in helping the watcher differentiate between a device that is a PC and one that is a cell phone, in the case where the watcher wishes to call the user's cell phone.
报告的关于设备的特征和状态信息用于选择目的——允许用户根据对设备的了解选择服务。设备特征和状态不能以任何可靠的方式用于提取设备上将接收的服务性质的信息。例如，如果设备特性包括CPU的速度，并且该速度足以支持高质量视频压缩，则这不能被解释为意味着视频质量对于该设备上的视频服务是好的。系统上的其他约束可能会减少该服务可用的CPU数量。如果希望表明设备上有更高质量的视频可用，则应通过包括服务特征来实现。在观察者希望呼叫用户手机的情况下，CPU的速度可能有助于帮助观察者区分PC设备和手机设备。
Similarly, if there is dynamic device status (such as whether the device is on or off), and this state impacts the state of the service, this is represented by adjusting the state of the service. Unless a consumer of a presence document has a priori knowledge indicating otherwise (note that presence agents often do), the state of a device has no bearing on the state of the service.
类似地，如果存在动态设备状态（例如设备是打开还是关闭），并且该状态会影响服务的状态，则可以通过调整服务的状态来表示。除非存在文档的使用者有先验知识指示其他情况（注意，存在代理通常会这样做），否则设备的状态对服务的状态没有影响。
Just like services, there is no enumeration of device types - PCs, PDAs, cell phones, etc. Rather, the device is defined by its characteristics, from which a watcher can extrapolate whether the device is a PDA, cell phone, or what have you.
就像服务一样，没有设备类型的枚举—PC、PDA、手机等。相反，设备是由其特征定义的，观察者可以从中推断设备是PDA、手机还是您拥有的其他设备。
It is important to point out that the device is a *model* of the underlying physical systems in which services execute. There is nothing that says that this model cannot be used to talk about systems where services run in virtualized systems, rather than real ones. For example, if a PC is executing a virtual machine and running services within that virtual machine, it is perfectly acceptable to use this model to talk about that PC as being composed of two separate devices.
需要指出的是，设备是执行服务的底层物理系统的“模型”。没有什么可以说这个模型不能用于讨论服务在虚拟化系统中运行的系统，而不是在真实系统中运行的系统。例如，如果一台PC正在执行一台虚拟机并在该虚拟机内运行服务，那么使用此模型将该PC描述为由两个独立的设备组成是完全可以接受的。
Ambiguity is a reality of a presence system, and it is explicitly modeled by this specification. Ambiguity exists when there are multiple pieces of information about a person, a particular device, or a particular service. This ambiguity naturally arises when multiple elements publish information about the person, a particular service, or a particular device. In some cases, a compositor can resolve the ambiguity in an automated way, and combine the data about the person, device, or service into a single coherent description.
模糊性是存在系统的一种现实，它由本规范明确建模。当存在关于某人、特定设备或特定服务的多条信息时，就会存在歧义。当多个元素发布关于个人、特定服务或特定设备的信息时，这种模糊性自然会出现。在某些情况下，合成器可以自动解决歧义，并将有关人员、设备或服务的数据合并到单个连贯的描述中。
In other cases, it cannot, perhaps because the compositor lacks the ability to do so.
在其他情况下，它不能，可能是因为合成器缺乏这样做的能力。
However, in many cases, the resolution of this ambiguity is best left to the watcher that consumes the document. This consumer could be an application with more information than the compositor, and thus be able to do a better job of resolving the ambiguity. Or, it may be presented to the human user, and the human can often resolve the ambiguity. Unsurprisingly, a human can often do this far better than an automaton can.
然而，在许多情况下，这种歧义的解决最好留给使用文档的观察者。这个使用者可以是一个比合成器拥有更多信息的应用程序，因此能够更好地解决歧义。或者，它可以呈现给人类用户，人类通常可以解决歧义。毫不奇怪，人类在这方面往往比机器人做得好得多。
To model ambiguity, the model allows each service, each device, or the person component to contain multiple occurrences. Each occurrence has a unique identifier, called the occurrence identifier. This identifier is unique across all other occurrence identifiers for any service, device, or person. That is, its uniqueness is scoped within all of the services, devices, and person elements for a particular presentity. The identifier ideally persists over time, since it serves as a valuable handle for setting composition and authorization policies. Even if there is a single occurrence for a particular device, service, or person, the occurrence has an occurrence identifier.
为了建模模糊性，该模型允许每个服务、每个设备或人员组件包含多个事件。每个事件都有一个唯一的标识符，称为事件标识符。该标识符在任何服务、设备或人员的所有其他事件标识符中都是唯一的。也就是说，它的唯一性在特定实体的所有服务、设备和人员元素中都有范围。标识符在理想情况下会随着时间的推移而存在，因为它是设置组合和授权策略的重要句柄。即使特定设备、服务或人员有一个单一事件，该事件也有一个事件标识符。
The occurrence identifier is not to be confused with the instance ID defined in the SIP Outbound specification [27]. A user agent instance is best modeled as a service, and indeed, a Globally Routable User Agent URI (GRUU) [22], which is derived from the instance ID, represents a reasonable choice for a service URI. However, if the status of such a UA instance could not be determined unambiguously, a presence document could include two or more occurrences of the service modeling that UA instance. In such a case, each occurrence has a unique occurrence ID, but they share the same service URI, and consequently, the same instance ID.
事件标识符不能与SIP出站规范中定义的实例ID混淆[27]。用户代理实例最好建模为服务，事实上，从实例ID派生的全局可路由用户代理URI（GRUU）[22]代表了服务URI的合理选择。然而，如果无法明确确定此类UA实例的状态，则状态文档可以包括对该UA实例进行服务建模的两个或多个实例。在这种情况下，每个事件都有一个唯一的事件ID，但它们共享相同的服务URI，因此也共享相同的实例ID。
When multiple occurrences exist in a document, it is important that some of the attributes of the device, service, or person help the recipient resolve the ambiguity. For humans, the note field and timestamp serve as valuable tools. For an automaton, nearly any attribute of the device, service, or person can be used to resolve the ambiguity. The timestamp in particular is very useful for both humans and automatons. As described in RFC 3863 [1], the timestamp provides the time of most recent change for the tuple. This specification defines the timestamp for person and device components as well, with the same meaning. Absent other information, the person, device, or service that most recently changed can be used as the more reliable source of data. However, such a resolution algorithm is not normatively required in any way.
当文档中存在多个实例时，设备、服务或人员的某些属性必须帮助收件人解决歧义。对于人类来说，note字段和时间戳是有价值的工具。对于自动机，几乎可以使用设备、服务或人员的任何属性来解决歧义。时间戳对人类和自动机都非常有用。如RFC 3863[1]中所述，时间戳为元组提供最近更改的时间。本规范还定义了人员和设备组件的时间戳，具有相同的含义。如果没有其他信息，最近更改的人员、设备或服务可以用作更可靠的数据源。然而，这种解析算法在任何方面都不是规范要求的。
It is clear that the existence of a presence attribute in a document tells something to a watcher about the value of that presence attribute. However, what does the absence of a presence attribute say? This data model follows the lead of RFC 3840 [17], which is used to define capabilities for SIP user agents. In that specification, if a capability declaration omits a particular feature tag, it means that the agent is making no definitive statement either way about whether this feature tag is supported. The same is true here - the absence of a presence attribute from a document means that a watcher cannot make any definitive statement about the value for that presence attribute. It may be absent because it is being withheld from the watcher, or it may be absent because that attribute is not supported by the presentity's software. Neither conclusion can be drawn.
很明显，文档中存在状态属性会向观察者告知该状态属性的值。然而，缺少presence属性意味着什么？该数据模型遵循RFC 3840[17]的指导，该模型用于定义SIP用户代理的功能。在该规范中，如果一个功能声明忽略了一个特定的功能标记，则意味着代理没有以任何方式对该功能标记是否受支持做出明确的声明。这里也是如此——文档中缺少状态属性意味着观察者无法对该状态属性的值做出任何明确的声明。它可能不存在，因为它被拒绝提供给观察者，也可能不存在，因为存在实体的软件不支持该属性。这两个结论都无法得出。
Because the absence of a presence attribute conveys no information whatsoever, presence documents achieve their maximum value when they have as many presence attributes as possible. As such, it is RECOMMENDED that a presence document contain as many presence attributes as the presentity is willing to and able to provide to a watcher.
因为缺少状态属性不会传递任何信息，所以状态文档在具有尽可能多的状态属性时会实现其最大价值。因此，建议状态文档包含状态实体愿意并能够向观察者提供的尽可能多的状态属性。
The data model tries to separate status information from characteristics, generally by defining status as a relatively dynamic state about a person, device, or service, whereas a characteristic is relatively static. However, this distinction is often artificial. Almost any characteristic can change over time, and sometimes characteristics can change relatively quickly. As a result, the distinction between status and characteristics is merely a conceptual one to facilitate understanding about the different types of presence information. Nothing in a presence document indicates whether an element is a characteristic vs. a status, and when a presence attribute is defined, there is no need for it to be declared one or the other. Presence documents allow any presence attribute, whether it can be thought of as a characteristic or a status, to change at any time.
数据模型试图将状态信息与特征分开，通常是通过将状态定义为关于人、设备或服务的相对动态状态，而特征是相对静态的。然而，这种区分往往是人为的。几乎任何特征都会随着时间的推移而变化，有时特征的变化相对较快。因此，状态和特征之间的区别仅仅是概念上的区别，以便于理解不同类型的存在信息。状态文档中没有任何内容指示元素是特征还是状态，并且当定义了状态属性时，不需要将其声明为一个或另一个。状态文档允许任何状态属性随时更改，无论该属性是否可以被视为特征或状态。
Unfortunately, the original PIDF specification did have a separate part of a tuple for describing status, and the basic status was defined to exist within that part of the tuple. This specification does not change PIDF; however, all future presence attributes MUST be defined as children of the <tuple> and not the <status> element. Furthermore, the schemas defined here do not contain a <status> element for either the <person> or <device> elements.
不幸的是，最初的PIDF规范确实在元组中有一个单独的部分用于描述状态，并且基本状态被定义为存在于元组的该部分中。本规范不改变PIDF；但是，所有未来状态属性必须定义为<tuple>的子元素，而不是<status>元素。此外，这里定义的模式不包含<person>或<device>元素的<status>元素。
The overall presence document has several important properties that are essential to this model.
“总体状态”文档有几个重要的属性，这些属性对该模型至关重要。
First, a presence document has a concrete meaning independent of how it is transported or where it is found. The semantics of a document are the same regardless of whether a document is published by a presence user agent to its compositor, or whether it is distributed from a presence agent to watchers. There are no required or implied behaviors for a recipient of a document. Rather, there are well-defined semantics for the document itself, and a recipient of a document can take whatever actions it chooses based on those semantics.
首先，状态文档的具体含义与它的运输方式或发现地点无关。文档的语义是相同的，无论文档是由状态用户代理发布到其合成器，还是从状态代理分发到观察者。对于文档的收件人，没有必需的或隐含的行为。相反，文档本身有定义良好的语义，文档的接收者可以根据这些语义选择任何操作。
A corollary of this property is that presence systems are infinitely composeable. A presence user agent can publish a document to its presence server. That presence server can compose it with other documents, and place the result in a notification to a watcher. That watcher can actually be another presence agent, combining that document with others it has received, and placing those results in yet another notify.
这个性质的一个推论是存在系统是无限可组合的。状态用户代理可以将文档发布到其状态服务器。该状态服务器可以将其与其他文档组合，并将结果发送给观察者。该观察者实际上可以是另一个状态代理，将该文档与它接收到的其他文档相结合，并将这些结果放入另一个notify中。
Yet another corollary of this property is that implied behaviors in reaction to the document cannot ever be assumed. For example, just because a service indicates that it supports audio does not mean that a watcher will offer audio in a communications attempt to that service. If doing so is necessary to reach the service, this must be indicated explicitly through reach information.
该属性的另一个推论是，无法假设对文档作出反应的隐含行为。例如，仅仅因为一个服务表明它支持音频，并不意味着观察者将在与该服务的通信尝试中提供音频。如果必须这样做才能到达服务，则必须通过reach信息明确指出这一点。
It is also important to understand that the role of the presence document is to help a user make a choice amongst a set of services, and furthermore, to know ahead of time with as much certainty as possible whether a communications attempt will succeed or fail. Success is a combination of many factors: Does the watcher understand the service URI? Can it act on all of the reach information? Does it support a subset of the capabilities associated with the service? Does the person information indicate that the user is likely to answer? All of these checks should ideally be made before attempting communication.
理解存在文档的作用是帮助用户在一组服务中做出选择，并且，提前尽可能确定通信尝试是否成功，这一点也很重要。成功是许多因素的组合：观察者是否理解服务URI？它能对所有reach信息起作用吗？它是否支持与服务相关联的功能子集？人员信息是否表明用户可能会回答？理想情况下，所有这些检查都应在尝试通信之前进行。
Because the presence document serves to help a user to choose and establish communications, the presentity URI - as the index to that document - represents a form of "one-number" communications. Starting from this URI, all of the communications modalities and their URIs for a user can be discovered, and then used to invoke a particular communications service. Rather than having to give out a separate phone number, email address, IM address, Voice over Internet
由于存在文档用于帮助用户选择和建立通信，因此作为该文档索引的存在实体URI表示一种“一个数字”通信形式。从这个URI开始，可以发现用户的所有通信模式及其URI，然后使用它们调用特定的通信服务。而不是必须给出一个单独的电话号码，电子邮件地址，即时通讯地址，互联网语音
Protocol (VoIP) address, and so on, the presentity URI can be provided, and all of the others can be learned from there.
协议（VoIP）地址等等，可以提供实体URI，并且可以从中学习所有其他URI。
Presence is defined in [21] as the ability, willingness, or desire to communicate across a set of devices. The core of this definition is the conveyance of information about the ability, willingness, or desire for communications. Thus, the presence data model needs to be tailored around conveying information that achieves this goal.
在[21]中，存在被定义为通过一组设备进行通信的能力、意愿或愿望。这一定义的核心是传递有关沟通能力、意愿或愿望的信息。因此，状态数据模型需要围绕传递实现这一目标的信息进行定制。
The person data component is targeted at conveying willingness and desire for communications. It is used to represent information about the users themselves that affects willingness and desire to communicate. Whether I am in a meeting, whether I am on the phone - each of these says something about my willingness to communicate, and thus makes sense for inclusion in a presence document.
个人数据组件旨在传达沟通意愿和愿望。它用于表示用户自身的信息，这些信息会影响交流意愿和愿望。无论我是否在开会，无论我是否在打电话——每一项都表明了我愿意沟通，因此将其包含在出席文档中是有意义的。
The service component of the data model aims to convey information on the ability to communicate. The ability to communicate is defined by the services by which a user is reachable. Thus, including them is essential.
数据模型的服务组件旨在传递有关通信能力的信息。通信能力由可访问用户的服务定义。因此，包括它们是至关重要的。
How do devices fit in? For many users, devices represent the ability to communicate, not services. Frequently, users make statements like, "Call me on my cell phone" or "I'm at my desk". These are statements for preference for communications using a specific device, as opposed to a service. Thus, it is our expectation that users will want to represent devices as part of the presence data.
设备如何适应环境？对于许多用户来说，设备代表的是通信能力，而不是服务。用户经常会说“用手机给我打电话”或“我在办公桌旁”。这些是使用特定设备而不是服务进行通信的首选语句。因此，我们期望用户希望将设备表示为状态数据的一部分。
Furthermore, the concept of device adds the ability to correlate services together. The device models the underlying platform that supports all of the services on the phone. Its state therefore impacts all services. For example, if a presence server can determine that a cell phone is off, this says something about the services that run on that device: they are all not available. Thus, if services include indicators about the devices on which they run, device state can be obtained and thus used to compute the state of the services on the device.
此外，设备的概念增加了将服务关联在一起的能力。该设备为支持手机上所有服务的底层平台建模。因此，其状态影响所有服务。例如，如果状态服务器可以确定手机已关机，这说明该设备上运行的服务都不可用。因此，如果服务包括关于其运行的设备的指示符，则可以获得设备状态，并因此用于计算设备上服务的状态。
The data model tries hard to separate device, service, and person as different concepts. Part of this differentiation is that many attributes will be applicable to some of these, but not others. For example, geographic location is a meaningful attribute of the person (the user has a location) and of a device (the device has a location), but not of a service (services don't inherently have locations). Based on this, geographic location information should only appear as part of device or person, never service. Furthermore,
数据模型试图将设备、服务和人员作为不同的概念分开。这种区别的一部分是，许多属性将适用于其中一些属性，但不适用于其他属性。例如，地理位置是个人（用户有位置）和设备（设备有位置）的有意义属性，但不是服务（服务本身没有位置）。基于此，地理位置信息应仅作为设备或人员的一部分出现，而不应作为服务出现。此外
it is possible and meaningful for location information to be conveyed for both device and person, and for these locations to be different. The fact that the presence system might try to determine the location of the person by extrapolation from the location of one of the devices is irrelevant from a data modeling perspective. Person location and device location are not the same thing.
对于设备和人员来说，传递位置信息是可能且有意义的，并且这些位置是不同的。从数据建模的角度来看，存在系统可能试图通过从其中一个设备的位置推断来确定人的位置这一事实是不相关的。人员位置和设备位置不是一回事。
[25] defines the <geopriv> XML element for conveying location information, and indicates that it is carried as a child of the <tuple> element in a PIDF document. [25] was developed prior to this specification, and unfortunately, its recommendation to include location objects underneath <tuple> runs contrary to the recommendations here. As such, implementations based on this specification SHOULD include <geopriv> location objects as part of person and/or device components of the document, but SHOULD be prepared to receive presence documents with that object as a child to <tuple>. A <geopriv> location object would be included in a person component when the document means to convey the location of the user, and within a device component when it means to convey the location of the device.
[25] 定义用于传递位置信息的<geopriv>XML元素，并指示它作为PIDF文档中<tuple>元素的子元素携带。[25]是在本规范之前开发的，不幸的是，它建议在<tuple>下面包含位置对象，这与此处的建议相反。因此，基于本规范的实现应包括<geopriv>位置对象作为文档的个人和/或设备组件的一部分，但应准备好将该对象作为<tuple>的子对象接收状态文档。当文档意味着传达用户的位置时，<geopriv>位置对象将包含在person组件中，当它意味着传达设备的位置时，将包含在设备组件中。
Information represented according to the data model described above needs to be mapped into an on-the-wire format for transport and storage. The Presence Information Data Format [1] is used for representation of presence data.
根据上述数据模型表示的信息需要映射为在线格式，以便传输和存储。存在信息数据格式[1]用于表示存在数据。
The <presence> element contains the presence information for the presentity. The "entity" attribute of this element contains the presentity URI.
<presence>元素包含存在实体的存在信息。此元素的“entity”属性包含presentity URI。
The existing <tuple> element in the PIDF document is used to represent the service. This is consistent with the original intent of RFC 2778 and RFC 3863, and achieves backward compatibility with implementations developed before the model described here was complete. The <contact> element in the <tuple> element is used to encode the service URI. New presence attributes, whether they represent dynamic status or static characteristics, appear directly as children of <tuple>. However, attributes defined prior to publication of this specification that were defined as children of <status> (such as <basic>) remain as children of <status>, for purposes of backward compatibility. Consequently, a presence attribute describing a service could appear as either a child of <status> or directly as a child of <tuple>, but never both.
PIDF文档中现有的<tuple>元素用于表示服务。这与RFC 2778和RFC 3863的初衷一致，并且实现了与在本文描述的模型完成之前开发的实现的向后兼容性。<tuple>元素中的<contact>元素用于编码服务URI。新的状态属性，无论是表示动态状态还是静态特征，都直接显示为<tuple>的子级。但是，为了向后兼容，在本规范发布之前定义为<status>子级（如<basic>）的属性仍然是<status>的子级。因此，描述服务的状态属性可以显示为<status>的子级，也可以直接显示为<tuple>的子级，但决不能同时显示两者。
The "id" attribute of the <tuple> element conveys the service occurrence. Each <tuple> element with the same <contact> URI represents a different occurrence of a particular service.
<tuple>元素的“id”属性表示服务发生。具有相同<contact>URI的每个<tuple>元素表示特定服务的不同出现。
This specification introduces the <person> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. Each one has a mandatory "id" attribute, which contains the occurrence identifier for the person. Each <person> element contains any number of elements that indicate status and characteristic information. This is followed by zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages.
本规范引入了<person>元素，它可以作为<presence>的子元素出现。每个文档可以有零个或多个此元素出现。每个人都有一个必需的“id”属性，该属性包含此人的事件标识符。每个<person>元素包含任意数量的元素，这些元素表示状态和特征信息。然后是零个或多个可选的<note>元素和可选的<timestamp>。多个<note>元素似乎以多种语言传达相同的注释。
RFC 3863 defines a <note> element, zero or more of which can be present as a child to <presence>. As it relates to the model defined here, these note elements, if present in a document, apply to all person occurrences that do not have any of their own <note> elements. In other words, if a <person> element has one or more <note> elements, those are the <note> elements for that <person> element. If a <person> element does not have any of its own <note> elements, the <note> elements that are the direct children of <presence> are the <note> elements for that <person>. If there are no <note> elements underneath the <person> element, and there are no <note> elements that are a direct child of <presence>, then that <person> element has no <note> elements.
RFC 3863定义了一个<note>元素，其中零个或多个元素可以作为<presence>的子元素出现。由于与此处定义的模型相关，这些注释元素（如果存在于文档中）适用于没有任何自己的<note>元素的所有人员事件。换句话说，如果一个<person>元素有一个或多个<note>元素，那么这些元素就是该<person>元素的<note>元素。如果一个<person>元素没有任何自己的<note>元素，那么<presence>的直接子元素<note>就是该<person>的<note>元素。如果<person>元素下面没有<note>元素，并且没有<note>元素是<presence>的直接子元素，那么<person>元素没有<note>元素。
This specification also introduces the <device> element, which can appear as a child to <presence>. There can be zero or more occurrences of this element per document. The <device> element can appear either before or after the <person> element; there are no constraints on order. Each <device> element has a mandatory "id" attribute, which contains the occurrence identifier for the device. Like <person>, <device> contains any number of elements that indicate status and characteristic information. This is followed by <deviceID>, which contains the URN for the device ID for this device. This is followed by zero or more optional <note> elements and an optional <timestamp>. Multiple <note> elements would appear to convey the same note in multiple languages.
本规范还引入了<device>元素，它可以作为<presence>的子元素出现。每个文档可以有零个或多个此元素出现。<device>元素可以出现在<person>元素之前或之后；对秩序没有任何限制。每个<device>元素都有一个必需的“id”属性，该属性包含设备的发生标识符。与<person>类似，<device>包含任意数量的表示状态和特征信息的元素。然后是<deviceID>，其中包含此设备的设备ID的URN。然后是零个或多个可选的<note>元素和可选的<timestamp>。多个<note>元素似乎以多种语言传达相同的注释。
A client that receives a PIDF document containing the <device> and <person> elements, but does not understand them (because it doesn't implement this specification), will ignore them. Furthermore, since the semantics of service as defined here are aligned with the meaning of a tuple as defined in RFC 2778 and RFC 3863, documents incorporating the concepts defined in this model are compliant with older implementations.
接收包含<device>和<person>元素的PIDF文档但不理解它们（因为它没有实现此规范）的客户端将忽略它们。此外，由于此处定义的服务语义与RFC 2778和RFC 3863中定义的元组含义一致，因此包含此模型中定义的概念的文档与较旧的实现兼容。
It's important to note that the mapping of the presence data model into a PIDF document is merely an exercise in syntax.
需要注意的是，将状态数据模型映射到PIDF文档只是一个语法练习。
Presence documents created according to this model MUST be valid, with the following exception. A compositor is permitted to create a presence document that it cannot fully validate but that otherwise validates when processed according to the lax processing rules allowed by the schema of the compositor. However, it is not expected that entities receiving these documents would perform schema validation; rather, they would merely access the information from the document in the places they were expecting it to be. Implementations SHOULD be prepared to receive documents that are not valid, and extract whatever information from them that they can parse.
根据此模型创建的状态文档必须有效，但以下情况除外。允许合成器创建无法完全验证但在根据合成器架构允许的宽松处理规则进行处理时进行验证的状态文档。但是，接收这些文档的实体不会执行模式验证；相反，他们只会在预期的位置访问文档中的信息。实现应该准备好接收无效的文档，并从中提取任何可以解析的信息。
The XML schemas are broken into a common schema, called common-schema.xsd, which contains common type definitions, and the rest of the data model, data-model.xsd.
XML模式分为一个公共模式，称为common-schema.xsd，其中包含公共类型定义，以及数据模型的其余部分data-model.xsd。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="Timestamp_t">
<xs:annotation>
<xs:documentation>Timestamp type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="Note_t">
<xs:annotation>
<xs:documentation>Note type</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:simpleType name="Timestamp_t">
<xs:annotation>
<xs:documentation>Timestamp type</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:dateTime"/>
</xs:simpleType>
<xs:simpleType name="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="Note_t">
<xs:annotation>
<xs:documentation>Note type</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extension base="xs:string">
<xs:attribute ref="xml:lang"/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
<xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup>
<xs:complexType name="empty"/>
</xs:schema>
</xs:complexType>
<xs:attributeGroup name="fromUntil">
<xs:attribute name="from" type="xs:dateTime"/>
<xs:attribute name="until" type="xs:dateTime"/>
</xs:attributeGroup>
<xs:complexType name="empty"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="device">
<xs:annotation>
<xs:documentation>Contains information about the
device</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="person">
<xs:annotation>
<xs:documentation>Contains information about the human
user</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="urn:ietf:params:xml:ns:pidf:data-model"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:include schemaLocation="common-schema.xsd"/>
<xs:element name="deviceID" type="deviceID_t">
<xs:annotation>
<xs:documentation>Device ID, a URN</xs:documentation>
</xs:annotation>
</xs:element>
<xs:element name="device">
<xs:annotation>
<xs:documentation>Contains information about the
device</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="deviceID"/>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="person">
<xs:annotation>
<xs:documentation>Contains information about the human
user</xs:documentation>
</xs:annotation>
<xs:complexType>
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Characteristic and status
information</xs:documentation>
</xs:annotation>
</xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
<xs:documentation>Characteristic and status
information</xs:documentation>
</xs:annotation>
</xs:any>
<xs:element name="note" type="Note_t" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element name="timestamp" type="Timestamp_t" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
</xs:schema>
When new presence attributes are added, any such extension has to consider the following questions:
当添加新的存在属性时，任何这样的扩展都必须考虑以下问题：
1. Is the new attribute applicable to person, service, or device data components? If it is applicable to more than one, what is its meaning in each context? An extension should strive to have each attribute concisely defined for each area of applicability, so that a source can clearly determine to which type of data component it should be applied.
1. 新属性是否适用于个人、服务或设备数据组件？如果它适用于不止一种情况，那么它在每种情况下的含义是什么？扩展应力求为每个适用性区域简洁地定义每个属性，以便源可以清楚地确定应将其应用于哪种类型的数据组件。
2. Does it belong in a new namespace, or an existing one? Generally, new presence attributes defined within the same specification SHOULD belong to the same namespace. Presence attributes defined in separate specifications, but produced in a coordinated way by a centralized administration, MAY be placed in the same namespace. Doing so, however, requires the centralized administration to ensure that there are no collisions of element names across those specifications. Furthermore, if a new extension has elements meant to be placed as the children of another element at a point of extensibility defined by <any namespace="##other">, the new extension MUST use a different namespace than that of its parent elements.
2. 它属于新名称空间还是现有名称空间？通常，在同一规范中定义的新状态属性应该属于同一名称空间。在单独规范中定义但由集中管理以协调方式生成的状态属性可以放在同一命名空间中。但是，这样做需要集中管理，以确保这些规范中的元素名称不会发生冲突。此外，如果一个新扩展的元素要作为另一个元素的子元素放置在<anynamespace=“##other”>定义的扩展点上，那么新扩展必须使用与其父元素不同的名称空间。
3. Does the extension itself require extensibility? If so, points of extension MUST be defined in the schema, and SHOULD be done using the <any namespace="##other"> construct.
3. 扩展本身是否需要可扩展性？如果是这样，扩展点必须在模式中定义，并且应该使用<anynamespace=“##other”>构造来完成。
In this section, we give an example of a physical system, present the model of that system using the concepts described here, and then show the resulting presence document. The example makes use of presence attributes defined in [23] and [24].
在本节中，我们将给出一个物理系统的示例，使用此处描述的概念展示该系统的模型，然后展示生成的状态文档。该示例使用了[23]和[24]中定义的状态属性。
In this scenario, a provider is offering a service very similar to the instant messaging services offered today by the public providers like AOL, Yahoo!, and MSN. In this service, each user has a "screen name" that identifies the user in the service. A single client, generally a PC application, connects to the service at a time. When the client connects, this fact is made available to other watchers of that user in the system. The user has the ability to set a textual note that describes what they are doing, and this note is seen by the watchers in the system. The user can set one of several status messages (busy, in a meeting, etc.), which are pre-defined notes that the system understands. If a user does not type anything on their keyboard for some time, the user's status changes to idle on the screens of the various watchers of the system. The system also indicates the amount of time that the user has been idle.
在这种情况下，提供商提供的服务与AOL、Yahoo！等公共提供商今天提供的即时消息服务非常相似！，和MSN。在此服务中，每个用户都有一个“屏幕名称”，用于标识服务中的用户。单个客户端（通常是PC应用程序）一次连接到服务。当客户端连接时，该事实将提供给系统中该用户的其他观察者。用户可以设置一个文本注释来描述他们正在做什么，系统中的观察者可以看到这个注释。用户可以设置几个状态消息（忙、会议中等）中的一个，这些消息是系统理解的预定义注释。如果用户在一段时间内没有在键盘上键入任何内容，则在系统的各个观察者的屏幕上，用户的状态将变为空闲。系统还指示用户空闲的时间量。
Whenever a user is connected to the system, they are capable of receiving instant messages. A user can set their status to "invisible", which means that they appear as offline to other users. However, if an IM is sent to them, it will still be delivered.
每当用户连接到系统时，他们都能够接收即时消息。用户可以将其状态设置为“不可见”，这意味着对其他用户来说，它们显示为脱机状态。但是，如果向他们发送即时消息，它仍然会被发送。
This system is modeled by representing each presentity in the system with three data components: a person component, a service component, and a device component. The person component describes the state of the user, including the note and the pre-defined status messages. These represent information about the human user, so they are included in the person component. The service tuple represents the IM service. No characteristics are included. The service URI published by the client is set to the client's Address of Record (AOR). The device component is used to model the PC. The device component includes the <user-input> element [23], since the idleness refers to usage of the device, not the service.
该系统通过使用三个数据组件表示系统中的每个实体来建模：个人组件、服务组件和设备组件。person组件描述用户的状态，包括注释和预定义的状态消息。这些表示有关人类用户的信息，因此它们包含在person组件中。服务元组表示IM服务。不包括任何特征。客户端发布的服务URI设置为客户端的记录地址（AOR）。设备组件用于为PC建模。设备组件包括<user input>元素[23]，因为空闲指的是设备的使用，而不是服务。
The document published by the client would look like this:
客户发布的文档如下所示：
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<caps:servcaps>
<?xml version="1.0" encoding="UTF-8"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
xmlns:rp="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:caps="urn:ietf:params:xml:ns:pidf:caps"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
<caps:servcaps>
<caps:extensions>
<caps:supported>
<caps:pref/>
</caps:supported>
</caps:extensions>
<caps:methods>
<caps:supported>
<caps:MESSAGE/>
<caps:OPTIONS/>
</caps:supported>
</caps:methods>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<dm:person id="p1">
<rp:activities>
<rp:on-the-phone/>
</rp:activities>
</dm:person>
<dm:device id="pc122">
<rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
</presence>
<caps:extensions>
<caps:supported>
<caps:pref/>
</caps:supported>
</caps:extensions>
<caps:methods>
<caps:supported>
<caps:MESSAGE/>
<caps:OPTIONS/>
</caps:supported>
</caps:methods>
</caps:servcaps>
<contact>sip:someone@example.com</contact>
</tuple>
<dm:person id="p1">
<rp:activities>
<rp:on-the-phone/>
</rp:activities>
</dm:person>
<dm:device id="pc122">
<rp:user-input>idle</rp:user-input>
<dm:deviceID>mac:8asd7d7d70</dm:deviceID>
</dm:device>
</presence>
It is worth commenting further on the value of having a separate device element just to convey the idle indicator. The idle indication of interest is really an indicator that the device is idle. By making that explicit, the idle indicator can be used by the presence server to affect the state of other services running on the same device. For example, let's say there is a VoIP application running on the same device. This application reports its presence state separately, but indicates that it runs on the same device. Since it has indicated that it runs on the same device, the presence server can use the status of the service to further refine the idle indicator of the device. Specifically, if the user is using its VoIP application, the presence server knows that the device is in use, even if the IM application reports that the device is idle. Typically, idleness is determined by lack of keyboard or mouse input, neither of which might be used during a VoIP call.
值得进一步说明的是，使用单独的设备元件仅传送空闲指示器的价值。感兴趣的空闲指示实际上是设备空闲的指示器。通过使其显式化，状态服务器可以使用空闲指示器来影响在同一设备上运行的其他服务的状态。例如，假设有一个VoIP应用程序在同一台设备上运行。此应用程序单独报告其存在状态，但表示它在同一设备上运行。因为它已经指示它在同一设备上运行，所以状态服务器可以使用服务的状态来进一步细化设备的空闲指示器。具体地说，如果用户正在使用其VoIP应用程序，则存在服务器知道该设备正在使用，即使IM应用程序报告该设备空闲。通常，空闲是由缺少键盘或鼠标输入决定的，这两种输入都不可能在VoIP呼叫期间使用。
In a more simplistic case, reporting the idle indicator as part of the device status allows that indicator to be used for other services on the same device. Taking, again, the example of the VoIP application on the same device, if the VoIP application does not report any device information, and a watcher is not provided information on the IM service, the presence document sent to the watcher can include the device status. Because of the usage of the
在更简单的情况下，将空闲指示器作为设备状态的一部分进行报告允许该指示器用于同一设备上的其他服务。再次以同一设备上的VoIP应用为例，如果VoIP应用不报告任何设备信息，并且没有向观察者提供关于IM服务的信息，则发送给观察者的存在文档可以包括设备状态。因为使用了
device IDs and the device information, the presence server can correlate the device status as reported by the IM application with the VoIP service, and use them together.
通过设备ID和设备信息，状态服务器可以将IM应用程序报告的设备状态与VoIP服务关联起来，并将它们一起使用。
The presence information described by the model defined here is very sensitive. It is for this reason that privacy filtering plays a key role in the processing of presence data. Privacy filtering is the act of applying permissions to a presence document for the purposes of removing information that a watcher is not authorized to see. In more general terms, privacy filtering is a form of authorization. Privacy filtering can also ensure that a watcher cannot see any presence data for a presentity, and indeed, it can even ensure that the presentity doesn't know that it is being blocked. The SIP presence specifications (RFC 3856 [21]) require that such authorization processing be performed before divulging presence information. Specifications have also been defined for conveying authorization policies to presence servers [26].
此处定义的模型描述的存在信息非常敏感。正是由于这个原因，隐私过滤在状态数据的处理中起着关键作用。隐私过滤是对状态文档应用权限的行为，目的是删除观察者无权查看的信息。更一般地说，隐私过滤是一种授权形式。隐私过滤还可以确保观察者看不到存在实体的任何存在数据，事实上，它甚至可以确保存在实体不知道它正在被阻止。SIP存在规范（RFC 3856[21]）要求在泄露存在信息之前执行此类授权处理。还定义了将授权策略传送到状态服务器的规范[26]。
Integrity of presence information is also critical. Modification of presence data by an attacker can lead to diverted communications, for example. Protocols used to transport presence data, such as SIP for presence, are used to provide necessary integrity functions.
状态信息的完整性也至关重要。例如，攻击者修改状态数据可能导致通信转移。用于传输状态数据的协议（如SIP for presence）用于提供必要的完整性功能。
This specification defines a data model that contains mostly tokens that are meant for consumption by programs, not directly by humans. Programs are expected to translate those tokens into language-appropriate text strings according to the preferences of the watcher.
该规范定义了一个数据模型，该模型主要包含由程序使用的令牌，而不是直接由人使用的令牌。程序需要根据观察者的偏好将这些标记翻译成适合语言的文本字符串。
However, this specification defines a <note> element that can contain free text. This element and other ones defined by extensions to PIDF that can contain free text SHOULD be labeled with the 'xml:lang' attribute to indicate their language and script. This specification allows multiple occurrences of the <note> element so that the presentity can convey the note in multiple scripts and languages. If no 'xml:lang' attribute is provided, the default value is "i-default" [8].
但是，本规范定义了一个可以包含自由文本的<note>元素。这个元素和其他由PIDF扩展定义的可以包含自由文本的元素应该标记为“xml:lang”属性，以指示它们的语言和脚本。本规范允许多次出现<note>元素，以便presentity可以用多种脚本和语言传达注释。如果未提供“xml:lang”属性，则默认值为“i-default”[8]。
Since the presence model is represented in XML, it provides native support for encoding information using the Unicode character set and its more compact representations including UTF-8. Conformant XML processors recognize both UTF-8 and UTF-16. Though XML includes provisions to identify and use other character encodings through use of an "encoding" attribute in an <?xml?> declaration, use of UTF-8 is
由于存在模型是用XML表示的，因此它使用Unicode字符集及其更紧凑的表示（包括UTF-8）为编码信息提供了本机支持。UTF-8和UTF-16兼容处理器。尽管XML包含通过在<？XML？>声明中使用“encoding”属性来识别和使用其他字符编码的规定，但UTF-8的使用是不正确的
RECOMMENDED in environments where parser encoding support incompatibility exists.
建议在解析器编码支持不兼容的环境中使用。
There are several IANA considerations associated with this specification.
与本规范相关的IANA注意事项有几个。
This section registers a new XML namespace, per the guidelines in [4]
本节根据[4]中的指南注册一个新的XML名称空间
URI: The URI for this namespace is urn:ietf:params:xml:ns:pidf:data-model.
URI：此命名空间的URI为urn:ietf:params:xml:ns:pidf:data-model。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
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>A Data Model for Presence</title>
</head>
<body>
<h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4479.txt">
RFC4479</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>A Data Model for Presence</title>
</head>
<body>
<h1>Namespace for Presence Data Model</h1>
<h2>urn:ietf:params:xml:ns:pidf:data-model</h2>
<p>See <a href="http://www.rfc-editor.org/rfc/rfc4479.txt">
RFC4479</a>.</p>
</body>
</html>
END
This section registers two XML schemas per the procedures in [4].
本节按照[4]中的过程注册两个XML模式。
URI: urn:ietf:params:xml:schema:pidf:common-schema.
URI:urn:ietf:params:xml:schema:pidf:common schema。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of Section 5.1.1.
此模式的XML可作为第5.1.1节的唯一内容找到。
URI: urn:ietf:params:xml:schema:pidf:data-model.
URI:urn:ietf:params:xml:schema:pidf:data-model。
Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), Jonathan Rosenberg (jdrosen@jdrosen.net).
注册人联系人：IETF，简单工作组(simple@ietf.org)，乔纳森·罗森伯格(jdrosen@jdrosen.net).
The XML for this schema can be found as the sole content of Section 5.1.2.
此模式的XML可作为第5.1.2节的唯一内容找到。
This document is really a distillation of many ideas discussed over a long period of time. These ideas were contributed by many participants in the SIMPLE working group. Aki Niemi, Paul Kyzivat, Cullen Jennings, Ben Campbell, Robert Sparks, Dean Willis, Adam Roach, Hisham Khartabil, and Jon Peterson contributed many of the concepts that are described here. Example presence documents came from Robert Sparks' example presence documents specification, and ideas on defining services through characteristics, rather than enumeration, came from Adam Roach's service features document. A special thanks to Steve Donovan for discussions on the topics discussed here, and to Elwyn Davies for his final review of the document.
这份文件实际上是经过长时间讨论的许多想法的结晶。这些想法是由简单工作组的许多与会者提出的。Aki Niemi、Paul Kyzivat、Cullen Jennings、Ben Campbell、Robert Sparks、Dean Willis、Adam Roach、Hisham Khartabil和Jon Peterson提出了本文描述的许多概念。示例呈现文档来自Robert Sparks的示例呈现文档规范，关于通过特征而不是枚举定义服务的想法来自Adam Roach的服务特性文档。特别感谢Steve Donovan对本文讨论主题的讨论，以及Elwyn Davies对文件的最终审查。
[1] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[1] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[2] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller Preferences for the Session Initiation Protocol (SIP)", RFC 3841, August 2004.
[2] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“会话启动协议（SIP）的呼叫方偏好”，RFC 38412004年8月。
[3] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[3] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[4] Mealling，M.，“IETF XML注册表”，BCP 81，RFC 3688，2004年1月。
[5] Yergeau, F., Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C REC REC-xml-20040204, February 2004.
[5] Yergeau，F.，Paoli，J.，Sperberg McQueen，C.，Bray，T.，和E.Maler，“可扩展标记语言（XML）1.0（第三版）”，W3C REC REC-XML-200402042004年2月。
[6] Maloney, M., Beech, D., Thompson, H., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C REC REC-xmlschema-1-20041028, October 2004.
[6] Maloney，M.，Beech，D.，Thompson，H.，和N.Mendelsohn，“XML模式第1部分：结构第二版”，W3C REC-xmlschema-1-20041028，2004年10月。
[7] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes Second Edition", W3C REC REC-xmlschema-2-20041028, October 2004.
[7] Malhotra，A.和P.Biron，“XML模式第2部分：数据类型第二版”，W3C REC REC-xmlschema-2-20041028，2004年10月。
[8] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[8] Alvestrand，H.，“IETF字符集和语言政策”，BCP 18，RFC 2277，1998年1月。
[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[9] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[10] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[10] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[11] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[11] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[12] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[12] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
[13] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", Work in Progress, December 2005.
[13] Saint Andre，P.，“可扩展消息和状态协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，正在进行的工作，2005年12月。
[14] Wilde, E. and A. Vaha-Sipila, "URI Scheme for GSM Short Message Service", Work in Progress, February 2006.
[14] Wilde，E.和A.Vaha Sipila，“GSM短消息服务的URI方案”，正在进行的工作，2006年2月。
[15] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[15] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[16] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999.
[16] Klyne，G.“描述媒体功能集的语法”，RFC2533，1999年3月。
[17] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[17] Rosenberg，J.，Schulzrinne，H.，和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC 3840，2004年8月。
[18] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[18] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[19] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", Work in Progress, March 2006.
[19] Rosenberg，J.，“会话启动协议（SIP）和垃圾邮件”，正在进行的工作，2006年3月。
[20] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[20] Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[21] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[21] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[22] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", Work in Progress, October 2005.
[22] Rosenberg，J.，“在会话启动协议（SIP）中获取和使用全局可路由用户代理（UA）URI（GRUU）”，正在进行的工作，2005年10月。
[23] Schulzrinne, H., "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
[23] Schulzrinne，H.，“RPID：状态信息数据格式（PIDF）的丰富状态扩展”，RFC4480，2006年7月。
[24] Lonnfors, M. and K. Kiss, "Session Initiation Protocol (SIP) User Agent Capability Extension to Presence Information Data Format (PIDF)", Work in Progress, January 2006.
[24] Lonnfors，M.和K.Kiss，“会话启动协议（SIP）用户代理能力扩展到状态信息数据格式（PIDF）”，正在进行的工作，2006年1月。
[25] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[25] Peterson，J.，“基于状态的GEOPRIV定位对象格式”，RFC 4119，2005年12月。
[26] Rosenberg, J., "Presence Authorization Rules", Work in Progress, March 2006.
[26] Rosenberg，J.，“在场授权规则”，正在进行的工作，2006年3月。
[27] Jennings C. and R. Mahy, "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)", Work in Progress, March 2006.
[27] Jennings C.和R.Mahy，“在会话启动协议（SIP）中管理客户端启动的连接”，正在进行的工作，2006年3月。
Author's Address
作者地址
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US
Jonathan Rosenberg Cisco Systems 600美国新泽西州帕西帕尼拉尼德广场07054号
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Phone: +1 973 952-5000
EMail: jdrosen@cisco.com
URI: http://www.jdrosen.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
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 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 provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。