Network Working Group J. Rosenberg
Request for Comments: 3857 dynamicsoft
Category: Standards Track August 2004
A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines the watcher information template-package for the Session Initiation Protocol (SIP) event framework. Watcher information refers to the set of users subscribed to a particular resource within a particular event package. Watcher information changes dynamically as users subscribe, unsubscribe, are approved, or are rejected. A user can subscribe to this information, and therefore learn about changes to it. This event package is a template-package because it can be applied to any event package, including itself.
この文書では、セッション開始プロトコル（SIP）イベントフレームワークのウォッチャー情報テンプレートパッケージを定義します。ウォッチャ情報は、特定のイベントパッケージ内の特定のリソースへの加入ユーザのセットを指します。ウォッチャー情報は、ユーザーが、購読解除、承認された、または拒否されて動的に変化します。利用者がこの情報をサブスクライブするため、それへの変更について学ぶことができます。それは自分自身を含め、あらゆるイベントパッケージに適用することができますので、このイベントパッケージは、テンプレートパッケージです。
Table of Contents
目次
1. Introduction ........................................ 2
2. Terminology ......................................... 3
3. Usage Scenarios ..................................... 3
3.1. Presence Authorization ........................ 4
3.2. Blacklist Alerts .............................. 5
4. Package Definition .................................. 5
4.1. Event Package Name ............................ 5
4.2. Event Package Parameters ...................... 5
4.3. SUBSCRIBE Bodies .............................. 6
4.4. Subscription Duration ......................... 6
4.5. NOTIFY Bodies ................................. 7
4.6. Notifier Processing of SUBSCRIBE Requests...... 7
4.7. Notifier Generation of NOTIFY Requests ........ 8
4.7.1. The Subscription State Machine......... 9
4.7.2. Applying the State Machine............. 11
4.8. Subscriber Processing of NOTIFY Requests ...... 12
4.9. Handling of Forked Requests ................... 12
4.10. Rate of Notifications ......................... 13
4.11. State Agents .................................. 13
5. Example Usage ....................................... 14
6. Security Considerations ............................. 17
6.1. Denial of Service Attacks ..................... 17
6.2. Divulging Sensitive Information ............... 17
7. IANA Considerations ................................. 18
8. Acknowledgements .................................... 18
9. Normative References ................................ 18
10. Informative References .............................. 19
11. Author's Address .................................... 19
12. Full Copyright Statement ............................ 20
The Session Initiation Protocol (SIP) event framework is described in RFC 3265 [1]. It defines a generic framework for subscription to, and notification of, events related to SIP systems. The framework defines the methods SUBSCRIBE and NOTIFY, and introduces the notion of a package. A package is a concrete application of the event framework to a particular class of events. Packages have been defined for user presence [5], for example.
セッション開始プロトコル（SIP）イベント・フレームワークは、RFC 3265に記載されている[1]。それはへのサブスクリプション、および通知、SIPシステムに関連するイベントのための汎用フレームワークを定義します。フレームワークは、方法は、SUBSCRIBE及びNOTIFY定義、及びパッケージの概念を導入します。パッケージには、イベントの特定のクラスにイベント・フレームワークの具体的なアプリケーションです。パッケージは、例えば、ユーザのプレゼンス[5]に定義されています。
This document defines a "template-package" within the SIP event framework. A template-package has all the properties of a regular SIP event package. However, it is always associated with some other event package, and can always be applied to any event package, including the template-package itself.
この文書では、SIPイベントの枠組み内で、「テンプレート・パッケージ」を定義します。テンプレートパッケージは、通常のSIPイベントパッケージのすべてのプロパティを持っています。しかし、それは常にいくつかの他のイベントパッケージに関連付けられている、と常にテンプレートパッケージ自体を含め、あらゆるイベントパッケージに適用することができます。
The template-package defined here is for watcher information, and is denoted with the token "winfo". For any event package, such as presence, there exists a set (perhaps an empty set) of subscriptions that have been created or requested by users trying to ascertain the state of a resource in that package. This set of subscriptions changes over time as new subscriptions are requested by users, old subscriptions expire, and subscriptions are approved or rejected by the owners of that resource. The set of users subscribed to a particular resource for a specific event package, and the state of their subscriptions, is referred to as watcher information. Since this state is itself dynamic, it is reasonable to subscribe to it in order to learn about changes to it. The watcher information event template-package is meant to facilitate exactly that - tracking the state of subscriptions to a resource in another package.
ここで定義されたテンプレートパッケージは、ウォッチャ情報のためのものであり、トークン「winfo」と表記します。任意のイベントパッケージのために、そのような存在として、そのパッケージ内のリソースの状態を確認しようとするユーザによって作成または要求されたサブスクリプションのセット（おそらく空集合）が存在します。サブスクリプションの変更のこのセットは、新しいサブスクリプションは、ユーザーによって要求されているよう時間をかけて、古いサブスクリプションの有効期限が切れ、およびサブスクリプションは、そのリソースの所有者によって承認または拒否されています。特定イベントパッケージのための特定のリソース、およびそれらのサブスクリプションの状態に加入したユーザのセットは、ウォッチャー情報と呼ぶことにします。この状態はダイナミックそのものであるので、それへの変更について学ぶために、それに加入するのが妥当です。別のパッケージ内のリソースへのサブスクリプションの状態を追跡する - ウォッチャー情報イベントテンプレートパッケージは、まさにそれを促進するためのものです。
To denote this template-package, the name is constructed by appending ".winfo" to the name of whatever package is being tracked. For example, the set of people subscribed to presence is defined by the "presence.winfo" package.
このテンプレート・パッケージを示すために、名前が追跡されているものは何でも、パッケージの名前に「.winfo」を追加することによって構築されます。例えば、プレゼンスに加入人々の集合は「presence.winfo」パッケージで定義されています。
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 BCP14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" [2]のBCP14、RFC 2119に記載されるように解釈されるべきであり、対応する実装の要求レベルを示します。
This document fundamentally deals with recursion - subscriptions to subscriptions. Therefore, the term "subscription" itself can be confusing in this document. To reduce confusion, the term "watcherinfo subscription" refers to a subscription to watcher information, and the term "watcherinfo subscriber" refers to a user that has subscribed to watcher information. The term "watcherinfo notification" refers to a NOTIFY request sent as part of a watcherinfo subscription. When the terms "subscription", "subscriber", and "notification" are used unqualified, they refer to the "inner" subscriptions, subscribers and notifications - those that are being monitored through the watcherinfo subscriptions. We also use the term "watcher" to refer to a subscriber to the "inner" resource. Information on watchers is reported through watcherinfo subscriptions.
サブスクリプションへのサブスクリプション - このドキュメントでは、基本的に再帰を扱います。したがって、用語「サブスクリプション」自体は、本文書に混乱することができます。混乱を減らすために、「加入watcherinfo」という用語は、情報をウォッチャにサブスクリプションを意味し、「加入者watcherinfo」という用語は、情報をウォッチャに加入しているユーザを指します。用語「watcherinfo通知」watcherinfoサブスクリプションの一部として送信されたNOTIFYリクエストを指します。 watcherinfoサブスクリプションを通じて監視されているもの - 用語「サブスクリプション」、「加入者」、および「通知」修飾されていない使用されているとき、彼らは「内側」サブスクリプション、加入者との通知を参照してください。我々はまた、「内部」リソースに加入者を参照するために用語「ウォッチャー」を使用します。ウォッチャーに関する情報はwatcherinfoサブスクリプションを通じて報告されます。
There are many useful applications for the watcher information template-package.
ウォッチャー情報テンプレートパッケージのための多くの有用な用途があります。
The motivating application for this template-package is presence authorization. When user A subscribes to the presence of user B, the subscription needs to be authorized. Frequently, that authorization needs to occur through direct user intervention. For that to happen, B's software needs to become aware that a presence subscription has been requested. This is supported through watcher information. B's client software would SUBSCRIBE to the watcher information for the presence of B:
このテンプレート・パッケージのための動機アプリケーションは、プレゼンスの認可です。ユーザAがユーザBのプレゼンスに加入するとき、サブスクリプションが許可される必要があります。しばしば、その認可が直接ユーザーの介入を介して行われる必要があります。それが起こるためには、Bのソフトウェアは、プレゼンスサブスクリプションが要求されていることを自覚する必要があります。これは、ウォッチャ情報によってサポートされています。 Bのクライアントソフトウェアは、Bの存在をウォッチャ情報を購読します：
SUBSCRIBE sip:B@example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7 From: sip:B@example.com;tag=123s8a To: sip:B@example.com Call-ID: 9987@pc34.example.com Max-Forwards: 70 CSeq: 9887 SUBSCRIBE Contact: sip:B@pc34.example.com Event: presence.winfo
一口にSUBSCRIBE：B@example.com SIP / 2.0経由：SIP / 2.0 / UDP pc34.example.com;ブランチ= z9hG4bKnashds7から：SIP：B@example.com;タグ= 123s8aへ：SIP：B@example.comコール-ID：9987@pc34.example.comマックス・フォワード：70のCSeq：9887は、連絡先をSUBSCRIBE：SIP：B@pc34.example.comイベント：presence.winfo
The policy of the server is such that it allows B to subscribe to its own watcher information. So, when A subscribes to B's presence, B gets a notification of the change in watcher information state:
サーバーのポリシーでは、それは、独自のウォッチャ情報を購読するBを可能にするようなものです。 AはBのプレゼンスに加入するときに、Bは、ウォッチャ情報状態の変化の通知を取得します。
NOTIFY sip:B@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server.example.com;branch=z9hG4bKna66g From: sip:B@example.com;tag=xyz887 To: sip:B@example.com;tag=123s8a Call-ID: 9987@pc34.example.com Max-Forwards: 70 CSeq: 1288 NOTIFY Contact: sip:B@server.example.com Event: presence.winfo Content-Type: application/watcherinfo+xml Content-Length: ...
一口にNOTIFY：B@pc34.example.com SIP / 2.0経由：SIP / 2.0 / UDP server.example.com;からブランチ= z9hG4bKna66g：SIP：B@example.com;タグ= xyz887へ：一口例：@ B。 COM;タグ= 123s8aがコールIDを：9987@pc34.example.comマックス - フォワード：70のCSeq：1288連絡先をNOTIFY：SIP：B@server.example.comイベント：presence.winfoのContent-Type：アプリケーション/ watcherinfo + xmlのコンテンツの長さ：...
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:B@example.com" package="presence"> <watcher id="7768a77s" event="subscribe" status="pending">sip:A@example.com</watcher> </watcher-list> </watcherinfo>
<watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <xmlのバージョン= "1.0"？> <ウォッチャーリストリソース= "一口：Bの@例.COM」パッケージ= "存在"> <ウォッチャーID = "7768a77s" イベント= "加入" ステータス= "" 保留> SIP：A@example.com </ウォッチャー> </ウォッチャーリスト> </ watcherinfo>
This indicates to B that A has subscribed, and that the subscription is pending (meaning, it is awaiting authorization). B's software can alert B that this subscription is awaiting authorization. B can then set policy for that subscription.
これは、Aが加入しているBに示し、サブスクリプションが保留されていること（つまり、それが承認を待っています）。 Bのソフトウェアは、このサブスクリプションが承認を待っているBに警告することができます。 Bは、そのサブスクリプションのためのポリシーを設定することができます。
Applications can subscribe to watcher information in order to provide value-added features. An example application is "blacklist alerts". In this scenario, an application server maintains a list of known "bad guys". A user, Joe, signs up for service with the application provider, presumably by going to a web page and entering in his presence URI. The application server subscribes to the watcher information for Joe's presence. When someone attempts to SUBSCRIBE to Joe's user presence, the application learns of this subscription as a result of its watcher info subscription. It checks the watcher's URI against the database of known bad guys. If there is a match, it sends email to Joe letting him know about this.
アプリケーションは、付加価値機能を提供するために、情報をウォッチャに購読することができます。サンプルアプリケーションでは、「ブラックリスト警告」です。このシナリオでは、アプリケーション・サーバは、知られている「悪者」のリストを維持しています。利用者、ジョーは、おそらくWebページに行くと、彼の存在URIに入力することにより、アプリケーションプロバイダとのサービスにサインアップ。アプリケーションサーバは、ジョーの存在について、ウォッチャ情報にサブスクライブします。誰かがジョーのユーザーのプレゼンスをサブスクライブしようとすると、アプリケーションがそのウォッチャー情報購読の結果として、このサブスクリプションを知りました。それは知られている悪者のデータベースに対してウォッチャーのURIをチェックします。一致するものがあれば、それは彼がこのことについて知らせるジョーに電子メールを送信します。
For this application to work, Joe needs to make sure that the application is allowed to subscribe to his presence.winfo.
仕事へのこのアプリケーションでは、ジョーは、アプリケーションが自分のpresence.winfoに加入することが許可されていることを確認する必要があります。
This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [1].
このセクションでは、RFC 3265のセクション4.4で定義されるようなイベントパッケージを指定するために必要な詳細情報を記入[1]。
RFC 3265 [1] requires package definitions to specify the name of their package or template-package.
RFC 3265 [1]は、パッケージまたはテンプレートパッケージの名前を指定するには、パッケージの定義が必要です。
The name of this template-package is "winfo". It can be applied to any other package. Watcher information for any package foo is denoted by the name "foo.winfo". Recursive template-packaging is explicitly allowed (and useful), so that "foo.winfo.winfo" is a valid package name.
このテンプレート・パッケージの名前は「winfo」です。これは、他のパッケージにも適用することができます。任意のパッケージfooのウォッチャー情報は、名称「foo.winfo」で示されています。 「foo.winfo.winfoが」有効なパッケージ名になるように、再帰テンプレートパッケージは明示的に、（かつ有用）許可されています。
RFC 3265 [1] requires package and template-package definitions to specify any package specific parameters of the Event header field.
RFC 3265 [1]イベントヘッダフィールドのすべてのパッケージの特定のパラメータを指定するパッケージとテンプレートパッケージ定義を必要とします。
No package specific Event header field parameters are defined for this event template-package.
いいえパッケージの特定のイベントヘッダフィールドのパラメータは、このイベントテンプレートパッケージ用に定義されていません。
RFC 3265 [1] requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
RFC 3265 [1]は、もしあれば、SUBSCRIBE要求に体から、使用を定義するパッケージまたはテンプレートパッケージ定義を必要とします。
A SUBSCRIBE request for watcher information MAY contain a body. This body would serve the purpose of filtering the watcherinfo subscription. The definition of such a body is outside the scope of this specification. For example, in the case of presence, the body might indicate that notifications should contain full state every time something changes, and that the time the subscription was first made should not be included in the watcherinfo notifications.
ウォッチャ情報に対するSUBSCRIBEリクエストは、体を含むかもしれません。このボディはwatcherinfoサブスクリプションをフィルタリングする目的を果たすでしょう。このような体の定義は、本明細書の範囲外です。例えば、存在する場合には、身体は通知が満杯状態に何かが変わるたびに含まれており、サブスクリプションが最初に行われた時間はwatcherinfo通知に含まれるべきでないことをすべきであることを示している可能性があります。
A SUBSCRIBE request for a watcher information package MAY be sent without a body. This implies the default watcherinfo subscription filtering policy has been requested. The default policy is:
ウォッチャ情報パッケージのSUBSCRIBEリクエストは、本体なしで送信されるかもしれません。これは、サブスクリプション・フィルタリング・ポリシーが要求されているデフォルトのwatcherinfoを意味します。デフォルトポリシーは次のとおりです。
o Watcherinfo notifications are generated every time there is any change in the state of the watcher information.
O Watcherinfoの通知は、ウォッチャ情報の状態に何らかの変化があるたびに生成されます。
o Watcherinfo notifications triggered from a SUBSCRIBE contain full state (the list of all watchers that the watcherinfo subscriber is permitted to know about). Watcherinfo notifications triggered from a change in watcher state only contain information on the watcher whose state has changed.
O Watcherinfo通知は（watcherinfo加入者が知って許可されているすべてのウォッチャーのリスト）完全な状態が含まれているSUBSCRIBEからトリガ。通知がウォッチャー状態の変化からトリガWatcherinfoのみ状態変化しているウォッチャに関する情報が含まれています。
Of course, the server can apply any policy it likes to the subscription.
もちろん、サーバーは、それがサブスクリプションに好きな任意のポリシーを適用することができます。
RFC 3265 [1] requires package definitions to define a default value for subscription durations, and to discuss reasonable choices for durations when they are explicitly specified.
RFC 3265 [1]は、サブスクリプション期間のデフォルト値を定義し、それらが明示的に指定された場合の期間のための合理的な選択肢を議論するためにパッケージ定義が必要です。
Watcher information changes as users subscribe to a particular resource for some package, or their subscriptions time out. As a result, the state of watcher information can change very dynamically, depending on the number of subscribers for a particular resource in a given package. The rate at which subscriptions time out depends on how long a user maintains its subscription. Typically, watcherinfo subscriptions will be timed to span the lifetime of the subscriptions being watched, and therefore range from minutes to days.
ウォッチャー情報は、時間をユーザーがいくつかのパッケージの特定のリソースをサブスクライブするように変更、またはそのサブスクリプション。結果として、ウォッチャ情報の状態は、特定のパッケージ内の特定のリソースに対する加入者の数に応じて、非常に動的に変更することができます。時間をサブスクリプションする速度は、ユーザーがそのサブスクリプションを保持する期間によって異なります。典型的には、watcherinfoサブスクリプションは、視聴中のサブスクリプションの存続期間にまたがるように調節され、したがって分から数日の範囲です。
As a result of these factors, it is difficult to define a broadly useful default value for the lifetime of a watcherinfo subscription. We arbitrarily choose one hour. However, clients SHOULD use an Expires header field to specify their preferred duration.
これらの要因の結果として、watcherinfoサブスクリプションの有効期間のために広く有用デフォルト値を定義することは困難です。私たちは、任意に1時間を選択してください。しかしながら、クライアントはそれらの好ましい持続時間を指定する有効期限ヘッダーフィールドを使用すべきです。
RFC 3265 [1] requires package definitions to describe the allowed set of body types in NOTIFY requests, and to specify the default value to be used when there is no Accept header field in the SUBSCRIBE request.
RFC 3265 [1]要求を通知し、何SUBSCRIBEリクエストのヘッダフィールドを許可がない場合に使用するデフォルト値を指定するためにボディタイプの許可セットを記述するためにパッケージ定義を必要とします。
The body of the watcherinfo notification contains a watcher information document. This document describes some or all of the watchers for a resource within a given package, and the state of their subscriptions. All watcherinfo subscribers and notifiers MUST support the application/watcherinfo+xml format described in [3], and MUST list its MIME type, application/watcherinfo+xml, in any Accept header field present in the SUBSCRIBE request.
watcherinfo通知のボディは、ウォッチャ情報文書が含まれています。この文書では、特定のパッケージ内のリソース、およびそのサブスクリプションの状態のためウォッチャーの一部またはすべてを説明しています。全てwatcherinfoサブスクライバとノーティファイア[3]に記載のアプリケーション/ watcherinfo + XML形式をサポートしなければなりません、そのMIMEタイプ、アプリケーション/ watcherinfo + XMLをリストする必要があり、任意にSUBSCRIBEリクエスト中に存在するヘッダフィールドを受け入れます。
Other watcher information formats might be defined in the future. In that case, the watcherinfo subscriptions MAY indicate support for other formats. However, they MUST always support and list application/watcherinfo+xml as an allowed format.
その他のウォッチャ情報フォーマットは、将来的に定義される可能性があります。その場合には、watcherinfoサブスクリプションは、他の形式のサポートを示すことがあります。しかし、彼らは常に許可フォーマットとしてアプリケーション/ watcherinfo + XMLをサポートしてリストする必要があります。
Of course, the watcherinfo notifications generated by the server MUST be in one of the formats specified in the Accept header field in the SUBSCRIBE request. If no Accept header field was present, the notifications MUST use the application/watcherinfo+xml format described in [3].
もちろん、サーバによって生成されたwatcherinfo通知はSUBSCRIBEリクエストにAcceptヘッダーフィールドに指定された形式のいずれかでなければなりません。全く受け入れヘッダフィールドが存在しない場合、通知は、アプリケーション/ watcherinfo + [3]に記載のXMLフォーマットを使用しなければなりません。
RFC 3265 [1] specifies that packages should define any package-specific processing of SUBSCRIBE requests at a notifier, specifically with regards to authentication and authorization.
RFC 3265 [1]パッケージは、特に認証および承認に関して、通知でSUBSCRIBEリクエストのいずれかのパッケージ固有の処理を定義する必要があることを指定します。
The watcher information for a particular package contains sensitive information. Therefore, all watcherinfo subscriptions SHOULD be authenticated and then authorized before approval. Authentication MAY be performed using any of the techniques available through SIP, including digest, S/MIME, TLS or other transport specific mechanisms [4]. Authorization policy is at the discretion of the administrator, as always. However, a few recommendations can be made.
特定のパッケージのウォッチャ情報は、機密情報が含まれています。したがって、すべてのwatcherinfoサブスクリプションは、認証された後、承認の前に承認されるべきです。認証は、ダイジェストを含むS / MIME、TLSまたは他のトランスポート固有のメカニズム、SIPを介して利用可能な技術のいずれかを用いて行うことができる[4]。認可ポリシーは、いつものように、管理者の裁量です。しかし、いくつかの提言を行うことができます。
It is RECOMMENDED that user A be allowed to subscribe to their own watcher information for any package. This is true recursively, so that it is RECOMMENDED that a user be able to subscribe to the watcher information for their watcher information for any package.
ユーザAは、任意のパッケージのために独自のウォッチャ情報をサブスクライブを許可することが推奨されます。ユーザーが任意のパッケージのために自分のウォッチャ情報については、ウォッチャ情報に加入することができることが推奨されるように、これは、再帰的に真です。
It is RECOMMENDED that watcherinfo subscriptions for some package foo for user A be allowed from some other user B, if B is an authorized subscriber to A within the package foo. However, it is RECOMMENDED that the watcherinfo notifications sent to B only contain the state of B's own subscription. In other words, it is RECOMMENDED that a user be allowed to monitor the state of their own subscription.
Bは、パッケージfoo内に許可された加入者である場合、ユーザAのためのいくつかのパッケージfooのwatcherinfoサブスクリプションは、他のユーザBから許可されていることが推奨されます。しかし、Bに送られたwatcherinfo通知のみB自身のサブスクリプションの状態が含まれていることが推奨されます。換言すれば、ユーザーは自分のサブスクリプションの状態を監視するために許可されることが推奨されます。
To avoid infinite recursion of authorization policy, it is RECOMMENDED that only user A be allowed to subscribe to foo.winfo.winfo for user A, for any foo. It is also RECOMMENDED that by default, a server does not authorize any subscriptions to foo.winfo.winfo.winfo or any other deeper recursions.
認可ポリシーの無限再帰を回避するために、ユーザAのみが任意のfooのため、利用者Aのためにfoo.winfo.winfoする購読を許可することが推奨されます。また、デフォルトでは、サーバはすべてのサブスクリプションがfoo.winfo.winfo.winfoやその他の深い再帰を許可しないことが推奨されます。
The SIP Event framework requests that packages specify the conditions under which notifications are sent for that package, and how such notifications are constructed.
通知はそのパッケージのために送られ、そしてどのような通知が構築される条件を指定してパッケージ化SIPイベントフレームワークを要求。
Each watcherinfo subscription is associated with a set of "inner" subscriptions being watched. This set is defined by the URI in the Request URI of the watcherinfo SUBSCRIBE request, along with the parent event package of the watcherinfo subscription. The parent event package is obtained by removing the trailing ".winfo" from the value of the Event header field from the watcherinfo SUBSCRIBE request. If the Event header field in the watcherinfo subscription has a value of "presence.winfo", the parent event package is "presence". If the Event header field has a value of "presence.winfo.winfo", the parent event package is "presence.winfo". Normally, the URI in the Request URI of the watcherinfo SUBSCRIBE identifies an address-of-record within the domain. In that case, the set of subscriptions to be watched are all of the subscriptions for the parent event package that have been made to the resource in the Request URI of the watcherinfo SUBSCRIBE. However, the Request URI can contain a URI that identifies any set of subscriptions, including the subscriptions to a larger collection of resources. For example, sip:all-resources@example.com might be defined within example.com to refer to all resources. In that case, a watcherinfo subscription for "presence.winfo" to sip:all-resources@example.com is requesting notifications any time the state of any presence subscription for any resource within example.com changes. A watcherinfo notifier MAY generate a notification any time the state of any of the watched subscriptions changes.
各watcherinfoサブスクリプションが見られている「内側」サブスクリプションのセットに関連付けられています。このセットはwatcherinfoサブスクリプションの親イベントパッケージと一緒に、SUBSCRIBEリクエストwatcherinfoのリクエストURIでURIによって定義されます。親イベントパッケージは、SUBSCRIBEリクエストをwatcherinfoからイベントヘッダフィールドの値から末尾の「.winfo」を除去することによって得られます。 watcherinfoサブスクリプションでのイベントヘッダーフィールドは「presence.winfo」の値を持つ場合、親イベントパッケージは、「存在」です。 Eventヘッダーフィールドは「presence.winfo.winfo」の値を持つ場合、親イベントパッケージは、「presence.winfo」です。通常、watcherinfoのURIは、SUBSCRIBEリクエストにおけるURIは、アドレスのレコードドメイン内を識別します。その場合には、注目されるサブスクリプションのセットは、SUBSCRIBE watcherinfoリクエストのURIのリソースに対して行われた親イベントパッケージのサブスクリプションのすべてです。しかし、リクエストURIは、リソースのより大きなコレクションへのサブスクリプションを含むサブスクリプションの任意のセットを、特定するURIを含めることができます。たとえば、SIP：all-resources@example.comは、すべてのリソースを参照するためにexample.com内で定義される可能性があります。その場合には、一口に「presence.winfo」のwatcherinfoサブスクリプションは：all-resources@example.com example.com内の任意のリソースのための任意のプレゼンスサブスクリプションの状態変化通知をいつでも要求しています。 watcherinfo通知は見たサブスクリプションの変更のいずれかの状態の通知をいつでも発生するかもしれません。
Because a watcherinfo subscription is made to a collection of subscriptions, the watcher information package needs a model of subscription state. This is accomplished by specifying a subscription Fine State Machine (FSM), described below, which governs the subscription state of a user in any package. Watcherinfo notifications MAY be generated on transitions in this state machine. It's important to note that this FSM is just a model of the subscription state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
watcherinfoサブスクリプションは、サブスクリプションのコレクションに作られているので、ウォッチャ情報パッケージは、サブスクリプション状態のモデルを必要とします。これは、サブスクリプションファインステートマシン（FSM）を指定することによって達成される、任意のパッケージでのユーザーのサブスクリプションの状態を支配され、以下で説明します。 Watcherinfo通知は、このステート・マシンの遷移に生成することができます。それは、このFSMは、サーバーによって維持サブスクリプションの状態機械の単なるモデルであることに注意することが重要です。実装は、実装固有の方法で、この1に、自身のステートマシンをマッピングします。
The underlying state machine for a subscription is shown in Figure 1. It derives almost entirely from the descriptions in RFC 3265 [1], but adds the notion of a waiting state.
サブスクリプションのための基本となるステートマシンは、それはRFC 3265に記述からほぼ完全に派生[1]が、待機状態の概念が追加され、図1に示されています。
When a SUBSCRIBE request arrives, the subscription FSM is created in the init state. This state is transient. The next state depends on whether policy exists for the subscription. If there is an existing policy that determines that the subscription is forbidden, it moves into the terminated state immediately, where the FSM can be destroyed. If there is existing policy that determines that the subscription is authorized, the FSM moves into the active state. This state indicates that the subscriber will receive notifications.
SUBSCRIBEリクエストが到着すると、サブスクリプションのFSMは、初期化状態で作成されます。この状態は一時的です。次の状態は、ポリシーは、サブスクリプションのために存在するかどうかに依存します。サブスクリプションが禁止されていることを判断し、既存のポリシーがある場合、それはFSMが破壊される可能性が直ちに終了状態へと移動します。サブスクリプションが許可されていると判断した既存のポリシーがある場合、FSMは、アクティブ状態に移行します。この状態は、加入者が通知を受信することを示しています。
If, when a subscription arrives, there is no authorization policy in existence, the subscription moves into the pending state. In this state, the server is awaiting an authorization decision. No notifications are generated on changes in presence state (an initial NOTIFY will have been delivered as per RFC 3265 [1]), but the subscription FSM is maintained. If the authorization decision comes back positive, the subscription is approved, and moves into the active state. If the authorization is negative, the subscription is rejected, and the FSM goes into the terminated state. It is possible that the authorization decision can take a very long time. In fact, no authorization decision may arrive until after the subscription itself expires. If a pending subscription suffers a timeout, it moves into the waiting state. At any time, the server can decide to end a pending or waiting subscription because it is concerned about allocating memory and CPU resources to unauthorized subscription state. If this happens, a "giveup" event is generated by the server, moving the subscription to terminated.
、サブスクリプションが到着したときに、存在には許可ポリシーが存在しない場合は、サブスクリプションは保留状態に移行します。この状態では、サーバーは、認可の決定を待っています。何の通知がプレゼンス状態の変化に生成されない（初期のNOTIFY [1] RFC 3265に従って配信されているであろう）が、加入FSMが維持されます。認可判断が戻ってくる正の場合は、サブスクリプションが承認され、アクティブ状態に移行されます。承認が負の場合、サブスクリプションは拒否され、FSMは終了状態になります。認可の決定は非常に長い時間がかかることが可能です。実際には、何の認可判断は、サブスクリプション自体の有効期限が切れた後まで到着しないことがあります。保留中のサブスクリプションがタイムアウトを被った場合は、待機状態に移行します。任意の時点で、サーバーは、それが不正なサブスクリプションの状態にメモリやCPUリソースを割り当てることを懸念しているので、保留中または待機中のサブスクリプションを終了することを決定することができます。この問題が発生した場合は、「ギブアップ」イベントが終了し、サブスクリプションを移動する、サーバーによって生成されます。
The waiting state is similar to pending, in that no notifications are generated. However, if the subscription is approved or denied, the FSM enters the terminated state, and is destroyed. Furthermore, if another subscription is received to the same resource, from the same watcher, for the same event package, event package parameters and filter in the body of the SUBSCRIBE request (if one was present initially), the FSM enters the terminated state with a "giveup" event, and is destroyed. This transition occurs because, on arrival of a new subscription with identical parameters, it will enter the pending state, making the waiting state for the prior subscription redundant. The purpose of the waiting state is so that a user can fetch watcherinfo state at any time, and learn of any subscriptions that arrived previously (and which may arrive again) which require an authorization decision. Consider an example. A subscribes to B. B has not defined policy about this subscription, so it moves into the pending state. B is not "online", so that B's software agent cannot be contacted to approve the subscription. The subscription expires. Let's say it were destroyed. B logs in, and fetches its watcherinfo state. There is no record of the subscription from A, so no policy decision is made about subscriptions from A. B logs off. A refreshes its subscription. Once more, the subscription is pending since no policy is defined for it. This process could continue indefinitely. The waiting state ensures that B can find out about this subscription attempt.
待ち状態には通知が生成されないことで、保留に似ています。サブスクリプションが承認または拒否された場合には、FSMは終了状態になり、破壊されます。 （一方が最初に存在した場合）、別のサブスクリプションがSUBSCRIBEリクエストのボディに同一のリソース、同じウォッチャから、同じイベントパッケージのため、イベント・パッケージ・パラメータおよびフィルタに受信された場合さらに、FSMは、で終了状態になりますイベントを「ギブアップ」、そして破壊されます。この移行は、同一のパラメータを持つ新しいサブスクリプションの到着時に、それは冗長前のサブスクリプションを待っている状態を作り、保留状態になり、ために発生します。ユーザーはいつでもwatcherinfo状態を取得し、以前に到着したすべてのサブスクリプションを知ることができるように待機している状態の目的はある（そしてどの再び到着するかもしれない）の認可決定を必要とします。例を考えてみましょう。それは保留状態に移動するようB. Bに加入は、このサブスクリプションに関するポリシーを定義していません。 Bのソフトウェアエージェントがサブスクリプションを承認する連絡ができないようにBは、「オンライン」ではありません。サブスクリプションの有効期限が切れます。のは、それが破壊されたとしましょう。 Bは、ログインすると、そのwatcherinfo状態をフェッチします。そこからAサブスクリプションのレコードがないので、AをBがログオフから何の政策決定は、サブスクリプションについては行われません。 Aは、そのサブスクリプションをリフレッシュします。ポリシーがそれのために定義されていないので、もう一度、サブスクリプションは保留中です。このプロセスは、無期限に続けることができます。待ち状態はBは、このサブスクリプションの試みを知ることができますことを保証します。
subscribe,
policy= +----------+
reject | |<------------------------+
+------------>|terminated|<---------+ |
| | | | |
| | | |noresource |
| +----------+ |rejected |
| ^noresource |deactivated |
| |rejected |probation |
| |deactivated |timeout |noresource
| |probation | |rejected
| |giveup | |giveup
| | | |approved
+-------+ +-------+ +-------+ |
| |subscribe| |approved| | |
| init |-------->|pending|------->|active | |
| |no policy| | | | |
| | | | | | |
+-------+ +-------+ +-------+ |
| | ^ |
| subscribe, | | |
+-----------------------------------+ |
policy = accept | +-------+ |
| | | |
| |waiting|----------+
+----------->| |
timeout | |
+-------+
Figure 1: Subscription State Machine
図1：サブスクリプションのステートマシン
The waiting state is also needed to allow for authorization of fetch attempts, which are subscriptions that expire immediately.
待ち状態もすぐに期限切れサブスクリプションしている試みを、フェッチの許可を可能にするために必要とされます。
Of course, policy may never be specified for the subscription. As a result, the server can generate a giveup event to move the waiting subscription to the terminated state. The amount of time to wait before issuing a giveup event is system dependent.
もちろん、ポリシーがサブスクリプションに指定されない可能性があります。その結果、サーバが終了状態に待機しているサブスクリプションを移動するGIVEUPイベントを生成することができます。 GIVEUPイベントを発行するまでの待機時間はシステムに依存します。
The giveup event is generated in either the waiting or pending states to destroy resources associated with unauthorized subscriptions. This event is generated when a giveup timer fires. This timer is set to a timeout value when entering either the pending or waiting states. Servers need to exercise care in selecting this value. It needs to be large in order to provide a useful user experience; a user should be able to log in days later and see that someone tried to subscribe to them. However, allocating state to unauthorized subscriptions can be used as a source of DoS attacks. Therefore, it is RECOMMENDED that servers that retain state for unauthorized subscriptions add policies which prohibit a particular subscriber from having more than some number of pending or waiting subscriptions.
GIVEUPイベントは、不正なサブスクリプションに関連付けられたリソースを破壊するために待機または保留中の状態のいずれかで生成されます。このイベントは、ときGIVEUPタイマ火災を発生させます。保留中または待機中の状態のいずれかを入力するときに、このタイマーは、タイムアウト値に設定されています。サーバはこの値を選択するには注意を払う必要があります。これは、便利なユーザー体験を提供するために大きくする必要があります。ユーザーは数日後にログインすると、誰かが彼らに加入しようとしたことを見ることができるはずです。しかし、無許可のサブスクリプションの状態を割り当てることは、DoS攻撃の源として使用することができます。したがって、不正なサブスクリプションの状態を維持するサーバは保留中または待機中のサブスクリプションの一部数よりも多くを持っていることから、特定の加入者を禁止するポリシーを追加することをお勧めします。
At any time, the server can deactivate a subscription. Deactivation implies that the subscription is discarded without a change in authorization policy. This may be done in order to trigger refreshes of subscriptions for a graceful shutdown or subscription migration operation. A related event is probation, where a subscription is terminated, and the subscriber is requested to wait some amount of time before trying again. The meaning of these events is described in more detail in Section 3.2.4 of RFC 3265 [1].
任意の時点で、サーバーは、サブスクリプションを無効にすることができます。無効化は、サブスクリプションは、認可ポリシーを変更せずに破棄されることを意味しています。これは正常なシャットダウンまたはサブスクリプション移行操作のためのサブスクリプションのリフレッシュをトリガするために行うことができます。関連イベントは、サブスクリプションが終了した保護観察、で、加入者は再び試みる前に、ある程度の時間を待つように要求されています。これらのイベントの意味は、RFC 3265のセクション3.2.4でより詳細に記載されている[1]。
A subscription can be terminated at any time because the resource associated with that subscription no longer exists. This corresponds to the noresource event.
そのサブスクリプションに関連付けられたリソースが存在しないため、サブスクリプションは、いつでも終了することはできません。これはNORESOURCEイベントに対応しています。
The server MAY generate a notification to watcherinfo subscribers on a transition of the state machine. Whether it does or not is policy dependent. However, several guidelines are defined.
サーバーは、ステート・マシンの遷移時に加入者をwatcherinfoする通知を生成してもよいです。それがないかどうかは、政策依存しています。しかし、いくつかのガイドラインが規定されています。
Consider some event package foo. A subscribes to B for events within that package. A also subscribes to foo.winfo for B. In this scenario (where the subscriber to foo.winfo is also a subscriber to foo for the same resource), it is RECOMMENDED that A receive watcherinfo notifications only about the changes in its own subscription. Normally, A will receive notifications about changes in its subscription to foo through the Subscription-State header field. This will frequently obviate the need for a separate subscription to foo.winfo. However, if such a subscription is performed by A, the foo.winfo notifications SHOULD NOT report any state changes which would not be reported (because of authorization policy) in the Subscription-State header field in notifications on foo.
一部のイベントパッケージfooを考えてみましょう。そのパッケージ内のイベントのためにBに加入しています。また、（foo.winfoの加入者はまた、同じリソースに対してfooに加入者である）このシナリオでBについてfoo.winfoに加入し、Aのみ、自身の加入の変更に関する通知をwatcherinfo受けることが推奨されます。通常、AはSubscription-Stateヘッダフィールドによってfooにそのサブスクリプションの変更に関する通知を受信します。これは、頻繁にfoo.winfoするために、別のサブスクリプションの必要性を回避します。そのようなサブスクリプションがAによって行われる場合には、foo.winfo通知がFOOの通知にSubscription-Stateヘッダフィールドで（理由は認可ポリシーの）報告されない任意の状態の変化を報告すべきではありません。
As a general rule, when a watcherinfo subscriber is authorized to receive watcherinfo notifications about more than one watcher, it is RECOMMENDED that watcherinfo notifications contain information about those watchers which have changed state (and thus triggered a notification), instead of delivering the current state of every watcher in every watcherinfo notification. However, watcherinfo notifications triggered as a result of a fetch operation (a SUBSCRIBE with Expires of 0) SHOULD result in the full state of all watchers (of course, only those watchers that have been authorized to be divulged to the watcherinfo subscriber) to be present in the NOTIFY.
原則としてwatcherinfo加入者が複数のウォッチャに関する通知をwatcherinfo受信することを許可された場合、watcherinfo通知が状態を変化（ひいては通知をトリガした）を有するものウォッチャーに関する情報を含むことが推奨され、代わりに現在の状態を送達すべてのwatcherinfo通知内のすべてのウォッチャーの。しかし、watcherinfo通知は、（0の有効期限とSUBSCRIBE）フェッチ操作の結果としてトリガすることが（もちろん、watcherinfo加入者に漏洩することを許可されているのみウォッチャー）全てのウォッチャの完全な状態をもたらすはずですNOTIFYに存在します。
Frequently, states in the subscription state machine will be transient. For example, if an authorized watcher performs a fetch operation, this will cause the state machine to be created, transition from init to active, and then from active to terminated, followed by a destruction of the FSM. In such cases, watcherinfo notifications SHOULD NOT be sent for any transient states. In the prior example, the server wouldn't send any notifications, since all of the states are transient.
多くの場合、サブスクリプション・ステート・マシン内の状態は一時的になります。認可ウォッチャフェッチ操作を行った場合、例えば、これは、ステートマシンを作成するINITからアクティブへの遷移を引き起こすであろう、そして、アクティブからFSMの破壊に続いて、終了します。このような場合には、watcherinfo通知は任意の遷移状態のために送るべきではありません。すべての状態は一時的なので、前の例では、サーバは、任意の通知を送信しません。
RFC 3265 [1] expects packages to specify how a subscriber processes NOTIFY requests in any package specific ways, and in particular, how it uses the NOTIFY requests to construct a coherent view of the state of the subscribed resource. Typically, the watcherinfo NOTIFY will only contain information about those watchers whose state has changed. To construct a coherent view of the total state of all watchers, a watcherinfo subscriber will need to combine NOTIFYs received over time. This details of this process depend on the document format. See [3] for details on the application/watcherinfo+xml format.
RFC 3265 [1]パッケージは、加入者のプロセスは、それが加入リソースの状態のコヒーレントなビューを構築するNOTIFYリクエストをどのように使用するか、任意のパッケージの特定の方法で要求を通知し、具体的にどのように指定することを期待します。典型的には、watcherinfoのみ状態変化したものウォッチャーに関する情報を含むことになるNOTIFY。すべてのウォッチャーの合計状態のコヒーレントなビューを構築するために、watcherinfo加入者は、時間をかけて受け取ったのNOTIFYを結合する必要があります。このプロセスのこの詳細については、文書の形式によって異なります。アプリケーション/ watcherinfo + xml形式の詳細については、[3]を参照してください。
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
パッケージは要求が複数のサブスクリプションをインストールすることができSUBSCRIBEフォークかどうかを示すSIPイベントフレームワークの義務。
When a user wishes to obtain watcher information for some resource for package foo, the SUBSCRIBE to the watcher information will need to reach a collection of servers that have, unioned together, complete information about all watchers on that resource for package foo. If there are a multiplicity of servers handling subscriptions for that resource for package foo (for load balancing reasons, typically), it is very likely that no single server will have the complete set of watcher information. There are several solutions in this case. This specification does not mandate a particular one, nor does it rule out others. It merely ensures that a broad range of solutions can be built.
ユーザーはパッケージfooのためのいくつかのリソースに対するウォッチャの情報を得たい場合には、1つに結合しているサーバの集合、パッケージfooのため、そのリソース上のすべてのウォッチャーに関する完全な情報に到達する必要がありますウォッチャ情報にSUBSCRIBE。 （一般的に、負荷分散の理由から）パッケージfooのためのそのリソースのサブスクリプションを扱う多数のサーバがある場合、単一のサーバがウォッチャ情報の完全なセットを持っていない可能性が非常に高いです。この場合、いくつかのソリューションがあります。この仕様は、特定の1つを強制しません。また、他の人を除外しません。それは単に、幅広いソリューションを構築できることを保証します。
One solution is to use forking. The system can be designed so that a SUBSCRIBE for watcher information arrives at a special proxy which is aware of the requirements for watcher information. This proxy would fork the SUBSCRIBE request to all of the servers which could possibly maintain subscriptions for that resource for that package. Each of these servers, whether or not they have any current subscribers for that resource, would accept the watcherinfo subscription. Each needs to accept because they may all eventually receive a subscription for that resource. The watcherinfo subscriber would receive some number of watcherinfo NOTIFY requests, each of which establishes a separate dialog. By aggregating the information across each dialog, the watcherinfo subscriber can compute full watcherinfo state. In many cases, a particular dialog might never generate any watcherinfo notifications; this would happen if the servers never receive any subscriptions for the resource.
一つの解決策は、フォークを使用することです。ウォッチャーのためのSUBSCRIBE情報は、ウォッチャ情報の要件を認識している特殊なプロキシに到着するようにシステムを設計することができます。このプロキシは、おそらくそのパッケージのそのリソースのサブスクリプションを維持することができ、すべてのサーバにSUBSCRIBEリクエストをフォークます。これらの各サーバーは、彼らはそのリソースのいずれかの現在の加入者を持っているかどうかにかかわらず、watcherinfoサブスクリプションを受け入れるだろう。それぞれのは、彼らがすべて最終的にはそのリソースのサブスクリプションを受け取ることができるので、受け入れる必要があります。 watcherinfo加入者は、別のダイアログを確立それぞれが要求を、NOTIFY watcherinfoのいくつかの数を受信します。各ダイアログを介して情報を集約することにより、watcherinfo加入者は、完全なwatcherinfo状態を計算することができます。多くの場合、特定のダイアログには、任意のwatcherinfo通知を生成しませんかもしれません。サーバはリソースに対するすべてのサブスクリプションを受け取ることはありませんならば、これは起こるでしょう。
In order for such a system to be built in an interoperable fashion, all watcherinfo subscribers MUST be prepared to install multiple subscriptions as a result of a multiplicity of NOTIFY messages in response to a single SUBSCRIBE.
相互運用可能な方法で構築されるようなシステムのために、全てwatcherinfo加入者は、SUBSCRIBE単一に応答してメッセージをNOTIFYの多数の結果として、複数のサブスクリプションをインストールする準備をしなければなりません。
Another approach for handling the server multiplicity problem is to use state agents. See Section 4.11 for details.
サーバーに多数の問題を処理するための別のアプローチは、状態のエージェントを使用することです。詳細については、セクション4.11を参照してください。
RFC 3265 [1] mandates that packages define a maximum rate of notifications for their package.
RFC 3265 [1]パッケージは、パッケージのための通知の最大レートを定義義務付け。
For reasons of congestion control, it is important that the rate of notifications not become excessive. As a result, it is RECOMMENDED that the server not generate watcherinfo notifications for a single watcherinfo subscriber at a rate faster than once every 5 seconds.
輻輳制御の理由から、通知の割合が過大にならないことが重要です。その結果、サーバはより速く回5秒以上の速度で単一watcherinfo加入者のためのwatcherinfo通知を生成しないことをお勧めします。
RFC 3265 [1] asks packages to consider the role of state agents in their design.
RFC 3265 [1]はその設計の状態エージェントの役割を検討するために、パッケージを要求します。
State agents play an important role in this package. As discussed in Section 4.9, there may be a multiplicity of servers sharing the load of subscriptions for a particular package. A watcherinfo subscription might require subscription state spread across all of those servers. To handle that, a farm of state agents can be used. Each of these state agents would know the entire watcherinfo state for some set of resources. The means by which the state agents would determine the full watcherinfo state is outside the scope of this specification. When a watcherinfo subscription is received, it would be routed to a state agent that has the full watcherinfo state for the requested resource. This server would accept the watcherinfo subscription (assuming it was authorized, of course), and generate watcherinfo notifications as the watcherinfo state changed. The watcherinfo subscriber would only have a single dialog in this case.
状態エージェントは、このパッケージで重要な役割を果たしています。セクション4.9で議論するように、特定のパッケージのサブスクリプションの負荷を共有サーバの多数が存在し得ます。 watcherinfoサブスクリプションは、これらのサーバーのすべてにまたがっサブスクリプションの状態が必要な場合があります。それを処理するために、状態の物質の農場を使用することができます。これらの状態剤のそれぞれは、リソースの一部のセットのための全体watcherinfo状態を知っているだろう。状態エージェントがフルwatcherinfo状態を決定するであろうする手段は、本明細書の範囲外です。 watcherinfoサブスクリプションが受信されると、それは要求されたリソースのための完全なwatcherinfo状態を有する状態のエージェントにルーティングされます。このサーバはwatcherinfoサブスクリプション（もちろん、それが承認されたと仮定）を受け入れ、そしてwatcherinfo状態が変化して通知をwatcherinfo生成されます。 watcherinfo加入者のみが、この場合、単一のダイアログを持っているでしょう。
The following section discusses an example application and call flows using the watcherinfo package.
次のセクションでは、サンプル・アプリケーションについて説明し、コールがwatcherinfoパッケージを使用して流れます。
In this example, a user Joe, sip:joe@example.com provides presence through the example.com presence server. Joe subscribes to his own watcher information, in order to learn about people who subscribe to his presence, so that he can approve or reject their subscriptions. Joe sends the following SUBSCRIBE request:
この例では、ユーザジョー、SIP：joe@example.comはexample.comプレゼンスサーバを介してプレゼンスを提供します。ジョーは、彼が自分のサブスクリプションを承認または拒否することができるように、彼の存在を購読する人々について学ぶために、自分のウォッチャ情報にサブスクライブします。ジョーは、次のSUBSCRIBEリクエストを送信します。
SUBSCRIBE sip:joe@example.com SIP/2.0 Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds7 From: sip:joe@example.com;tag=123aa9 To: sip:joe@example.com Call-ID: 9987@pc34.example.com CSeq: 9887 SUBSCRIBE Contact: sip:joe@pc34.example.com Event: presence.winfo Max-Forwards: 70
SUBSCRIBE SIP：joe@example.com SIP / 2.0経由：SIP / 2.0 / UDP pc34.example.com;ブランチ= z9hG4bKnashds7から：SIP：joe@example.com;タグ= 123aa9へ：SIP：joe@example.comコール-ID：9987@pc34.example.comのCSeq：9887は、連絡先をSUBSCRIBE：SIP：joe@pc34.example.comイベント：マックス・フォワードpresence.winfo：70
The server responds with a 401 to authenticate, and Joe resubmits the SUBSCRIBE with credentials (message not shown). The server then authorizes the subscription, since it allows Joe to subscribe to his own watcher information for presence. It responds with a 200 OK:
サーバが認証するために401で応答し、そしてジョーはクレデンシャル（メッセージは示していない）とSUBSCRIBEを再送信します。それはジョーが存在するために、自分のウォッチャ情報を購読することができますので、その後、サーバーは、サブスクリプションを許可します。これは、200 OKで応答します。
SIP/2.0 200 OK Via: SIP/2.0/UDP pc34.example.com;branch=z9hG4bKnashds8 ;received=192.0.2.8 From: sip:joe@example.com;tag=123aa9 To: sip:joe@example.com;tag=xyzygg Call-ID: 9987@pc34.example.com CSeq: 9988 SUBSCRIBE Contact: sip:server19.example.com Expires: 3600 Event: presence.winfo
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP pc34.example.com;ブランチ= z9hG4bKnashds8は、受信= 192.0.2.8から：SIP：joe@example.com;タグ= 123aa9へ：SIP：joe@example.com。タグ= xyzyggコール-ID：9987@pc34.example.comのCSeq：9988は、連絡先をSUBSCRIBE：SIP：server19.example.com有効期限：3600イベント：presence.winfoを
The server then sends a NOTIFY with the current state of presence.winfo for joe@example.com:
その後、サーバーはjoe@example.comためpresence.winfoの現在の状態をNOTIFYを送信します。
NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ...
NOTIFY SIP：joe@pc34.example.com SIP / 2.0経由：SIP / 2.0 / UDP server19.example.com;ブランチ= z9hG4bKnasaiiから：SIP：joe@example.com;タグ= xyzyggへ：SIP：ジョー@例。 COM;タグ= 123aa9のCall-ID：9987@pc34.example.comのCSeq：1288問い合わせNOTIFY：一口：server19.example.comイベント：サブスクリプションのステートpresence.winfo：アクティブマックス・フォワード：70のContent-Type：アプリケーション/ watcherinfo + XMLコンテンツ-長さ：...
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="0" state="full"> <watcher-list resource="sip:joe@example.com" package="presence"> <watcher id="77ajsyy76" event="subscribe" status="pending">sip:A@example.com</watcher> </watcher-list> </watcherinfo>
<watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "0" の状態= "フル"> <xmlのバージョン= "1.0"？> <ウォッチャーリストリソース= "一口：ジョー@例.COM」パッケージ= "存在"> <ウォッチャーID = "77ajsyy76" イベント= "加入" ステータス= "" 保留> SIP：A@example.com </ウォッチャー> </ウォッチャーリスト> </ watcherinfo>
Joe then responds with a 200 OK to the NOTIFY:
ジョーはその後、NOTIFYに200 OKで応答します。
SIP/2.0 200 OK Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaii ;received=192.0.2.7 From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1288 NOTIFY
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP server19.example.com;ブランチ= z9hG4bKnasaii;から= 192.0.2.7を受け取っ：SIP：;：SIP：joe@example.comにタグ= xyzygg joe@example.com。タグ= 123aa9のCall-ID：9987@pc34.example.comのCSeq：1288は、NOTIFY
The NOTIFY tells Joe that user A currently has a pending subscription. Joe then authorizes A's subscription through some means. This causes a change in the status of the subscription (which moves from pending to active), and the delivery of another notification:
NOTIFYそのユーザAが現在保留中のサブスクリプションを持っているジョーに伝えます。ジョーはその後、いくつかの手段を介してAのサブスクリプションを許可します。これは、（アクティブにペンディングから移動）サブスクリプション、および他の通知の配信のステータスの変化を引き起こします。
NOTIFY sip:joe@pc34.example.com SIP/2.0 Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY Contact: sip:server19.example.com Event: presence.winfo Subscription-State: active Max-Forwards: 70 Content-Type: application/watcherinfo+xml Content-Length: ...
NOTIFY SIP：joe@pc34.example.com SIP / 2.0経由：SIP / 2.0 / UDP server19.example.com;ブランチ= z9hG4bKnasaijから：SIP：joe@example.com;タグ= xyzyggへ：SIP：ジョー@例。 COM;タグ= 123aa9のCall-ID：9987@pc34.example.comのCSeq：1289問い合わせNOTIFY：一口：server19.example.comイベント：サブスクリプションのステートpresence.winfo：アクティブマックス・フォワード：70のContent-Type：アプリケーション/ watcherinfo + XMLコンテンツ-長さ：...
<?xml version="1.0"?> <watcherinfo xmlns="urn:ietf:params:xml:ns:watcherinfo" version="1" state="partial"> <watcher-list resource="sip:joe@example.com" package="presence"> <watcher id="77ajsyy76" event="approved" status="active">sip:A@example.com</watcher> </watcher-list> </watcherinfo>
<watcherinfoのxmlns = "壷：IETF：のparams：XML：NS：watcherinfo" バージョン= "1" の状態= "部分"> <xmlのバージョン= "1.0"？> <ウォッチャーリストリソース= "一口：ジョー@例A@example.com </ウォッチャー> </ウォッチャーリスト> </ watcherinfo>：.COM」パッケージ= "存在"> <ウォッチャーID = "77ajsyy76" イベント= "" ステータス= "" アクティブ> SIP承認
B then responds with a 200 OK to the NOTIFY:
Bは、NOTIFYに200 OKで応答します。
SIP/2.0 200 OK Via: SIP/2.0/UDP server19.example.com;branch=z9hG4bKnasaij ;received=192.0.2.7 From: sip:joe@example.com;tag=xyzygg To: sip:joe@example.com;tag=123aa9 Call-ID: 9987@pc34.example.com CSeq: 1289 NOTIFY
SIP / 2.0 200 OK経由：SIP / 2.0 / UDP server19.example.com;ブランチ= z9hG4bKnasaij;から= 192.0.2.7を受け取っ：SIP：;：SIP：joe@example.comにタグ= xyzygg joe@example.com。タグ= 123aa9のCall-ID：9987@pc34.example.comのCSeq：1289は、NOTIFY
Watcher information generates notifications about changes in the state of watchers for a particular resource. It is possible for a single resource to have many watchers, resulting in the possibility of a large volume of notifications. This makes watcherinfo subscription a potential tool for denial of service attacks. Preventing these can be done through a combination of sensible authorization policies and good operating principles.
ウォッチャー情報は、特定のリソースの監視者の状態の変化についての通知を生成します。単一のリソースは、通知の大量の可能性が生じ、多くのウォッチャーを有することが可能です。これはwatcherinfoサブスクリプションサービス拒否攻撃の潜在的なツールになります。これらを防止することは賢明な認可ポリシーとの良好な動作原理を組み合わせて行うことができます。
First, when a resource has a lot of watchers, watcherinfo subscriptions to that resource should only be allowed from explicitly authorized entities, whose identity has been properly authenticated. That prevents a watcherinfo NOTIFY stream from being generated from subscriptions made by an attacker.
リソースはウォッチャーの多くを持っている場合まず、そのリソースへのサブスクリプションwatcherinfoのみアイデンティティが正常に認証された明示的に許可されたエンティティから許されるべきです。つまり、攻撃者によって行われたサブスクリプションから生成されてからNOTIFY watcherinfo流れを防止します。
Even when watcherinfo subscriptions are properly authenticated, there are still potential attacks. For example, consider a valid user, T, who is to be the target of an attack. T has subscribed to their own watcher information. The attacker generates a large number of subscriptions (not watcherinfo subscriptions). If the server creates subscription state for unauthenticated subscriptions, and reports those changes in watcherinfo notifications, user T would receive a flood of watcherinfo notifications. In fact, if the server generates a watcherinfo notification when the subscription is created, and another when it is terminated, there will be an amplification by a factor of two. The amplification would actually be substantial if the server generates full state in each watcherinfo notification. Indeed, the amount of data sent to T would be the square of the data generated by the attacker! Each of the N subscriptions generated by the attacker would result in a watcherinfo NOTIFY being sent to T, each of which would report on up to N watchers. To avoid this, servers should never generate subscription state for unauthenticated SUBSCRIBE requests, and should never generate watcherinfo notifications for them either.
watcherinfoサブスクリプションが正しく認証された場合でも、まだ潜在的な攻撃があります。例えば、攻撃の対象となる有効なユーザー、Tを、考えます。 Tは独自のウォッチャ情報に加入しています。攻撃者は、サブスクリプションの数が多い（サブスクリプションをwatcherinfoない）を生成します。サーバが認証されていないサブスクリプションのサブスクリプションの状態を作成し、watcherinfo通知でそれらの変更を報告した場合、ユーザーのTはwatcherinfo通知の洪水を受け取ることになります。実際には、サーバーがwatcherinfo通知を生成した場合、サブスクリプションが作成されたとき、それが終了すると、別のは、2倍に増幅があるでしょう。サーバは、各watcherinfo通知に完全な状態を生成する場合、増幅は、実際にはかなりのであろう。確かに、Tに送信されるデータの量は、攻撃者によって生成されたデータの二乗になります！ watcherinfoをもたらす攻撃者によって生成されたN個のサブスクリプションの各々は、その各々がNウォッチャーまでに報告する、Tに送信されるNOTIFY。これを避けるために、サーバが認証されていないため、サブスクリプションの状態を生成することはありませんSUBSCRIBEリクエスト、およびいずれかのそれらの通知をwatcherinfo生成することはありません。
Watcher information indicates what users are interested in a particular resource. Depending on the package and the resource, this can be very sensitive information. For example, in the case of presence, the watcher information for some user represents the friends, family, and business relations of that person. This information can be used for a variety of malicious purposes.
ウォッチャー情報は、ユーザーが特定のリソースに関心があるかを示します。パッケージとリソースに応じて、これは非常に敏感な情報とすることができます。例えば、存在する場合には、一部のユーザーのためのウォッチャ情報は、その人の友人、家族、およびビジネス関係を表しています。この情報は、悪質な様々な目的のために使用することができます。
One way in which this information can be revealed is eavesdropping. An attacker can observe watcherinfo notifications, and learn this information. To prevent that, watchers MAY use the sips URI scheme when subscribing to a watcherinfo resource. Notifiers for watcherinfo MUST support TLS and sips as if they were a proxy (see Section 26.3.1 of RFC 3261).
この情報を明らかにすることができる1つの方法は、盗聴です。攻撃者は、通知をwatcherinfo観察し、この情報を知ることができます。 watcherinfoリソースに加入したときにそれを防ぐために、ウォッチャーは一口URIスキームを使用するかもしれません。彼らはプロキシが（RFC 3261のセクション26.3.1を参照）であるかのようにwatcherinfoためのNotifierは、TLSおよびSIPをサポートしなければなりません。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
SIP暗号化は、S / MIMEを使用して、両方のSUBSCRIBE及びNOTIFYリクエストを送信するためのエンドツーエンドの使用され得ます。
Another way in which this information can be revealed is through spoofed subscriptions. These attacks can be prevented by authenticating and authorizing all watcherinfo subscriptions. In order for the notifier to authenticate the subscriber, it MAY use HTTP Digest (Section 22 of RFC 3261). As a result, all watchers MUST support HTTP Digest. This is a redundant requirement, however, since all SIP user agents are mandated to support it by RFC 3261.
この情報を明らかにすることができるもう一つの方法は、偽装されたサブスクリプションを介して行われます。これらの攻撃は、すべてのwatcherinfoサブスクリプションを認証および認可することによって防止することができます。加入者を認証するための通知ためには、HTTPダイジェスト（RFC 3261のセクション22）を使用することができます。その結果、すべてのウォッチャーは、HTTPダイジェストをサポートしなければなりません。すべてのSIPユーザエージェントは、RFC 3261によって、それをサポートするように義務付けられているので、これは、しかし、冗長な要件です。
This specification registers an event template package as specified in Section 6.2 of RFC 3265 [1].
この仕様は、RFC 3265のセクション6.2で指定されたイベント・テンプレート・パッケージを登録する[1]。
Package Name: winfo
パッケージ名：winfo
Template Package: yes
テンプレートパッケージ：はい
Published Specification: RFC 3857
公開された仕様：RFC 3857
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
人への問い合わせ先：ジョナサン・ローゼンバーグ、jdrosen@jdrosen.netを。
The authors would like to thank Adam Roach, Allison Mankin and Brian Stucker for their detailed comments.
作者は彼らの詳細なコメントのためにアダムローチ、アリソンマンキンとブライアンStuckerに感謝したいと思います。
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1]ローチ、A.B.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[3]ローゼンバーグ、J.、 "ウォッチャー情報のための拡張マークアップ言語（XML）ベースのフォーマット"、RFC 3858、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] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004.
[5]ローゼンバーグ、J.、RFC 3856、2004年7月 "セッション開始プロトコル（SIP）のためのプレゼンスイベントパッケージ"。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
ジョナサン・ローゼンバーグdynamicsoft 600 Lanidexプラザパーシッパニー、NJ 07054
EMail: jdrosen@dynamicsoft.com
メールアドレス：jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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に情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。