Network Working Group M. Lonnfors
Request for Comments: 5263 J. Costa-Requena
Category: Standards Track E. Leppanen
Nokia
H. Khartabil
Ericsson
September 2008
Network Working Group M. Lonnfors
Request for Comments: 5263 J. Costa-Requena
Category: Standards Track E. Leppanen
Nokia
H. Khartabil
Ericsson
September 2008
Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information
会话启动协议（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）。本备忘录的分发不受限制。
Abstract
摘要
By default, presence delivered using the presence event package for the Session Initiation Protocol (SIP) is represented in the Presence Information Data Format (PIDF). A PIDF document contains a set of elements, each representing a different aspect of the presence being reported. When any subset of the elements change, even just a single element, a new document containing the full set of elements is delivered. This memo defines an extension allowing delivery of only the presence data that has actually changed.
默认情况下，使用会话启动协议（SIP）的状态事件包交付的状态以状态信息数据格式（PIDF）表示。PIDF文档包含一组元素，每个元素表示所报告状态的不同方面。当元素的任何子集发生更改时，即使只是一个元素，也会交付一个包含完整元素集的新文档。此备忘录定义了一个扩展，只允许传递实际更改的状态数据。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to the Partial Notification Mechanism . . . . . . 3
3.1. Basic Presence Agent Operation . . . . . . . . . . . . . . 3
3.2. Operation with Partial Notification . . . . . . . . . . . 3
4. Client and Server Operations . . . . . . . . . . . . . . . . . 4
4.1. Content-Type for Partial Notifications . . . . . . . . . . 4
4.2. Watcher Generation of SUBSCRIBE Requests . . . . . . . . . 4
4.3. Presence Agent Processing of SUBSCRIBE Requests . . . . . 4
4.4. Presence Agent Generation of Partial Notifications . . . . 5
4.5. Watcher Processing of NOTIFY Requests . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Introduction to the Partial Notification Mechanism . . . . . . 3
3.1. Basic Presence Agent Operation . . . . . . . . . . . . . . 3
3.2. Operation with Partial Notification . . . . . . . . . . . 3
4. Client and Server Operations . . . . . . . . . . . . . . . . . 4
4.1. Content-Type for Partial Notifications . . . . . . . . . . 4
4.2. Watcher Generation of SUBSCRIBE Requests . . . . . . . . . 4
4.3. Presence Agent Processing of SUBSCRIBE Requests . . . . . 4
4.4. Presence Agent Generation of Partial Notifications . . . . 5
4.5. Watcher Processing of NOTIFY Requests . . . . . . . . . . 6
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
A presence event package for Session Initiation Protocol (SIP) [3] allows users ('watchers') to subscribe to other users' ('presentities') presence information. The presence information is composed of multiple pieces of data that are delivered to the watcher. The size of the presence information document can be large (i.e., the presence document can contain an arbitrary number of elements called presence tuples that convey data). As specified in RFC 2778 [9] and the presence event package for SIP [3], a Presence Agent (PA) always delivers in presence notifications all the presence data that has been authorized for a certain watcher. This is done regardless of what presence data has changed compared to last notification. It may not be reasonable to send the complete presence information over low bandwidth and high latency links when only part of the presence information has actually changed. This may end up degrading the presence service and causing bad perception at the watcher side.
会话启动协议（SIP）[3]的存在事件包允许用户（“观察者”）订阅其他用户（“存在实体”）的存在信息。状态信息由多个数据段组成，这些数据段被传递给观察者。存在信息文档的大小可以很大（即，存在文档可以包含任意数量的称为表示数据的存在元组的元素）。正如RFC 2778[9]和SIP[3]的状态事件包中所规定的，状态代理（PA）始终在状态通知中传递已授权给特定观察者的所有状态数据。无论与上次通知相比状态数据发生了什么变化，都会执行此操作。当仅存在信息的一部分实际改变时，通过低带宽和高延迟链路发送完整的存在信息可能是不合理的。这可能会导致状态服务降级，并在观察者端造成不良感知。
This document defines a partial notification approach where the presence server delivers to the watchers only those parts of the presence information that have changed compared to the presence information sent in the previous notifications. This reduces the amount of data that is transported over the network.
本文档定义了一种部分通知方法，其中状态服务器仅向观察者提供与先前通知中发送的状态信息相比已更改的状态信息部分。这减少了通过网络传输的数据量。
This mechanism utilizes the presence event package for SIP [3] and a new MIME type for carrying partial Presence Information Data Format documents [2].
该机制利用SIP[3]的状态事件包和一种新的MIME类型来承载部分状态信息数据格式文档[2]。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and indicate requirement levels for compliant implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[1]中所述进行解释，并指出符合性实施的要求级别。
This document makes use of the vocabulary defined in RFC 2778 [9], RFC 3265 [6], the presence event package for SIP [3], and the PIDF extension for Partial Presence [2].
本文档使用了RFC 2778[9]、RFC 3265[6]中定义的词汇表、SIP[3]的状态事件包以及部分状态的PIDF扩展[2]。
This chapter briefly introduces the regular functionality of the presence service, and gives an overview of the partial notification solution. This section is informational in nature. It does not contain any normative statements.
本章简要介绍状态信息服务的常规功能，并概述部分通知解决方案。本节内容仅供参考。它不包含任何规范性声明。
The presence service normally operates so that a watcher sends a SIP SUBSCRIBE request targeted to the presentity. The request is routed to the presence agent where the presentity's presence information is stored. The SUBSCRIBE request can include an Accept header field that indicates the supported content types.
存在服务通常运行，以便观察者向存在实体发送SIP订阅请求。请求被路由到存在实体的存在信息存储的存在代理。SUBSCRIBE请求可以包括一个Accept标头字段，该字段指示支持的内容类型。
The presence agent receives the SUBSCRIBE request and if there is no Accept header indicating the supported content types or the Accept header contains the default PIDF content type, the PA will generate presence notifications using the default PIDF format [5]. The PIDF document can contain one or multiple XML elements. The PIDF document includes a set of elements defined in RFC 2778 [9], and its extensions for representing the presence information. This PIDF document will be carried in the body of a NOTIFY request constructed as per RFC 3265 [6]. During basic operation, the presence document always contains the full state corresponding to the presence status of the presentity, as determined by the PA local policy and authorization rules.
状态代理接收订阅请求，如果没有表示支持的内容类型的Accept标头，或者Accept标头包含默认的PIDF内容类型，PA将使用默认的PIDF格式生成状态通知[5]。PIDF文档可以包含一个或多个XML元素。PIDF文档包括RFC 2778[9]中定义的一组元素及其表示状态信息的扩展。本PIDF文件将包含在根据RFC 3265[6]构建的通知请求正文中。在基本操作期间，存在文档始终包含与存在实体的存在状态相对应的完整状态，由PA本地策略和授权规则确定。
The partial notification mechanism allows a watcher to request that, whenever possible, notifications contain only presence information that has actually changed. A watcher that wants to receive partial notifications according to this document, creates a SIP SUBSCRIBE request similar to that of a regular presence subscription. However, the SIP SUBSCRIBE request contains an Accept header field whose value
部分通知机制允许观察者请求，只要可能，通知只包含实际更改的状态信息。希望根据本文档接收部分通知的观察者将创建一个类似于常规状态订阅的SIP订阅请求。但是，SIP SUBSCRIBE请求包含一个Accept头字段，其值为
contains the "application/pidf-diff+xml" tag as well as the "application/pidf+xml" tag.
包含“application/pidf diff+xml”标记以及“application/pidf+xml”标记。
When the presence agent receives the subscription, it examines the Accept header field value and if the "application/pidf-diff+xml" value is present, it can decide to use the partial notifications mechanism specified in this memo. The presence agent builds NOTIFY requests that contain the Content-Type header field set to "application/pidf-diff+xml". The first NOTIFY request that contains presence information will contain a full presence document. Subsequent NOTIFY requests can contain partial presence documents. This behavior is described in detail in Section 4.
当状态代理收到订阅时，它检查Accept header字段值，如果存在“application/pidf diff+xml”值，它可以决定使用此备忘录中指定的部分通知机制。状态代理生成包含设置为“application/pidf diff+xml”的Content-Type头字段的NOTIFY请求。包含状态信息的第一个通知请求将包含完整的状态文档。后续通知请求可以包含部分状态文档。第4节详细描述了这种行为。
Unless otherwise specified in this document, the regular watcher and presence agent behavior is applied as defined in the SIP presence event package [3].
除非本文档中另有规定，否则按照SIP状态事件包[3]中的定义应用常规观察者和状态代理行为。
Entities supporting the partial notification extension described in this document MUST support the 'application/pidf-diff+xml' content type specified in the PIDF extension for partial presence [2].
支持本文档中描述的部分通知扩展的实体必须支持部分存在的pidf扩展中指定的“application/pidf diff+xml”内容类型[2]。
A SUBSCRIBE request can be used to negotiate the preferred content type to be used in the notifications. The Accept header field is used for this purpose as specified in RFC 3261 [4]. When a watcher wants to allow the presence agent to send partial notifications the watcher MUST include an Accept header field in its SUBSCRIBE request. The value of the Accept header field MUST contain 'application/ pidf-diff+xml' (in addition to 'application/pidf+xml' required by the SIP presence event package [3]). The watcher MAY include a "q" parameter with each Accept value to indicate the relative preference of that value.
订阅请求可用于协商通知中使用的首选内容类型。按照RFC 3261[4]中的规定，Accept header字段用于此目的。当观察者希望允许状态代理发送部分通知时，观察者必须在其订阅请求中包含Accept标头字段。Accept header字段的值必须包含“application/pidf diff+xml”（除了SIP presence事件包[3]所需的“application/pidf+xml”）。观察者可以包括带有每个接受值的“q”参数，以指示该值的相对偏好。
The presence agent receives subscriptions from watchers and generates notifications according to the SIP presence event package [3]. If the watcher has indicated the supported content types in the Accept header field of the SUBSCRIBE request, the presence agent compares the values included in the Accept header field with the supported ones, and decides which one to use. If the watcher has indicated preferred accept values by means of "q" parameters, the presence
状态代理从观察者接收订阅，并根据SIP状态事件包生成通知[3]。如果观察者在订阅请求的Accept header字段中指示了受支持的内容类型，则presence agent会将Accept header字段中包含的值与受支持的值进行比较，并决定使用哪个值。如果观察者已通过“q”参数指示首选接受值，则存在
agent SHOULD base the decision on those preferences, unless otherwise indicated by the presence agent local policy.
代理应根据这些首选项做出决定，除非状态代理本地策略另有指示。
Once a subscription is accepted and installed, the PA MUST deliver the full state of the presence information in the first partial notification that contains a presence document having <pidf-full> root element. If the presence agent decides to send notifications that include a presence document according to this specification, the presence agent MUST build a presence document according to the PIDF extension for Partial Presence [2] and MUST set the Content-Type header field to the value 'application/pidf-diff+xml'.
一旦接受并安装了订阅，PA必须在包含根元素为<pidf full>的状态文档的第一个部分通知中传递状态信息的完整状态。如果状态代理决定根据本规范发送包含状态文档的通知，则状态代理必须根据部分状态的PIDF扩展构建状态文档[2]，并且必须将内容类型头字段设置为值“application/PIDF diff+xml”。
When using the 'application/pidf-diff+xml' MIME type, the PA MUST include a "version" attribute; for the first partial notification (within a given subscription), the PA MUST initialize version to value one (1). This version counter is scoped to the subscription, and is incremented by one within each partial notification. The version value is only reset when the given subscription is terminated. It is not reset when the subscription is refreshed.
当使用'application/pidf diff+xml'MIME类型时，PA必须包含一个“version”属性；对于第一个部分通知（在给定订阅内），PA必须将版本初始化为值1（1）。此版本计数器的作用域为订阅，并在每个部分通知中递增1。版本值仅在给定订阅终止时重置。在刷新订阅时不会重置它。
When the PA generates a partial presence document, the PA SHOULD include only that presence information that has changed compared to the previous notifications. It is up to the PA's local policy to determine what is considered as a change to the previous state.
当PA生成部分状态文档时，PA应仅包括与先前通知相比已更改的状态信息。由巴勒斯坦权力机构的当地政策来决定什么是对前一州的改变。
The PA MUST construct the partial presence document according to the following logic:
PA必须根据以下逻辑构建部分在场文件：
o The PA MUST construct the presence information according to the PIDF extension for Partial Presence [2]. All the information that has been added to the presence document is listed inside <add> elements. All information that has been removed from the presence document is listed inside <remove> elements, and all information that has been changed is listed under <replace> elements.
o PA必须根据部分存在的PIDF扩展构造存在信息[2]。添加到状态文档中的所有信息都列在<add>元素中。已从状态文档中删除的所有信息都列在<remove>元素中，已更改的所有信息都列在<replace>元素下。
o The PA MUST include a "version" attribute in the presence document. The PA MUST increment the version number by one compared to the earlier successfully sent presence document in the PIDF extension for Partial Presence [2] format to the watcher associated with a certain subscription.
o PA必须在状态文档中包含“版本”属性。PA必须将版本号增加一个，与先前以PIDF扩展成功发送给与特定订阅相关的观察者的部分存在[2]格式的存在文档相比。
The PA MUST NOT send a new NOTIFY request that contains a partial notification for the same Request-URI until it has received a final response from the watcher for the previous one or the previous NOTIFY request has timed out.
PA不得发送包含同一请求URI的部分通知的新通知请求，直到收到来自观察者的上一个通知请求的最终响应或上一个通知请求超时。
When the PA receives a SUBSCRIBE request (refresh or termination) within the associated subscription, it SHOULD send a NOTIFY request containing the full presence document.
当PA在相关订阅中收到订阅请求（刷新或终止）时，它应发送包含完整状态文档的通知请求。
If the PA has used other than the 'application/pidf-diff+xml' content type in notifications within the existing subscription, and changes to deliver partial notifications, the PA MUST deliver the full state of the presence information containing a presence document having <pidf-full> root element as the first partial notification.
如果PA在现有订阅的通知中使用了除“application/pidf diff+xml”内容类型之外的其他内容类型，并更改为传递部分通知，则PA必须传递状态信息的完整状态，其中包含作为第一部分通知的根元素为<pidf full>的状态文档。
Watcher processes all NOTIFY requests that contain 'application/ pidf+xml' content type as specified in RFC 3856 [3].
观察者处理所有包含RFC 3856[3]中指定的“应用程序/pidf+xml”内容类型的NOTIFY请求。
When the watcher receives the first notification containing the 'application/pidf-diff+xml' MIME body the watcher MUST initialize an internal version counter, related to this subscription, to the value of the "version" included in the presence document. This version counter is scoped to the subscription. The watcher MUST also store the received full presence document as its local copy.
当观察者收到第一个包含“application/pidf diff+xml”MIME正文的通知时，观察者必须将与此订阅相关的内部版本计数器初始化为状态文档中包含的“version”值。此版本计数器的作用域为订阅。观察者还必须将收到的完整状态文档存储为其本地副本。
When the watcher receives a subsequent 'application/pidf-diff+xml' encoded presence document the watcher MUST compare the received "version" attribute with the local version counter. If the watcher receives a presence document with the "version" attribute value equal or lower than the locally stored version number, it is considered a PA failure, and the watcher SHOULD discard the document without further processing. Otherwise, the watcher MUST modify its locally stored information according to the following logic:
当观察者收到后续的“应用程序/pidf diff+xml”编码的状态文档时，观察者必须将收到的“版本”属性与本地版本计数器进行比较。如果观察者接收到“版本”属性值等于或低于本地存储版本号的状态文档，则视为PA故障，观察者应丢弃该文档，无需进一步处理。否则，观察者必须根据以下逻辑修改其本地存储的信息：
o If the root element of the presence document is <pidf-full>, the watcher must replace its local copy of the presence document with the presence document received in the 'application/pidf-diff+xml' body and set the internal version value to the value of the "version" attribute included in the presence document.
o 如果状态文档的根元素为<pidf full>，则观察者必须将其状态文档的本地副本替换为在“应用程序/pidf diff+xml”正文中接收到的状态文档，并将内部版本值设置为状态文档中包含的“版本”属性的值。
o If the root element of the presence document is <pidf-diff> and the received version number is incremented by one compared with the local version counter, the watcher MUST apply the changes to its local copy of the full presence document indicated in the received 'application/pidf-diff+xml' document as specified in PIDF extension for Partial Presence [2]. The watcher MUST increment the local version counter by one.
o 如果状态文档的根元素是<pidf diff>，并且接收到的版本号与本地版本计数器相比增加1，观察者必须按照pidf扩展部分存在[2]中的规定，将更改应用于接收到的“应用程序/pidf diff+xml”文档中指示的完整存在文档的本地副本。观察者必须将本地版本计数器增加1。
o If the root element of the presence document is <pidf-diff> and the received "version" value is higher by more than one compared with the locally stored value, the watcher assumes that one or more NOTIFYs were lost. The watcher SHOULD either refresh the subscription in order to receive a full presence document or terminate the subscription.
o 如果状态文档的根元素是<pidf diff>，并且接收到的“version”值比本地存储的值高出一个以上，则观察者认为一个或多个notify丢失。观察者应刷新订阅以接收完整状态文档，或终止订阅。
If the watcher encounters a processing error while processing the received 'application/pidf-diff+xml' encoded presence document, look at Section 5.1 of [8]. In this case, the watcher SHOULD renew the subscription. The watcher MAY also fall back to normal presence operations by not inserting 'application/pidf-diff+xml' in a new SUBSCRIBE request. It is hardly reasonable to signal this error to the notifier even if the error exists in the notifier process.
如果观察者在处理收到的“应用程序/pidf diff+xml”编码的状态文档时遇到处理错误，请参阅[8]的第5.1节。在这种情况下，观察者应该续订。观察者也可以通过在新的订阅请求中不插入“application/pidf diff+xml”而退回到正常的状态操作。即使通知程序进程中存在错误，也很难将此错误通知通知通知程序。
If the PA changes the content type used in notifications within the existing subscription, the watcher MUST discard all the previously received presence information (except local version counter) from that particular presentity and process the new content as specified for that content type. The local version counter MUST NOT be discarded because if the PA changes back to 'application/ pidf-diff+xml', the MIME type version counter will continue to increase from the last version value.
如果PA更改了现有订阅中通知中使用的内容类型，则观察者必须放弃该特定存在实体先前接收到的所有存在信息（本地版本计数器除外），并按照为该内容类型指定的方式处理新内容。不能丢弃本地版本计数器，因为如果PA更改回“application/pidf diff+xml”，MIME类型的版本计数器将从上一个版本值继续增加。
The following message flow shows an example applying the partial notifications mechanism.
下面的消息流显示了应用部分通知机制的示例。
A watcher sends a SUBSCRIBE request declaring support for the default presence format ('application/pidf+xml) and for the partial notification format ('application/pidf-diff+xml') in the Accept header field value. The watcher uses the "q" parameter to set the preference for receiving partial notifications. The PA accepts the subscription and, based on the "q" parameter value, selects to send partial notifications in NOTIFY requests. The first NOTIFY request includes the full state of presence information. The following notifications only include information about delta of the presence information from the previous NOTIFY requests.
观察者发送一个订阅请求，声明支持Accept header字段值中的默认状态格式（“应用程序/pidf+xml”）和部分通知格式（“应用程序/pidf diff+xml”）。观察者使用“q”参数设置接收部分通知的首选项。PA接受订阅，并根据“q”参数值选择在NOTIFY请求中发送部分通知。第一个通知请求包括完整的存在状态信息。以下通知仅包括有关先前NOTIFY请求中状态信息增量的信息。
Watcher Presence Agent PUA
| F1 SUBSCRIBE | |
|-------------------------->| |
| F2 200 OK | |
|<--------------------------| |
| F3 NOTIFY | |
|<--------------------------| |
| F4 200 OK | |
|-------------------------->| |
| | |
| | Update presence |
| |<----------------------- |
| | |
| F5 NOTIFY | |
|<--------------------------| |
| F6 200 OK | |
|-------------------------->| |
Watcher Presence Agent 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:watcher@example.com> ;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml;q=0.3,
application/pidf-diff+xml;q=1
Contact: <sip:user@watcherhost.example.com>
Expires: 3600
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:watcher@example.com> ;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Max-Forwards: 70
Event: presence
Accept: application/pidf+xml;q=0.3,
application/pidf-diff+xml;q=1
Contact: <sip:user@watcherhost.example.com>
Expires: 3600
Content-Length: 0
The PA accepts the subscription and generates a 200 OK response to the SUBSCRIBE request
PA接受订阅并对订阅请求生成200 OK响应
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:watcher@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Event: presence
Expires: 3600
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:watcher@example.com>;tag=xfg9
Call-ID: 2010@watcherhost.example.com
CSeq: 17766 SUBSCRIBE
Event: presence
Expires: 3600
Contact: <sip:server.example.com>
Content-Length: 0
The PA, based on the "q" parameter value in the Accept header of the SUBSCRIBE request (F1), decides to use partial notifications. The PA creates the first NOTIFY request that includes the full presence document.
PA根据订阅请求（F1）的Accept头中的“q”参数值决定使用部分通知。PA创建第一个包含完整状态文档的通知请求。
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 To: <sip:watcher@example.com>;tag=xfg9 From: <sip:resource@example.com>;tag=ffd2 Call-ID: 2010@watcherhost.example.com Event: presence Subscription-State: active;expires=3599 Max-Forwards: 70 CSeq: 8775 NOTIFY Contact: <sip:server.example.com> Content-Type: application/pidf-diff+xml Content-Length: ...
通知sip：user@watcherhost.example.comSIP/2.0 Via:SIP/2.0/TCP server.example.com；分支=z9hG4bKna998sk至：<sip:watcher@example.com>;tag=xfg9 From:<sip:resource@example.com>;tag=ffd2呼叫ID:2010@watcherhost.example.com事件：状态订阅状态：活动；expires=3599最大转发：70 CSeq:8775通知联系人：<sip:server.example.com>内容类型：应用程序/pidf diff+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cp="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="sip:resource@example.com"
version="1">
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-full xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:c="urn:ietf:params:xml:ns:pidf:caps"
xmlns:cp="urn:ietf:params:xml:ns:pidf:cipid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="sip:resource@example.com"
version="1">
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:video>false</c:video>
<c:message>true</c:message>
</c:servcaps>
<r:relationship><r:assistant/></r:relationship>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="sg89ae">
<status>
<basic>open</basic>
</status>
<c:servcaps>
<c:audio>true</c:audio>
<c:video>false</c:video>
<c:message>true</c:message>
</c:servcaps>
<r:relationship><r:assistant/></r:relationship>
<contact priority="0.8">tel:09012345678</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">im:res@example.com</contact>
</tuple>
<tuple id="cg231jcr">
<status>
<basic>open</basic>
</status>
<contact priority="1.0">im:res@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>closed</basic>
</status>
<cp:homepage>http://example.com/~res/</cp:homepage>
<cp:icon>http://example.com/~res/icon.gif</cp:icon>
<cp:card>http://example.com/~res/card.vcd</cp:card>
<contact priority="0.9">sip:resource@example.com</contact>
</tuple>
<tuple id="r1230d">
<status>
<basic>closed</basic>
</status>
<cp:homepage>http://example.com/~res/</cp:homepage>
<cp:icon>http://example.com/~res/icon.gif</cp:icon>
<cp:card>http://example.com/~res/card.vcd</cp:card>
<contact priority="0.9">sip:resource@example.com</contact>
</tuple>
<note xml:lang="en">Full state presence document</note>
<note xml:lang="en">Full state presence document</note>
<dm:person id="fdkfj">
<r:activities>
<r:on-the-phone/>
<r:busy/>
</r:activities>
</dm:person>
<dm:person id="fdkfj">
<r:activities>
<r:on-the-phone/>
<r:busy/>
</r:activities>
</dm:person>
<dm:device id="u00b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>mac:xxx</dm:deviceID>
</dm:device>
<dm:device id="u00b40c7">
<c:devcaps>
<c:mobility>
<c:supported>
<c:mobile/>
</c:supported>
</c:mobility>
</c:devcaps>
<dm:deviceID>mac:xxx</dm:deviceID>
</dm:device>
</p:pidf-full>
</p:pidf-full>
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
To: <sip:watcher@example.com>;tag=xfg9
From: <sip:resource@example.com>;tag=ffd2
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
To: <sip:watcher@example.com>;tag=xfg9
From: <sip:resource@example.com>;tag=ffd2
Call-ID: 2010@watcherhost.example.com
CSeq: 8775 NOTIFY
Content-Length: 0
At a later time, the presentity's presence information changes. The PA generates a NOTIFY request that includes information about the changes.
稍后，存在实体的存在信息会发生变化。PA生成一个通知请求，其中包括有关更改的信息。
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 To: <sip:watcher@example.com>;tag=xfg9 From: <sip:resource@example.com>;tag=ffd2 Call-ID: 2010@watcherhost.example.com CSeq: 8776 NOTIFY Event: presence Subscription-State: active;expires=3543 Max-Forwards: 70 Contact: <sip:server.example.com> Content-Type: application/pidf-diff+xml Content-Length: ...
通知sip：user@watcherhost.example.comSIP/2.0 Via:SIP/2.0/TCP server.example.com；分支=z9hG4bKna998sl至：<sip:watcher@example.com>;tag=xfg9 From:<sip:resource@example.com>;tag=ffd2呼叫ID:2010@watcherhost.example.comCSeq:8776通知事件：状态订阅状态：活动；expires=3543最大转发：70联系人：<sip:server.example.com>内容类型：应用程序/pidf diff+xml内容长度：。。。
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="sip:resource@example.com"
version="2">
<?xml version="1.0" encoding="UTF-8"?>
<p:pidf-diff xmlns="urn:ietf:params:xml:ns:pidf"
xmlns:p="urn:ietf:params:xml:ns:pidf-diff"
xmlns:r="urn:ietf:params:xml:ns:pidf:rpid"
xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model"
entity="sip:resource@example.com"
version="2">
<p:add sel="presence/note" pos="before"><tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:res@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and note element</note>
</tuple>
<p:add sel="presence/note" pos="before"><tuple id="ert4773">
<status>
<basic>open</basic>
</status>
<contact priority="0.4">mailto:res@example.com</contact>
<note xml:lang="en">This is a new tuple inserted
between the last tuple and note element</note>
</tuple>
</p:add>
</p:add>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
<p:remove sel="*/dm:person/r:activities/r:busy"/>
<p:remove sel="*/dm:person/r:activities/r:busy"/>
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
</p:pidf-diff>
</p:pidf-diff>
F6 200 OK watcher-> example.com server
F6 200 OK watcher->example.com服务器
SIP/2.0 200 OK
Via: SIP/2.0/TCP server.example.com;
branch=z9hG4bKna998sl
;received=192.0.2.2
To: <sip:watcher@example.com>;tag=xfg9
From: <sip:resource@example.com>;tag=ffd2
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
To: <sip:watcher@example.com>;tag=xfg9
From: <sip:resource@example.com>;tag=ffd2
Call-ID: 2010@watcherhost.example.com
CSeq: 8776 NOTIFY
Content-Length: 0
This specification relies on the presence event package for SIP [3]. Partial notifications can reveal information about what has changed compared to the previous notification. This can make it easier for an eavesdropper to know what kind of changes are happening in the presentity's presence information. However, the same information can be found if the presence event package is used with baseline PIDF [5].
本规范依赖于SIP[3]的状态事件包。部分通知可以显示与先前通知相比发生了哪些更改的信息。这可以让窃听者更容易知道存在实体的存在信息发生了什么样的变化。但是，如果存在事件包与基线PIDF一起使用，则可以找到相同的信息[5]。
A third party can inject a NOTIFY request with partial state that will cause the watcher to think it has missed a partial notification and to request a new full presence document. This is no worse than what we have without this extension since a party that could perform such action could also send a NOTIFY with Subscription-State: terminated and achieve the same effect without knowing about the extension. Partial Notification does not make the situation any worse, and the protection mechanisms from the existing system apply to preventing this attack against the partial notification mechanism.
第三方可以将NOTIFY请求注入部分状态，这将导致观察者认为它错过了部分通知，并请求新的完整状态文档。这并不比没有此扩展的情况更糟糕，因为可以执行此操作的一方也可以发送订阅状态为“已终止”的通知，并在不知道扩展的情况下实现相同的效果。部分通知不会使情况变得更糟，现有系统的保护机制适用于防止针对部分通知机制的攻击。
Presence-related security considerations are extensively discussed in the presence event package for SIP [3] and all those identified security considerations apply to this document as well. Issues described in the presence event package for SIP [3], including confidentiality, message integrity and authenticity, outbound authentication, replay prevention, Denial-of-Service (DoS) attacks against thirst parties and DoS attacks against servers all apply here without any change.
SIP[3]的状态事件包中广泛讨论了与状态相关的安全注意事项，所有确定的安全注意事项也适用于本文档。SIP[3]的状态事件包中描述的问题，包括机密性、消息完整性和真实性、出站身份验证、重播预防、针对第三方的拒绝服务（DoS）攻击和针对服务器的DoS攻击，均适用于此处，无需任何更改。
It is RECOMMENDED that TLS [7] be used between elements to provide hop-by-hop confidentially protection. Furthermore, S/MIME MAY be used for integrity and authenticity of SUBSCRIBE and NOTIFY requests. This is described in Section 23 of RFC 3261.
建议在元件之间使用TLS[7]，以提供逐跳保密保护。此外，S/MIME可用于订阅和通知请求的完整性和真实性。RFC 3261第23节对此进行了说明。
The authors would like to thank Jari Urpalainen, Jyrki Aarnos, Jonathan Rosenberg, Dean Willis, Kriztian Kiss, Juha Kalliokulju, Miguel Garcia, Anders Kristensen, Yannis Pavlidis, Ben Cambell, Robert Sparks, and Tim Moran for their valuable comments.
作者要感谢贾里·厄帕莱宁、杰尔基·奥诺斯、乔纳森·罗森博格、迪安·威利斯、克里兹坦·基斯、朱哈·卡利奥库尔朱、米格尔·加西亚、安德斯·克里斯滕森、亚尼斯·帕夫利迪斯、本·坎贝尔、罗伯特·斯帕克斯和蒂姆·莫兰的宝贵评论。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Lonnfors, M., Khartabil, H., Leppanen, E., and J. Urpalainen, "Presence Information Data Format (PIDF) Extension for Partial Presence", RFC 5262, August 008.
[2] Lonnfors，M.，Khartabil，H.，Leppanen，E.，和J.Urpalainen，“局部存在的存在信息数据格式（PIDF）扩展”，RFC 5262008年8月。
[3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[3] Rosenberg，J.，“会话启动协议（SIP）的状态事件包”，RFC3856，2004年8月。
[4] 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.
[4] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[5] Sugano, H., Fujimoto, S., Klyne, G., Bateman, A., Carr, W., and J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004.
[5] Sugano，H.，Fujimoto，S.，Klyne，G.，Batman，A.，Carr，W.，和J.Peterson，“状态信息数据格式（PIDF）”，RFC 38632004年8月。
[6] Roach, A., "SIP-Specific Event Notification", RFC 3265, June 2002.
[6] Roach，A.，“SIP特定事件通知”，RFC 3265，2002年6月。
[7] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[7] Dierks，T.和E.Rescorla，“TLS协议版本1.1”，RFC 4346，2006年4月。
[8] Urpalainen, J., "An Extensible Markup Language (XML) Patch Operations Framework Utilizing XML Path Language (XPath) Selectors", RFC 5261, September 2008.
[8] Urpalainen，J.，“利用XML路径语言（XPath）选择器的可扩展标记语言（XML）修补程序操作框架”，RFC 5261，2008年9月。
[9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[9] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
Authors' Addresses
作者地址
Mikko Lonnfors Nokia P.O. Box 321 Helsinki Finland
芬兰赫尔辛基诺基亚邮政信箱321号Mikko Lonnfors
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 Helsinki Finland
Jose Costa Requena诺基亚邮政信箱321芬兰赫尔辛基
Phone: +358 71 8008000
EMail: jose.costa-requena@nokia.com
Phone: +358 71 8008000
EMail: jose.costa-requena@nokia.com
Eva Leppanen Nokia Lempaala Finland
Eva Leppanen诺基亚兰帕拉芬兰
EMail: eva.leppanen@saunalahti.fi
EMail: eva.leppanen@saunalahti.fi
Hisham Khartabil Ericsson Melbourne Australia
澳大利亚墨尔本希沙姆哈塔比尔爱立信酒店
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.