Network Working Group J. Rosenberg
Request for Comments: 3856 dynamicsoft
Category: Standards Track August 2004
Network Working Group J. Rosenberg
Request for Comments: 3856 dynamicsoft
Category: Standards Track August 2004
A Presence Event Package for the Session Initiation Protocol (SIP)
会话启动协议（SIP）的状态事件包
Status of this Memo
本备忘录的状况
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the usage of the Session Initiation Protocol (SIP) for subscriptions and notifications of presence. Presence is defined as the willingness and ability of a user to communicate with other users on the network. Historically, presence has been limited to "on-line" and "off-line" indicators; the notion of presence here is broader. Subscriptions and notifications of presence are supported by defining an event package within the general SIP event notification framework. This protocol is also compliant with the Common Presence Profile (CPP) framework.
本文档介绍会话启动协议（SIP）在订阅和状态通知中的用法。存在被定义为用户与网络上其他用户通信的意愿和能力。历史上，存在仅限于“在线”和“离线”指标；这里存在的概念更广泛。通过在通用SIP事件通知框架中定义事件包来支持订阅和状态通知。该协议还符合公共状态配置文件（CPP）框架。
Table of Contents
目录
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Definitions ................................................. 3
4. Overview of Operation ....................................... 4
5. Usage of Presence URIs ...................................... 6
6. Presence Event Package ...................................... 7
6.1. Package Name .......................................... 8
6.2. Event Package Parameters .............................. 8
6.3. SUBSCRIBE Bodies ...................................... 8
6.4. Subscription Duration ................................. 9
6.5. NOTIFY Bodies ......................................... 9
6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
6.6.1. Authentication ................................. 10
6.6.2. Authorization .................................. 10
6.7. Notifier Generation of NOTIFY Requests ................ 11
1. Introduction ................................................ 2
2. Terminology ................................................. 3
3. Definitions ................................................. 3
4. Overview of Operation ....................................... 4
5. Usage of Presence URIs ...................................... 6
6. Presence Event Package ...................................... 7
6.1. Package Name .......................................... 8
6.2. Event Package Parameters .............................. 8
6.3. SUBSCRIBE Bodies ...................................... 8
6.4. Subscription Duration ................................. 9
6.5. NOTIFY Bodies ......................................... 9
6.6. Notifier Processing of SUBSCRIBE Requests ............. 9
6.6.1. Authentication ................................. 10
6.6.2. Authorization .................................. 10
6.7. Notifier Generation of NOTIFY Requests ................ 11
6.8. Subscriber Processing of NOTIFY Requests .............. 13
6.9. Handling of Forked Requests ........................... 13
6.10. Rate of Notifications ................................. 14
6.11. State Agents .......................................... 14
6.11.1. Aggregation, Authentication, and Authorization. 14
6.11.2. Migration ..................................... 15
7. Learning Presence State ..................................... 16
7.1. Co-location ........................................... 16
7.2. REGISTER .............................................. 16
7.3. Uploading Presence Documents .......................... 17
8. Example Message Flow ........................................ 17
9. Security Considerations ..................................... 20
9.1. Confidentiality ....................................... 20
9.2. Message Integrity and Authenticity .................... 21
9.3. Outbound Authentication ............................... 22
9.4. Replay Prevention ..................................... 22
9.5. Denial of Service Attacks Against Third Parties ....... 22
9.6. Denial Of Service Attacks Against Servers ............. 23
10. IANA Considerations ......................................... 23
11. Contributors ................................................ 24
12. Acknowledgements ............................................ 25
13. Normative References ........................................ 25
14. Informative References ...................................... 26
15. Author's Address ............................................ 26
16. Full Copyright Statement .................................... 27
6.8. Subscriber Processing of NOTIFY Requests .............. 13
6.9. Handling of Forked Requests ........................... 13
6.10. Rate of Notifications ................................. 14
6.11. State Agents .......................................... 14
6.11.1. Aggregation, Authentication, and Authorization. 14
6.11.2. Migration ..................................... 15
7. Learning Presence State ..................................... 16
7.1. Co-location ........................................... 16
7.2. REGISTER .............................................. 16
7.3. Uploading Presence Documents .......................... 17
8. Example Message Flow ........................................ 17
9. Security Considerations ..................................... 20
9.1. Confidentiality ....................................... 20
9.2. Message Integrity and Authenticity .................... 21
9.3. Outbound Authentication ............................... 22
9.4. Replay Prevention ..................................... 22
9.5. Denial of Service Attacks Against Third Parties ....... 22
9.6. Denial Of Service Attacks Against Servers ............. 23
10. IANA Considerations ......................................... 23
11. Contributors ................................................ 24
12. Acknowledgements ............................................ 25
13. Normative References ........................................ 25
14. Informative References ...................................... 26
15. Author's Address ............................................ 26
16. Full Copyright Statement .................................... 27
Presence, also known as presence information, 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. In that model, a presence service is a system that accepts, stores, and distributes presence information to interested parties, called watchers. A presence protocol is a protocol for providing a presence service over the Internet or any IP network.
状态，也称为状态信息，表示用户跨一组设备进行通信的能力和意愿。RFC 2778[10]定义了用于描述提供状态信息的系统的模型和术语。在该模型中，状态服务是一个接受、存储状态信息并将其分发给相关方（称为观察者）的系统。存在协议是用于通过因特网或任何IP网络提供存在服务的协议。
This document proposes the usage of the Session Initiation Protocol (SIP) [1] as a presence protocol. This is accomplished through a concrete instantiation of the general event notification framework defined for SIP [2], and as such, makes use of the SUBSCRIBE and NOTIFY methods defined there. Specifically, this document defines an event package, as described in RFC 3265 [2]. SIP is particularly well suited as a presence protocol. SIP location services already contain presence information, in the form of registrations. Furthermore, SIP networks are capable of routing requests from any user on the network to the server that holds the registration state for a user. As this state is a key component of user presence, those
本文档建议使用会话发起协议（SIP）[1]作为存在协议。这是通过为SIP[2]定义的通用事件通知框架的具体实例来实现的，因此，使用了其中定义的SUBSCRIBE和NOTIFY方法。具体而言，本文档定义了一个事件包，如RFC 3265[2]所述。SIP特别适合作为存在协议。SIP位置服务已经包含注册形式的状态信息。此外，SIP网络能够将来自网络上任何用户的请求路由到持有用户注册状态的服务器。由于此状态是用户状态的关键组成部分，因此
SIP networks can allow SUBSCRIBE requests to be routed to the same server. This means that SIP networks can be reused to establish global connectivity for presence subscriptions and notifications.
SIP网络允许将订阅请求路由到同一服务器。这意味着可以重用SIP网络来建立状态订阅和通知的全局连接。
This event package is based on the concept of a presence agent, which is a new logical entity that is capable of accepting subscriptions, storing subscription state, and generating notifications when there are changes in presence. The entity is defined as a logical one, since it is generally co-resident with another entity.
此事件包基于状态代理的概念，它是一个新的逻辑实体，能够接受订阅、存储订阅状态并在状态发生更改时生成通知。实体被定义为逻辑实体，因为它通常与另一个实体共存。
This event package is also compliant with the Common Presence Profile (CPP) framework that has been defined in [3]. This allows SIP for presence to easily interwork with other presence systems compliant to CPP.
此事件包还符合[3]中定义的公共状态配置文件（CPP）框架。这使得SIP for presence能够轻松地与符合CPP的其他presence系统交互。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [4] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[4]中所述进行解释，并指明符合性实施的要求级别。
This document uses the terms as defined in RFC 2778 [10]. Additionally, the following terms are defined and/or additionally clarified:
本文件使用RFC 2778[10]中定义的术语。此外，定义和/或额外澄清了以下术语：
Presence User Agent (PUA): A Presence User Agent manipulates presence information for a presentity. This manipulation can be the side effect of some other action (such as sending a SIP REGISTER request to add a new Contact) or can be done explicitly through the publication of presence documents. We explicitly allow multiple PUAs per presentity. This means that a user can have many devices (such as a cell phone and Personal Digital Assistant (PDA)), each of which is independently generating a component of the overall presence information for a presentity. PUAs push data into the presence system, but are outside of it, in that they do not receive SUBSCRIBE messages or send NOTIFY messages.
状态用户代理（PUA）：状态用户代理为状态实体操纵状态信息。这种操作可能是某些其他操作（例如发送SIP注册请求以添加新联系人）的副作用，也可以通过发布状态文档显式完成。我们明确允许每个实体有多个PUA。这意味着用户可以具有许多设备（例如，手机和个人数字助理（PDA）），其中每个设备独立地为存在实体生成整体存在信息的组件。PUA将数据推送到状态系统中，但不在状态系统之外，因为它们不接收订阅消息或发送通知消息。
Presence Agent (PA): A presence agent is a SIP user agent which is capable of receiving SUBSCRIBE requests, responding to them, and generating notifications of changes in presence state. A presence agent must have knowledge of the presence state of a presentity. This means that it must have access to presence data manipulated by PUAs for the presentity. One way to do this is by co-locating the PA with the proxy/registrar.
状态代理（PA）：状态代理是一种SIP用户代理，能够接收订阅请求、响应请求并生成状态更改通知。存在代理必须了解存在实体的存在状态。这意味着它必须能够访问PUAs为presentity操纵的状态数据。实现这一点的一种方法是将PA与代理/注册人放在一起。
Another way is to co-locate it with the presence user agent of the presentity. However, these are not the only ways, and this specification makes no recommendations about where the PA function should be located. A PA is always addressable with a SIP URI that uniquely identifies the presentity (i.e., sip:joe@example.com). There can be multiple PAs for a particular presentity, each of which handles some subset of the total subscriptions currently active for the presentity. A PA is also a notifier (defined in RFC 3265 [2]) that supports the presence event package.
另一种方法是将其与实体的状态用户代理共同定位。然而，这些并不是唯一的方法，本规范未对PA功能的位置提出建议。PA始终可通过唯一标识存在实体的SIP URI寻址（即SIP：joe@example.com). 一个特定实体可以有多个PA，每个PA处理该实体当前活动的总订阅的某个子集。PA也是支持状态事件包的通知程序（在RFC 3265[2]中定义）。
Presence Server: A presence server is a physical entity that can act as either a presence agent or as a proxy server for SUBSCRIBE requests. When acting as a PA, it is aware of the presence information of the presentity through some protocol means. When acting as a proxy, the SUBSCRIBE requests are proxied to another entity that may act as a PA.
状态服务器：状态服务器是一个物理实体，可以充当状态代理或订阅请求的代理服务器。当充当PA时，它通过一些协议手段意识到存在实体的存在信息。当充当代理时，订阅请求被代理给可能充当PA的另一个实体。
Edge Presence Server: An edge presence server is a presence agent that is co-located with a PUA. It is aware of the presence information of the presentity because it is co-located with the entity that manipulates this presence information.
边缘状态服务器：边缘状态服务器是与PUA位于同一位置的状态代理。它知道存在实体的存在信息，因为它与操纵该存在信息的实体位于同一位置。
In this section, we present an overview of the operation of this event package. The overview describes behavior that is documented in part here, in part within the SIP event framework [2], and in part in the SIP specification [1], in order to provide clarity on this package for readers only casually familiar with those specifications. However, the detailed semantics of this package require the reader to be familiar with SIP events and the SIP specification itself.
在本节中，我们将概述此事件包的操作。概述部分描述了此处记录的行为，部分在SIP事件框架[2]中记录，部分在SIP规范[1]中记录，以便为仅偶尔熟悉这些规范的读者提供此包的清晰性。然而，这个包的详细语义要求读者熟悉SIP事件和SIP规范本身。
When an entity, the subscriber, wishes to learn about presence information from some user, it creates a SUBSCRIBE request. This request identifies the desired presentity in the Request-URI, using a SIP URI, SIPS URI [1] or a presence (pres) URI [3]. The SUBSCRIBE request is carried along SIP proxies as any other SIP request would be. In most cases, it eventually arrives at a presence server, which can either generate a response to the request (in which case it acts as the presence agent for the presentity), or proxy it on to an edge presence server. If the edge presence server handles the subscription, it is acting as the presence agent for the presentity. The decision at a presence server about whether to proxy or terminate the SUBSCRIBE is a local matter; however, we describe one way to effect such a configuration, using REGISTER.
当一个实体（订户）希望从某个用户那里了解状态信息时，它会创建一个订阅请求。此请求使用SIP URI、SIPS URI[1]或存在（pres）URI[3]在请求URI中标识所需的存在实体。订阅请求与任何其他SIP请求一样随SIP代理一起进行。在大多数情况下，它最终到达状态服务器，该服务器可以生成对请求的响应（在这种情况下，它充当状态实体的状态代理），或者将其代理到边缘状态服务器。如果边缘呈现服务器处理订阅，则它将充当呈现实体的呈现代理。存在服务器上关于是否代理或终止订阅的决定是本地事务；然而，我们描述了一种实现这种配置的方法，即使用寄存器。
The presence agent (whether in the presence server or edge presence server) first authenticates the subscription, then authorizes it. The means for authorization are outside the scope of this protocol, and we expect that many mechanisms will be used. If authorized, a 200 OK response is returned. If authorization could not be obtained at this time, the subscription is considered "pending", and a 202 response is returned. In both cases, the PA sends an immediate NOTIFY message containing the state of the presentity and of the subscription. The presentity state may be bogus in the case of a pending subscription, indicating offline no matter what the actual state of the presentity, for example. This is to protect the privacy of the presentity, who may not want to reveal that they have not provided authorization for the subscriber. As the state of the presentity changes, the PA generates NOTIFYs containing those state changes to all subscribers with authorized subscriptions. Changes in the state of the subscription itself can also trigger NOTIFY requests; that state is carried in the Subscription-State header field of the NOTIFY, and would typically indicate whether the subscription is active or pending.
状态代理（无论是在状态服务器还是边缘状态服务器中）首先对订阅进行身份验证，然后对其进行授权。授权手段不在本协议的范围内，我们预计将使用许多机制。如果授权，则返回200 OK响应。如果此时无法获得授权，则订阅将被视为“挂起”，并返回202响应。在这两种情况下，PA发送包含存在实体和订阅状态的即时通知消息。例如，在挂起订阅的情况下，存在实体状态可能是虚假的，表示无论存在实体的实际状态如何，都处于脱机状态。这是为了保护现有实体的隐私，他们可能不想透露他们没有为订阅者提供授权。当存在实体的状态发生变化时，PA会生成包含这些状态变化的NOTIFY，通知所有具有授权订阅的订阅者。订阅本身状态的更改也会触发NOTIFY请求；该状态在NOTIFY的Subscription state标头字段中携带，通常会指示订阅是活动的还是挂起的。
The SUBSCRIBE message establishes a "dialog" with the presence agent. A dialog is defined in RFC 3261 [1], and it represents the SIP state between a pair of entities to facilitate peer-to-peer message exchanges. This state includes the sequence numbers for messages in both directions (SUBSCRIBE from the subscriber, NOTIFY from the presence agent), in addition to a route set and remote target URI. The route set is a list of SIP (or SIPS) URIs which identify SIP proxy servers that are to be visited along the path of SUBSCRIBE refreshes or NOTIFY requests. The remote target URI is the SIP or SIPS URI that identifies the target of the message - the subscriber, in the case of NOTIFY, or the presence agent, in the case of a SUBSCRIBE refresh.
订阅消息与状态代理建立“对话”。RFC 3261[1]中定义了一个对话框，它表示一对实体之间的SIP状态，以促进对等消息交换。除了路由集和远程目标URI之外，该状态还包括双向消息的序列号（从订阅者订阅、从状态代理通知）。路由集是一个SIP（或SIPS）URI的列表，这些URI标识将沿订阅刷新或通知请求路径访问的SIP代理服务器。远程目标URI是标识消息目标的SIP或SIPS URI—在NOTIFY情况下是订阅者，在SUBSCRIBE刷新情况下是存在代理。
SIP provides a procedure called record-routing that allows for proxy servers to request to be on the path of NOTIFY messages and SUBSCRIBE refreshes. This is accomplished by inserting a URI into the Record-Route header field in the initial SUBSCRIBE request.
SIP提供了一个称为记录路由的过程，该过程允许代理服务器请求位于NOTIFY消息和订阅刷新的路径上。这是通过在初始订阅请求的记录路由头字段中插入URI来实现的。
The subscription persists for a duration that is negotiated as part of the initial SUBSCRIBE. The subscriber will need to refresh the subscription before its expiration, if they wish to retain the subscription. This is accomplished by sending a SUBSCRIBE refresh within the same dialog established by the initial SUBSCRIBE. This SUBSCRIBE is nearly identical to the initial one, but contains a tag in the To header field, a higher CSeq header field value, and possibly a set of Route header field values that identify the path of proxies the request is to take.
订阅将持续一段时间，作为初始订阅的一部分进行协商。如果订阅方希望保留订阅，则需要在订阅到期前刷新订阅。这是通过在初始订阅建立的同一对话框中发送订阅刷新来实现的。此订阅与初始订阅几乎相同，但在to标头字段中包含一个标记、一个更高的CSeq标头字段值，并且可能包含一组路由标头字段值，用于标识请求要采用的代理的路径。
The subscriber can terminate the subscription by sending a SUBSCRIBE, within the dialog, with an Expires header field (which indicates duration of the subscription) value of zero. This causes an immediate termination of the subscription. A NOTIFY request is then generated by the presence agent with the most recent state. In fact, behavior of the presence agent for handling a SUBSCRIBE request with Expires of zero is no different than for any other expiration value; pending or authorized SUBSCRIBE requests result in a triggered NOTIFY with the current presentity and subscription state.
订阅者可以通过在对话框中发送一个Expires头字段（表示订阅持续时间）值为零的订阅来终止订阅。这将导致订阅立即终止。然后，状态代理将生成具有最新状态的通知请求。事实上，状态代理处理过期为零的订阅请求的行为与任何其他过期值的行为没有什么不同；挂起或授权的订阅请求将导致触发具有当前存在实体和订阅状态的通知。
The presence agent can terminate the subscription at any time. To do so, it sends a NOTIFY request with a Subscription-State header field indicating that the subscription has been terminated. A reason parameter can be supplied which provides the reason.
状态代理可以随时终止订阅。为此，它发送一个通知请求，其中包含一个订阅状态标头字段，指示订阅已终止。可以提供一个提供原因的原因参数。
It is also possible to fetch the current presence state, resulting in a one-time notification containing the current state. This is accomplished by sending a SUBSCRIBE request with an immediate expiration.
还可以获取当前状态，从而生成包含当前状态的一次性通知。这是通过发送一个立即过期的订阅请求来实现的。
A presentity is identified in the most general way through a presence URI [3], which is of the form pres:user@domain. These URIs are resolved to protocol specific URIs, such as the SIP or SIPS URI, through domain-specific mapping policies maintained on a server.
通过呈现URI[3]以最一般的方式标识呈现实体，呈现URI的形式为pres:user@domain. 这些URI通过服务器上维护的特定于域的映射策略解析为特定于协议的URI，如SIP或SIPS URI。
It is very possible that a user will have both a SIP (and/or SIPS) URI and a pres URI to identify both themself and other users. This leads to questions about how these URI relate and which are to be used.
用户很可能同时拥有SIP（和/或SIPS）URI和pres URI来标识自己和其他用户。这导致了关于这些URI如何关联以及将使用哪些URI的问题。
In some instances, a user starts with one URI format, such as the pres URI, and learns a URI in a different format through some protocol means. As an example, a SUBSCRIBE request sent to a pres URI will result in learning a SIP or SIPS URI for the presentity from the Contact header field of the 200 OK to the SUBSCRIBE request. As another example, a DNS mechanism might be defined that would allow lookup of a pres URI to obtain a SIP or SIPS URI. In cases where one URI is learned from another through protocol means, those means will often provide some kind of scoping that limit the lifetime of the learned URI. DNS, for example, provides a TTL which would limit the scope of the URI. These scopes are very useful to avoid stale or conflicting URIs for identifying the same resource. To ensure that a user can always determine whether a learned URI is still valid, it is RECOMMENDED that systems which provide lookup services for presence URIs have some kind of scoping mechanism.
在一些实例中，用户从一种URI格式（例如presuri）开始，并通过一些协议手段学习不同格式的URI。作为示例，发送到pres URI的订阅请求将导致从200 OK的联系人报头字段到订阅请求学习存在实体的SIP或SIPS URI。作为另一个示例，可以定义允许查找pres URI以获得SIP或SIPS URI的DNS机制。在通过协议手段从另一个URI中学习一个URI的情况下，这些手段通常会提供某种范围限制学习的URI的生存期。例如，DNS提供了一个限制URI范围的TTL。这些作用域对于避免标识相同资源的过时或冲突URI非常有用。为了确保用户始终能够确定所学习的URI是否仍然有效，建议为状态URI提供查找服务的系统具有某种范围界定机制。
If a subscriber is only aware of the protocol-independent pres URI for a presentity, it follows the procedures defined in [5]. These procedures will result in the placement of the pres URI in the Request-URI of the SIP request, followed by the usage of the DNS procedures defined in [5] to determine the host to send the SIP request to. Of course, a local outbound proxy may alternatively be used, as specified in RFC 3261 [1]. If the subscriber is aware of both the protocol-independent pres URI and the SIP or SIPS URI for the same presentity, and both are valid (as discussed above) it SHOULD use the pres URI format. Of course, if the subscriber only knows the SIP URI for the presentity, that URI is used, and standard RFC 3261 processing will occur. When the pres URI is used, any proxies along the path of the SUBSCRIBE request which do not understand the URI scheme will reject the request. As such, it is expected that many systems will be initially deployed that only provide users with a SIP URI.
如果订户只知道存在实体的与协议无关的pres URI，则遵循[5]中定义的过程。这些过程将导致在SIP请求的请求URI中放置pres URI，然后使用[5]中定义的DNS过程来确定要向其发送SIP请求的主机。当然，也可以使用本地出站代理，如RFC 3261[1]中所述。如果订户知道协议独立的pres-URI和相同实体的SIP或SIPS-URI，并且两者都有效（如上所述），则应使用pres-URI格式。当然，如果订户只知道存在实体的SIP URI，则使用该URI，并且将发生标准RFC 3261处理。使用pres URI时，订阅请求路径上任何不理解URI方案的代理都将拒绝该请求。因此，预计最初将部署许多只向用户提供SIPURI的系统。
SUBSCRIBE messages also contain logical identifiers that define the originator and recipient of the subscription (the To and From header fields). These headers can take either a pres or SIP URI. When the subscriber is aware of both a pres and SIP URI for its own identity, it SHOULD use the pres URI in the From header field. Similarly, when the subscriber is aware of both a pres and a SIP URI for the desired presentity, it SHOULD use the pres URI in the To header field.
订阅消息还包含定义订阅的发起人和收件人（收件人和发件人标头字段）的逻辑标识符。这些头可以采用pres或SIPURI。当订阅者知道其自身标识的pres和SIP URI时，应该在From头字段中使用pres URI。类似地，当订户知道所需存在实体的pres和SIP URI时，它应该在To报头字段中使用pres URI。
The usage of the pres URI instead of the SIP URI within the SIP message supports interoperability through gateways to other CPP-compliant systems. It provides a protocol-independent form of identification which can be passed between systems. Without such an identity, gateways would be forced to map SIP URIs into the addressing format of other protocols. Generally, this is done by converting the SIP URI to the form <foreign-protocol-scheme>:<encoded SIP URI>@<gateway>. This is commonly done in email systems, and has many known problems. The usage of the pres URI is a SHOULD, and not a MUST, to allow for cases where it is known that there are no gateways present, or where the usage of the pres URI will cause interoperability problems with SIP components that do not support the pres URI.
在SIP消息中使用pres URI而不是SIP URI支持通过网关到其他符合CPP的系统的互操作性。它提供了一种独立于协议的标识形式，可以在系统之间传递。如果没有这样的标识，网关将被迫将SIPURI映射为其他协议的寻址格式。通常，这是通过将SIP URI转换为<foreign protocol scheme>：<encoded SIP URI>@<gateway>的形式来完成的。这通常在电子邮件系统中完成，并且存在许多已知问题。对于已知不存在网关的情况，或者使用pres URI将导致与不支持pres URI的SIP组件的互操作性问题的情况，使用pres URI是应该的，而不是必须的。
The Contact, Record-Route and Route fields do not identify logical entities, but rather concrete ones used for SIP messaging. SIP [1] specifies rules for their construction.
联系人、记录路由和路由字段不标识逻辑实体，而是标识用于SIP消息传递的具体实体。SIP[1]规定了其构造规则。
The SIP event framework [2] defines a SIP extension for subscribing to, and receiving notifications of, events. It leaves the definition of many aspects of these events to concrete extensions, known as
SIP事件框架[2]定义了用于订阅和接收事件通知的SIP扩展。它将这些事件的许多方面的定义留给具体的扩展，称为
event packages. This document qualifies as an event package. This section fills in the information required for all event packages by RFC 3265 [2].
事件包。此文档符合事件包的条件。本节填写RFC 3265[2]要求的所有事件包的信息。
The name of this package is "presence". As specified in RFC 3265 [2], this value appears in the Event header field present in SUBSCRIBE and NOTIFY requests.
此包的名称为“存在”。如RFC 3265[2]所述，此值出现在订阅和通知请求中的事件头字段中。
Example:
例子：
Event: presence
活动：出席
The SIP event framework allows event packages to define additional parameters carried in the Event header field. This package, presence, does not define any additional parameters.
SIP事件框架允许事件包定义事件头字段中携带的其他参数。此包presence不定义任何其他参数。
A SUBSCRIBE request MAY contain a body. The purpose of the body depends on its type. Subscriptions will normally not contain bodies.
订阅请求可能包含一个正文。主体的用途取决于其类型。订阅通常不包含正文。
The Request-URI, which identifies the presentity, combined with the event package name, is sufficient for presence.
标识存在实体的请求URI与事件包名称相结合，足以表示存在。
One type of body that can be included in a SUBSCRIBE request is a filter document. These filters request that only certain presence events generate notifications, or would ask for a restriction on the set of data returned in NOTIFY requests. For example, a presence filter might specify that the notifications should only be generated when the status of the user's instant inbox [10] changes. It might also say that the content of these notifications should only contain the status of the instant inbox. Filter documents are not specified in this document, and at the time of writing, are expected to be the subject of future standardization activity.
可以包含在订阅请求中的一种主体类型是筛选文档。这些筛选器请求仅某些状态事件生成通知，或者请求对NOTIFY请求中返回的数据集进行限制。例如，状态筛选器可能指定仅当用户的即时收件箱[10]的状态更改时才生成通知。它还可以说，这些通知的内容应该只包含即时收件箱的状态。本文件未规定过滤文件，在编写本文件时，过滤文件预计将成为未来标准化活动的主题。
Honoring of these filters is at the policy discretion of the PA.
这些过滤器的遵守由PA的政策决定。
If the SUBSCRIBE request does not contain a filter, this tells the PA that no filter is to be applied. The PA SHOULD send NOTIFY requests at the discretion of its own policy.
如果订阅请求不包含筛选器，这将告诉PA不应用筛选器。PA应自行决定发送通知请求。
User presence changes as a result of many events. Some examples are:
许多事件都会导致用户状态发生变化。例如：
o Turning on and off of a cell phone
o 打开和关闭手机
o Modifying the registration from a softphone
o 从软电话修改注册
o Changing the status on an instant messaging tool
o 更改即时消息工具的状态
These events are usually triggered by human intervention, and occur with a frequency on the order of seconds to hours. As such, subscriptions should have an expiration in the middle of this range, which is roughly one hour. Therefore, the default expiration time for subscriptions within this package is 3600 seconds. As per RFC 3265 [2], the subscriber MAY specify an alternate expiration in the Expires header field.
这些事件通常由人为干预触发，发生频率为秒到小时。因此，订阅应该在这个范围的中间有一个有效期，大约是一个小时。因此，此包中订阅的默认过期时间为3600秒。根据RFC 3265[2]，订阅者可以在Expires标头字段中指定替代到期。
As described in RFC 3265 [2], the NOTIFY message will contain bodies that describe the state of the subscribed resource. This body is in a format listed in the Accept header field of the SUBSCRIBE, or a package-specific default if the Accept header field was omitted from the SUBSCRIBE.
如RFC 3265[2]所述，NOTIFY消息将包含描述订阅资源状态的主体。此正文采用订阅的Accept header字段中列出的格式，如果订阅中省略了Accept header字段，则为特定于包的默认格式。
In this event package, the body of the notification contains a presence document. This document describes the presence of the presentity that was subscribed to. All subscribers and notifiers MUST support the "application/pidf+xml" presence data format described in [6]. The subscribe request MAY contain an Accept header field. If no such header field is present, it has a default value of "application/pidf+xml". If the header field is present, it MUST include "application/pidf+xml", and MAY include any other types capable of representing user presence.
在此事件包中，通知正文包含状态文档。本文档描述了所订阅的实体的存在。所有订阅者和通知者必须支持[6]中所述的“应用程序/pidf+xml”状态数据格式。订阅请求可能包含接受标头字段。如果不存在这样的头字段，则其默认值为“application/pidf+xml”。如果存在标题字段，则它必须包括“application/pidf+xml”，并且可以包括能够表示用户存在的任何其他类型。
Based on the proxy routing procedures defined in the SIP specification, the SUBSCRIBE request will arrive at a presence agent (PA). This subsection defines package-specific processing at the PA of a SUBSCRIBE request. General processing rules for requests are covered in Section 8.2 of RFC 3261 [1], in addition to general SUBSCRIBE processing in RFC 3265 [2].
根据SIP规范中定义的代理路由过程，订阅请求将到达存在代理（PA）。本小节定义了订阅请求PA处的包特定处理。除了RFC 3265[2]中的一般订阅处理外，RFC 3261[1]第8.2节还介绍了请求的一般处理规则。
User presence is highly sensitive information. Because the implications of divulging presence information can be severe, strong requirements are imposed on the PA regarding subscription processing, especially related to authentication and authorization.
用户状态是高度敏感的信息。由于泄露状态信息的影响可能非常严重，因此对PA在订阅处理方面提出了严格的要求，尤其是与身份验证和授权相关的要求。
A presence agent MUST authenticate all subscription requests. This authentication can be done using any of the mechanisms defined in RFC 3261 [1]. Note that digest is mandatory to implement, as specified in RFC 3261.
状态代理必须验证所有订阅请求。可以使用RFC 3261[1]中定义的任何机制进行身份验证。请注意，按照RFC 3261的规定，摘要是必须实现的。
In single-domain systems, where the subscribers all have shared secrets with the PA, the combination of digest authentication over Transport Layer Security (TLS) [7] provides a secure and workable solution for authentication. This use case is described in Section 26.3.2.1 of RFC 3261 [1].
在单域系统中，订阅者都与PA共享秘密，传输层安全（TLS）上的摘要认证组合[7]为认证提供了安全可行的解决方案。RFC 3261[1]第26.3.2.1节描述了该用例。
In inter-domain scenarios, establishing an authenticated identity of the subscriber is harder. It is anticipated that authentication will often be established through transitive trust. SIP mechanisms for network asserted identity can be applied to establish the identity of the subscriber [11].
在域间场景中，更难建立订户的身份验证。预计身份验证通常会通过可传递信任建立。网络断言身份的SIP机制可用于建立订户的身份[11]。
A presentity MAY choose to represent itself with a SIPS URI. By "represent itself", it means that the user represented by the presentity hands out, on business cards, web pages, and so on, a SIPS URI for their presentity. The semantics associated with this URI, as described in RFC 3261 [1], require TLS usage on each hop between the subscriber and the server in the domain of the URI. This provides additional assurances (but no absolute guarantees) that identity has been verified at each hop.
存在实体可以选择用SIPS URI表示自己。“表示自身”是指由实体表示的用户在名片、网页等上为其实体提供SIPS URI。如RFC 3261[1]中所述，与此URI相关联的语义要求在URI域中订户和服务器之间的每个跃点上使用TLS。这提供了额外的保证（但没有绝对保证），即身份已在每个跃点得到验证。
Another mechanism for authentication is S/MIME. Its usage with SIP is described fully in RFC 3261 [1]. It provides an end-to-end authentication mechanism that can be used for a PA to establish the identity of the subscriber.
另一种身份验证机制是S/MIME。RFC 3261[1]中对其与SIP的用法进行了详细描述。它提供端到端认证机制，可用于PA建立订户的身份。
Once authenticated, the PA makes an authorization decision. A PA MUST NOT accept a subscription unless authorization has been provided by the presentity. The means by which authorization are provided are outside the scope of this document. Authorization may have been provided ahead of time through access lists, perhaps specified in a web page. Authorization may have been provided by means of uploading of some kind of standardized access control list document. Back end authorization servers, such as a DIAMETER [12] server, can also be
一旦认证，PA将做出授权决定。除非存在实体提供授权，否则PA不得接受认购。提供授权的方式不在本文件范围内。授权可能通过访问列表提前提供，可能在网页中指定。授权可能通过上传某种标准化访问控制列表文件的方式提供。后端授权服务器，如DIAMETER[12]服务器，也可以
used. It is also useful to be able to query the user for authorization following the receipt of a subscription request for which no authorization information has been provided. The "watcherinfo" event template package for SIP [8] defines a means by which a presentity can become aware that a user has attempted to subscribe to it, so that it can then provide an authorization decision.
习惯于在收到未提供授权信息的订阅请求后，能够查询用户的授权也是很有用的。SIP[8]的“watcherinfo”事件模板包定义了一种方式，通过该方式，实体可以意识到用户试图订阅它，从而可以提供授权决策。
Authorization decisions can be very complex. Ultimately, all authorization decisions can be mapped into one of three states: rejected, successful, and pending. Any subscription for which the client is authorized to receive information about some subset of presence state at some points in time is a successful subscription. Any subscription for which the client will never receive any information about any subset of the presence state is a rejected subscription. Any subscription for which it is not yet known whether it is successful or rejected is pending. Generally, a pending subscription occurs when the server cannot obtain authorization at the time of the subscription, but may be able to do so at a later time, perhaps when the presentity becomes available.
授权决策可能非常复杂。最终，所有授权决策都可以映射到三种状态之一：拒绝、成功和挂起。客户机被授权在某些时间点接收关于状态状态子集的信息的任何订阅都是成功的订阅。客户端将永远不会收到关于状态状态的任何子集的任何信息的任何订阅都是被拒绝的订阅。任何尚不知道其成功与否的订阅都处于挂起状态。通常，当服务器在订阅时无法获得授权，但可能能够在稍后时间（可能是当存在实体变得可用时）获得授权时，将发生挂起的订阅。
The appropriate response codes for conveying a successful, rejected, or pending subscription (200, 403 or 603, and 202, respectively) are described in RFC 3265 [2].
RFC 3265[2]中描述了用于传达成功、拒绝或待决订阅（分别为200、403或603和202）的适当响应代码。
If the resource is not in a meaningful state, RFC 3265 [2] allows the body of the initial NOTIFY to be empty. In the case of presence, that NOTIFY MAY contain a presence document. This document would indicate whatever presence state the subscriber has been authorized to see; it is interpreted by the subscriber as the current presence state of the presentity. For pending subscriptions, the state of the presentity SHOULD include some kind of textual note that indicates a pending status.
如果资源未处于有意义的状态，RFC 3265[2]允许初始通知的正文为空。在出席的情况下，该通知可能包含出席文件。本文件将说明订户被授权查看的任何状态；订户将其解释为存在实体的当前存在状态。对于挂起的订阅，存在实体的状态应该包括某种文本注释，用于指示挂起状态。
Polite blocking, as described in [13], is possible by generating a 200 OK to the subscription even though it has been rejected (or marked pending). Of course, an immediate NOTIFY will still be sent. The contents of the presence document in such a NOTIFY are at the discretion of the implementor, but SHOULD be constructed in such a way as to not reveal to the subscriber that their request has actually been blocked. Typically, this is done by indicating "offline" or equivalent status for a single contact address.
如[13]中所述，即使订阅已被拒绝（或标记为挂起），也可以通过对订阅生成200 OK来进行礼貌阻止。当然，仍将发送即时通知。此类通知中存在文档的内容由实施者自行决定，但其构造方式应确保不会向订阅者透露其请求实际上已被阻止。通常，这是通过为单个联系人地址指示“脱机”或等效状态来完成的。
RFC 3265 details the formatting and structure of NOTIFY messages. However, packages are mandated to provide detailed information on when to send a NOTIFY, how to compute the state of the resource, how
RFC 3265详细说明了NOTIFY消息的格式和结构。但是，包必须提供关于何时发送通知、如何计算资源状态以及如何发送通知的详细信息
to generate neutral or fake state information, and whether state information is complete or partial. This section describes those details for the presence event package.
生成中性或伪状态信息，以及状态信息是否完整或部分。本节介绍状态事件包的详细信息。
A PA MAY send a NOTIFY at any time. Typically, it will send one when the state of the presentity changes. The NOTIFY request MAY contain a body indicating the state of the presentity. The times at which the NOTIFY is sent for a particular subscriber, and the contents of the body within that notification, are subject to any rules specified by the authorization policy that governs the subscription. This protocol in no way limits the scope of such policies. As a baseline, a reasonable policy is to generate notifications when the state of any of the presence tuples changes. These notifications would contain the complete and current presence state of the presentity as known to the presence agent. Future extensions can be defined that allow a subscriber to request that the notifications contain changes in presence information only, rather than complete state.
PA可随时发送通知。通常，当存在实体的状态改变时，它会发送一个。通知请求可以包含指示存在实体状态的主体。为特定订阅者发送通知的时间以及该通知中正文的内容受管理订阅的授权策略指定的任何规则的约束。本协议绝不限制此类政策的范围。作为基线，合理的策略是在任何状态元组的状态发生变化时生成通知。这些通知将包含存在代理已知的存在实体的完整和当前存在状态。可以定义未来的扩展，允许订阅者请求通知仅包含状态信息的更改，而不包含完整状态的更改。
In the case of a pending subscription, when final authorization is determined, a NOTIFY can be sent. If the result of the authorization decision was success, a NOTIFY SHOULD be sent and SHOULD contain a presence document with the current state of the presentity. If the subscription is rejected, a NOTIFY MAY be sent. As described in RFC 3265 [2], the Subscription-State header field indicates the state of the subscription.
对于挂起的订阅，当确定最终授权时，可以发送通知。如果授权决定的结果是成功的，则应发送一份通知，并应包含一份具有存在实体当前状态的存在文档。如果订阅被拒绝，则可能会发送通知。如RFC 3265[2]所述，订阅状态标头字段指示订阅的状态。
The body of the NOTIFY MUST be sent using one of the types listed in the Accept header field in the most recent SUBSCRIBE request, or using the type "application/pidf+xml" if no Accept header field was present.
必须使用最新订阅请求中Accept header字段中列出的类型之一发送通知正文，或者如果不存在Accept header字段，则使用类型“application/pidf+xml”。
The means by which the PA learns the state of the presentity are also outside the scope of this recommendation. Registrations can provide a component of the presentity state. However, the means by which a PA uses registrations to construct a presence document are an implementation choice. If a PUA wishes to explicitly inform the presence agent of its presence state, it should explicitly publish the presence document (or its piece of it) rather than attempting to manipulate their registrations to achieve the desired result.
PA了解实体状态的方法也不在本建议的范围内。注册可以提供实体状态的一个组成部分。然而，PA使用注册来构造呈现文档的方式是一种实现选择。如果PUA希望明确告知在线状态代理其在线状态，则应明确发布在线状态文档（或其中的一部分），而不是试图操纵其注册以实现预期结果。
For reasons of privacy, it will frequently be necessary to encrypt the contents of the notifications. This can be accomplished using S/MIME. The encryption can be performed using the key of the subscriber as identified in the From field of the SUBSCRIBE request. Similarly, integrity of the notifications is important to subscribers. As such, the contents of the notifications MAY provide authentication and message integrity using S/MIME. Since the NOTIFY is generated by the presence server, which may not have access to the
出于隐私考虑，通常需要加密通知的内容。这可以使用S/MIME实现。可以使用订阅请求的From字段中标识的订阅方密钥执行加密。类似地，通知的完整性对订阅者也很重要。因此，通知的内容可以使用S/MIME提供认证和消息完整性。因为通知是由状态服务器生成的，它可能无法访问
key of the user represented by the presentity, it will frequently be the case that the NOTIFY is signed by a third party. It is RECOMMENDED that the signature be by an authority over the domain of the presentity. In other words, for a user pres:user@example.com, the signator of the NOTIFY SHOULD be the authority for example.com.
由存在实体表示的用户密钥，通常情况下，通知由第三方签署。建议由实体所在领域的权威机构签署。换句话说，对于用户pres：user@example.com，通知的签署人应为权威机构，例如：example.com。
RFC 3265 [2] leaves it to event packages to describe the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state.
RFC 3265[2]让事件包来描述订阅者在收到通知请求后遵循的过程，包括形成一致资源状态所需的任何逻辑。
In this specification, each NOTIFY contains either no presence document, or a document representing the complete and coherent state of the presentity. Within a dialog, the presence document in the NOTIFY request with the highest CSeq header field value is the current one. When no document is present in that NOTIFY, the presence document present in the NOTIFY with the next highest CSeq value is used. Extensions which specify the use of partial state for presentities will need to dictate how coherent state is achieved.
在本规范中，每个通知要么不包含存在文档，要么包含表示存在实体的完整和一致状态的文档。在对话框中，通知请求中CSeq头字段值最高的状态文档是当前文档。当该通知中不存在文档时，将使用下一个最高CSeq值的通知中存在的状态文档。指定对存在实体使用部分态的扩展将需要规定如何实现相干态。
RFC 3265 [2] requires each package to describe handling of forked SUBSCRIBE requests.
RFC 3265[2]要求每个包描述分叉订阅请求的处理。
This specification only allows a single dialog to be constructed as a result of emitting an initial SUBSCRIBE request. This guarantees that only a single PA is generating notifications for a particular subscription to a particular presentity. The result of this is that a presentity can have multiple PAs active, but these should be homogeneous, so that each can generate the same set of notifications for the presentity. Supporting heterogeneous PAs, each of which generates notifications for a subset of the presence data, is complex and difficult to manage. Doing so would require the subscriber to act as the aggregator for presence data. This aggregation function can only reasonably be performed by agents representing the presentity. Therefore, if aggregation is needed, it MUST be done in a PA representing the presentity.
此规范仅允许在发出初始订阅请求后构造单个对话框。这保证只有一个PA为特定实体的特定订阅生成通知。这样做的结果是，一个实体可以有多个激活的PA，但这些PA应该是同质的，以便每个PA都可以为该实体生成相同的通知集。支持异构PAs（每个PAs都会为状态数据的子集生成通知）是复杂且难以管理的。这样做需要订户充当状态数据的聚合器。这种聚合功能只能由代表存在实体的代理合理地执行。因此，如果需要聚合，则必须在表示存在实体的PA中进行聚合。
Section 4.4.9 of RFC 3265 [2] describes the processing that is required to guarantee the creation of a single dialog in response to a SUBSCRIBE request.
RFC 3265[2]第4.4.9节描述了保证响应订阅请求创建单个对话框所需的处理。
RFC 3265 [2] requires each package to specify the maximum rate at which notifications can be sent.
RFC 3265[2]要求每个包指定可以发送通知的最大速率。
A PA SHOULD NOT generate notifications for a single presentity at a rate of more than once every five seconds.
PA不应以每五秒钟超过一次的速率为单个实体生成通知。
RFC 3265 [2] requires each package to consider the role of state agents in the package, and if they are used, to specify how authentication and authorization are done.
RFC 3265（2）要求每个包考虑包中的状态代理的作用，并且如果使用这些代理，则指定如何进行身份验证和授权。
State agents are core to this package. Whenever the PA is not co-located with the PUA for the presentity, the PA is acting as a state agent. It collects presence state from the PUA, and aggregates it into a presence document. Because there can be multiple PUA, a centralized state agent is needed to perform this aggregation. That is why state agents are fundamental to presence. Indeed, they have a specific term that describes them - a presence server.
州代理是这个包的核心。当PA与PUA不在同一地点时，PA将充当国家代理人。它从PUA收集状态信息，并将其聚合到状态文档中。因为可以有多个PUA，所以需要一个集中式状态代理来执行此聚合。这就是为什么国家代理人是存在的基础。事实上，它们有一个特定的术语来描述它们——状态服务器。
The means by which aggregation is done in the state agent is purely a matter of policy. The policy will typically combine the desires of the presentity along with the desires of the provider. This document in no way restricts the set of policies which may be applied.
在状态代理中进行聚合的方法纯粹是一个策略问题。该政策通常将存在实体的愿望与提供者的愿望结合起来。本文件不限制可能应用的策略集。
However, there is clearly a need for the state agent to have access to the state of the presentity. This state is manipulated by the PUA. One way in which the state agent can obtain this state is to subscribe to it. As a result, if there were 5 PUA manipulating presence state for a single presentity, the state agent would generate 5 subscriptions, one to each PUA. For this mechanism to be effective, all PUA SHOULD be capable of acting as a PA for the state that they manipulate, and that they authorize subscriptions that can be authenticated as coming from the domain of the presentity.
然而，国家代理人显然需要进入存在实体的状态。该状态由PUA控制。状态代理获取此状态的一种方法是订阅它。因此，如果有5个PUA操纵单个presence实体的presence状态，则状态代理将生成5个订阅，每个PUA一个订阅。为了使该机制有效，所有PUA都应该能够充当它们所操纵状态的PA，并且它们授权可以验证为来自存在实体域的订阅。
The usage of state agents does not significantly alter the way in which authentication is done by the PA. Any of the SIP authentication mechanisms can be used by a state agent. However, digest authentication will require the state agent to be aware of the shared secret between the presentity and the subscriber. This will require some means to securely transfer the shared secrets from the presentity to the state agent.
状态代理的使用不会显著改变PA进行身份验证的方式。状态代理可以使用任何SIP身份验证机制。然而，摘要认证将要求状态代理知道存在实体和订阅者之间的共享秘密。这将需要某种方法将共享机密从实体安全地转移到国家机构。
The usage of state agents does, however, have a significant impact on authorization. As stated in Section 6.6, a PA is required to authorize all subscriptions. If no explicit authorization policy has been defined, the PA will need to query the user for authorization. In a presence edge server (where the PUA is co-located with the PUA), this is trivially accomplished. However, when state agents are used (i.e., a presence server), a means is needed to alert the user that an authorization decision is required. This is the reason for the watcherinfo event template-package [8]. All state agents SHOULD support the watcherinfo template-package.
然而，状态代理的使用确实对授权有重大影响。如第6.6节所述，PA需要授权所有认购。如果未定义明确的授权策略，PA将需要查询用户以获得授权。在状态边缘服务器（其中PUA与PUA位于同一位置）中，这是很容易实现的。然而，当使用状态代理（即，存在服务器）时，需要一种方法来提醒用户需要授权决策。这就是watcherinfo事件模板包[8]的原因。所有状态代理都应支持watcherinfo模板包。
On occasion, it makes sense for the PA function to migrate from one server to another. For example, for reasons of scale, the PA function may reside in the presence server when the PUA is not running, but when the PUA connects to the network, the PA migrates subscriptions to it in order to reduce state in the network. The mechanism for accomplishing the migration is described in Section 3.3.5 of RFC 3265 [2]. However, packages need to define under what conditions such a migration would take place.
有时，PA功能从一台服务器迁移到另一台服务器是有意义的。例如，出于规模的原因，当PUA未运行时，PA功能可能驻留在状态服务器中，但当PUA连接到网络时，PA将订阅迁移到该服务器以减少网络中的状态。RFC 3265[2]第3.3.5节描述了完成迁移的机制。但是，包需要定义在什么条件下会发生这种迁移。
A PA MAY choose to migrate subscriptions at any time, through configuration, or through dynamic means. The REGISTER request provides one dynamic means for a presence server to discover that the function can migrate to a PUA. Specifically, if a PUA wishes to indicate support for the PA function, it SHOULD use the callee capabilities specification [9] to indicate that it supports the SUBSCRIBE request method and the presence event package. The combination of these two define a PA. Of course, a presence server can always attempt a migration without these explicit hints. If it fails with either a 405 or 489 response code, the server knows that the PUA does not support the PA function. In this case, the server itself will need to act as a PA for that subscription request. Once such a failure has occurred, the server SHOULD NOT attempt further migrations to that PUA for the duration of its registration. However, to avoid the extra traffic generated by these failed requests, a presence server SHOULD support the callee capabilities extension.
PA可以选择随时通过配置或动态方式迁移订阅。注册请求为状态服务器提供了一种动态方法，以发现功能可以迁移到PUA。具体地说，如果PUA希望表示支持PA功能，它应该使用被调用方能力规范[9]来表示它支持订阅请求方法和存在事件包。这两者的结合定义了PA。当然，状态服务器总是可以在没有这些明确提示的情况下尝试迁移。如果出现405或489响应代码故障，则服务器知道PUA不支持PA功能。在这种情况下，服务器本身需要充当该订阅请求的PA。一旦发生此类故障，服务器在注册期间不应尝试进一步迁移到该PUA。但是，为了避免这些失败请求产生的额外流量，状态服务器应该支持被叫方功能扩展。
Furthermore, indication of support for the SUBSCRIBE request and the presence event package is not sufficient for migration of subscriptions. A PA SHOULD NOT migrate the subscription if it is composing aggregated presence documents received from multiple PUA.
此外，指示对订阅请求和存在事件包的支持不足以迁移订阅。如果PA正在编写从多个PUA接收的聚合状态文档，则不应迁移订阅。
Presence information can be obtained by the PA in many ways. No specific mechanism is mandated by this specification. This section overviews some of the options, for informational purposes only.
PA可以通过多种方式获得存在信息。本规范未规定任何特定机制。本节概述了一些选项，仅供参考。
When the PA function is co-located with the PUA, presence is known directly by the PA.
当PA功能与PUA位于同一位置时，PA直接知道是否存在。
A UA uses the SIP REGISTER method to inform the SIP network of its current communications addresses (i.e., Contact addresses). Multiple UA can independently register Contact addresses for the same address-of-record. This registration state represents an important piece of the overall presence information for a presentity. It is an indication of basic reachability for communications.
UA使用SIP注册方法通知SIP网络其当前通信地址（即联系人地址）。多个UA可以为同一记录地址独立注册联系人地址。该注册状态表示存在实体的整体存在信息的重要部分。它表示通信的基本可达性。
Usage of REGISTER information to construct presence is only possible if the PA has access to the registration database, and can be informed of changes to that database. One way to accomplish that is to co-locate the PA with the registrar.
只有当PA可以访问注册数据库，并且可以被告知该数据库的更改时，才能使用注册信息来构建存在。实现这一点的一种方法是将PA与注册官放在同一地点。
The means by which registration state is converted into presence state is a matter of local policy, and beyond the scope of this specification. However, some general guidelines can be provided. The address-of-record in the registration (the To header field) identifies the presentity. Each registered Contact header field identifies a point of communications for that presentity, which can be modeled using a tuple. Note that the contact address in the tuple need not be the same as the registered contact address. Using an address-of-record instead allows subsequent communications from a watcher to pass through proxies. This is useful for policy processing on behalf of the presentity and the provider.
注册状态转换为存在状态的方式是本地策略的问题，超出了本规范的范围。但是，可以提供一些一般性指南。注册中的记录地址（收件人标题字段）标识存在实体。每个已注册联系人头字段标识该实体的通信点，可以使用元组对其进行建模。请注意，元组中的联系人地址不必与注册的联系人地址相同。相反，使用记录地址允许来自观察者的后续通信通过代理。这对于代表实体和提供者进行策略处理非常有用。
A PUA that uses registrations to manipulate presence state SHOULD make use of the SIP callee capabilities extension [9]. This allows the PUA to provide the PA with richer information about itself. For example, the presence of the methods parameter listing the method "MESSAGE" indicates support for instant messaging.
使用注册操作存在状态的PUA应使用SIP被叫方功能扩展[9]。这允许PUA向PA提供更丰富的自身信息。例如，列出方法“MESSAGE”的methods参数表示支持即时消息传递。
The q values from the Contact header field [1] can be used to establish relative priorities amongst the various communications addresses in the Contact header fields.
来自联系人报头字段[1]的q值可用于在联系人报头字段中的各种通信地址之间建立相对优先级。
The usage of registrations to obtain presence information increases the requirements for authenticity and integrity of registrations. Therefore, REGISTER requests used by presence user agents MUST be authenticated.
使用注册获取状态信息增加了对注册真实性和完整性的要求。因此，状态用户代理使用的注册请求必须经过身份验证。
If a means exists to upload presence documents from PUA to the PA, the PA can act as an aggregator and redistributor of those documents. The PA, in this case, would take the presence documents received from each PUA for the same presentity, and merge the tuples across all of those PUA into a single presence document. Typically, this aggregation would be accomplished through administrator or user defined policies about how the aggregation should be done.
如果存在将状态文档从PUA上传到PA的方法，PA可以充当这些文档的聚合器和重新分发器。在这种情况下，PA将获取从每个PUA接收的相同呈现实体的呈现文档，并将所有这些PUA中的元组合并到单个呈现文档中。通常，此聚合将通过管理员或用户定义的有关如何进行聚合的策略来完成。
The specific means by which a presence document is uploaded to a presence agent are outside the scope of this specification. When a PUA wishes to have direct manipulation of the presence that is distributed to subscribers, direct uploading of presence documents is RECOMMENDED.
将状态文档上载到状态代理的具体方式不在本规范的范围内。当PUA希望直接操纵分发给订阅者的状态时，建议直接上传状态文档。
This message flow illustrates how the presence server can be responsible for sending notifications for a presentity. This flow assumes that the watcher has previously been authorized to subscribe to this resource at the server.
此消息流说明了状态服务器如何负责发送状态实体的通知。此流假定观察者先前已被授权在服务器上订阅此资源。
In this flow, the PUA informs the server about the updated presence information through some non-SIP means.
在该流中，PUA通过一些非SIP手段将更新的存在信息通知服务器。
When the value of the Content-Length header field is "..." this means that the value should be whatever the computed length of the body is.
当内容长度标题字段的值为“…”时，这意味着该值应为正文的计算长度。
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
Watcher Server PUA
| F1 SUBSCRIBE | |
|------------------>| |
| F2 200 OK | |
|<------------------| |
| F3 NOTIFY | |
|<------------------| |
| F4 200 OK | |
|------------------>| |
| | |
| | Update presence |
| |<------------------ |
| | |
| F5 NOTIFY | |
|<------------------| |
| F6 200 OK | |
|------------------>| |
Message Details
消息详细信息
F1 SUBSCRIBE watcher->example.com server
F1订阅观察者->example.com服务器
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0
SUBSCRIBE sip:resource@example.com SIP/2.0
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
To: <sip:resource@example.com>
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml
Contact: <sip:user@watcherhost.example.com>
Expires: 600
Content-Length: 0
F2 200 OK example.com server->watcher
F2 200 OK example.com服务器->观察者
SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Expires: 600
Contact: sip:server.example.com
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP watcherhost.example.com;branch=z9hG4bKnashds7
;received=192.0.2.1
To: <sip:resource@example.com>;tag=ffd2
From: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Expires: 600
Contact: sip:server.example.com
Content-Length: 0
F3 NOTIFY example.com server-> watcher
F3通知example.com服务器->观察者
NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：user@watcherhost.example.comSIP/2.0 Via:SIP/2.0/TCP server.example.com；分支=z9hG4bKna998sk来自：<sip:resource@example.com>;标记=ffd2到：<sip:user@example.com>;tag=xfg9呼叫ID:2010@watcherhost.example.com事件：状态订阅状态：活动；expires=599最大转发：70 CSeq:8775通知联系人：sip:server.example.com内容类型：应用程序/pidf+xml内容长度：。。。
[PIDF Document]
[PIDF文件]
F4 200 OK watcher-> example.com server
F4 200 OK watcher->example.com服务器
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sk
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0
F5 NOTIFY example.com server -> watcher
F5通知example.com服务器->观察者
NOTIFY sip:user@watcherhost.example.com SIP/2.0 Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl From: <sip:resource@example.com>;tag=ffd2 To: <sip:user@example.com>;tag=xfg9 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=543 Max-Forwards: 70 Contact: sip:server.example.com Content-Type: application/pidf+xml Content-Length: ...
通知sip：user@watcherhost.example.comSIP/2.0 Via:SIP/2.0/TCP server.example.com；分支=z9hG4bKna998sl来自：<sip:resource@example.com>;标记=ffd2到：<sip:user@example.com>;tag=xfg9呼叫ID:2010@watcherhost.example.comCSeq:8776通知事件：状态订阅状态：活动；expires=543最大转发：70联系人：sip:server.example.com内容类型：application/pidf+xml内容长度：。。。
[New PIDF Document]
[新的PIDF文件]
F6 200 OK
F6 200正常
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;branch=z9hG4bKna998sl
;received=192.0.2.2
From: <sip:resource@example.com>;tag=ffd2
To: <sip:user@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0
There are numerous security considerations for presence. RFC 2779 [13] outlines many of them, and they are discussed above. This section considers them issue by issue.
存在许多安全考虑因素。RFC 2779[13]概述了其中的许多内容，并在上文中进行了讨论。本节逐项审议这些问题。
Confidentiality encompasses many aspects of a presence system:
保密性包括存在系统的许多方面：
o Subscribers may not want to reveal the fact that they have subscribed to certain users
o 订阅者可能不想透露他们已经订阅了某些用户的事实
o Users may not want to reveal that they have accepted subscriptions from certain users
o 用户可能不想透露他们已经接受了某些用户的订阅
o Notifications (and fetch results) may contain sensitive data which should not be revealed to anyone but the subscriber
o 通知（和获取结果）可能包含敏感数据，这些数据不应透露给除订户以外的任何人
Confidentiality is provided through a combination of hop-by-hop encryption and end-to-end encryption. The hop-by-hop mechanisms provide scalable confidentiality services, disable attacks involving traffic analysis, and hide all aspects of presence messages. However, they operate based on transitivity of trust, and they cause message content to be revealed to proxies. The end-to-end mechanisms do not require transitivity of trust, and reveal information only to the desired recipient. However, end-to-end encryption cannot hide all information, and is susceptible to traffic analysis. Strong end-to-end authentication and encryption can be done using public keys, and end-to-end encryption can be done using private keys [14]. Both hop-by-hop and end-to-end mechanisms will likely be needed for complete privacy services.
通过逐跳加密和端到端加密的组合提供机密性。逐跳机制提供可扩展的保密服务，禁用涉及流量分析的攻击，并隐藏状态消息的所有方面。然而，它们基于信任的传递性进行操作，并导致消息内容向代理显示。端到端机制不需要信任的传递性，只向所需的接收者透露信息。但是，端到端加密无法隐藏所有信息，并且容易受到流量分析的影响。强端到端身份验证和加密可以使用公钥完成，端到端加密可以使用私钥完成[14]。完整的隐私服务可能需要逐跳和端到端机制。
SIP allows any hop by hop encryption scheme, but TLS is mandatory to implement for servers. Therefore, it is RECOMMENDED that TLS [7] be used between elements to provide this function. The details for usage of TLS for server-to-server and client-to-server security are detailed in Section 26.3.2 of RFC 3261 [1].
SIP允许任何逐跳加密方案，但必须为服务器实现TLS。因此，建议在元件之间使用TLS[7]来提供此功能。RFC 3261[1]第26.3.2节详细介绍了使用TLS实现服务器到服务器和客户端到服务器安全的详细信息。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
使用S/MIME的SIP加密可用于端到端传输订阅和通知请求。
It is important for the message recipient to ensure that the message contents are actually what was sent by the originator, and that the recipient of the message be able to determine who the originator really is. This applies to both requests and responses of SUBSCRIBE and NOTIFY. NOTIFY requests are particularly important. Without authentication and integrity, presence documents could be forged or modified, fooling the watcher into believing incorrect presence information.
邮件收件人必须确保邮件内容实际上是发端人发送的内容，并且邮件收件人能够确定发端人的真实身份。这适用于SUBSCRIBE和NOTIFY的请求和响应。通知请求尤其重要。如果没有身份验证和完整性，状态文档可能被伪造或修改，从而欺骗观察者相信不正确的状态信息。
RFC 3261 provides many mechanisms to provide these features. In order for the PA to authenticate the watcher, it MAY use HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP Digest. This is a redundant requirement, however, since all SIP user agents are mandated to support it by RFC 3261. To provide authenticity and integrity services, a watcher MAY use the SIPS scheme when subscribing to the presentity. To support this, all PA MUST support TLS and SIPS as if they were a proxy (see Section 26.3.1 of RFC 3261).
RFC3261提供了许多机制来提供这些特性。为了让PA认证观察者，它可以使用HTTP摘要（RFC 3261第22节）。因此，所有观察者都必须支持HTTP摘要。然而，这是一个冗余需求，因为RFC3261强制所有SIP用户代理支持它。为了提供真实性和完整性服务，观察者在订阅实体时可以使用SIPS方案。为了支持这一点，所有PA必须支持TLS和SIP，就像它们是代理一样（参见RFC 3261第26.3.1节）。
Furthermore, SMIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261.
此外，SMIME可用于订阅和通知请求的完整性和真实性。RFC 3261第23节对此进行了说明。
When local proxies are used for transmission of outbound messages, proxy authentication is RECOMMENDED. This is useful to verify the identity of the originator, and prevent spoofing and spamming at the originating network.
当使用本地代理传输出站消息时，建议使用代理身份验证。这有助于验证发起人的身份，并防止发起网络上的欺骗和垃圾邮件。
Replay attacks can be used by an attacker to fool a watcher into believing an outdated presence state for a presentity. For example, a document describing a presentity as being "offline" can be replayed, fooling watchers into thinking that the user is never online. This may effectively block communications with the presentity.
重播攻击可被攻击者用来欺骗观察者，使其相信存在实体的过时存在状态。例如，一个描述实体处于“离线”状态的文档可以被重放，从而愚弄观察者，让他们认为用户永远不会在线。这可以有效地阻止与存在实体的通信。
SIP S/MIME can provide message integrity and authentication over SIP request bodies. Watchers and PAs MAY implement S/MIME signatures to prevent these replay attacks. When it is used for that purpose, the presence document carried in the NOTIFY request MUST contain a timestamp. In the case of PIDF, this is accomplished using the timestamp element, as described in Section 6 of [6]. Tuples whose timestamp is older than the timestamp of the most recently received presence document SHOULD be considered stale, and discarded.
SIP S/MIME可以通过SIP请求体提供消息完整性和身份验证。观察者和PA可以实现S/MIME签名以防止这些重播攻击。当用于该目的时，NOTIFY请求中携带的状态文档必须包含时间戳。在PIDF的情况下，这是使用timestamp元素实现的，如[6]第6节所述。时间戳早于最近接收到的状态文档的时间戳的元组应被视为过时，并被丢弃。
Finally, HTTP digest authentication (which MUST be implemented by watchers and PAs) MAY be used to prevent replay attacks, when there is a shared secret between the PA and the watcher. In such a case, the watcher can challenge the NOTIFY requests with the auth-int quality of protection.
最后，当PA和观察者之间存在共享秘密时，HTTP摘要身份验证（必须由观察者和PA实现）可用于防止重播攻击。在这种情况下，观察者可以使用auth int保护质量来质询NOTIFY请求。
Denial of Service (DOS) attacks are a critical problem for an open, inter-domain, presence protocol. Unfortunately, presence is a good candidate for Distributed DoS (DDOS) attacks because of its amplification properties. A single SUBSCRIBE message could generate a nearly unending stream of notifications, so long as a suitably dynamic source of presence data can be found. Thus, a simple way to launch an attack against a target is to send subscriptions to a large number of users, and in the Contact header field (which is where notifications are sent), place the address of the target. RFC 3265 provides some mechanisms to mitigate these attacks [2]. If a NOTIFY is not acknowledged or was not wanted, the subscription that generated it is removed. This eliminates the amplification properties of providing false Contact addresses.
拒绝服务（DOS）攻击是开放域间存在协议的一个关键问题。不幸的是，由于存在的放大特性，它是分布式拒绝服务（DDOS）攻击的很好候选。只要能够找到适当的动态状态数据源，单个订阅消息就可以生成几乎无休止的通知流。因此，对目标发起攻击的一种简单方法是向大量用户发送订阅，并在联系人标头字段（发送通知的位置）中放置目标地址。RFC 3265提供了一些机制来缓解这些攻击[2]。如果未确认或不需要通知，则会删除生成通知的订阅。这消除了提供虚假联系地址的放大特性。
Authentication and authorization at the PA can also prevent these attacks. Typically, authorization policy will not allow subscriptions from unknown watchers. If the attacks are launched from watchers unknown to the presentity (a common case), the attacks are mitigated.
PA的身份验证和授权也可以防止这些攻击。通常，授权策略不允许来自未知观察者的订阅。如果攻击是由存在实体未知的观察者发起的（一种常见情况），则会减轻攻击。
Denial of service attacks can also be launched against a presence agent itself, in order to disrupt service to a community of users. SIP itself, along with RFC 3265 [2], describes several mechanisms to mitigate these attacks.
还可以针对状态代理本身发起拒绝服务攻击，以中断对用户社区的服务。SIP本身以及RFC 3265[2]描述了几种缓解这些攻击的机制。
A server can prevent SYN-attack style attacks through a four-way handshake using digest authentication [1]. Even if the server does not have a shared secret with the client, it can verify the source IP address of the request using the "anonymous" user mechanism described in Section 22.1 of RFC 3261 [1]. SIP also allows a server to instruct a client to back-off from sending it requests, using the 503 response code (Section 21.5.4 of RFC 3261 [1]). This can be used to fend off floods of SUBSCRIBE requests launched as a result of a distributed denial of service attack.
服务器可以通过使用摘要身份验证的四向握手来防止SYN攻击类型的攻击[1]。即使服务器没有与客户端共享的秘密，它也可以使用RFC 3261[1]第22.1节中描述的“匿名”用户机制验证请求的源IP地址。SIP还允许服务器使用503响应代码（RFC 3261[1]第21.5.4节）指示客户端停止向其发送请求。这可用于抵御由于分布式拒绝服务攻击而引发的大量订阅请求。
This specification registers an event package, based on the registration procedures defined in RFC 3265 [2]. The following is the information required for such a registration:
本规范根据RFC 3265[2]中定义的注册过程注册事件包。以下是此类注册所需的信息：
Package Name: presence
包裹名称：存在
Package or Template-Package: This is a package.
包或模板包：这是一个包。
Published Document: RFC 3856
出版文件：RFC3856
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
联系人：Jonathan Rosenberg，jdrosen@jdrosen.net.
The following individuals were part of the initial team that worked through the technical design of this specification:
以下人员是完成本规范技术设计的初始团队的一部分：
Jonathan Lennox Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
乔纳森·伦诺克斯哥伦比亚大学M/S 0401 1214，纽约州纽约市阿姆斯特丹大道，邮编10027-7003
EMail: lennox@cs.columbia.edu
EMail: lennox@cs.columbia.edu
Robert Sparks dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
罗伯特·斯帕克斯动力软件5100丁尼生公园路1200号套房，德克萨斯州普莱诺75024
EMail: rsparks@dynamicsoft.com
EMail: rsparks@dynamicsoft.com
Ben Campbell
班·坎贝尔
EMail: ben@nostrum.com
EMail: ben@nostrum.com
Dean Willis dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024
Dean Willis dynamicsoft 5100丁尼生公园路1200号套房，德克萨斯州普莱诺75024
EMail: dwillis@dynamicsoft.com
EMail: dwillis@dynamicsoft.com
Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003
亨宁·舒尔兹林内哥伦比亚大学M/S 0401 1214纽约州纽约市阿姆斯特丹大道10027-7003
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
Christian Huitema微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399
伯纳德·阿博巴（Bernard Aboba）微软公司华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: bernarda@microsoft.com
EMail: bernarda@microsoft.com
David Gurle Reuters Corporation
大卫·古尔路透社公司
EMail: David.Gurle@reuters.com
EMail: David.Gurle@reuters.com
David Oran Cisco Systems 170 West Tasman Dr. San Jose, CA 95134
David Oran Cisco Systems 170西塔斯曼加利福尼亚州圣何塞博士，邮编95134
EMail: oran@cisco.com
EMail: oran@cisco.com
We would like to thank Rick Workman, Adam Roach, Sean Olson, Billy Biggs, Stuart Barkley, Mauricio Arango, Richard Shockey, Jorgen Bjorkner, Henry Sinnreich, Ronald Akers, Paul Kyzivat, Ya-Ching Tan, Patrik Faltstrom, Allison Mankin and Hisham Khartabil for their comments and support of this specification.
我们要感谢Rick Workman、Adam Roach、Sean Olson、Billy Biggs、Stuart Barkley、Mauricio Arango、Richard Shockey、Jorgen Bjorkner、Henry Sinnreich、Ronald Akers、Paul Kyzivat、Ya Ching Tan、Patrik Faltstrom、Allison Mankin和Hisham Khartabil对本规范的评论和支持。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, H., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，H.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[2] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[3] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[3] 彼得森，J.，“在场的共同概况（CPP）”，RFC 3859，2004年8月。
[4] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[5] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[5] Peterson，J.，“即时消息和状态的地址解析”，RFC 38612004年8月。
[6] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[6] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[7] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.
[7] Dierks，T.和C.Allen，“TLS协议1.0版”，RFC 2246，1999年1月。
[8] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[8] Rosenberg，J.，“会话启动协议（SIP）的观察者信息事件模板包”，RFC3857，2004年8月。
[9] Schulzrinne, H. Rosenberg, J., and P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, August 2004.
[9] Schulzrinne，H.Rosenberg，J.和P.Kyzivat，“指出会话启动协议（SIP）中的用户代理功能”，RFC3840，2004年8月。
[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] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", Work in Progress, May 2004.
[11] Peterson，J.，“会话启动协议（SIP）中身份验证管理的增强”，正在进行的工作，2004年5月。
[12] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.
[12] Calhoun，P.，Loughney，J.，Guttman，E.，Zorn，G.，和J.Arkko，“直径基础协议”，RFC 3588，2003年9月。
[13] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[13] Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息传递/存在协议要求”，RFC 2779，2000年2月。
[14] Gutmann, P., "Password-Based Encryption for CMS", RFC 3211, December 2001.
[14] Gutmann，P.，“基于密码的CMS加密”，RFC 321112001年12月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Jonathan Rosenberg dynamicsoft 600新泽西州帕西帕尼拉尼德斯广场07054
EMail: jdrosen@dynamicsoft.com
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。