[要約] RFC 6446は、SIPイベント通知の通知レート制御のための拡張機能です。その目的は、ネットワークの過負荷を防ぎ、通知の効率的な配信を確保することです。
Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 6446 K. Kiss
Updates: 3265 Nokia
Category: Standards Track S. Loreto
ISSN: 2070-1721 Ericsson
January 2012
Session Initiation Protocol (SIP) Event Notification Extension for Notification Rate Control
セッション開始プロトコル（SIP）イベント通知通知レートコントロールのための通知拡張
Abstract
概要
This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. This document updates RFC 3265.
このドキュメントは、セッション開始プロトコル（SIP）イベント通知を調整するためのメカニズムを指定します。これらのメカニズムは、すべてのSIPイベントパッケージにサブスクリプションに適用できます。このドキュメントは、RFC 3265を更新します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 5741のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6446.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6446で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Definitions and Document Conventions . . . . . . . . . . . . . 5
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Use Case for Limiting the Maximum Rate of Notifications . 5
3.2. Use Case for Setting a Minimum Rate for Notifications . . 6
3.3. Use Case for Specifying an Adaptive Minimum Rate of
Notifications . . . . . . . . . . . . . . . . . . . . . . 6
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic Operations . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 8
4.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 9
5. Operation of the Maximum Rate Mechanism . . . . . . . . . . . 9
5.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 9
5.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 10
5.3. Selecting the Maximum Rate . . . . . . . . . . . . . . . . 11
5.4. The Maximum Rate Mechanism for the Resource List Server . 11
5.5. Buffer Policy Description . . . . . . . . . . . . . . . . 13
5.5.1. Partial-State Notifications . . . . . . . . . . . . . 13
5.5.2. Full-State Notifications . . . . . . . . . . . . . . . 13
5.6. Estimated Bandwidth Savings . . . . . . . . . . . . . . . 14
6. Operation of the Minimum Rate Mechanism . . . . . . . . . . . 14
6.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 14
6.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 15
6.3. Selecting the Minimum Rate . . . . . . . . . . . . . . . . 16
7. Operation of the Adaptive Minimum Rate Mechanism . . . . . . . 16
7.1. Subscriber Behavior . . . . . . . . . . . . . . . . . . . 16
7.2. Notifier Behavior . . . . . . . . . . . . . . . . . . . . 17
7.3. Selecting the Adaptive Minimum Rate . . . . . . . . . . . 18
7.4. Calculating the Timeout . . . . . . . . . . . . . . . . . 18
8. Usage of the Maximum Rate, Minimum Rate, and Adaptive
Minimum Rate Mechanisms in a Combination . . . . . . . . . . . 19
9. Protocol Element Definitions . . . . . . . . . . . . . . . . . 20
9.1. "max-rate", "min-rate", and "adaptive-min-rate" Header
Field Parameters . . . . . . . . . . . . . . . . . . . . . 21
9.2. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 21
9.3. Event Header Field Usage in Responses to the NOTIFY
Request . . . . . . . . . . . . . . . . . . . . . . . . . 21
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
11. Security Considerations . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
13.1. Normative References . . . . . . . . . . . . . . . . . . . 23
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
The SIP events framework [RFC3265] defines a generic framework for subscriptions to and notifications of events related to SIP systems. This framework defines the methods SUBSCRIBE and NOTIFY, and introduces the concept of an event package, which is a concrete application of the SIP events framework to a particular class of events.
SIPイベントフレームワーク[RFC3265]は、SIPシステムに関連するイベントのサブスクリプションと通知の一般的なフレームワークを定義します。このフレームワークは、サブスクライブと通知のメソッドを定義し、特定のクラスのイベントにSIPイベントフレームワークの具体的なアプリケーションであるイベントパッケージの概念を紹介します。
One of the things the SIP events framework mandates is that each event package specification defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier. Such a limit is provided in order to reduce network load.
SIPイベントフレームワークが義務付けていることの1つは、各イベントパッケージ仕様が、単一の通知者によって通知を生成できるレートで絶対最大を定義することです。このような制限は、ネットワークの負荷を減らすために提供されます。
All of the existing event package specifications include a recommendation for the maximum notification rate, ranging from once in every five seconds [RFC3856], [RFC3680], [RFC3857] to once per second [RFC3842].
既存のすべてのイベントパッケージ仕様には、5秒ごとに1回[RFC3856]、[RFC3680]、[RFC3857]に1回[RFC3842]までの最大通知率の推奨事項が含まれています。
Per the SIP events framework, each event package specification is allowed to define additional throttle mechanisms that allow the subscriber to further limit the rate of event notification. So far, none of the event package specifications have defined such a mechanism.
SIPイベントフレームワークごとに、各イベントパッケージ仕様は、サブスクライバーがイベント通知のレートをさらに制限できる追加のスロットルメカニズムを定義することができます。これまでのところ、イベントパッケージの仕様はいずれもこのようなメカニズムを定義していません。
The resource list extension [RFC4662] to the SIP events framework also deals with rate limiting of event notifications. The extension allows a subscriber to subscribe to a heterogeneous list of resources with a single SUBSCRIBE request, rather than having to install a subscription for each resource separately. The event list subscription also allows rate limiting, or throttling of notifications, by means of the Resource List Server (RLS) buffering notifications of resource state changes, and sending them in batches. However, the event list mechanism provides no means for the subscriber to set the interval for the throttling.
SIPイベントフレームワークへのリソースリスト拡張[RFC4662]は、イベント通知のレート制限も扱っています。この拡張機能により、サブスクライバーは、各リソースのサブスクリプションを個別にインストールする必要があるのではなく、単一のサブスクライブリクエストを持つリソースの異種リストを購読できます。イベントリストのサブスクリプションは、リソースリストサーバー（RLS）バッファリング通知の通知を使用して、それらをバッチで送信することにより、レートの制限または通知のスロットリングも可能にします。ただし、イベントリストメカニズムは、サブスクライバーがスロットリングの間隔を設定する手段を提供しません。
Some event packages are also interested in specifying an absolute or an adaptive minimum rate at which notifications need to be generated by a notifier. This helps the subscriber to effectively use different trigger criteria within a subscription to eliminate unnecessary notifications but at the same time make sure that the current event state is periodically received.
一部のイベントパッケージには、通知を通知者が生成する必要がある絶対的または適応最小レートを指定することにも関心があります。これにより、サブスクライバーがサブスクリプション内で異なるトリガー基準を効果的に使用して不必要な通知を排除するのに役立ちますが、同時に現在のイベント状態が定期的に受信されることを確認します。
This document defines an extension to the SIP events framework by defining the following three Event header field parameters that allow a subscriber to set a maximum, a minimum, and an adaptive minimum rate of notifications generated by the notifier:
このドキュメントでは、サブスクライバーが最大値、最小、および適応型最小レートの通知の最小レートを設定できるようにする次の3つのイベントヘッダーフィールドパラメーターを定義することにより、SIPイベントフレームワークの拡張を定義します。
max-rate: specifies a maximum number of notifications per second.
MAX-RATE：1秒あたりの通知の最大数を指定します。
min-rate: specifies a minimum number of notifications per second.
Min-Rate：1秒あたりの通知の最小数を指定します。
adaptive-min-rate: specifies an adaptive minimum number of notifications per second.
Adaptive-Min-rate：秒あたりの適応最小通知数を指定します。
These mechanisms are applicable to any event subscription, both single event subscription and event list subscription. A notifier compliant to this specification will adjust the rate at which it generates notifications.
これらのメカニズムは、単一のイベントサブスクリプションとイベントリストサブスクリプションの両方のイベントサブスクリプションに適用できます。この仕様に準拠した紹介者は、通知を生成するレートを調整します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [RFC2119]で説明されているように解釈され、準拠した実装の要件レベルを示します。
Indented passages such as this one are used in this document to provide additional information and clarifying text. They do not contain normative protocol behavior.
このドキュメントでは、このドキュメントでは、追加情報と明確化テキストを提供するために、このようなインデントされたパッセージが使用されています。それらには規範的なプロトコルの動作が含まれていません。
A presence client in a mobile device contains a list of 100 buddies or presentities. In order to decrease the processing and network load of watching 100 presentities, the presence client has employed an RLS with the list of buddies, and therefore only needs a single subscription to the RLS to receive notifications of the presence state of the resource list.
モバイルデバイスのプレゼンスクライアントには、100人の仲間またはプレゼンテーションのリストが含まれています。100のプレゼンテーションを監視する処理とネットワークの負荷を減らすために、プレゼンスクライアントはバディのリストを含むRLSを採用しているため、リソースリストの存在状態の通知を受信するためにRLSの1つのサブスクリプションのみが必要です。
In order to control the buffer policy of the RLS, the presence client sets a maximum rate of notifications. The RLS will buffer notifications that are generated faster than they are allowed to be sent due to the maximum rate and batch all of the buffered state changes together in a single notification. The maximum rate applies to the overall resource list, which means that there is a hard cap imposed by the maximum rate to the number of notifications per second that the presence client can expect to receive.
RLSのバッファポリシーを制御するために、プレゼンスクライアントは通知の最大レートを設定します。RLSは、最大レートのために送信されるよりも速く生成される通知をバッファリングし、バッファー状態のすべての変更を単一の通知で一緒にバッチします。最大レートは、全体的なリソースリストに適用されます。つまり、クライアントが受け取ることが期待できる秒あたりの通知の数に最大レートによって課されるハードキャップが課されることを意味します。
The presence client can also modify the maximum rate of notifications during the lifetime of the subscription. For example, if the mobile device detects inactivity from the user for a period of time, the presence client can simply pause notifications by choosing a "max-rate" parameter that allows only a single notification for the
プレゼンスクライアントは、サブスクリプションの存続期間中に通知の最大レートを変更することもできます。たとえば、モバイルデバイスがしばらくの間ユーザーからの非アクティブ性を検出した場合、プレゼンスクライアントは、「最大定格」パラメーターを選択して、単一の通知のみを可能にする「最大定格」パラメーターを選択して、通知を一時停止することができます。
remainder of the subscription lifetime. When the user becomes active again, the presence client can resume the stream of notifications by re-subscribing with a "max-rate" parameter set to the earlier-used value. Application of the mechanism defined by RFC 5839 [RFC5839] can also eliminate the transmission of a (full-state) notification carrying the latest resource state to the presence client after a subscription refresh.
サブスクリプション寿命の残り。ユーザーが再びアクティブになると、プレゼンスクライアントは、「最大レート」パラメーターを以前に使用した値に設定することにより、通知のストリームを再開できます。RFC 5839 [RFC5839]によって定義されたメカニズムの適用は、サブスクリプション更新後に最新のリソース状態を存在クライアントに運ぶ（フルステート）通知の送信を排除することもできます。
A location application is monitoring the movement of a target. In order to decrease the processing and network load, the location application has made a subscription to a Location Server with a set of location filters [RFC6447] that specify trigger criteria, e.g., to send an update only when the target has moved at least n meters. However, the application is also interested in receiving the current state periodically, even if the state of the target has not changed enough to satisfy any of the trigger criteria, e.g., has not moved at least n meters within the period.
ロケーションアプリケーションは、ターゲットの動きを監視しています。処理とネットワークの負荷を減らすために、ロケーションアプリケーションは、ターゲットが少なくともnを移動した場合にのみ更新を送信するトリガー基準を指定するロケーションフィルターのセット[RFC6447]を備えたロケーションサーバーのサブスクリプションを作成しましたメーター。ただし、アプリケーションは、ターゲットの状態がトリガー基準のいずれかを満たすほど十分に変更されていなくても、期間内に少なくともNメートルを移動していない場合でも、定期的に現在の状態を受信することに関心があります。
The location application sets a minimum rate of notifications and includes it in the subscription sent to the Location Server. The "min-rate" parameter indicates the minimum number of notifications per second the notifier needs to generate.
ロケーションアプリケーションは、通知の最小レートを設定し、ロケーションサーバーに送信されたサブスクリプションに含めます。「Min-Rate」パラメーターは、通知者が生成する必要がある秒あたりの通知の最小数を示します。
The location application can modify the minimum rate of notifications during the lifetime of the subscription. For example, when the subscription to the movement of a target is made, the notifier may not have the location information available. Thus, the first notification might be empty or certain values might be absent. An important use case is placing constraints on when complete state should be provided after creating the subscription. Once state is acquired and the second notification is sent, the subscriber updates or changes the "min-rate" parameter to a more sensible value. This update can be performed in the response to the notification that contains the complete state information.
ロケーションアプリケーションは、サブスクリプションの存続期間中に通知の最小レートを変更できます。たとえば、ターゲットの動きのサブスクリプションが作成された場合、通知者は位置情報を使用できない場合があります。したがって、最初の通知が空であるか、特定の値がない場合があります。重要なユースケースは、サブスクリプションを作成した後に完全な状態を提供する必要がある場合に制約を置くことです。状態が取得され、2番目の通知が送信されると、サブスクライバーは「最小レート」パラメーターをより賢明な値に更新または変更します。この更新は、完全な状態情報を含む通知への応答で実行できます。
The minimum rate mechanism introduces a static and instantaneous rate control without the functionality to increase or decrease the notification rate adaptively. However, there are some applications that would work better with an adaptive minimum rate control.
最小レートメカニズムは、通知レートを適応的に増加または減少させる機能を伴わずに静的および瞬時のレート制御を導入します。ただし、適応的な最小レート制御によりうまく機能するアプリケーションがいくつかあります。
A location application is monitoring the movement of a target. In order to decrease the processing in the application, the location application wants to make a subscription that dynamically decreases the minimum rate of notifications if the target has sent out several
ロケーションアプリケーションは、ターゲットの動きを監視しています。アプリケーションの処理を減らすために、ロケーションアプリケーションは、ターゲットがいくつかを送信した場合に通知の最小レートを動的に減らすサブスクリプションを作成したい
notifications recently. However, if there have been only few recent notifications by the target, the location application wants the minimum rate of notifications to increase.
最近の通知。ただし、ターゲットによる最近の通知しかなかった場合、ロケーションアプリケーションは通知の最小レートを増やす必要があります。
The location application sets an adaptive minimum rate of notifications and includes it in the subscription sent to the Location Server. The "adaptive-min-rate" parameter value is used by the notifier to dynamically calculate the actual maximum time between two notifications. In order to dynamically calculate the maximum time, the notifier takes into consideration the rate at which notifications have been sent recently. In the adaptive minimum rate mechanism, the notifier can increase or decrease the notification rate compared to the minimum rate mechanism based on the recent number of notifications sent out in the last period.
ロケーションアプリケーションは、適応的な最小通知レートを設定し、ロケーションサーバーに送信されたサブスクリプションにそれを含めます。「Adaptive-Min-rate」パラメーター値は、通知者によって使用され、2つの通知の間の実際の最大時間を動的に計算します。最大時間を動的に計算するために、通知者は最近通知が送信されたレートを考慮します。適応型最小レートメカニズムでは、通知者は、最近の通知の数に基づいて最小レートメカニズムと比較して通知率を増加または減少させることができます。
The location application can also modify the "adaptive-min-rate" parameter during the lifetime of the subscription.
ロケーションアプリケーションは、サブスクリプションの寿命の間に「適応型-min-rate」パラメーターを変更することもできます。
REQ1: The subscriber must be able to set a maximum rate of notifications in a specific subscription.
REQ1：サブスクライバーは、特定のサブスクリプションで最大通知率を設定できる必要があります。
REQ2: The subscriber must be able to set a minimum rate of notifications in a specific subscription.
REQ2：サブスクライバーは、特定のサブスクリプションで最小通知率を設定できる必要があります。
REQ3: The subscriber must be able to set an adaptive minimum rate of notifications in a specific subscription, which adjusts the minimum rate of notifications based on a moving average.
REQ3：サブスクライバーは、移動平均に基づいて最小通知率を調整する特定のサブスクリプションに適応最小通知率を設定できる必要があります。
REQ4: It must be possible to apply the maximum rate, the minimum rate, and the adaptive minimum rate mechanisms all together, or in any combination, in a specific subscription.
Req4：特定のサブスクリプションで、最大レート、最小レート、および適応最小レートメカニズムをすべて一緒に、または任意の組み合わせで適用することが可能である必要があります。
REQ5: It must be possible to use any of the different rate control mechanisms in subscriptions to any events.
Req5：サブスクリプションでは、任意のイベントに異なるレート制御メカニズムを使用することが可能である必要があります。
REQ6: It must be possible to use any of the different rate control mechanisms together with any other event filtering mechanisms.
Req6：異なるレート制御メカニズムを他のイベントフィルタリングメカニズムとともに使用することが可能である必要があります。
REQ7: The notifier must be allowed to use a policy in which the maximum rate, minimum rate, and adaptive minimum rate parameters are adjusted from the value given by the subscriber.
REQ7：宛先は、最大レート、最小レート、および適応最小レートパラメーターがサブスクライバーによって指定された値から調整されるポリシーを使用することを許可する必要があります。
For example, due to congestion, local policy at the notifier could temporarily dictate a policy that in effect further decreases the maximum rate of notifications. In another example, the notifier could increase the subscriber-proposed maximum rate so that at least one notification is generated during the remainder of the subscription lifetime.
たとえば、輻輳のために、通知者のローカルポリシーは、事実上、通知の最大レートをさらに低下させるポリシーを一時的に指示する可能性があります。別の例では、通知者はサブスクライバーが推定した最大レートを増やすことができるため、サブスクリプション寿命の残りの間に少なくとも1つの通知が生成されるようになります。
REQ8: The different rate control mechanisms must address corner cases for setting the notification rates appropriately. At a minimum, the mechanisms must address the situation in which the time between two notifications exceeds the subscription duration and should provide procedures for avoiding this situation.
REQ8：異なるレート制御メカニズムは、通知率を適切に設定するためにコーナーケースに対処する必要があります。少なくとも、メカニズムは、2つの通知の間の時間がサブスクリプション期間を超え、この状況を回避するための手順を提供する必要がある状況に対処する必要があります。
REQ9: It must be possible to invoke, modify, or remove the different rate control mechanisms in the course of an active subscription.
Req9：アクティブなサブスクリプションの過程で、異なるレート制御メカニズムを呼び出し、変更、または削除することが可能である必要があります。
REQ10: The different rate control mechanisms must allow for the application of authentication and integrity protection mechanisms to subscriptions invoking that mechanism.
REQ10：異なるレート制御メカニズムは、そのメカニズムを呼び出すサブスクリプションに認証と整合性の保護メカニズムを適用する必要があります。
In general, a subscriber generates SUBSCRIBE requests and processes NOTIFY requests as described in RFC 3265 [RFC3265].
一般に、サブスクライバーは、RFC 3265 [RFC3265]で説明されているように、サブスクライバーのリクエストとプロセスに通知リクエストを生成します。
A subscriber that wants to have a maximum, minimum, or adaptive minimum rate of event notifications in a specific event subscription does so by including a "max-rate", "min-rate", or "adaptive-min-rate" Event header field parameter(s) as part of the SUBSCRIBE request.
特定のイベントサブスクリプションでのイベント通知の最大、最小、または適応最小レートの最小レートを望んでいるサブスクライバーは、「最大評価」、「最小評価」、または「適応型 - マンレート」イベントヘッダーを含めることにより、そうしますサブスクライブリクエストの一部としてのフィールドパラメーター。
A subscriber that wants to update a previously agreed event rate control parameter does so by including the updated "max-rate", "min-rate", or "adaptive-min-rate" Event header field parameter(s) as part of a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request. If the subscriber does not include at least one of the "max-rate", "min-rate", or "adaptive-min-rate" header field parameters in the most recent SUBSCRIBE request in a given dialog, the subscriber MUST NOT include an Event header field with any of those parameters in a 2xx response to a NOTIFY request in that dialog.
以前に合意したイベントレートコントロールパラメーターを更新したいサブスクライバーは、更新された「最大レート」、「MIN-RATE」、または「Adaptive-Min-rate」イベントヘッダーフィールドパラメーターをAの一部として含めることにより、そうします。その後のサブスクライブリクエストまたはNotifyリクエストへの2xx応答。サブスクライバーが、特定のダイアログに最新のサブスクライブリクエストに「最大レート」、「最小評価」、または「適応min-rate」ヘッダーフィールドパラメーターの少なくとも1つを含まない場合、サブスクライバーには含まれてはなりません。そのダイアログの通知要求に対する2xx応答のこれらのパラメーターのいずれかを備えたイベントヘッダーフィールド。
In general, a notifier processes SUBSCRIBE requests and generates NOTIFY requests as described in RFC 3265 [RFC3265].
一般に、Notifierプロセスはリクエストを購読し、RFC 3265 [RFC3265]で説明されている通知要求を生成します。
A notifier that supports the different rate control mechanisms MUST adjust its rate of notification according to the rate control values agreed with the subscriber. If the notifier needs to lower the subscription expiration value, or if a local policy or other implementation-determined constraint at the notifier cannot satisfy the rate control request, then the notifier can adjust (i.e., increase or decrease) appropriately the subscriber-requested rate control values. The notifier MUST reflect back the possibly adjusted rate control values in a "max-rate", "min-rate", or "adaptive-min-rate" Subscription-State header field parameter of the subsequent NOTIFY requests.
さまざまなレート制御メカニズムをサポートする通知者は、サブスクライバーと合意したレート制御値に従って通知率を調整する必要があります。通知者がサブスクリプションの有効期限を下げる必要がある場合、またはローカルポリシーまたは他の実装で決定された制約が通知者の制御要求を満たすことができない場合、通知者はサブスクライバー要求レートを適切に調整（つまり、増加または減少させる）ことができます制御値。通知者は、後続の通知リクエストの「最大レート」、「MIN-RATE」、または「Adaptive-Min-rate」サブスクリプション状態ヘッダーフィールドパラメーターの調整されたレート制御値を反映する必要があります。
A subscriber that wishes to apply a maximum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the "max-rate" Event header field parameter. This parameter specifies the requested maximum number of notifications per second. The value of this parameter is a positive real number given by a finite decimal representation.
サブスクリプションの通知に最大レートを適用したいサブスクライバーは、「最大レート」イベントヘッダーフィールドパラメーターを含むサブスクライブリクエストを作成する必要があります。このパラメーターは、要求された最大通知数あたりの最大数を指定します。このパラメーターの値は、有限10進表現によって与えられる正の実数です。
Note that the grammar in section 9.2 constrains this value to be between 0.0000000001 and 99.9999999999. Zero is not an allowed value.
セクション9.2の文法は、この値が0.0000000001から99.999999999の間であると制約していることに注意してください。ゼロは許容値ではありません。
Note that the witnessed notification rate may not conform to the "max-rate" value for a number of reasons. For example, network jitter and retransmissions may result in the subscriber receiving the notifications more frequently than the "max-rate" value recommends.
目撃された通知率は、いくつかの理由で「最大評価」値に準拠していない可能性があることに注意してください。たとえば、ネットワークジッターと再送信により、サブスクライバーが「最大定格」値が推奨するよりも頻繁に通知を受信する可能性があります。
A subscriber that wishes to update the previously agreed maximum rate of notifications MUST include the updated "max-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
以前に合意した最大通知率を更新したいサブスクライバーには、その後のサブスクライブリクエストまたは通知リクエストへの2xx応答に更新された「最大レート」イベントヘッダーフィールドパラメーターを含める必要があります。
A subscriber that wishes to remove the maximum rate control from notifications MUST indicate so by not including a "max-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
通知から最大レートコントロールを削除したいサブスクライバーは、後続のサブスクライブリクエストに「最大レート」イベントヘッダーフィールドパラメーターまたは通知リクエストへの2XX応答を含めないことにより、そのように示す必要があります。
There are two main consequences for the subscriber when applying the maximum rate mechanism: state transitions may be lost and event notifications may be delayed. If either of these side effects constitute a problem to the application that utilizes the event notifications, developers are instructed not to use the mechanism.
最大レートメカニズムを適用する場合、サブスクライバーには2つの主な結果があります。状態遷移が失われ、イベント通知が遅れる可能性があります。これらの副作用のいずれかが、イベント通知を利用するアプリケーションの問題を構成する場合、開発者はメカニズムを使用しないように指示されます。
A notifier that supports the maximum rate mechanism MUST extract the value of the "max-rate" Event header parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request and use it as the suggested maximum number of notifications per second. This value can be adjusted by the notifier, as defined in Section 5.3.
最大レートメカニズムをサポートする紹介者は、サブスクライブリクエストまたは通知要求への2xx応答から「最大レート」イベントヘッダーパラメーターの値を抽出し、1秒あたりの最大通知の最大数として使用する必要があります。この値は、セクション5.3で定義されているように、通知者によって調整できます。
A compliant notifier MUST reflect back the possibly adjusted maximum rate of notifications in a "max-rate" Subscription-State header field parameter of the subsequent NOTIFY requests. The indicated "max-rate" value is adopted by the notifier, and the notification rate is adjusted accordingly.
準拠した通知者は、後続の通知リクエストの「最大レート」サブスクリプションヘッダーフィールドパラメーターの調整された最大通知率を反映する必要があります。指定された「最大定格」値は通知者によって採用され、通知率はそれに応じて調整されます。
A notifier that does not understand this extension will not reflect the "max-rate" Subscription-State header field parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
この拡張機能を理解していない通知者は、Notifyリクエストの「最大定格」サブスクリプションヘッダーフィールドパラメーターを反映していません。このパラメーターがないことは、サブスクライバーに、通信器によってレート制御がサポートされていないことを示します。
A compliant notifier MUST NOT generate a notification if the interval since the most recent notification is less than the reciprocal value of the "max-rate" parameter, except when generating the notification either upon receipt of a SUBSCRIBE request, when the subscription state is changing from "pending" to "active" state, or upon termination of the subscription (the last notification).
準拠した通知は、最新の通知が「最大定格」パラメーターの相互値よりも小さいため、通知を生成してはなりません。「保留」から「アクティブ」状態まで、またはサブスクリプションの終了時（最後の通知）。
When a local policy dictates a maximum rate for notifications, a notifier will not generate notifications more frequently than the local policy maximum rate, even if the subscriber is not asking for maximum rate control. The notifier MAY inform the subscriber about such a local policy maximum rate using the "max-rate" Subscription-State header field parameter included in subsequent NOTIFY requests.
ローカルポリシーが通知の最大レートを決定する場合、通知者は、サブスクライバーが最大レート制御を求めていなくても、ローカルポリシーの最大レートよりも頻繁に通知を生成しません。通知者は、後続のNotifyリクエストに含まれる「Max-rate」サブスクリプションヘッダーフィールドパラメーターを使用して、このようなローカルポリシーの最大レートについてサブスクライバーに通知することができます。
Retransmissions of NOTIFY requests are not affected by the maximum rate mechanism, i.e., the maximum rate mechanism only applies to the generation of new transactions. In other words, the maximum rate mechanism does not in any way break or modify the normal retransmission mechanism specified in RFC 3261 [RFC3261].
通知要求の再送信は、最大レートメカニズムの影響を受けません。つまり、最大レートメカニズムは新しいトランザクションの生成にのみ適用されます。言い換えれば、最大速度メカニズムは、RFC 3261 [RFC3261]で指定された通常の再送信メカニズムを破壊または変更しません。
Special care needs to be taken when selecting the maximum rate. For example, the maximum rate could potentially set a minimum time value between notifications that exceeds the subscription expiration value. Such a configuration would effectively quench the notifier, resulting in exactly two notifications being generated. If the subscriber requests a maximum rate that would result in no notification before the subscription expiration, the notifier MUST increase the maximum rate and set it to the reciprocal value of the remaining subscription expiration time. According to RFC 3265 [RFC3265], the notifier may also shorten the subscription expiry anytime during an active subscription. If the subscription expiry is shortened during an active subscription, the notifier MUST also increase the "max-rate" value and set it to the reciprocal value of the reduced subscription expiration time.
最大レートを選択する際には、特別な注意が必要です。たとえば、最大レートは、サブスクリプションの有効期限を超える通知間で最小時間値を設定する可能性があります。このような構成は、通信器を効果的に消光し、その結果、正確に2つの通知が生成されます。サブスクライバーがサブスクリプションの有効期限の前に通知を行わない最大レートを要求した場合、通知者は最大レートを上げて、残りのサブスクリプションの有効期限の相互値に設定する必要があります。RFC 3265 [RFC3265]によると、通信器は、アクティブなサブスクリプション中にいつでもサブスクリプションの有効期限を短くすることもあります。アクティブなサブスクリプション中にサブスクリプションの有効期限が短縮された場合、通知者は「最大定格」値を増やし、サブスクリプションの有効期限を短縮する相互値に設定する必要があります。
In some cases, it makes sense to temporarily pause the notification stream on an existing subscription dialog without terminating the subscription, e.g., due to inactivity on the application user interface. Whenever a subscriber discovers the need to perform the notification pause operation, it SHOULD set the maximum rate to the reciprocal value of the remaining subscription expiration value. This results in receiving no further notifications until the subscription expires or the subscriber sends a SUBSCRIBE request resuming notifications.
場合によっては、アプリケーションユーザーインターフェイスの不活性のため、サブスクリプションを終了せずに既存のサブスクリプションダイアログで通知ストリームを一時的に一時停止することが理にかなっています。サブスクライバーが通知の一時停止操作を実行する必要性を発見するときはいつでも、最大レートを残りのサブスクリプション有効期限の相互値に設定する必要があります。これにより、サブスクリプションが期限切れになるか、サブスクライバーがサブスクライブリクエストの再開通知を送信するまで、それ以上の通知を受信しません。
The notifier MAY decide to increase or decrease the proposed "max-rate" value by the subscriber based on its local policy, static configuration, or other implementation-determined constraints. In addition, different event packages MAY define other constraints for the allowed maximum rate ranges. Such constraints are out of the scope of this specification.
通知者は、ローカルポリシー、静的構成、またはその他の実装で決定された制約に基づいて、サブスクライバーによって提案された「最大定格」値を増加または減少させることを決定する場合があります。さらに、異なるイベントパッケージは、許可された最大レート範囲の他の制約を定義する場合があります。このような制約は、この仕様の範囲外です。
When applied to a list subscription [RFC4662], the maximum rate mechanism has some additional considerations. Specifically, the maximum rate applies to the aggregate notification stream resulting from the list subscription, rather than explicitly controlling the notification of each of the implied constituent events. Moreover, the RLS can use the maximum rate mechanism on its own to control the rate of the back-end subscriptions to avoid overflowing its buffer.
リストサブスクリプション[RFC4662]に適用すると、最大レートメカニズムにはいくつかの追加の考慮事項があります。具体的には、最大レートは、暗黙の構成要素イベントの各通知を明示的に制御するのではなく、リストサブスクリプションから生じる集約通知ストリームに適用されます。さらに、RLSは、最大レートメカニズムを単独で使用して、バックエンドサブスクリプションの速度を制御して、バッファーのオーバーフローを避けることができます。
The notifier is responsible for sending event notifications upon state changes of the subscribed resource. We can model the notifier as consisting of four components: the event state resource(s), the
通知者は、購読されたリソースの状態変更時にイベント通知を送信する責任があります。4つのコンポーネントで構成される通知者をモデル化できます。イベント状態リソース、
RLS (or any other notifier), a notification buffer, and finally the subscriber, or watcher of the event state, as shown in Figure 1.
図1に示すように、RLS（またはその他の通知者）、通知バッファー、および最終的にイベント状態のサブスクライバーまたはウォッチャー。
+--------+
| Event |
+--------+ |Resource| +--------+
| Event | +--------+ | Event |
|Resource| | |Resource|
+---.=---+ | +---=----+
`-.. | _.--'
``-._ | _.--'
+'--'--'-+
|Resource|
| List |
| Server |
+---.----+
|
|
)--+---(
| | .--------.
|Buffer|<======'max-rate|
| | `--------'
)--.---(
|
|
.---+---.
| Event |
|Watcher|
`-------'
Figure 1: Model for the RLS Supporting Event Rate Control
図1：イベントレートコントロールをサポートするRLSのモデル
In short, the RLS reads event state changes from the event state resource, either by creating a back-end subscription or by other means; it packages them into event notifications and submits them into the output buffer. The rate at which this output buffer drains is controlled by the subscriber via the maximum rate mechanism. When a set of notifications are batched together, the way in which overlapping resource state is handled depends on the type of the resource state:
要するに、RLSは、バックエンドのサブスクリプションを作成するか、他の手段で、イベント状態リソースからのイベント状態の変更を読み取ります。それらをイベント通知にパッケージ化し、それらを出力バッファーに提出します。この出力バッファーが排出される速度は、最大速度メカニズムを介してサブスクライバーによって制御されます。通知のセットが一緒にバッチされている場合、重複するリソース状態が処理される方法は、リソース状態のタイプによって異なります。
In theory, there are many buffer policies that the notifier could implement. However, we only concentrate on two practical buffer policies in this specification, leaving additional ones for further study and out of the scope of this specification. These two buffer policies depend on the mode in which the notifier is operating.
理論的には、通知者が実装できる多くのバッファポリシーがあります。ただし、この仕様には2つの実用的なバッファーポリシーのみに集中しているため、追加のバッファーポリシーはさらなる研究とこの仕様の範囲外に残ります。これらの2つのバッファポリシーは、通知者が動作しているモードに依存します。
Full-state: Last (most recent) full-state notification of each resource is sent out, and all others in the buffer are discarded. This policy applies to those event packages that carry full-state notifications.
フルステート：各リソースの最後の（最新の）フルステート通知が送信され、バッファ内の他のすべてが破棄されます。このポリシーは、フルステート通知を搭載したイベントパッケージに適用されます。
Partial-state: The state deltas of each buffered partial notification per resource are merged, and the resulting notification is sent out. This policy applies to those event packages that carry partial-state notifications.
部分状態：リソースごとにバッファリングされた各部分通知の状態デルタがマージされ、結果の通知が送信されます。このポリシーは、部分状態通知を搭載したイベントパッケージに適用されます。
With partial notifications, the notifier needs to maintain a separate buffer for each subscriber since each subscriber may have a different value for the maximum rate of notifications. The notifier will always need to keep both a copy of the current full state of the resource F, as well as the last successfully communicated full state view F' of the resource in a specific subscription. The construction of a partial notification then involves creating a difference of the two states, and generating a notification that contains that difference.
部分通知を使用すると、各サブスクライバーが通知の最大レートに対して異なる値を持つ可能性があるため、各サブスクライバーの個別のバッファーを維持する必要があります。通知者は、リソースFの現在の完全な状態のコピーと、特定のサブスクリプションでリソースの最後の完全な状態ビューf 'のコピーを常に保持する必要があります。部分的な通知の構築には、2つの状態の違いを作成し、その違いを含む通知を生成することが含まれます。
When the maximum rate mechanism is applied to the subscription, it is important that F' be replaced with F only when the difference of F and F' is already included in a partial-state notification to the subscriber allowed by the maximum rate mechanism. Additionally, the notifier implementation SHOULD check to see that the size of an accumulated partial state notification is smaller than the full state, and if not, the notifier SHOULD send the full-state notification instead.
最大レートメカニズムがサブスクリプションに適用される場合、fとf 'の差が最大レートメカニズムによって許可されたサブスクライバーへの部分状態通知に既に含まれている場合にのみ、fをfに置き換えることが重要です。さらに、通知者の実装では、蓄積された部分状態通知のサイズが完全な状態よりも小さいことを確認する必要があり、そうでない場合は、代わりに完全な状態通知を送信する必要があります。
With full-state notifications, the notifier only needs to keep the full state of the resource, and when that changes, send the resulting notification to the subscriber.
フルステート通知により、宛先はリソースの完全な状態を保持する必要があり、その変更が発生した場合、サブスクライバーに結果の通知を送信します。
When the maximum rate mechanism is applied to the subscription, the notifier receives the state changes of the resource and generates a notification. If there is a pending notification, the notifier simply replaces that notification with the new notification, discarding the older state.
最大レートメカニズムがサブスクリプションに適用されると、監視員はリソースの状態の変更を受信し、通知を生成します。保留中の通知がある場合、Notifierはその通知を新しい通知に置き換え、古い状態を破棄します。
It is difficult to estimate the total bandwidth savings accrued by using the maximum rate mechanism over a subscription, since such estimates will vary depending on the usage scenarios. However, it is easy to see that given a subscription where several full-state notifications would have normally been sent in any given interval set by the "max-rate" parameter, only a single notification is sent during the same interval when using the maximum rate mechanism, yielding bandwidth savings of several times the notification size.
このような推定値は使用状況シナリオによって異なるため、サブスクリプション上の最大レートメカニズムを使用して発生した帯域幅の総節約を推定することは困難です。ただし、「最大定格」パラメーターによって設定された特定のインターバルで通常いくつかのフルステート通知が送信されるサブスクリプションを考えると、最大値を使用する場合、同じ間隔中に1つの通知のみが送信されることがわかります。レートメカニズム、通知サイズの数倍の帯域幅の節約をもたらします。
With partial-state notifications, drawing estimates is further complicated by the fact that the states of consecutive updates may or may not overlap. However, even in the worst-case scenario, where each partial update is to a different part of the full state, a rate controlled notification merging all of these n partial states together should at a maximum be the size of a full-state update. In this case, the bandwidth savings are approximately n times the size of the header fields of the NOTIFY request.
部分状態の通知により、連続した更新状態が重複する場合と重複していない場合があるという事実により、描画の推定値がさらに複雑になります。ただし、各部分的な更新が完全な状態の異なる部分にある最悪のシナリオでさえ、これらのn偏状状態のすべてをまとめるレート制御通知は、最大でフルステートアップデートのサイズでなければなりません。この場合、帯域幅の節約は、Notifyリクエストのヘッダーフィールドのサイズの約n倍です。
It is also true that there are several compression schemes available that have been designed to save bandwidth in SIP, e.g., SigComp [RFC3320] and TLS compression [RFC3943]. However, such compression schemes are complementary rather than competing mechanisms to the maximum rate mechanism. After all, they can both be applied simultaneously.
また、SIP、例えばSigComp [RFC3320]およびTLS圧縮[RFC3943]を節約するように設計されたいくつかの圧縮スキームが利用可能であることも事実です。ただし、このような圧縮スキームは、最大速度メカニズムと競合するメカニズムではなく、補完的なものです。結局のところ、両方を同時に適用できます。
A subscriber that wishes to apply a minimum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the "min-rate" Event header field parameter. This parameter specifies the requested minimum number of notifications per second. The value of this parameter is a positive real number given by a finite decimal representation.
サブスクリプションの通知に最小レートを適用したいサブスクライバーは、「最小レート」イベントヘッダーフィールドパラメーターを含むサブスクライブリクエストを作成する必要があります。このパラメーターは、要求された最小通知の1秒あたりの通知を指定します。このパラメーターの値は、有限10進表現によって与えられる正の実数です。
Note that the grammar in section 9.2 constrains this value to be between 0.0000000001 and 99.9999999999. Zero is not an allowed value.
セクション9.2の文法は、この値が0.0000000001から99.999999999の間であると制約していることに注意してください。ゼロは許容値ではありません。
A subscriber that wishes to update the previously agreed minimum rate of notifications MUST include the updated "min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
以前に合意した最小通知レートを更新したいサブスクライバーには、その後のサブスクライブリクエストまたはNotifyリクエストへの2XX応答に更新された「最小」イベントヘッダーフィールドパラメーターを含める必要があります。
A subscriber that wishes to remove the minimum rate control from notifications MUST indicate so by not including a "min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
通知から最小レートコントロールを削除したいサブスクライバーは、その後のサブスクライブリクエストに「最小レート」イベントヘッダーフィールドパラメーターまたは通知リクエストへの2XX応答を含めないことにより、そのように示す必要があります。
The main consequence for the subscriber when applying the minimum rate mechanism is that it can receive a notification even if nothing has changed in the current state of the notifier. However, RFC 5839 [RFC5839] defines a mechanism that allows suppression of a NOTIFY request or a NOTIFY request body if the state has not changed.
最小レートメカニズムを適用する際のサブスクライバーの主な結果は、通知者の現在の状態で何も変更されていなくても通知を受信できることです。ただし、RFC 5839 [RFC5839]は、状態が変更されていない場合、通知要求または通知リクエスト機の抑制を可能にするメカニズムを定義します。
A notifier that supports the minimum rate mechanism MUST extract the value of the "min-rate" Event header field parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request and use it as the suggested minimum number of notifications per second. This value can be adjusted by the notifier, as defined in Section 6.3.
最小レートメカニズムをサポートする紹介者は、サブスクライブリクエストまたは通知要求への2xx応答から「最小レート」イベントヘッダーフィールドパラメーターの値を抽出し、1秒あたりの最小通知の最小数として使用する必要があります。この値は、セクション6.3で定義されているように、通知者によって調整できます。
A compliant notifier MUST reflect back the possibly adjusted minimum rate of notifications in a "min-rate" Subscription-State header field parameter of the subsequent NOTIFY requests. The indicated "min-rate" value is adopted by the notifier, and the notification rate is adjusted accordingly.
準拠した通知者は、後続の通知リクエストの「最小レート」サブスクリプションヘッダーフィールドパラメーターの調整された最小通知率を反映する必要があります。指定された「最小レート」値は通知者によって採用され、通知率はそれに応じて調整されます。
A notifier that does not understand this extension will not reflect the "min-rate" Subscription-State header field parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
この拡張機能を理解していない通知者は、Notifyリクエストの「最小レート」サブスクリプションヘッダーフィールドパラメーターを反映していません。このパラメーターがないことは、サブスクライバーに、通信器によってレート制御がサポートされていないことを示します。
A compliant notifier MUST generate notifications when state changes occur or when the time since the most recent notification exceeds the reciprocal value of the "min-rate" parameter. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a minimum rate mechanism MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state. If the subscriber and the notifier support the procedures in RFC 5839 [RFC5839], the complete NOTIFY request or the NOTIFY request body can be suppressed if the state has not changed from the previous notification.
準拠した通知者は、状態の変更が発生したときに通知を生成する必要があります。最新の通知が「最小レート」パラメーターの相互値を超える時期が必要です。サブスクライブリクエストに示されているイベントパッケージとサブスクライバー設定に応じて、最小レートメカニズムの結果として送信されたNotifyリクエストには、現在の完全な状態または現在の状態と最後の正常に通信された状態の違いを示す部分状態のいずれかを含める必要があります。。サブスクライバーと通知者がRFC 5839 [RFC5839]の手順をサポートしている場合、状態が以前の通知から変更されていない場合、完全な通知要求またはNotifyリクエスト本体を抑制できます。
Retransmissions of NOTIFY requests are not affected by the minimum rate mechanism, i.e., the minimum rate mechanism only applies to the generation of new transactions. In other words, the minimum rate mechanism does not in any way break or modify the normal retransmission mechanism.
通知要求の再送信は、最小レートメカニズムの影響を受けません。つまり、最小レートメカニズムは新しいトランザクションの生成にのみ適用されます。言い換えれば、最小レートメカニズムは、通常の再送信メカニズムを破壊または変更しません。
The minimum rate mechanism can be used to generate a lot of notifications, creating additional processing load for the notifier. Some of the notifications may also be unnecessary possibly repeating already known state information to the subscriber. It is difficult to provide generic guidelines for the acceptable minimum rate value ranges; however, the subscriber SHOULD request the lowest possible minimum rate. Different event packages MAY define other constraints for the allowed minimum rate values. Such constraints are out of the scope of this specification.
最小レートメカニズムを使用して、多くの通知を生成し、通知者に追加の処理負荷を作成できます。通知の一部は、既知の状態情報を加入者に繰り返す不要な場合もあります。許容可能な最小レート値範囲に一般的なガイドラインを提供することは困難です。ただし、サブスクライバーは可能な限り低い最小レートを要求する必要があります。さまざまなイベントパッケージは、許可された最小レート値の他の制約を定義する場合があります。このような制約は、この仕様の範囲外です。
The notifier MAY decide to increase or decrease the proposed "min-rate" value by the subscriber based on its local policy, static configuration, or other implementation-determined constraints.
通知者は、ローカルポリシー、静的構成、またはその他の実装で決定された制約に基づいて、サブスクライバーによって提案された「最小レート」値を増加または減少させることを決定する場合があります。
A subscriber that wishes to apply an adaptive minimum rate to notifications in a subscription MUST construct a SUBSCRIBE request that includes the "adaptive-min-rate" Event header field parameter. This parameter specifies an adaptive minimum number of notifications per second. The value of this parameter is a positive real number given by a finite decimal representation.
サブスクリプションの通知に適応最小レートを適用したいサブスクライバーは、「Adaptive-Min-Rate」イベントヘッダーフィールドパラメーターを含むサブスクライブリクエストを作成する必要があります。このパラメーターは、秒あたりの適応最小通知数を指定します。このパラメーターの値は、有限10進表現によって与えられる正の実数です。
Note that the grammar in section 9.2 constrains this value to be between 0.0000000001 and 99.9999999999. Zero is not an allowed value.
セクション9.2の文法は、この値が0.0000000001から99.999999999の間であると制約していることに注意してください。ゼロは許容値ではありません。
A subscriber that wishes to update the previously agreed adaptive minimum rate of notifications MUST include the updated "adaptive-min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
以前に合意した適応最小通知レートを更新したいサブスクライバーには、その後のサブスクライブリクエストまたはNotifyリクエストへの2XX応答に更新された「適応型-min-rate」イベントヘッダーフィールドパラメーターを含める必要があります。
A subscriber that wishes to remove the adaptive minimum rate control from notifications MUST indicate so by not including an "adaptive-min-rate" Event header field parameter in a subsequent SUBSCRIBE request or a 2xx response to the NOTIFY request.
通知から適応最小レートコントロールを削除したいサブスクライバーは、その後のサブスクライブリクエストまたは通知リクエストへの2xx応答に「適応型-min-rate」イベントヘッダーフィールドパラメーターを含めないことを示す必要があります。
The main consequence for the subscriber when applying the adaptive minimum rate mechanism is that it can receive a notification, even if nothing has changed in the current state of the notifier. However, RFC 5839 [RFC5839] defines a mechanism that allows suppression of a NOTIFY request or a NOTIFY request body if the state has not changed.
適応最小レートメカニズムを適用する際のサブスクライバーの主な結果は、通知者の現在の状態で何も変更されていなくても、通知を受信できることです。ただし、RFC 5839 [RFC5839]は、状態が変更されていない場合、通知要求または通知リクエスト機の抑制を可能にするメカニズムを定義します。
A notifier that supports the adaptive minimum rate mechanism MUST extract the value of the "adaptive-min-rate" Event header parameter from a SUBSCRIBE request or a 2xx response to the NOTIFY request and use it to calculate the actual maximum time between two notifications, as defined in Section 7.4.
適応型最小レートメカニズムをサポートする紹介者は、サブスクライブリクエストまたは通知要求に対する2xx応答から「適応型-min-rate」イベントヘッダーパラメーターの値を抽出する必要があります。セクション7.4で定義されています。
The "adaptive-min-rate" value can be adjusted by the notifier, as defined in Section 7.3.
セクション7.3で定義されているように、「適応型-min-rate」値は、通知者によって調整できます。
A compliant notifier MUST reflect back the possibly adjusted adaptive minimum rate of notifications in an "adaptive-min-rate" Subscription-State header field parameter of the subsequent NOTIFY requests. The indicated "adaptive-min-rate" value is adopted by the notifier, and the notification rate is adjusted accordingly.
準拠した通知者は、後続のNotifyリクエストの「Adaptive-Min-Rate」サブスクリプションステートヘッダーフィールドパラメーターの調整された適応最小通知率を反映する必要があります。指定された「適応型-min-rate」値は通知者によって採用され、通知率はそれに応じて調整されます。
A notifier that does not understand this extension will not reflect the "adaptive-min-rate" Subscription-State header parameter in the NOTIFY requests; the absence of this parameter indicates to the subscriber that no rate control is supported by the notifier.
この拡張機能を理解していない通知者は、Notifyリクエストの「Adaptive-Min-Rate」サブスクリプション状態ヘッダーパラメーターを反映していません。このパラメーターがないことは、サブスクライバーに、通信器によってレート制御がサポートされていないことを示します。
A compliant notifier MUST generate notifications when state changes occur or when the time since the most recent notification exceeds the value calculated using the formula defined in Section 7.4. Depending on the event package and subscriber preferences indicated in the SUBSCRIBE request, the NOTIFY request sent as a result of a minimum rate mechanism MUST contain either the current full state or the partial state showing the difference between the current state and the last successfully communicated state. If the subscriber and the notifier support the procedures in RFC 5839 [RFC5839], the complete NOTIFY request or the NOTIFY request body can be suppressed if the state has not changed from the previous notification.
準拠通知者は、状態の変更が発生したときに通知を生成する必要があります。最新の通知以来の時間が、セクション7.4で定義された式を使用して計算された値を超えている必要があります。サブスクライブリクエストに示されているイベントパッケージとサブスクライバー設定に応じて、最小レートメカニズムの結果として送信されたNotifyリクエストには、現在の完全な状態または現在の状態と最後の正常に通信された状態の違いを示す部分状態のいずれかを含める必要があります。。サブスクライバーと通知者がRFC 5839 [RFC5839]の手順をサポートしている場合、状態が以前の通知から変更されていない場合、完全な通知要求またはNotifyリクエスト本体を抑制できます。
The adaptive minimum rate mechanism is implemented as follows:
適応最小レートメカニズムは次のように実装されます。
1) When a subscription is first created, the notifier creates a record ("count" parameter) that keeps track of the number of notifications that have been sent in the "period". The "count" parameter is initialized to contain a history of having sent a "period * adaptive-min-rate" number of notifications for the "period".
1) サブスクリプションが最初に作成されると、Notifierは「期間」で送信された通知の数を追跡するレコード（「カウント」パラメーター）を作成します。「カウント」パラメーターは、「ピリオド」の「ピリオド *アダプティブミンレート」数の通知を送信した履歴を含むように初期化されます。
2) The "timeout" value is calculated according to the equation given in Section 7.4.
2) 「タイムアウト」値は、セクション7.4に示されている方程式に従って計算されます。
3) If the timeout period passes without a NOTIFY request being sent in the subscription, then the current resource state is sent (subject to any filtering associated with the subscription).
3) サブスクリプションで通知要求が送信されない場合、タイムアウト期間が通過した場合、現在のリソース状態が送信されます（サブスクリプションに関連付けられたフィルタリングの対象となります）。
4) Whenever a NOTIFY request is sent (regardless of whether due to a "timeout" event or a state change), the notifier updates the notification history record stored in the "count" parameter, recalculates the value of "timeout", and returns to step 3.
4) 通知要求が送信されるたびに（「タイムアウト」イベントまたは状態の変更に起因するかどうかに関係なく）、Notifierは「カウント」パラメーターに保存されている通知履歴レコードを更新し、「タイムアウト」の値を再計算し、ステップに戻ります3。
Retransmissions of NOTIFY requests are not affected by the timeout, i.e., the timeout only applies to the generation of new transactions. In other words, the timeout does not in any way break or modify the normal retransmission mechanism specified in RFC 3261 [RFC3261].
通知リクエストの再送信は、タイムアウトの影響を受けません。つまり、タイムアウトは新しいトランザクションの生成にのみ適用されます。言い換えれば、タイムアウトは、RFC 3261 [RFC3261]で指定された通常の再送信メカニズムを破壊または変更しません。
The adaptive minimum rate mechanism can be used to generate a lot of notifications, creating additional processing load for the notifier. Some of the notifications may also be unnecessary, possibly repeating already known state information to the subscriber. It is difficult to provide generic guidelines for the acceptable adaptive minimum rate value ranges; however, the subscriber SHOULD request the lowest possible adaptive minimum rate value. Different event packages MAY define other constraints for the allowed adaptive minimum rate values. Such constraints are out of the scope of this specification.
適応型最小レートメカニズムを使用して多くの通知を生成し、通知者に追加の処理負荷を作成できます。通知の一部も不要であり、おそらく既知の状態情報を加入者に繰り返している可能性があります。許容可能な適応最小レート値範囲に一般的なガイドラインを提供することは困難です。ただし、サブスクライバーは、可能な限り低い適応最小レート値を要求する必要があります。さまざまなイベントパッケージは、許可された適応最小レート値の他の制約を定義する場合があります。このような制約は、この仕様の範囲外です。
The notifier MAY decide to increase or decrease the proposed "adaptive-min-rate" value based on its local policy, static configuration, or other implementation-determined constraints.
通知者は、ローカルポリシー、静的構成、またはその他の実装で決定された制約に基づいて、提案されている「適応型min-rate」値を増やすか減少させることができます。
The formula used to vary the absolute pacing in a way that will meet the adaptive minimum rate requested over the period is given in equation (1):
絶対ペーシングを変化させるために使用される式は、期間中に要求された適応最小レートを満たす方法で変化させます。
timeout = count / ((adaptive-min-rate ^ 2) * period) (1)
The output of the formula, "timeout", is the time to the next notification, expressed in seconds. The formula has three inputs:
フォーミュラ「タイムアウト」の出力は、次の通知までの時間であり、数秒で表されます。式には3つの入力があります。
adaptive-min-rate: The value of the "adaptive-min-rate" parameter conveyed in the Subscription-State header field.
Adaptive-Min-rate：サブスクリプション状態のヘッダーフィールドで伝達される「適応型-min-rate」パラメーターの値。
period: The rolling average period, in seconds. The granularity of the values for the "period" parameter is set by local policy at the notifier; however, the notifier MUST choose a value greater than the reciprocal value of the "adaptive-min-rate" parameter. It is also RECOMMENDED that the notifier choose a "period" parameter several times larger than reciprocal value of the "adaptive-min-rate" parameter in order to maximize the effectiveness of equation (1). It is an implementation decision whether the notifier uses the same value of the "period" parameter for all subscriptions or individual values for each subscription.
期間：ローリング平均期間、秒単位。「ピリオド」パラメーターの値の粒度は、Notifierのローカルポリシーによって設定されます。ただし、Notifierは、「Adaptive-Min-Rate」パラメーターの相互値よりも大きい値を選択する必要があります。また、通知者は、方程式（1）の有効性を最大化するために、「適応型-min-rate」パラメーターの相互値よりも数倍大きい「期間」パラメーターを選択することをお勧めします。通知者が各サブスクリプションのすべてのサブスクリプションまたは個々の値に対して「ピリオド」パラメーターの同じ値を使用するかどうかは実装決定です。
count: The number of notifications that have been sent during the last "period" of seconds, not including any retransmissions of requests.
カウント：リクエストの再送信を含めずに、秒の最後の「期間」に送信された通知の数。
In case both the maximum rate and the adaptive minimum rate mechanisms are used in the same subscription, the formula used to dynamically calculate the timeout is given in equation (2):
最大レートと適応最小レートメカニズムの両方が同じサブスクリプションで使用されている場合、タイムアウトを動的に計算するために使用される式は、式（2）に示されています。
timeout = MAX[(1/max-rate), count/((adaptive-min-rate ^ 2)*period)] (2)
max-rate: The value of the "max-rate" parameter conveyed in the Subscription-State header field.
MAX-RATE：サブスクリプション状態のヘッダーフィールドで伝達される「最大レート」パラメーターの値。
The formula in (2) makes sure that for all the possible values of the "max-rate" and "adaptive-min-rate" parameters, with "adaptive-min-rate" < "max-rate", the timeout never results in a lower value than the reciprocal value of the "max-rate" parameter.
（2）の式では、「最大平均」および「適応型 - min-rate」パラメーターのすべての可能な値に対して、「適応型-min-rate」<"max-rate」を確実にすることを確認します。「最大定格」パラメーターの相互値よりも低い値。
In some situations, it may be beneficial for the notifier to achieve an adaptive minimum rate in a different way than the algorithm detailed in this document allows. However, the notifier MUST comply with any "max-rate" or "min-rate" parameters that have been negotiated.
状況によっては、このドキュメントで詳述されているアルゴリズムが許可するのとは異なる方法で適応最小レートを達成することがまたかcifuisiveであることが有益かもしれません。ただし、通知者は、交渉された「最大評価」または「最小レート」パラメーターを遵守する必要があります。
8. Usage of the Maximum Rate, Minimum Rate, and Adaptive Minimum Rate Mechanisms in a Combination
8. 組み合わせでの最大レート、最小レート、および適応最小レートメカニズムの使用
Applications can subscribe to an event package using all the rate control mechanisms individually, or in combination; in fact there is no technical incompatibility among them. However, there are some combinations of the different rate control mechanisms that make little sense to be used together. This section lists all the combinations that are possible to insert in a subscription; the ability to use each combination in a subscription is also analyzed.
アプリケーションは、すべてのレート制御メカニズムを個別に、または組み合わせて使用して、イベントパッケージを購読できます。実際、それらの間に技術的な互換性はありません。ただし、一緒に使用することはほとんど意味がない、異なるレート制御メカニズムの組み合わせがいくつかあります。このセクションには、サブスクリプションに挿入できるすべての組み合わせをリストします。サブスクリプションで各組み合わせを使用する機能も分析されます。
maximum rate and minimum rate: This combination allows a reduced notification rate, but at the same time assures the reception of periodic notifications.
最大レートと最小レート：この組み合わせにより、通知率が低下すると同時に、定期的な通知の受信が保証されます。
A subscriber SHOULD choose a "min-rate" value lower than the "max-rate" value, otherwise, the notifier MUST adjust the subscriber provided "min-rate" value to a value equal to or lower than the "max-rate" value.
サブスクライバーは、「最大定格」値よりも低い「最小レート」値を選択する必要があります。そうしないと、通知者は「最小レート」値が「最大レート」以下の値に提供されるサブスクライバーを調整する必要があります。価値。
maximum rate and adaptive minimum rate: It works in a similar way as the combination above, but with the difference that the interval at which notifications are assured changes dynamically.
最大レートと適応最小レート：上記の組み合わせと同様の方法で機能しますが、通知が保証されている間隔が動的に変化するという差があります。
A subscriber SHOULD choose an "adaptive-min-rate" value lower than the "max-rate" value, otherwise, the notifier MUST adjust the subscriber provided "adaptive-min-rate" value to a value equal to or lower than the "max-rate" value.
サブスクライバーは、「最大定格」値よりも低い「適応型min-rate」値を選択する必要があります。そうしないと、紹介者は「適応min-rate」値が提供されたサブスクライバーを「」以下の値に等しい値または低い値に調整する必要があります。最大レート "値。
minimum rate and adaptive minimum rate: When using the adaptive minimum rate mechanism, frequent state changes in a short period can result in no notifications for a longer period following the short period. The addition of the minimum rate mechanism ensures that the subscriber always receives notifications after a specified interval.
最小レートと適応最小レート：適応最小レートメカニズムを使用する場合、短期間で頻繁な状態の変化により、短期間に続いて長期間通知が発生しない可能性があります。最小レートメカニズムの追加により、サブスクライバーが指定された間隔の後に常に通知を受信することが保証されます。
A subscriber SHOULD choose a "min-rate" value lower than the "adaptive-min-rate" value, otherwise, the notifier MUST NOT consider the "min-rate" value.
サブスクライバーは、「適応型-min-rate」値よりも低い「最小レート」値を選択する必要があります。そうしないと、紹介者は「最小レート」値を考慮してはなりません。
maximum rate, minimum rate, and adaptive minimum rate: This combination makes little sense to be used, although it is not forbidden.
最大レート、最小レート、および適応最小レート：この組み合わせは、禁止されていませんが、使用することはほとんど意味がありません。
A subscriber SHOULD choose a "min-rate" and "adaptive-min-rate" values lower than the "max-rate" value, otherwise, the notifier MUST adjust the subscriber provided "min-rate" and "adaptive-min-rate" values to a value equal to or lower than the "max-rate" value.
サブスクライバーは、「最大定格」値よりも低い「最小評価」および「適応型 - min-rate」値を選択する必要があります。そうしないと、紹介者は「最小レート」および「適応型-min-rate」を提供するサブスクライバーを調整する必要があります。「「最大定格」値以下の値への値。
A subscriber SHOULD choose a "min-rate" value lower than the "adaptive-min-rate" value, otherwise, the notifier MUST NOT consider the "min-rate" value.
サブスクライバーは、「適応型-min-rate」値よりも低い「最小レート」値を選択する必要があります。そうしないと、紹介者は「最小レート」値を考慮してはなりません。
This section describes the protocol extensions required for the different rate control mechanisms.
このセクションでは、異なるレート制御メカニズムに必要なプロトコル拡張について説明します。
9.1. "max-rate", "min-rate", and "adaptive-min-rate" Header Field Parameters
9.1. 「Max-rate」、「Min-Rate」、および「Adaptive-Min-Rate」ヘッダーフィールドパラメーター
The "max-rate", "min-rate", and "adaptive-min-rate" parameters are added to the rule definitions of the Event header field and the Subscription-State header field in RFC 3265 [RFC3265] grammar. Usage of this parameter is described in Sections 5, 6, and 7.
「最大レート」、「ミニレート」、および「適応型 - マンレート」パラメーターは、RFC 3265 [RFC3265]文法のイベントヘッダーフィールドとサブスクリプションステートヘッダーフィールドのルール定義に追加されます。このパラメーターの使用法は、セクション5、6、および7で説明されています。
This section describes the Augmented BNF [RFC5234] definitions for the new header field parameters. Note that we derive here from the ruleset present in RFC 3265 [RFC3265], adding additional alternatives to the alternative sets of "event-param" and "subexp-params" defined therein.
このセクションでは、新しいヘッダーフィールドパラメーターの拡張BNF [RFC5234]定義について説明します。ここでは、RFC 3265 [RFC3265]に存在するルールセットから派生しており、そこに定義されている「イベントパラム」と「サブエクスポパラム」の代替セットに追加の代替案を追加することに注意してください。
event-param = max-rate-param
/ min-rate-param
/ amin-rate-param
subexp-params = max-rate-param
/ min-rate-param
/ amin-rate-param
max-rate-param = "max-rate" EQUAL
(1*2DIGIT ["." 1*10DIGIT])
min-rate-param = "min-rate" EQUAL
(1*2DIGIT ["." 1*10DIGIT])
amin-rate-param = "adaptive-min-rate" EQUAL
(1*2DIGIT ["." 1*10DIGIT])
This table expands the table described in Section 7.2 of RFC 3265 [RFC3265], allowing the Event header field to appear in a 2xx response to a NOTIFY request. The use of the Event header field in responses other than 2xx to NOTIFY requests is undefined and out of scope of this specification.
この表は、RFC 3265 [RFC3265]のセクション7.2で説明されている表を展開し、イベントヘッダーフィールドが通知要求に2xx応答で表示されるようにします。2XX以外の回答でイベントヘッダーフィールドを使用してリクエストを通知することは未定義であり、この仕様の範囲外です。
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Event 2xx - - - - - - - - o
A subscriber that wishes to update the previously agreed value for maximum, minimum, or adaptive minimum rate of notifications MUST include all desired values for the "max-rate", "min-rate", and "adaptive-min-rate" parameters in an Event header field of the 2xx response to a NOTIFY request. Any of the other header field
通知の最大、最小、または適応最小レートの最大値、最小値、または適応最小レートで、以前に合意した値を更新したいサブスクライバーには、「最大評価」、「MIN-RATE」、および「Adaptive-Min-rate」パラメーターのすべての望ましい値を含める必要があります。Notifyリクエストに対する2XX応答のイベントヘッダーフィールド。他のヘッダーフィールドのいずれか
parameters currently defined for the Event header field by other specifications do not have a meaning if the Event header field is included in the 2xx response to the NOTIFY request. These header field parameters MUST be ignored by the notifier, if present.
他の仕様によってイベントヘッダーフィールドに現在定義されているパラメーターには、イベントヘッダーフィールドがNotifyリクエストへの2XX応答に含まれている場合、意味がありません。これらのヘッダーフィールドパラメーターは、存在する場合は通信器によって無視する必要があります。
The event type listed in the Event header field of the 2xx response to the NOTIFY request MUST match the event type of the Event header field in the corresponding NOTIFY request.
Notifyリクエストに対する2xx応答のイベントヘッダーフィールドにリストされているイベントタイプは、対応するNotifyリクエストのイベントヘッダーフィールドのイベントタイプと一致する必要があります。
This specification registers three new SIP header field parameters in the "Header Field Parameters and Parameter Values" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry.
この仕様は、「ヘッダーフィールドパラメーターとパラメーター値」の3つの新しいSIPヘッダーフィールドパラメーターを「セッション開始プロトコル（SIP）パラメーター」レジストリのサブレジストリに登録します。
Predefined
Header Field Parameter Name Values Reference
-------------------- --------------- ---------- ---------
Event max-rate No [RFC6446]
Subscription-State max-rate No [RFC6446]
Event min-rate No [RFC6446]
Subscription-State min-rate No [RFC6446]
Event adaptive-min-rate No [RFC6446]
Subscription-State adaptive-min-rate No [RFC6446]
This specification also updates the reference defining the Event header field in the "Header Fields" sub-registry of the "Session Initiation Protocol (SIP) Parameters" registry.
この仕様は、「セッション開始プロトコル（SIP）パラメーター」レジストリの「ヘッダーフィールド」のサブレジストリのイベントヘッダーフィールドを定義するリファレンスを更新します。
Header Name compact Reference
----------- ------- ------------------
Event o [RFC3265][RFC6446]
Naturally, the security considerations listed in RFC 3265 [RFC3265], which the rate control mechanisms described in this document extends, apply in their entirety. In particular, authentication and message integrity SHOULD be applied to subscriptions with this extension.
当然、RFC 3265 [RFC3265]にリストされているセキュリティ上の考慮事項は、このドキュメントで説明されているレート制御メカニズムが拡張され、全体が適用されます。特に、この拡張機能を使用して、認証とメッセージの整合性をサブスクリプションに適用する必要があります。
RFC 3265 [RFC3265] recommends the integrity protection of the Event header field of SUBSCRIBE requests. Implementations of this extension SHOULD also provide integrity protection for the Event header field included in the 2xx response to the NOTIFY request. Without integrity protection, an eavesdropper could see and modify the Event header field, or it could manipulate the transmission of a 200 (OK) response to the NOTIFY request to suppress or flood notifications without the subscriber seeing what caused the problem.
RFC 3265 [RFC3265]は、購読要求のイベントヘッダーフィールドの整合性保護を推奨しています。この拡張機能の実装は、Notifyリクエストへの2XX応答に含まれるイベントヘッダーフィールドの整合性保護も提供する必要があります。整合性保護がなければ、盗聴者はイベントヘッダーフィールドを見て変更したり、問題の原因を確認せずに抑制またはフラッディング通知の通知要求に対する200（OK）応答の送信を操作することができます。
When the maximum rate mechanism involves partial-state notifications, the security considerations listed in RFC 5263 [RFC5263] apply in their entirety.
最大レートメカニズムに部分状態通知が含まれる場合、RFC 5263 [RFC5263]にリストされているセキュリティに関する考慮事項全体が適用されます。
Thanks to Pekka Pessi, Dean Willis, Eric Burger, Alex Audu, Alexander Milinski, Jonathan Rosenberg, Cullen Jennings, Adam Roach, Hisham Khartabil, Dale Worley, Martin Thomson, Byron Campen, Alan Johnston, Michael Procter, Janet Gunn, and Ari Keranen for support and/or review of this work.
ペッカ・ペッシ、ディーン・ウィリス、エリック・バーガー、アレックス・オードゥ、アレクサンダー・ミリンスキー、ジョナサン・ローゼンバーグ、カレン・ジェニングス、アダム・ローチ、ヒシャム・ハルタビル、デール・ウォーリー、マーティン・トムソン、バイロン・カンペン、アラン・ジョンストン、マイケル・プロクター、ジャネット・ガン、アリ・ケラネンこの作業のサポートおよび/またはレビューのため。
Thanks to Brian Rosen for the idea of the minimum and adaptive minimum rate mechanisms, and to Adam Roach for the work on the algorithm for the adaptive minimum rate mechanism and other feedback.
最小および適応型の最小レートメカニズムのアイデアについては、Adam Roachに感謝します。また、適応最小レートメカニズムおよびその他のフィードバックのアルゴリズムでの作業については、Adam Roachに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3261] 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.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662] Roach、A.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張」、RFC 4662、2006年8月。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234] Crocker、D.、ed。およびP. Overell、「構文仕様のためのBNFの増強：ABNF」、STD 68、RFC 5234、2008年1月。
[RFC5263] Lonnfors, M., Costa-Requena, J., Leppanen, E., and H. Khartabil, "Session Initiation Protocol (SIP) Extension for Partial Notification of Presence Information", RFC 5263, September 2008.
[RFC5263] Lonnfors、M.、Costa-Requena、J.、Leppanen、E。、およびH. Khartabil、「存在情報の部分的な通知のためのセッション開始プロトコル（SIP）拡張」、RFC 5263、2008年9月。
[RFC3320] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003.
[RFC3320] Price、R.、Bormann、C.、Christoffersson、J.、Hannu、H.、Liu、Z。、およびJ. Rosenberg、「Signaling Compression（Sigcomp）」、RFC 3320、2003年1月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680] Rosenberg、J。、「登録のためのセッション開始プロトコル（SIP）イベントパッケージ」、RFC 3680、2004年3月。
[RFC3842] Mahy, R., "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)", RFC 3842, August 2004.
[RFC3842] Mahy、R。、「セッション開始プロトコル（SIP）のメッセージの概要とメッセージ待機表示イベントパッケージ」、RFC 3842、2004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856] Rosenberg、J。、「セッション開始プロトコル（SIP）のプレゼンスイベントパッケージ」、RFC 3856、2004年8月。
[RFC3857] Rosenberg, J., "A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP)", RFC 3857, August 2004.
[RFC3857] Rosenberg、J。、「セッション開始プロトコル（SIP）のウォッチャー情報イベントテンプレートパッケージ」、RFC 3857、2004年8月。
[RFC3943] Friend, R., "Transport Layer Security (TLS) Protocol Compression Using Lempel-Ziv-Stac (LZS)", RFC 3943, November 2004.
[RFC3943] Friend、R。、「LEMPEL-ZIV-STAC（LZS）を使用した輸送層セキュリティ（TLS）プロトコル圧縮」、RFC 3943、2004年11月。
[RFC5839] Niemi, A. and D. Willis, Ed., "An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification", RFC 5839, May 2010.
[RFC5839] Niemi、A。およびD. Willis編、「条件付きイベント通知のためのセッション開始プロトコル（SIP）イベントの拡張」、RFC 5839、2010年5月。
[RFC6447] Mahy, R., Rosen, B., and H. Tschofenig, "Filtering Location Notifications in the Session Initiation Protocol (SIP)", RFC 6447, January 2012.
[RFC6447] Mahy、R.、Rosen、B。、およびH. Tschofenig、「セッション開始プロトコル（SIP）の位置通知のフィルタリング」、RFC 6447、2012年1月。
Authors' Addresses
著者のアドレス
Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
Aki niemi Nokia P.O.Box 407 Nokia Group、Fin 00045フィンランド
Phone: +358 50 389 1644
EMail: aki.niemi@nokia.com
Krisztian Kiss Nokia 200 South Mathilda Ave Sunnyvale, CA 94086 US
クリスティアン・キス・ノキア200サウスマチルダアベニューサニーベール、カリフォルニア94086米国
Phone: +1 650 391 5969
EMail: krisztian.kiss@nokia.com
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland
Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420フィンランド
EMail: salvatore.loreto@ericsson.com