RFC3857 日本語訳
3857 A Watcher Information Event Template-Package for the SessionInitiation Protocol (SIP). J. Rosenberg. August 2004. (Format: TXT=46221 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Rosenberg Request for Comments: 3857 dynamicsoft Category: Standards Track August 2004
コメントを求めるワーキンググループJ.ローゼンバーグの要求をネットワークでつないでください: 3857dynamicsoft Category: 標準化過程2004年8月
A Watcher Information Event Template-Package for
the Session Initiation Protocol (SIP)
セッション開始プロトコルのためのウォッチャー情報イベントテンプレートパッケージ(一口)
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはSession Initiationプロトコル(SIP)イベント枠組みのためのウォッチャー情報テンプレートパッケージを定義します。 ウォッチャー情報は特定のイベントパッケージの中の特定のリソースに申し込まれたユーザのセットについて言及します。 ユーザが申し込むか、外すか、承認されているか、または拒絶されるとき、ウォッチャー情報はダイナミックに変化します。 ユーザは、この情報に加入して、したがって、それへの変化に関して学ぶことができます。 それ自体を含むどんなイベントパッケージにもそれを適用できるので、このイベントパッケージはテンプレートパッケージです。
Rosenberg Standards Track [Page 1] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[1ページ]。
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
1. 序論… 2 2. 用語… 3 3. 用法シナリオ… 3 3.1. 存在認可… 4 3.2. ブラックリスト警戒… 5 4. 定義をパッケージしてください… 5 4.1. イベントパッケージ名… 5 4.2. イベントパッケージパラメタ… 5 4.3. ボディーを申し込んでください… 6 4.4. 購読持続時間… 6 4.5. ボディーに通知してください… 7 4.6. より多くのNotifierに処理する、要求を申し込んでください… 7 4.7. Notifier世代、要求に通知してください… 8 4.7.1. 購読州のマシン… 9 4.7.2. 州のマシンを適用します… 11 4.8. 加入者、処理する、要求に通知してください… 12 4.9. 股状の要求の取り扱い… 12 4.10. 通知の速度… 13 4.11. エージェントを述べてください… 13 5. 例の用法… 14 6. セキュリティ問題… 17 6.1. サービス妨害は攻撃されます… 17 6.2. 機密情報を明かします… 17 7. IANA問題… 18 8. 承認… 18 9. 標準の参照… 18 10. 有益な参照… 19 11. 作者のアドレス… 19 12. 完全な著作権宣言文… 20
1. Introduction
1. 序論
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.
Session Initiationプロトコル(SIP)イベント枠組みはRFC3265[1]で説明されます。 出来事はSIPシステムに関係しました。購読のための一般的な枠組みを定義する、通知、枠組みが方法を定義する、登録、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イベントパッケージのすべての特性があります。 しかしながら、それは、いつもある他のイベントパッケージに関連していて、いつもどんなイベントパッケージにも適用できます、テンプレートパッケージ自体を含んでいて。
Rosenberg Standards Track [Page 2] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[2ページ]。
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"パッケージによって定義されます。
2. Terminology
2. 用語
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP14, RFC 2119 [2] and indicate requirement levels for compliant implementations.
本書では、キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[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購読の一部として送られたNOTIFY要求を示します。 用語「購読」、「加入者」、および「通知」がそうときに、資格がない状態で使用されて、「内側」の購読、加入者、および通知を参照します--watcherinfo購読でモニターされているもの。 また、私たちは、「内側」のリソースに加入者を差し向けるのに「ウォッチャー」という用語を使用します。 ウォッチャーに関する情報はwatcherinfo購読で報告されます。
3. Usage Scenarios
3. 用法シナリオ
There are many useful applications for the watcher information template-package.
ウォッチャー情報テンプレートパッケージの多くの役に立つ利用があります。
Rosenberg Standards Track [Page 3] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[3ページ]。
3.1. Presence Authorization
3.1. 存在認可
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の存在のためのウォッチャー情報への登録:
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
一口: 登録、 B@example.com SIP/2.0Via: 一口/2.0/UDP pc34.example.com; ブランチ=z9hG4bKnashds7From: 一口: B@example.com;tag は123s8a To:と等しいです。 一口: B@example.com Call-ID: 前方へ 9987@pc34.example.com マックス: 70CSeq: 9887は接触を申し込みます: 一口: 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はウォッチャー情報状態の変化の通知を得ます:
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.0Via: 一口/2.0/UDP server.example.com; ブランチ=z9hG4bKna66g From: 一口: B@example.com;tag はxyz887To:と等しいです。 一口: B@example.com;tag は123s8a Call-IDと等しいです: 前方へ 9987@pc34.example.com マックス: 70CSeq: 1288は接触に通知します: 一口: B@server.example.com Event: presence.winfoコンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
<?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>
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= B@example.com 」パッケージ=、「存在、「><ウォッチャーイド="7768a77s"イベントが「申し込んでください」という状態=と等しい、「未定である、「>一口: A@example.com 、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
Rosenberg Standards Track [Page 4] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[4ページ]。
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はその購読のための方針を設定できます。
3.2. Blacklist Alerts
3.2. ブラックリスト警戒
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.
アプリケーションは、付加価値が付いた特徴を提供するためにウォッチャー情報に加入できます。 例のアプリケーションは「ブラックリスト警戒」です。 このシナリオでは、アプリケーション・サーバーは知られている「悪者」のリストを維持します。 ユーザ(ジョー)はアプリケーションプロバイダーでサービスに申し込みをします、おそらく、ウェブページに行って、彼の存在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に加入できるのを確実にする必要があります。
4. Package Definition
4. パッケージ定義
This section fills in the details needed to specify an event package as defined in Section 4.4 of RFC 3265 [1].
このセクションはRFC3265[1]のセクション4.4で定義されるようにイベントパッケージを指定するのに必要である詳細に記入します。
4.1. Event Package Name
4.1. イベントパッケージ名
RFC 3265 [1] requires package definitions to specify the name of their package or template-package.
RFC3265[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"は妥当なパッケージ名です。
4.2. Event Package Parameters
4.2. イベントパッケージパラメタ
RFC 3265 [1] requires package and template-package definitions to specify any package specific parameters of the Event header field.
RFC3265[1]はパッケージを必要とします、そして、いずれも指定するテンプレートパッケージ定義はEventヘッダーフィールドの特定のパラメタをパッケージします。
No package specific Event header field parameters are defined for this event template-package.
どんなパッケージの特定のEventヘッダーフィールドパラメタもこのイベントテンプレートパッケージのために定義されません。
Rosenberg Standards Track [Page 5] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[5ページ]。
4.3. SUBSCRIBE Bodies
4.3. ボディーを申し込んでください。
RFC 3265 [1] requires package or template-package definitions to define the usage, if any, of bodies in SUBSCRIBE requests.
RFC3265[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通知は状態が変化したウォッチャーの情報を含むだけです。
Of course, the server can apply any policy it likes to the subscription.
もちろん、サーバはそれが購読に好きであるどんな方針も当てはまることができます。
4.4. Subscription Duration
4.4. 購読持続時間
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時間任意に選びます。 しかしながら、クライアントSHOULDは、彼らの都合のよい持続時間を指定するのにExpiresヘッダーフィールドを使用します。
Rosenberg Standards Track [Page 6] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[6ページ]。
4.5. NOTIFY Bodies
4.5. ボディーに通知してください。
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.
RFC3265[1]が、Acceptヘッダーフィールドが全くないとNOTIFY要求で許容セットのボディータイプについて説明して、デフォルト値を指定するパッケージ定義が使用されているのを必要とする、登録、要求。
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加入者とnotifiersは[3]で説明されたアプリケーション/watcherinfo+xml形式を支持しなければならなくて、MIMEの種類を記載しなければなりません、アプリケーション/watcherinfo+xml、中の現在のどんなAcceptヘッダーフィールドでも登録、要求。
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].
もちろん、中でAcceptヘッダーフィールドで指定された形式の1つにはサーバで発生するwatcherinfo通知があるに違いない、登録、要求。 どんなAcceptヘッダーフィールドも存在していなかったなら、通知は[3]で説明されたアプリケーション/watcherinfo+xml形式を使用しなければなりません。
4.6. Notifier Processing of SUBSCRIBE Requests
4.6. より多くのNotifierに処理する、要求を申し込んでください。
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.
パッケージがどんなパッケージの特定の処理も定義するはずであるRFC3265[1]が指定する、登録、notifierでの特に認証と認可への尊敬による要求。
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購読SHOULD。 認証はSIP、包含で利用可能なテクニックのいずれも読みこなす実行された使用、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がどんなパッケージのためのそれら自身のウォッチャー情報にも加入できるのは、RECOMMENDEDです。 これは再帰的に本当です、ユーザがどんなパッケージのためのそれらのウォッチャー情報のためのウォッチャー情報にも加入できるのが、RECOMMENDEDであるように。
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
ユーザAのためのいくらかのパッケージfooのためのwatcherinfo購読がある他のユーザBから許されているのは、RECOMMENDEDです、Bがパッケージfooの中のAへの認可された加入者であるなら。 しかしながら、それはRECOMMENDEDです。
Rosenberg Standards Track [Page 7] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[7ページ]。
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に送られたwatcherinfo通知はビーズの自己の購読の状態を含むだけです。 言い換えれば、ユーザがそれら自身の購読の状態をモニターできるのは、RECOMMENDEDです。
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だけがユーザAのためにfoo.winfo.winfoに加入できるのは、認可方針の無限の再帰を避けるためには、RECOMMENDEDです、どんなfooのためにも。 また、デフォルトで、サーバがfoo.winfo.winfo.winfoのどんな購読かいかなる他のより深い再帰も認可しないのは、RECOMMENDEDです。
4.7. Notifier Generation of NOTIFY Requests
4.7. Notifier世代、要求に通知してください。
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 Event枠組みの要求を送ります。
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購読は見られる1セットの「内側」の購読に関連しています。 このセットがURIによってwatcherinfoのRequest URIで定義される、登録、watcherinfo購読の親イベントパッケージと共に要求します。 Eventヘッダーフィールドの値からwatcherinfoから引きずっている".winfo"を取り除くことによって親イベントパッケージを入手する、登録、要求。 watcherinfo購読におけるEventヘッダーフィールドに"presence.winfo"の値があるなら、親イベントパッケージは「存在」です。 Eventヘッダーフィールドに"presence.winfo.winfo"の値があるなら、親イベントパッケージは"presence.winfo"です。 通常watcherinfoのRequest URIにおけるURI、登録、ドメインの中で記録されている住所を特定します。 その場合、見られるべき購読のセットはwatcherinfoのRequest URIにおけるリソースにされた親イベントパッケージのための購読のすべてです。登録。 しかしながら、Request URIはどんなセットの購読も特定するURIを含むことができます、リソースの、より大きい収集の購読を含んでいて。 例えば、ちびちび飲んでください: all-resources@example.com は、すべてのリソースを示すためにexample.comの中で定義されるかもしれません。 その場合、"presence.winfo"がちびちび飲むwatcherinfo購読: all-resources@example.com は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
watcherinfo購読を購読の収集にするので、ウォッチャー資料ファイルは購読州のモデルを必要とします。 これは、どんなパッケージの中にもユーザの購読状態を決定する以下で説明された購読のすばらしい州Machine(FSM)を指定することによって、達成されます。 Watcherinfo通知は変遷のときにこの州のマシンで発生するかもしれません。 それ、このFSMがただモデルであることに注意するために、重要です。
Rosenberg Standards Track [Page 8] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[8ページ]。
subscription state machinery maintained by a server. An implementation would map its own state machines to this one in an implementation-specific manner.
購読州の機械は、サーバで. 実現が実現特有の方法でそれ自身の州のマシンをこれに写像すると主張しました。
4.7.1. The Subscription State Machine
4.7.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.
購読のための基本的な州のマシンは図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はイニット状態で作成されます。 この状態は一時的です。 次の状態は方針が購読のために存在しているかどうかに依存します。 購読が禁じられることを決定する既存の方針があれば、すぐに終えられた状態に動きます、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.
購読が到着するとき、現存するどんな認可方針もなければ、購読は未定の状態に動きます。 この状態では、サーバは認可決定を待っています。 存在状態の変化の上で通知を全く発生させません。(RFC3265[1])に従って初期のNOTIFYを届けてしまうでしょうが、購読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
待ち状態は通知が全く発生しないという点において未定の状態で同様です。 しかしながら、購読が承認されるか、または否定されるなら、FSMは終えられた状態に入れて、破壊されます。 登録、要求(1つが初めは存在していたなら)、FSM。その上、別の購読を出来事が同じイベントパッケージのためにボディーのパラメタとフィルタをパッケージする同じウォッチャーから同じリソースに受ける、"giveup"出来事に伴う終えられた状態に入って、破壊されます。 この変遷は到着次第同じパラメタがある新規申込みでは、未定の状態に入るので、起こります、先の購読のための待ち状態を余分にして。 ユーザがそうすることができるように、待ち状態の目的はそうです。
Rosenberg Standards Track [Page 9] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[9ページ]。
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.
いつでも、watcherinfo状態をとって来てください、そして、それが以前に(どれが再び到着するかもしれない)到着したことをあらゆる購読を学んでください(認可決定を必要とします)。 例を考えてください。 Aは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 | |
+-------+
申し込んでください、そして、方針は+と等しいです。----------+ 廃棄物| | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--+ +------------>|終わります。| <、-、-、-、-、-、-、-、--+ | | | | | | | | | |noresource| | +----------+ |拒絶されます。| | ^noresource|非活性化されます。| | |拒絶されます。|執行猶予| | |非活性化されます。|タイムアウト|noresource| |執行猶予| |拒絶されます。| |giveup| |giveup| | | |+を承認します。-------+ +-------+ +-------+ | | |申し込んでください。| |承認されます。| | | | イニット|、-、-、-、-、-、-、--、>|未定|、-、-、-、-、-、--、>|アクティブ| | | |方針がありません。| | | | | | | | | | | | +-------+ +-------+ +-------+ | | | ^ | | 申し込んでください。| | | +-----------------------------------+ | 方針=は受け入れます。| +-------+ | | | | | | |待ち|----------+ +----------->|、| タイムアウト| | +-------+
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.
また、待ち状態が、すぐに期限が切れる購読であるフェッチ試みの認可を考慮するのに必要です。
Rosenberg Standards Track [Page 10] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[10ページ]。
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の源が攻撃するとき、権限のない購読に状態を割り当てるのを使用できます。 したがって、権限のない購読のための状態を保有するサーバが特定の加入者には何らかの数の未定であるか待ち購読以上があるのを禁止する方針を加えるのは、RECOMMENDEDです。
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].
いつでも、サーバは購読を非活性化できます。 非活性化は、購読が認可方針における変化なしで捨てられるのを含意します。 これが完了しているかもしれない、引き金は優雅な閉鎖か購読移動操作のための購読をリフレッシュします。 関連する出来事は執行猶予です、購読が終えられて、加入者が再試行する前にいつかの時間待つよう要求されているところで。 これらの出来事の意味はさらに詳細に.4セクション3.2RFC3265[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出来事に対応しています。
4.7.2. Applying the State Machine
4.7.2. 州のマシンを適用します。
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
いくつかの出来事がパッケージfooであると考えてください。 Aはそのパッケージの中の出来事のためのBに加入します。 また、AはB.Inのために、このシナリオ(またfoo.winfoへの加入者が同じリソースのためのfooへの加入者であるところ)をfoo.winfoに申し込んで、Aがそれ自身の購読における変化だけに関するwatcherinfo通知を受け取るのは、RECOMMENDEDです。 通常、AはSubscription-州のヘッダーフィールドを通してfooの購読における変化に関する通知を受け取るでしょう。 これは頻繁にfoo.winfoの別々の購読の必要性を取り除くでしょう。 しかしながら、そのような購読がAによって実行されるなら、foo.winfo通知SHOULD NOTはいずれも報告します。
Rosenberg Standards Track [Page 11] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[11ページ]。
state changes which would not be reported (because of authorization policy) in the Subscription-State header field in notifications on foo.
fooに関する通知におけるSubscription-州のヘッダーフィールドで報告されない(認可方針のために)変化を述べてください。
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加入者が1人以上のウォッチャーに関するwatcherinfo通知を受け取るのに権限を与えられるとき、概して、watcherinfo通知がそれらのウォッチャーの情報を含んでいるのは、RECOMMENDEDです(状態(そして、その結果、通知の引き金となる)を変えました)、あらゆるwatcherinfo通知における、すべてのウォッチャーの現状を送ることの代わりに。 しかしながら、watcherinfo通知は、フェッチ操作(0のExpiresと共に登録)の結果、NOTIFYに存在しているようにすべてのウォッチャー(もちろんwatcherinfo加入者に明かされるのに権限を与えられたそれらのウォッチャーだけ)の完全な状態でSHOULD結果の引き金となりました。
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.
頻繁に、購読州のマシンの州は一時的になるでしょう。 例えば、認可されたウォッチャーがフェッチ操作を実行すると、これで州のマシンを作成するでしょう、イニットからアクティブまでそして、アクティブから終えられるまでの変遷、FSMの破壊があとに続いていて。 そのような場合watcherinfo通知SHOULD NOT、あらゆる一時的な州に送ってください。 先の例では、州のすべてが一時的であるので、サーバは少しの通知も送らないでしょう。
4.8. Subscriber Processing of NOTIFY Requests
4.8. 加入者、処理する、要求に通知してください。
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.
RFC3265[1]は、加入者がいずれでもどうNOTIFY要求を処理するかを指定するパッケージが特定の道と、それが特に、どう、申し込まれたリソースの状態の論理的な視点を構成するというNOTIFY要求を使用するかをパッケージすると予想します。 通常、watcherinfo NOTIFYは状態が変化したそれらのウォッチャーの情報を含むだけでしょう。 すべてのウォッチャーの総状態の論理的な視点を構成するために、watcherinfo加入者は、時間がたつにつれて受け取られたNOTIFYsを結合する必要があるでしょう。 この過程のこの詳細はドキュメント・フォーマットに依存します。 アプリケーション/watcherinfo+xml形式に関する詳細のための[3]を見てください。
4.9. Handling of Forked Requests
4.9. 股状の要求の取り扱い
The SIP Events framework mandates that packages indicate whether or not forked SUBSCRIBE requests can install multiple subscriptions.
SIP Events枠組みは、分岐するか否かに関係なく、そのパッケージが示すのを強制します。登録、要求はインストール複数の購読をそうすることができます。
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,
ユーザがパッケージfooのための何らかのリソースのためのウォッチャー情報を得たがっているとき情報が一緒にunionedされて、パッケージfooのためのそのリソースにすべてのウォッチャーの完全な情報を持っているサーバの収集に達する必要があるウォッチャーへの登録。 パッケージfooのためのそのリソースのための購読を扱うサーバのaの多様性がある、(ロードバランシング理由で
Rosenberg Standards Track [Page 12] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[12ページ]。
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.
通常)、どんなただ一つのサーバにも、完全なウォッチャー情報が非常にありそうにないでしょう。 この場合、いくつかの解決策があります。 この仕様は特定のものを強制しません、そして、それは他のものを除外しません。 それは、広範囲な解決策を築き上げることができるのを単に確実にします。
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 NOTIFY要求を受け取るでしょう。それはそれぞれ別々の対話を確立します。 各対話の向こう側に情報に集めることによって、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加入者がNOTIFYの多様性の結果が、シングルに対応して登録を通信するとき複数の購読をインストールする用意ができていなければなりません。
Another approach for handling the server multiplicity problem is to use state agents. See Section 4.11 for details.
サーバ多様性問題を扱うための別のアプローチは州のエージェントを使用することです。 詳細に関してセクション4.11を見てください。
4.10. Rate of Notifications
4.10. 通知の速度
RFC 3265 [1] mandates that packages define a maximum rate of notifications for their package.
それがパッケージするRFC3265[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.
輻輳制御の理由で、通知の速度が過度にならないのは、重要です。 その結果、サーバが独身のwatcherinfo加入者のために速度でwatcherinfo通知を5秒あたりの一度より速く発生させないのは、RECOMMENDEDです。
4.11. State Agents
4.11. 州のエージェント
RFC 3265 [1] asks packages to consider the role of state agents in their design.
RFC3265[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
州のエージェントはこのパッケージの中に重要な役割を果たします。 セクション4.9で議論するように、特定のパッケージのための購読の負荷を共有するサーバの多様性があるかもしれません。 watcherinfo
Rosenberg Standards Track [Page 13] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[13ページ]。
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.
購読はすべての向こう側に広げられた購読状態にそれらのサーバを要求するかもしれません。 それを扱うために、州のエージェントの農場を使用できます。 これらの州のエージェントの各人は何らかのセットのリソースで全体のwatcherinfo州を知っているでしょう。 この仕様の範囲の外に州のエージェントが完全なwatcherinfo状態を決定する手段があります。 watcherinfo購読が受け取られているとき、それは要求されたリソースのための完全なwatcherinfo状態を持っている州のエージェントに発送されるでしょう。 watcherinfo状態が変化したとき、このサーバは、watcherinfo購読(それが認可されたと仮定しますもちろん)を受け入れて、watcherinfo通知を発生させるでしょう。 watcherinfo加入者には、この場合、ただ一つの対話があるだけでしょう。
5. Example Usage
5. 例の用法
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@example.com はexample.com存在サーバを通して存在を提供します。ジョーは彼自身のウォッチャー情報に加入します、彼の存在に加入する人々に関して学ぶために、彼が彼らの購読を承認するか、または拒絶できるように。 ジョーが以下を送る、登録、以下を要求してください。
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
一口: 登録、 joe@example.com SIP/2.0Via: 一口/2.0/UDP pc34.example.com; ブランチ=z9hG4bKnashds7From: 一口: joe@example.com;tag は123aa9To:と等しいです。 一口: joe@example.com Call-ID: 9987@pc34.example.com CSeq: 9887は接触を申し込みます: 一口: joe@pc34.example.com Event: 前方へ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で反応して、ジョーが再提出する、信任状(示されなかったメッセージ)で登録。 そして、ジョーがそれで存在のための彼自身のウォッチャー情報に加入できるので、サーバは購読を認可します。 それは200OKで応じます:
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
以下を通って一口/2.0 200OK 一口/2.0/UDP pc34.example.com; ブランチはz9hG4bKnashds8と等しいです; =192.0.2.8From:を受けます。 一口: joe@example.com;tag は123aa9To:と等しいです。 一口: joe@example.com;tag はxyzygg Call-IDと等しいです: 9987@pc34.example.com CSeq: 9988は接触を申し込みます: 一口: server19.example.com Expires: 3600年の出来事: presence.winfo
Rosenberg Standards Track [Page 14] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[14ページ]。
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一口: joe@pc34.example.com SIP/2.0Via: 一口/2.0/UDP server19.example.com; ブランチ=z9hG4bKnasaii From: 一口: joe@example.com;tag はxyzygg To:と等しいです。 一口: joe@example.com;tag は123aa9 Call-IDと等しいです: 9987@pc34.example.com CSeq: 1288は接触に通知します: 一口: server19.example.com Event: presence.winfo Subscription-州: アクティブなマックス-フォワード: 70コンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
<?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>
<?xmlバージョン= 「1インチ?」「完全な「><ウォッチャーリストリソース=」一口: 「0インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= joe@example.com 」パッケージ=、「存在、「><ウォッチャーイド=「77ajsyy76"出来事=」は申し込む」という状態が等しい、「未定である、「>一口: A@example.com 、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
Joe then responds with a 200 OK to the NOTIFY:
次に、ジョーは200OKでNOTIFYに応じます:
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
以下を通って一口/2.0 200OK 一口/2.0/UDP server19.example.com; ブランチはz9hG4bKnasaiiと等しいです; =192.0.2.7From:を受けます。 一口: joe@example.com;tag はxyzygg To:と等しいです。 一口: joe@example.com;tag は123aa9 Call-IDと等しいです: 9987@pc34.example.com CSeq: 1288に通知します。
Rosenberg Standards Track [Page 15] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[15ページ]。
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一口: joe@pc34.example.com SIP/2.0Via: 一口/2.0/UDP server19.example.com; ブランチ=z9hG4bKnasaij From: 一口: joe@example.com;tag はxyzygg To:と等しいです。 一口: joe@example.com;tag は123aa9 Call-IDと等しいです: 9987@pc34.example.com CSeq: 1289は接触に通知します: 一口: server19.example.com Event: presence.winfo Subscription-州: アクティブなマックス-フォワード: 70コンテントタイプ: アプリケーション/watcherinfo+xml Content長さ: ...
<?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>
<?xmlバージョン= 「1インチ?」「部分的な「><ウォッチャーリストリソース=」一口: 「1インチの状態=」という><watcherinfo xmlns=「つぼ:ietf:params:xml:ナノ秒: watcherinfo」バージョン= joe@example.com 」パッケージ=、「存在、「承認された><ウォッチャーイド=「77ajsyy76"出来事=」」状態が等しい、「アクティブである、「>一口: A@example.com 、lt;、/ウォッチャー></ウォッチャーリスト></watcherinfoな>、」
B then responds with a 200 OK to the NOTIFY:
次に、Bは200OKでNOTIFYに応じます:
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
以下を通って一口/2.0 200OK 一口/2.0/UDP server19.example.com; ブランチはz9hG4bKnasaijと等しいです; =192.0.2.7From:を受けます。 一口: joe@example.com;tag はxyzygg To:と等しいです。 一口: joe@example.com;tag は123aa9 Call-IDと等しいです: 9987@pc34.example.com CSeq: 1289に通知します。
Rosenberg Standards Track [Page 16] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[16ページ]。
6. Security Considerations
6. セキュリティ問題
6.1. Denial of Service Attacks
6.1. サービス不能攻撃
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 NOTIFYの流れが攻撃者によってされた購読から発生するのを防ぎます。
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に送られたデータ量は攻撃者によって発生したデータの正方形です! 攻撃者で発生している購読がそれのそれぞれが報告するだろうTに送られるwatcherinfo NOTIFYにNウォッチャーまで結果になるそれぞれのN。 それらのためのwatcherinfo通知を要求して、決して発生させるべきではありません。これを避けるために、サーバが購読状態を決して発生させるべきでない、非認証、登録、どちらか。
6.2. Divulging Sensitive Information
6.2. 機密情報を明かします。
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.
ウォッチャー情報は、どんなユーザが特定のリソースに興味を持っているかを示します。 パッケージとリソースによって、これは非常に機密の情報であるかもしれません。 例えば、存在の場合では、ユーザへのウォッチャー情報はその人の友人、家族、およびビジネス関係の代理をします。 さまざまな悪意の目的にこの情報を使用できます。
Rosenberg Standards Track [Page 17] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[17ページ]。
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計画を使用するかもしれません。 watcherinfoのためのNotifiersはTLSを支持しなければならなくて、まるで彼らがプロキシであるかのようにちびちび飲みます(.1セクション26.3RFC3261を見てください)。
SIP encryption, using S/MIME, MAY be used end-to-end for the transmission of both SUBSCRIBE and NOTIFY requests.
S/MIMEを使用して、SIP暗号化が中古の両方のトランスミッションのための終わりから終わりであるかもしれない、登録、そして、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購読を認証して、認可することによって、これらの攻撃を防ぐことができます。 notifierが加入者を認証するように、それはHTTP Digest(RFC3261のセクション22)を使用するかもしれません。 その結果、すべてのウォッチャーがHTTP Digestを支持しなければなりません。 すべてのSIPユーザエージェントがRFC3261でそれを支持するために強制されるので、しかしながら、これは余分な要件です。
7. IANA Considerations
7. IANA問題
This specification registers an event template package as specified in Section 6.2 of RFC 3265 [1].
この仕様はRFC3265[1]のセクション6.2での指定されるとしてのイベントテンプレートパッケージを登録します。
Package Name: winfo
名前をパッケージしてください: winfo
Template Package: yes
テンプレートパッケージ: はい
Published Specification: RFC 3857
広められた仕様: RFC3857
Person to Contact: Jonathan Rosenberg, jdrosen@jdrosen.net.
連絡する人: ジョナサン・ローゼンバーグ、 jdrosen@jdrosen.net 。
8. Acknowledgements
8. 承認
The authors would like to thank Adam Roach, Allison Mankin and Brian Stucker for their detailed comments.
作者は彼らの詳細なコメントについてアダム・ローチ、アリソン・マンキン、およびブライアンStuckerに感謝したがっています。
9. Normative References
9. 引用規格
[1] Roach, A.B., "Session Initiation Protocol (SIP)-Specific Event
Notification", RFC 3265, June 2002.
[1] ローチ、A.B.、「セッション開始プロトコル(一口)特定のイベント通知」、RFC3265、2002年6月。
[2] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。
[3] Rosenberg, J., "An Extensible Markup Language (XML) Based Format
for Watcher Information", RFC 3858, August 2004.
[3] ローゼンバーグ、J.、「拡張マークアップ言語(XML)はウォッチャー情報のための形式を基礎づけた」RFC3858、2004年8月。
Rosenberg Standards Track [Page 18] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[18ページ]。
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、2002年6月。
10. Informative References
10. 有益な参照
[5] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, July 2004.
[5] ローゼンバーグ、J.、「セッション開始プロトコル(一口)のための存在イベントパッケージ」、RFC3856、2004年7月。
11. Author's Address
11. 作者のアドレス
Jonathan Rosenberg dynamicsoft 600 Lanidex Plaza Parsippany, NJ 07054
Lanidex Plazaパーシッパニー、ジョナサンローゼンバーグdynamicsoft600ニュージャージー 07054
EMail: jdrosen@dynamicsoft.com
メール: jdrosen@dynamicsoft.com
Rosenberg Standards Track [Page 19] RFC 3857 Watcher Information August 2004
ローゼンバーグStandardsはウォッチャー情報2004年8月にRFC3857を追跡します[19ページ]。
12. Full Copyright Statement
12. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Rosenberg Standards Track [Page 20]
ローゼンバーグ標準化過程[20ページ]
一覧
スポンサーリンク
