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
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
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].
このメカニズムは、[3] SIPのプレゼンスイベントパッケージを利用して、部分的プレゼンス情報データ形式の文書を運ぶための新しい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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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要求を送信するようにプレゼンスサービスが正常に動作します。要求は、プレゼンティティのプレゼンス情報が格納されているプレゼンスエージェントにルーティングされます。 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.
プレゼンス・エージェントは、SUBSCRIBEリクエストを受信していないし、存在する場合はデフォルトPIDF形式を使用して、PAは、プレゼンス通知を生成するサポートされているコンテンツの種類を示すヘッダを受け入れるか、受け入れヘッダがデフォルトPIDFコンテンツタイプが含まれている[5]。 PIDFドキュメントは、一つまたは複数のXML要素を含むことができます。 PIDF文書[9] RFC 2778で定義された要素の組を含み、プレゼンス情報を表すためにその拡張。このPIDF文書は、RFC 3265に従って構成されたNOTIFYリクエストのボディに実施される[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 contains the "application/pidf-diff+xml" tag as well as the "application/pidf+xml" tag.
部分的な通知メカニズムは、可能な限り、通知が実際に変更されただけのプレゼンス情報を含む要求に対するウォッチャが可能になります。この文書によると、部分的に通知を受け取りたいウォッチャーは、SIPは、通常のプレゼンスサブスクリプションと同様のSUBSCRIBEリクエストを作成します。しかし、SIPリクエストは、その値が「アプリケーション/ PIDF-差分+ XML」タグならびに「アプリケーション/ PIDF + XML」タグを含むAcceptヘッダーフィールドを含むSUBSCRIBE。
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.
プレゼンス・エージェントは、サブスクリプションを受信すると、ヘッダフィールド値を受け入れ、「アプリケーション/ PIDF-差分+ XML」の値が存在する場合、それはこのメモで指定された部分的な通知メカニズムを使用することを決定することができる調べ。プレゼンスエージェントは、「アプリケーション/ PIDF-デフ+ XML」に設定Content-Typeヘッダフィールドが含まれているNOTIFYリクエストを構築します。最初の完全なプレゼンスドキュメントが含まれていますプレゼンス情報を含む要求を通知します。それ以降の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].
この文書に記載され、部分的通知拡張をサポートするエンティティは、[2]の部分的存在のPIDF拡張で指定された「アプリケーション/ PIDF-差分+ XMLのコンテンツ・タイプをサポートしなければなりません。
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.
SUBSCRIBEリクエストは、通知に使用される好適なコンテンツタイプを交渉するために使用することができます。 RFC 3261で指定されるようにAcceptヘッダーフィールドは、この目的のために使用されている[4]。ウォッチャーは、部分的に通知ウォッチャーを送信するためにプレゼンスエージェントを許可したい場合には、そのSUBSCRIBEリクエストにAcceptヘッダーフィールドを含まなければなりません。 Acceptヘッダーフィールドの値が「アプリケーション/ PIDF-差分+ XML」を含まなければなりません（SIPプレゼンス・イベント・パッケージで必要とされる「アプリケーション/ PIDF + XML」に加えて、[3]）。各々がその値の相対的な優先度を示す値を受け入れるとウォッチャは「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 agent SHOULD base the decision on those preferences, unless otherwise indicated by the presence agent local policy.
プレゼンス・エージェントは、SIPプレゼンス・イベント・パッケージ[3]に記載のウォッチャーからサブスクリプションを受信し、通知を生成します。ウォッチャは、SUBSCRIBEリクエストのAcceptヘッダーフィールドでサポートされているコンテンツの種類を示している場合、プレゼンス・エージェントがサポートされているものとAcceptヘッダーフィールドに含まれる値を比較し、使用するかを決定します。ウォッチャは、「Q」のパラメータを用いて値を受け入れる好ましい示している場合そうでない場合、プレゼンスエージェント、ローカルポリシーによって示されない限り、プレゼンスエージェントは、それらの選好の決定の基礎べきです。
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フル>ルート要素を有するプレゼンスドキュメントを含む第1の部分に通知するプレゼンス情報の完全な状態を提供しなければなりません。プレゼンス・エージェントは、この仕様に応じてプレゼンス文書を含む通知を送信することを決定した場合、プレゼンス・エージェントは、[2]は部分的存在についてPIDF拡張に応じてプレゼンス文書を構築する必要があり、その値 'にContent-Typeヘッダフィールドを設定しなければなりませんアプリケーション/ 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.
「アプリケーション/ PIDF-diffの+ xmlの」MIMEタイプを使用している場合、PAは、「バージョン」の属性を含まなければなりません。 （所与のサブスクリプション内の）第1の部分の通知のために、PAは、一つの評価にバージョンを初期化しなければならない（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は前回の通知と比較して変化しているだけでプレゼンス情報を含むべきです。これは、以前の状態への変化と考えられているかを決定するために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 [2]は部分的存在についてPIDF拡張に応じてプレゼンス情報を構成しなければなりません。プレゼンス文書に追加されたすべての情報は、要素の<add>の内側に記載されています。プレゼンス文書から削除されているすべての情報は、<削除>要素の内側に記載されていて、変更されたすべての情報は、要素<置き換え>の下に表示されます。
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は、特定のサブスクリプションに関連付けられているウォッチャにプレゼンス部分[2]フォーマットのPIDF拡張における以前正常に送信されたプレゼンス文書と比較して、1つによりバージョン番号をインクリメントしなければなりません。
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は、それがタイムアウトした前の1またはNOTIFY以前の要求に対するウォッチャからの最終的な応答を受信するまで、同じ要求URIのための部分的な通知を含む新しいNOTIFYリクエストを送ってはいけません。
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は、関連するサブスクリプション内のSUBSCRIBEリクエスト（リフレッシュまたは終了）を受信すると、それは完全なプレゼンス文書を含むNOTIFYリクエストを送るべきです。
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は、部分的通知を配信するために既存のサブスクリプション内の通知、および変更の「アプリケーション/ PIDF-差分+ XML」コンテンツタイプ以外使用している場合、PAは有するプレゼンスドキュメントを含むプレゼンス情報の完全な状態を提供しなければなりません<第1の部分の通知などPIDFフル>ルート要素。
Watcher processes all NOTIFY requests that contain 'application/ pidf+xml' content type as specified in RFC 3856 [3].
ウォッチャープロセスはすべて、RFC 3856で指定されるように「アプリケーション/ PIDF + XMLのコンテンツ・タイプを含むNOTIFYリクエストを[3]。
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.
ウォッチャーは「アプリケーション/ PIDF-差分+ XML」MIME本体を含む最初の通知を受信すると、ウォッチャーは、プレゼンス文書に含まれる「バージョン」の値に、このサブスクリプションに関連する内部バージョンカウンタを初期化しなければなりません。このバージョンカウンタは、サブスクリプションにスコープされます。ウォッチャーはまた、そのローカルコピーとして受け取った完全なプレゼンス文書を保存しなければなりません。
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-差分+ 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.
プレゼンス文書のルート要素は<PIDFフル>である場合O、ウォッチャーは、「アプリケーション/ 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-差分>は、受信したバージョン番号が、ローカルバージョンカウンタと比較して、1つだけ増分され、ウォッチャーは、受信に示される完全なプレゼンスドキュメントのローカルコピーに変更を適用する必要がある場合「アプリケーション/ PIDF-差分+ XML」のドキュメントの部分的存在についてPIDF拡張で指定されている[2]。ウォッチャーは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-差分>及び受信した「バージョン」値がローカルに格納された値と比較し、複数の高くされ、ウォッチャーは、一の以上の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-差分+ xmlの」符号化されたプレゼンス文書を処理中ウォッチャーは、処理エラーが発生した場合、[8]のセクション5.1を見てください。この場合、ウォッチャーは、契約を更新すべきです。ウォッチャーは、新しいSUBSCRIBEリクエストで「アプリケーション/ PIDF-diffの+ xmlの」を挿入しないことにより、通常のプレゼンス操作にフォールバックするかもしれません。エラーがnotifierプロセスに存在する場合でも、通知には、このエラーを通知することはほとんど合理的です。
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が戻っ「アプリケーション/ 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.
ウォッチャは、デフォルトプレゼンスフォーマット（のための「アプリケーション/ PIDF + XML）と部分的通知形式のAcceptヘッダーフィールド値（」アプリケーション/ PIDF-差分+ XML '）サポートを宣言SUBSCRIBEリクエストを送信します。ウォッチャーは、部分的な通知を受信するためのプリファレンスを設定する「Q」パラメータを使用します。 PAは、サブスクリプションを受け入れて、「Q」のパラメータ値に基づいて、NOTIFYリクエストをして、部分的に通知を送信するために選択されます。最初のNOTIFYリクエストは、プレゼンス情報の完全な状態を含みます。次の通知は、前のNOTIFYリクエストからのプレゼンス情報のデルタに関する情報が含まれています。
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 SUBSCRIBE watcher-> 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
The PA accepts the subscription and generates a 200 OK response to the SUBSCRIBE request
PAは、サブスクリプションを受け入れ、SUBSCRIBEリクエストに対する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経由：SIP / 2.0 / TCP watcherhost.example.com。ブランチ= z9hG4bKnashds7は、受信= 192.0.2.1へ：<SIP：resource@example.com>;タグ= FFD2から：<SIP：watcher@example.com>;タグ=コールIDをxfg9：2010@watcherhost.example.com CSeq：17766イベントSUBSCRIBE：存在が有効期限：3600連絡先：<一口：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.
SUBSCRIBEリクエスト（F1）の受け入れヘッダ内の「Q」パラメータの値に基づいて、PAは、部分的な通知を使用することを決定します。 PAは、完全なプレゼンス文書を含む第1のNOTIFYリクエストを作成します。
F3 NOTIFY example.com server -> watcher
F3がexample.comサーバーをNOTIFY - >ウォッチャー
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: ...
user@watcherhost.example.com SIP / 2.0経由：SIP NOTIFY SIP / 2.0 / TCPのserver.example.comを。ブランチ= z9hG4bKna998skへ：<SIP：watcher@example.com>;タグ= xfg9から：<SIP：resource@example.com>;タグ=コールIDをFFD2：2010@watcherhost.example.comイベント：プレゼンスサブスクリプション・ステート：;：70件のCSeq：8775連絡先をNOTIFY：アクティブ= 3599マックス・フォワードの有効期限が切れる<一口：server.example.com>のContent-Type：アプリケーション/ 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" エンコード= "UTF-8"？> <P：PIDFフルのxmlns = "壷：IETF：のparams：XML：NS：PIDF" のxmlns：P = "壷：IETF：のparams：XML ：NS：PIDF-差分 "のxmlns：R = "URN：IETF：paramsは：XML：NS：PIDF：RPID" のxmlns：C = "URN：IETF：paramsは：XML：NS：PIDF：キャップ" のxmlns：CP =" URN：IETF：paramsは：XML：NS：PIDF：cipid "のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" エンティティ= "SIP：resource@example.com" バージョン=" 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="cg231jcr"> <status> <basic>open</basic> </status> <contact priority="1.0">im:res@example.com</contact> </tuple>
<タプルID = "cg231jcr"> <状態> <基本>開く</塩基性> </状態> <コンタクト優先度= "1.0"> IM：res@example.com </接触> </タプル>
<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>
<タプルID = "r1230d"> <状態> <基本> </塩基性> </状態>閉鎖<CP：ホームページ> http://example.com/~res/ </ CP：ホームページ> <CP：アイコン> http://example.com/~res/icon.gif </ CP：アイコン> <CP：カード> http://example.com/~res/card.vcd </ CP：カード> <連絡先の優先順位=」 0.9" > SIP：resource@example.com </連絡先> </タプル>
<note xml:lang="en">Full state presence document</note>
<メモのxml：LANG = "EN">完全な状態のプレゼンス文書</ノート>
<dm:person id="fdkfj"> <r:activities> <r:on-the-phone/> <r:busy/> </r:activities> </dm:person>
<DM：人のID = "fdkfj"> <R：活動> <R：オン・ザ・電話/> <R：忙しい/> </ R：活動> </ DM：人>
<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：デバイスID = "u00b40c7"> <C：devcaps> <C：モビリティ> <C：サポート> <C：モバイル/> </ C：サポート> </ C：モビリティ> </ C：devcaps> < DM：deviceIDの>マック：XXX </ DM：deviceIDの> </ DM：デバイス>
</p:pidf-full>
</ P：PIDF-フル>
F4 200 OK watcher -> example.com server
F4 200 OKウォッチャー - > 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経由：SIP / 2.0 / TCPのserver.example.com。ブランチ= z9hG4bKna998skは、受信= 192.0.2.2へ：<SIP：watcher@example.com>;タグ= xfg9から：<SIP：resource@example.com>;タグ=コールIDをFFD2：2010@watcherhost.example.com CSeq：8775のContent-LengthをNOTIFY：0
At a later time, the presentity's presence information changes. The PA generates a NOTIFY request that includes information about the changes.
後で、プレゼンティティのプレゼンス情報が変更されます。 PAは、変更に関する情報が含まれてNOTIFYリクエストを生成します。
F5 NOTIFY example.com server -> watcher
F5がexample.comサーバーをNOTIFY - >ウォッチャー
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: ...
<?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" エンコード= "UTF-8"？> <P：PIDF-差分のxmlns = "壷：IETF：のparams：XML：NS：PIDF" のxmlns：P = "壷：IETF：のparams：XML ：NS：PIDF-差分 "のxmlns：R = "URN：IETF：paramsは：XML：NS：PIDF：RPID" のxmlns：DM = "URN：IETF：paramsは：XML：NS：PIDF：データモデル" エンティティ=" SIP：resource@example.com」バージョン= "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：SEL = "プレゼンス/音符" POSを追加= "前"> <タプルID = "ert4773"> <状態> <基本>開く</塩基性> </状態> <コンタクト優先度= "0.4">のmailto： res@example.com </連絡先> <メモのxml：langは=「EN」>これは</タプル> </注意>を最後のタプルとノート要素との間に挿入された新しいタプルです
</p:add>
</ P：追加>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()" >open</p:replace>
<P：交換するSEL = "* /タプル[@ ID = 'r1230d'] /ステータス/ベーシック/テキスト（）">開く</ P：交換してください>
<p:remove sel="*/dm:person/r:activities/r:busy"/>
<P：削除SEL = "* / DM：人/ R：活動/ R：忙しいです" />
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority" >0.7</p:replace>
<P：置き換えるSEL = "* /タプル[@ ID = 'cg231jcr'] /コンタクト/ @優先度"> 0.7 </ P：置き換えます>
</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
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リクエストを注入することができます。終了し、延長について知らなくても、同じ効果を得る：これは、このようなアクションを実行することができ党も購読ステートで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は、SUBSCRIBEとNOTIFYリクエストの整合性と信頼のために使用されるかもしれません。これは、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.
作者は彼らの貴重なコメントをヤリUrpalainen、ユルキAarnos、ジョナサン・ローゼンバーグ、ディーンウィリス、Kriztianキス、ユハKalliokulju、ミゲル・ガルシア、アンダース・クリステンセン、ヤニスPavlidis、ベン・キャンベル、ロバートスパークス、とティム・モランに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[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 5262年8月008。
[3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[3]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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]菅野、H.、藤本、S.、Klyne、G.、ベイトマン、A.、カー、W.、およびJ.ピーターソン、 "プレゼンス情報データフォーマット（PIDF）"、RFC 3863、2004年8月。
[6] Roach, A., "SIP-Specific Event Notification", RFC 3265, June 2002.
[6]ローチ、A.、 "SIP固有のイベント通知"、RFC 3265、2002年6月。
[7] Dierks, T. and E. Rescorla, "The TLS Protocol Version 1.1", RFC 4346, April 2006.
[7]ダークス、T.およびE.レスコラ、 "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）パッチOperations Frameworkの利用XMLパス言語（XPath）セレクタ"、RFC 5261、2008年9月。
[9] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[9]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
Authors' Addresses
著者のアドレス
Mikko Lonnfors Nokia P.O. Box 321 Helsinki Finland
ミッコLönnforsNokiaの私書箱321ヘルシンキフィンランド箱
Phone: +358 71 8008000 EMail: mikko.lonnfors@nokia.com
電話番号：+358 71 8008000 Eメール：mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 Helsinki Finland
ホセコスタ・レケーナNokiaの私書箱321ヘルシンキフィンランド箱
Phone: +358 71 8008000 EMail: jose.costa-requena@nokia.com
電話番号：+358 71 8008000 Eメール：jose.costa-requena@nokia.com
Eva Leppanen Nokia Lempaala Finland
エヴァLeppanenノキアLempaalaフィンランド
EMail: eva.leppanen@saunalahti.fi
メールアドレス：eva.leppanen@saunalahti.fi
Hisham Khartabil Ericsson Melbourne Australia
ヒシャムKhartabilエリクソンメルボルンオーストラリア
Phone: +61 416 108 890 EMail: hisham.khartabil@gmail.com
電話：+61 416 108 890 Eメール：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。