[要約] RFC 5263は、SIP拡張機能である部分的なプレゼンス情報の通知に関するものです。その目的は、プレゼンス情報の一部の変更を通知するためのメカニズムを提供することです。
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
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]用のプレゼンスイベントパッケージと、部分的な存在情報データ形式ドキュメント[2]を搭載するための新しいMIMEタイプを利用しています。
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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"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サブスクライブリクエストを送信します。リクエストは、プレゼンスの存在情報が保存されるプレゼンスエージェントにルーティングされます。購読要求には、サポートされているコンテンツタイプを示す受け入れヘッダーフィールドを含めることができます。
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.
存在エージェントはサブスクライブリクエストを受信し、サポートされているコンテンツタイプを示す受け入れヘッダーがない場合、または承認ヘッダーにデフォルトのPIDFコンテンツタイプが含まれている場合、PAはデフォルトのPIDF形式[5]を使用して存在通知を生成します。PIDFドキュメントには、1つまたは複数の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 contains the "application/pidf-diff+xml" tag as well as the "application/pidf+xml" tag.
部分的な通知メカニズムにより、ウォッチャーは、可能な限り、通知に実際に変更された存在情報のみが含まれていることを要求することができます。このドキュメントに従って部分通知を受け取りたいウォッチャーは、通常の存在サブスクリプションのそれと同様のSIPサブスクライブリクエストを作成します。ただし、SIPサブスクライブリクエストには、「アプリケーション/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.
存在エージェントがサブスクリプションを受信すると、受け入れヘッダーフィールド値を調べ、「アプリケーション/PIDF-DIFF XML」値が存在する場合、このメモで指定された部分通知メカニズムを使用することを決定できます。プレゼンスエージェントは、「アプリケーション/PIDF-DIFF XML」に設定されたコンテンツタイプのヘッダーフィールドを含む通知リクエストを構築します。存在情報を含む最初の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拡張で指定された「アプリケーション/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.
購読要求を使用して、通知で使用する優先コンテンツタイプをネゴシエートすることができます。Acceptヘッダーフィールドは、RFC 3261 [4]で指定されているように、この目的に使用されます。ウォッチャーがプレゼンスエージェントに部分通知を送信できるようにしたい場合、ウォッチャーはサブスクライブリクエストに受け入れヘッダーフィールドを含める必要があります。Acceptヘッダーフィールドの値には、「アプリケーション/ PIDF-DIFF XML」（SIPプレゼンスイベントパッケージ[3]に必要な「アプリケーション/ 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 agent SHOULD base the decision on those preferences, unless otherwise indicated by the presence agent local policy.
プレゼンスエージェントは、ウォッチャーからサブスクリプションを受信し、SIPプレゼンスイベントパッケージ[3]に従って通知を生成します。ウォッチャーがサブスクライブリクエストの受け入れヘッダーフィールドでサポートされているコンテンツタイプを示した場合、存在エージェントは、受け入れヘッダーフィールドとサポートされた値を比較し、使用するものを決定します。ウォッチャーが「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-FULL>ルート要素を持つ存在ドキュメントを含む最初の部分通知に存在情報の完全な状態を提供する必要があります。存在エージェントがこの仕様に従って存在ドキュメントを含む通知を送信することを決定した場合、存在エージェントは、部分的な存在のためにPIDF拡張に従って存在ドキュメントを構築する必要があり[2]、コンテンツタイプのヘッダーフィールドを値に設定する必要があります。アプリケーション/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には「バージョン」属性を含める必要があります。最初の部分通知（特定のサブスクリプション内）では、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には以前の通知と比較して変更された存在情報のみを含める必要があります。以前の状態の変更と見なされるものを決定するのは、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>要素内にリストされており、変更されたすべての情報は<plateg>要素にリストされています。
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]形式[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は、以前のものまたは以前の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が関連するサブスクリプション内でサブスクライブリクエスト（更新または終了）を受信した場合、完全な存在ドキュメントを含む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-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で指定されている「アプリケーション/ PIDF XML」コンテンツタイプを含むすべてのリクエストをすべて通知します[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-DIFF 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-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拡張で指定されているアプリケーション/PIDF-DIFF XML 'ドキュメント[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-DIFF>であり、受信した「バージョン」値がローカルに保存された値と比較して複数の値が高い場合、ウォッチャーは1つ以上の通知が失われたと想定しています。ウォッチャーは、フルプレゼンスドキュメントを受け取るためにサブスクリプションを更新するか、サブスクリプションを終了する必要があります。
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を見てください。この場合、ウォッチャーはサブスクリプションを更新する必要があります。また、ウォッチャーは、新しいサブスクライブリクエストに「アプリケーション/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.
ウォッチャーは、デフォルトのプレゼンスフォーマット（ 'アプリケーション/PIDF XML）と、受け入れヘッダーフィールド値の部分通知形式（' Application/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 | |
|-------------------------->| |
Message Details
メッセージの詳細
F1 SUBSCRIBE watcher->example.com server
f1 subscribewatcher-> 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はサブスクリプションを受け入れ、サブスクライブリクエストに対する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
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は、完全なプレゼンスドキュメントを含む最初のNotifyリクエストを作成します。
F3 NOTIFY example.com server -> watcher
f3 notify 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: ...
<?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="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>
<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: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>
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
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 notify 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: ...
<?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>
<p:replace sel="*/tuple[@id='r1230d']/status/basic/text()"
>open</p:replace>
<p:remove sel="*/dm:person/r:activities/r:busy"/>
<p:replace sel="*/tuple[@id='cg231jcr']/contact/@priority"
>0.7</p:replace>
</p:pidf-diff>
F6 200 OK watcher-> example.com server
F6 200 OKウォッチャー - > 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.
サードパーティは、監視者に部分的な通知を逃し、新しい完全な存在ドキュメントをリクエストすると思わせる部分状態で通知要求を挿入できます。このようなアクションを実行できる当事者は、サブスクリプション状態で通知を送信する可能性があるため、これはこの拡張機能なしで私たちが持っているものよりも悪くはありません。部分通知は状況を悪化させず、既存のシステムからの保護メカニズムは、部分通知メカニズムに対するこの攻撃を防ぐために適用されます。
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]に記載されている問題[3]には、機密性、メッセージの整合性と信頼性、アウトバウンド認証、リプレイ防止、サービス拒否（DOS）攻撃が喉の渇き（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.
著者は、Jari Urpalainen、Jyrki Aarnos、Jonathan Rosenberg、Dean Willis、Kriztian Kiss、Juha Kalliokulju、Miguel Garcia、Anders Kristensen、Yannis Pavlidis、Ben Cambell、Robert Sparks、Tim Moranに感謝します。
[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 5262、8月008。
[3] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[3] Rosenberg、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INTIATION Protocol"、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.、Bateman、A.、Carr、W。、およびJ. Peterson、「プレゼンス情報データ形式（PIDF）」、RFC 3863、2004年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 PATH言語（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 2778、2000年2月。
Authors' Addresses
著者のアドレス
Mikko Lonnfors Nokia P.O. Box 321 Helsinki Finland
Mikko Lonfors Nokia P.O.ボックス321ヘルシンキフィンランド
Phone: +358 71 8008000
EMail: mikko.lonnfors@nokia.com
Jose Costa-Requena Nokia P.O. Box 321 Helsinki Finland
Jose Costa-Requena Nokia P.O.ボックス321ヘルシンキフィンランド
Phone: +358 71 8008000
EMail: jose.costa-requena@nokia.com
Eva Leppanen Nokia Lempaala Finland
Eva Leppanen Nokia Lempaala Finland
EMail: eva.leppanen@saunalahti.fi
Hisham Khartabil Ericsson Melbourne Australia
Hisham Khartabil Ericsson Melbourne Australia
Phone: +61 416 108 890
EMail: hisham.khartabil@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。