[要約] RFC 3857は、SIP（Session Initiation Protocol）のためのウォッチャー情報イベントテンプレートパッケージに関する規格です。このRFCの目的は、SIPセッションの監視者情報を効果的に伝達するためのテンプレートを提供することです。
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)
セッション開始プロトコル（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）The Internet Society（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）イベントフレームワークのウォッチャー情報テンプレートパッケージを定義します。ウォッチャー情報とは、特定のイベントパッケージ内の特定のリソースにサブスクライブされたユーザーのセットを指します。ユーザーが購読したり、登録されていない、承認されたり、拒否されたりするにつれて、Watcher情報は動的に変更されます。ユーザーはこの情報を購読することができ、したがって、変更について学ぶことができます。このイベントパッケージは、それ自体を含むあらゆるイベントパッケージに適用できるため、テンプレートパッケージです。
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システムに関連するイベントのサブスクリプションおよび通知の一般的なフレームワークを定義します。フレームワークは、サブスクライブと通知のメソッドを定義し、パッケージの概念を導入します。パッケージは、特定のクラスのイベントへのイベントフレームワークの具体的なアプリケーションです。たとえば、ユーザーの存在のためにパッケージが定義されています[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」で示されています。存在感などのイベントパッケージには、そのパッケージのリソースの状態を確認しようとするユーザーが作成または要求したサブスクリプションのセット（おそらく空のセット）が存在します。新しいサブスクリプションがユーザーによって要求され、古いサブスクリプションが失効し、サブスクリプションがそのリソースの所有者によって承認または拒否されると、このサブスクリプションのセットが時間とともに変更されます。特定のイベントパッケージの特定のリソースにサブスクライブし、サブスクリプションの状態はWatcher Informationと呼ばれます。この状態自体は動的であるため、変更について学ぶために購読することは合理的です。ウォッチャー情報イベントテンプレートパッケージは、まさにそれを容易にすることを目的としています - 別のパッケージのリソースへのサブスクリプションの状態を追跡します。
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」を追加することによって構築されます。たとえば、存在感に加入した人々のセットは、「存在感」パッケージによって定義されます。
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.
このドキュメントでは、キーワードが「必須」、「必須」、「必須」、「shall」、「shall "、" low "of" bould "、" becommented "、"、 "、"、 "optional"BCP14、RFC 2119 [2]で説明されているように解釈され、準拠の実装の要件レベルを示します。
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サブスクリプションの一部として送信された通知リクエストを指します。「サブスクリプション」、「サブスクライバー」、および「通知」という用語が資格のない使用されている場合、「内側」のサブスクリプション、サブスクライバー、および通知（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
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: ...
<?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> 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.
<？xml version = "1.0"？> <watcherinfo xmlns = "urn：ietf：params：xml：ns：watcherinfo"バージョン= "0" state = "full"> <watcher-list resource = "sip：b@例.com "package =" expension "> <watcher id =" 7768a77s "event =" subscribe "pestation =" pesting "> sip：a@example.com </watcher> </watcher-list> </watcherinfo>Aが購読していること、およびサブスクリプションが保留中であること（つまり、承認を待っています）。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.
アプリケーションは、付加価値のある機能を提供するために、ウォッチャー情報を購読できます。アプリケーションの例は、「ブラックリストアラート」です。このシナリオでは、アプリケーションサーバーは既知の「悪者」のリストを維持しています。ユーザーのJoeは、おそらくWebページにアクセスしてURIの存在に入ることにより、アプリケーションプロバイダーとのサービスにサインアップします。Application Serverは、Joeの存在に関するWatcher情報を購読しています。誰かがJoeのユーザーの存在を購読しようとすると、Watcher Info Subscriptionの結果としてアプリケーションがこのサブスクリプションを学びます。既知の悪者のデータベースに対してウォッチャーのURIをチェックします。試合がある場合、それはジョーにメールを送信し、これについて彼に知らせます。
For this application to work, Joe needs to make sure that the application is allowed to subscribe to his presence.winfo.
このアプリケーションが機能するためには、ジョーはアプリケーションが彼の存在を購読することを許可されていることを確認する必要があります。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 [1]のセクション4.4で定義されているイベントパッケージを指定するために必要な詳細を記入します。
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]は、サブスクライブリクエストのボディの使用法を定義するために、パッケージまたはテンプレートパッケージ定義が必要です。
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.
ウォッチャー情報の購読リクエストにはボディが含まれる場合があります。このボディは、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:
ウォッチャー情報パッケージの購読リクエストは、ボディなしで送信される場合があります。これは、デフォルトの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サブスクライバーが知ることが許可されているすべてのウォッチャーのリスト）。WatcherInfoの通知は、Watcher Stateの変更からトリガーされ、州が変更されたWatcherに関する情報のみが含まれています。
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]は、通知リクエストで許可されたボディタイプのセットを記述し、サブスクライブリクエストに受け入れヘッダーフィールドがない場合に使用されるデフォルト値を指定するために、パッケージ定義を必要とします。
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形式をサポートする必要があり、サブスクライブリクエストに存在するAcceptヘッダーフィールドに、MIMEタイプ、アプリケーション/WatcherINFO XMLをリストする必要があります。
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通知は、サブスクライブリクエストのAccept Headerフィールドで指定された形式の1つでなければなりません。受け入れヘッダーフィールドが存在しない場合、通知は[3]で説明されているアプリケーション/WatcherInfo 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]は、特に認証と承認に関して、通知者でサブスクライブリクエストのパッケージ固有の処理を定義する必要があることを指定します。
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サブスクリプションは認証され、承認前に承認される必要があります。SIPを通じて利用可能な手法のいずれかを使用して、Digest、S/MIME、TLS、またはその他の輸送固有のメカニズムを使用して、認証を実行できます[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の認定サブスクライバーである場合、ユーザー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.winfo.winfoに任意のfooに対してサブスクライブすることを許可することをお勧めします。また、デフォルトでは、サーバーは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サブスクライブリクエストのリクエストURIでURIによって定義され、WatcherInfoサブスクリプションの親イベントパッケージがあります。Parent Eventパッケージは、WatcherINFOサブスクライブリクエストからイベントヘッダーフィールドの値からトレーニング「.winfo」を削除することにより取得されます。watcherinfoサブスクリプションのイベントヘッダーフィールドに「finess.winfo」の値がある場合、親イベントパッケージは「存在感」です。イベントヘッダーフィールドに「conession.winfo.winfo」の値がある場合、親イベントパッケージは「finess.winfo」です。通常、WatcherInfoサブスクライブのリクエストURIのURIは、ドメイン内の記録アドレスを識別します。その場合、監視されるサブスクリプションのセットは、WatcherInfoサブスクライブのリクエストURIでリソースに作成された親イベントパッケージのすべてのサブスクリプションです。ただし、リクエストURIには、より大きなリソースコレクションへのサブスクリプションを含む、サブスクリプションのセットを識別するURIを含めることができます。たとえば、sip：all-resources@example.comは、すべてのリソースを参照するためにExample.com内で定義される場合があります。その場合、sip：all-resources@example.comへの「存在感」のwatcherinfoサブスクリプションは、example.com内のリソースのプレゼンスサブスクリプションの状態が変更されます。WatcherInfo Notifierは、監視されているサブスクリプションの状態が変更されるたびに通知を生成する場合があります。
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は、サーバーが維持するサブスクリプション状態の機械のモデルにすぎないことに注意することが重要です。実装は、実装固有の方法で独自の状態マシンをこれにマッピングします。
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.
サブスクリプションの基礎となる状態マシンを図1に示します。これは、ほぼ完全にRFC 3265 [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.
サブスクライブリクエストが届くと、サブスクリプションFSMがinit状態に作成されます。この状態は一時的です。次の状態は、サブスクリプションのポリシーが存在するかどうかに依存します。サブスクリプションが禁止されていると判断した既存のポリシーがある場合、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.
サブスクリプションが到着した場合、存在する許可ポリシーが存在しない場合、サブスクリプションは保留中の状態に移動します。この状態では、サーバーは承認決定を待っています。存在状態の変更で通知は生成されません（RFC 3265 [1]に従って初期通知が配信されます）が、サブスクリプションFSMは維持されます。承認の決定が肯定的に戻った場合、サブスクリプションは承認され、アクティブな状態に移動します。承認が否定されている場合、サブスクリプションは拒否され、FSMは終了状態になります。承認の決定には非常に長い時間がかかる可能性があります。実際、サブスクリプション自体が期限切れになるまで、承認の決定が届くことはありません。保留中のサブスクリプションがタイムアウトに苦しむ場合、それは待機状態に移動します。メモリとCPUリソースを不正なサブスクリプション状態に割り当てることを懸念しているため、サーバーはいつでも保留中または待機のサブスクリプションを終了することを決定できます。これが発生した場合、サーバーによって「giveup」イベントが生成され、サブスクリプションを終了するように移動します。
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は終了状態に入り、破壊されます。さらに、同じウォッチャーから別のサブスクリプションが同じイベントパッケージ、イベントパッケージパラメーター、およびサブスクライブリクエストの本文でフィルターを受け取った場合（最初は最初に存在していた場合）、FSMは終了状態に入ります「giveup」イベント、そして破壊されます。この遷移は、同一のパラメーターを持つ新しいサブスクリプションが到着すると、保留中の状態に入り、以前のサブスクリプションの待機状態が冗長になるために発生します。待機状態の目的は、ユーザーがいつでもWatcherInfo状態を取得し、承認決定が必要な（そして再び到着する可能性がある）サブスクリプションを学ぶことができるようにすることです。例を考えてみましょう。Bに登録されているaは、このサブスクリプションに関するポリシーを定義していないため、保留中の状態に移行します。Bは「オンライン」ではないため、サブスクリプションを承認するためにBのソフトウェアエージェントに連絡することはできません。サブスクリプションの有効期限が切れます。破壊されたとしましょう。bログインし、Watcherinfo状態を取得します。Aからのサブスクリプションの記録はないため、A。Bログオフからのサブスクリプションについてはポリシー決定は行われません。サブスクリプションをresedします。もう一度、ポリシーが定義されていないため、サブスクリプションは保留中です。このプロセスは無期限に継続する可能性があります。待機状態は、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 Timerが発射すると生成されます。このタイマーは、保留中または待機状態のいずれかを入力するときにタイムアウト値に設定されます。サーバーは、この値を選択する際にケアを行使する必要があります。有用なユーザーエクスペリエンスを提供するためには、大きくする必要があります。ユーザーは数日後にログインして、誰かがそれらを購読しようとしたことを確認できるはずです。ただし、状態を不正なサブスクリプションに割り当てることは、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 [1]のセクション3.2.4で詳細に説明しています。
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を検討してください。Aは、そのパッケージ内のイベントについてBを購読します。また、Bのfoo.winfoを購読しています。このシナリオ（Foo.winfoへのサブスクライバーも同じリソースのためにFooのサブスクライバーでもあります）では、WatcherInfoの通知が独自のサブスクリプションの変更についてのみ通知することをお勧めします。通常、Aは、サブスクリプション状態のヘッダーフィールドを介してFOOのサブスクリプションの変更に関する通知を受け取ります。これにより、foo.winfoの個別のサブスクリプションが必要になります。ただし、そのようなサブスクリプションがAによって実行された場合、Foo.winfo通知は、FOOの通知でサブスクリプションステートヘッダーフィールドに報告されない状態の変更を報告してはなりません。
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の通知を複数のWatcherに受信することを許可されている場合、WatcherInfoの通知には、現在の状態を配信する代わりに、状態を変更した（したがって通知をトリガーした）ウォッチャーに関する情報を含めることをお勧めします。すべてのWatcherinfo通知のすべてのウォッチャーの。ただし、フェッチ操作の結果としてトリガーされたWatcherInfo通知（0の有効期限が切れているサブスクライブ）は、すべてのウォッチャーの完全な状態になるはずです（もちろん、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]は、パッケージがパッケージに固有の方法でリクエストを通知する方法、特に通知要求を使用してサブスクライブリソースの状態のコヒーレントビューを作成する方法を指定することをパッケージに期待しています。通常、Watcherinfo Notifyには、状態が変更されたウォッチャーに関する情報のみが含まれます。すべてのウォッチャーの総状態の一貫したビューを構築するには、WatcherINFOのサブスクライバーは、受け取った通知を時間の経過とともに組み合わせる必要があります。このプロセスの詳細は、ドキュメント形式に依存します。[3] Application/WatcherInfo XML形式の詳細については、[3]を参照してください。
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
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のリソースのWatcher情報を取得したい場合、Watcher情報を購読すると、パッケージFOOのリソースに関するすべてのウォッチャーに関する完全な情報を完全に統合したサーバーのコレクションにアクセスする必要があります。パッケージFOOのリソースのサブスクリプションを処理するサーバーの多数のサーバーがある場合（通常、ロードバランスの理由で、通常）、単一のサーバーがウォッチャー情報の完全なセットを持つことはありません。この場合にはいくつかの解決策があります。この仕様は特定の仕様を義務付けるものではなく、他の仕様も除外しません。幅広いソリューションを構築できることを保証するだけです。
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.
解決策の1つは、フォーキングを使用することです。このシステムは、ウォッチャー情報の購読がウォッチャー情報の要件を認識している特別なプロキシに到着するように設計できます。このプロキシは、そのパッケージのリソースのサブスクリプションを維持できる可能性のあるすべてのサーバーにサブスクライブリクエストをフォークします。これらの各サーバーは、そのリソースの現在のサブスクライバーを持っているかどうかにかかわらず、WatcherINFOサブスクリプションを受け入れます。最終的にそのリソースのサブスクリプションを受信する可能性があるため、それぞれを受け入れる必要があります。watcherinfoのサブスクライバーは、いくつかの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サブスクライバーを、単一の購読に応じて多数の通知メッセージの結果として複数のサブスクリプションをインストールする準備をする必要があります。
Another approach for handling the server multiplicity problem is to use state agents. See Section 4.11 for details.
サーバーの多様性の問題を処理するためのもう1つのアプローチは、状態エージェントを使用することです。詳細については、セクション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秒ごとに1回よりも速いレートで、単一の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:
この例では、ユーザーJoe、sip：joe@example.comは、example.com Presenceサーバーを通じて存在感を提供します。ジョーは、彼の存在を購読する人々について学ぶために、彼自身のウォッチャー情報を購読しています。Joeは次の購読リクエストを送信します。
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
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で応答して認証され、Joeはサブスクライブを資格情報で再送信します（メッセージは表示されていません）。その後、サーバーはサブスクリプションを承認します。これにより、ジョーは存在のために自分のウォッチャー情報を購読できるようにするためです。それは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 The server then sends a NOTIFY with the current state of presence.winfo for joe@example.com:
sip/2.0 200 ok via：sip/2.0/udp pc34.example.com; branch = z9hg4bknashds8;受信= 192.0.2.8 from：sip：joe@example.com; tag = 123aa9 to：sip：joe@example.com;タグ= xyzygg call-id：9987@pc34.example.com cseq：9988 subscribe連絡先：sip：server19.example.com有効期限：3600イベント：fesencion.winfoサーバーは、現在のプレゼンスの状態で通知を送信します。joe@example.com：
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: ...
<?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>
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 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:
sip/2.0 200 ok via：sip/2.0/udp server19.example.com; branch = z9hg4bknasaii;受信= 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に伝えます。その後、ジョーは何らかの手段で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: ...
<?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>
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
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のサブスクリプションは、アイデンティティが適切に認証されている明示的に承認されたエンティティからのみ許可されるべきです。これにより、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に送信されるデータの量は、攻撃者によって生成されたデータの平方になります！攻撃者によって生成された各nサブスクリプションは、watcherinfoがtに送信されるように通知され、それぞれがnウォッチャーまで報告されます。これを回避するために、サーバーは、認定されていないサブスクライブリクエストのためにサブスクリプション状態を生成してはなりません。また、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リソースを購読するときにSIPS URIスキームを使用する場合があります。watcherinfoの通知者は、まるでプロキシであるかのようにTLSとSIPをサポートする必要があります（RFC 3261のセクション26.3.1を参照）。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
S/MIMEを使用したSIP暗号化は、サブスクライブと通知の両方のリクエストを送信するためにエンドツーエンドを使用できます。
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.
連絡先：Jonathan Rosenberg、jdrosen@jdrosen.net。
The authors would like to thank Adam Roach, Allison Mankin and Brian Stucker for their detailed comments.
著者は、詳細なコメントをしてくれたAdam Roach、Allison Mankin、Brian Stuckerに感謝したいと思います。
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[1] Roach、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format for Watcher Information", RFC 3858, August 2004.
[3] Rosenberg、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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[5] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, July 2004.
[5] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年7月。
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Jonathan Rosenberg Dynamicsoft 600 Lanidex Plaza Parsippany、NJ 07054
EMail: jdrosen@dynamicsoft.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
著作権（c）The Internet Society（2004）。この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われた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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。