Internet Engineering Task Force (IETF) A. Niemi
Request for Comments: 5839 Nokia
Category: Standards Track D. Willis, Ed.
ISSN: 2070-1721 Softarmor Systems
May 2010
An Extension to Session Initiation Protocol (SIP) Events
for Conditional Event Notification
Abstract
抽象
The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing, and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed.
セッション開始プロトコル（SIP）イベント・フレームワークは、他のSIPユーザエージェントからの様々なイベントの非同期通知を受信可能にします。このフレームワークは、作成リフレッシュ、およびサブスクリプションを終了、ならびにフェッチおよびリソースの状態の定期的なポーリングのための手順を定義します。これらの手順は、すでにユーザーエージェントが受信したイベント通知を再生避けるために、何のツールを提供していません。このメモは、加入者が、前の通知を受信してから状態が変化したかどうかにサブスクリプション要求を調整することを可能にするSIPイベントに拡張を定義します。そのような条件が真である場合、得られたイベント通知の本体全体通知メッセージのいずれかが抑制されます。
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/rfc5839.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5839で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Document Conventions . . . . . . . . . . . . . . . . . . . 5
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Motivations and Background . . . . . . . . . . . . . . . . . . 5
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Problem Description . . . . . . . . . . . . . . . . . . . 5
2.3. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 7
4. Resource Model for Entity-Tags . . . . . . . . . . . . . . . . 10
5. Subscriber Behavior . . . . . . . . . . . . . . . . . . . . . 12
5.1. Detecting Support for Conditional Notification . . . . . . 13
5.2. Generating SUBSCRIBE Requests . . . . . . . . . . . . . . 13
5.3. Receiving NOTIFY Requests . . . . . . . . . . . . . . . . 14
5.4. Polling or Fetching Resource State . . . . . . . . . . . . 15
5.5. Resuming a Subscription . . . . . . . . . . . . . . . . . 17
5.6. Refreshing a Subscription . . . . . . . . . . . . . . . . 18
5.7. Terminating a Subscription . . . . . . . . . . . . . . . . 18
5.8. Handling Transient Errors . . . . . . . . . . . . . . . . 19
6. Notifier Behavior . . . . . . . . . . . . . . . . . . . . . . 20
6.1. Generating Entity-tags . . . . . . . . . . . . . . . . . . 20
6.2. Suppressing NOTIFY Bodies . . . . . . . . . . . . . . . . 20
6.3. Suppressing NOTIFY Requests . . . . . . . . . . . . . . . 21
6.4. State Differentials . . . . . . . . . . . . . . . . . . . 21
6.5. List Subscriptions . . . . . . . . . . . . . . . . . . . . 22
7. Protocol Element Definitions . . . . . . . . . . . . . . . . . 22
7.1. 204 (No Notification) Response Code . . . . . . . . . . . 22
7.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 22
7.3. Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
8.1. 204 (No Notification) Response Code . . . . . . . . . . . 23
8.2. Suppress-If-Match Header Field . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 24
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
11.1. Normative References . . . . . . . . . . . . . . . . . . . 24
11.2. Informative References . . . . . . . . . . . . . . . . . . 24
The Session Initiation Protocol (SIP) events framework provides an extensible facility for requesting notification of certain events from other SIP user agents. This framework includes procedures for creating, refreshing, and terminating subscriptions, as well as the possibility to fetch or periodically poll the event resource.
セッション開始プロトコル（SIP）イベント・フレームワークは、他のSIPユーザエージェントからの特定のイベントの通知を要求するための拡張機能を提供します。このフレームワークは、作成リフレッシュ、およびサブスクリプションを終了する手順、ならびにイベントリソースをフェッチまたは定期的にポーリングする可能性を含みます。
Several instantiations of this framework, called event packages have been defined, e.g., for presence [RFC3856], message waiting indications [RFC3842], and registrations [RFC3680].
このフレームワークのいくつかのインスタンスは、呼び出されたイベントパッケージが存在する[RFC3856]、メッセージ待機指示[RFC3842]、および登録[RFC3680]のために、例えば、定義されています。
By default, every SUBSCRIBE request generates a NOTIFY request containing the latest event state. Typically, a SUBSCRIBE request is issued by the subscriber whenever it needs a subscription to be installed, periodically refreshed, or terminated. Once the subscription has been installed, the majority of the NOTIFYs generated by the subscription refreshes are superfluous; the subscriber usually is in possession of the event state already, except in the unlikely case where a state change exactly coincides with the periodic subscription refresh. In most cases, the final event state generated upon terminating the subscription similarly contains resource state that the subscriber already has.
デフォルトでは、すべての要求は、最新のイベント状態を含むNOTIFYリクエストを生成SUBSCRIBE。一般的に、SUBSCRIBEリクエストは、それがインストールされているサブスクリプションが必要な時はいつでも加入者によって発行され、定期的にリフレッシュ、または終了します。サブスクリプションがインストールされると、サブスクリプションの更新によって生成されたのNOTIFYの大半は不要です。加入者は、通常、状態変化を正確に定期的なサブスクリプションの更新と一致する可能性は低い場合を除き、すでにイベント状態を所有しています。ほとんどの場合、サブスクリプションを終了する際に発生する最後のイベントの状態は、同様に、加入者がすでに持っているリソースの状態が含まれています。
Fetching or polling of resource state behaves in a similarly suboptimal way in cases where the state has not changed since the previous poll occurred. In general, the problem lies with the inability to persist state across a SUBSCRIBE request.
フェッチまたはリソースの状態のポーリングは、前のポーリングが発生したため、状態が変更されていない場合においても同様に、次善のように動作します。一般的に、問題は、SUBSCRIBEリクエストを横切って状態を保持することができないことです。
This memo defines an extension to optimize the SIP events framework. This extension allows a notifier to tag notifications (called entity-tags hereafter) and the subscriber to condition its subsequent SUBSCRIBE requests for actual changes since a notification carrying that entity-tag was issued. The solution is similar to conditional requests defined in the Hypertext Transfer Protocol (HTTP) [RFC2616], and follows the mechanism already defined for the PUBLISH [RFC3903] method for issuing conditional event publications.
このメモは、SIPイベント・フレームワークを最適化するための拡張を定義します。この拡張は、通知（と呼ばれるエンティティタグ以下）とエンティティタグが発行されたことを運ぶの通知以降の実際の変更のために、それに続くSUBSCRIBEリクエストを調整するために、加入者にタグを通知することができます。溶液は、ハイパーテキスト転送プロトコル（HTTP）[RFC2616]で定義された条件付きの要求と同様であり、既に条件イベントパブリケーションを発行するためのPUBLISH [RFC3903]方法のために定義されたメカニズムに従います。
This memo is structured as follows. Section 2 explains the background, motivations, and requirements for the work; Section 3 gives a general overview of the mechanism; Section 4 explains the underlying model for resources and entities as they apply to conditional notification; Section 5 defines the subscriber behavior; Section 6 defines the notifier behavior; Section 7 includes the protocol element definitions; Section 8 includes the IANA considerations; and Section 9 includes the security considerations.
次のようにこのメモは構成されています。第2節では、仕事の背景、動機、および要件について説明します。第3節では、メカニズムの一般的な概要を説明します。彼らは条件付きの通知に適用される第4節では、リソースとエンティティのための基礎となるモデルを説明します。セクション5は、加入者の挙動を定義します。セクション6は、通知動作を定義します。セクション7は、プロトコル要素の定義を含みます。第8章は、IANAの考慮を含み;そして、セクション9は、セキュリティ上の考慮事項が含まれています。
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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations.
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119 [RFC2119]に記載され、対応する実装の要求レベルを示すものと解釈されます。
In addition to the terminology introduced in [RFC3261], [RFC3265], and [RFC3903], this specification uses these additional terms to describe the objects of conditional notification:
[RFC3261]で導入された用語、[RFC3265]及び[RFC3903]に加えて、本明細書は、条件通知のオブジェクトを記述するために、これらの追加の用語を使用します。
resource An object identified by a URI whose resource state can be accessed using the SIP Event Notification framework. There is a single authoritative notifier responsible for communicating the resource state.
そのリソース状態SIPイベント通知フレームワークを使用してアクセスすることができるURIで識別されるオブジェクトをリソース。リソースの状態を通信するための責任を単一の権威通知があります。
entity The representation of resource state. An entity consists of the state data carried in the body of a NOTIFY message, as well as related meta-data in the message header. There may be many versions of an entity, one current and the others stale. Each version of an entity is identified by an entity-tag, which is guaranteed to be unique across all versions of all entities for a resource and event package.
エンティティのリソース状態の表現。エンティティは、NOTIFYメッセージのボディで搬送状態データ、並びにメッセージヘッダー内の関連するメタデータから成ります。多くのエンティティのバージョン、一方の電流および他は古いがあるかもしれません。エンティティの各バージョンは、リソースおよびイベントパッケージのすべてのエンティティのすべてのバージョン間で一意であることが保証されるエンティティタグによって識別されます。
A SUBSCRIBE request creates a subscription with a finite lifetime. This lifetime is negotiated using the Expires header field, and unless the subscription is refreshed by the subscriber before the expiration is met, the subscription is terminated. The frequency of these subscription refreshes depends on the event package, and typically ranges from minutes to hours.
SUBSCRIBEリクエストは、有限の寿命を持つサブスクリプションを作成します。この寿命はExpiresヘッダーフィールドを使用してネゴシエートされ、サブスクリプションは有効期限が満たされる前に、加入者によって更新されない限り、サブスクリプションが終了されます。これらのサブスクリプションの更新の頻度は、イベントパッケージに依存し、通常は数分から数時間の範囲です。
The SIP events framework does not include different protocol methods for initiating and terminating of subscriptions, subscription refreshes, and fetches inside and outside of the SIP dialog. The SUBSCRIBE method is overloaded to perform all of these functions. The difference between a fetch that does not create a (lasting) subscription and a SUBSCRIBE that creates one is in the Expires header field value of the SUBSCRIBE; a zero-expiry SUBSCRIBE only generates a single NOTIFY, after which the subscription immediately terminates. Lasting subscriptions typically have relatively short expiry periods, requiring periodic sending of new SUBSCRIBE requests in order to refresh the subscription.
SIPイベント・フレームワークは、開始とサブスクリプション、サブスクリプションの更新を終了するための異なるプロトコル方法を含み、内側およびSIPダイアログの外側にフェッチしません。 SUBSCRIBEメソッドは、これらの機能のすべてを実行するためにオーバーロードされます。すなわち、（持続）サブスクリプションを作成し、その一つは、SUBSCRIBEのヘッダフィールド値を有効期限内で作成加入していないフェッチとの間の差、ゼロの有効期限は、サブスクリプションがすぐに終了した後、NOTIFYシングルを生成SUBSCRIBE。永続的なサブスクリプションは、通常、定期的なサブスクリプションをリフレッシュするために、新しいSUBSCRIBEリクエストの送信を必要とし、比較的短い期間満了期間を持っています。
Each new SUBSCRIBE request generates a NOTIFY request containing the latest resource state. Even if the state has not changed, it is sent again in response to each poll or subscription refresh. This is very similar to the HTTP [RFC2616] problem of repeated GET operations on a resource. HTTP solves the problem using conditional requests. The server versions each entity with an entity-tag that identifies a specific instance of that entity. Clients making GET requests can then include the entity-tag for the version of the entity that they believe to be current in an "If-None-Match" header field. The server can compare this entity-tag to the entity it believes to be current and suppress resending the entity in the response if the server believes the client's version matches. In other words, the server doesn't resend information that the client has already received.
それぞれの新しいSUBSCRIBEリクエストは、最新のリソースの状態を含むNOTIFYリクエストを生成します。状態が変更されていない場合でも、それは、各ポーリングまたはサブスクリプションの更新に応じて再送信されます。これは、リソースの繰り返しGET操作のHTTP [RFC2616]の問題に非常によく似ています。 HTTPは、条件付きリクエストを使用して問題を解決します。サーバのバージョン、そのエンティティの特定のインスタンスを識別するエンティティタグを有する各エンティティ。 GET要求を行うクライアントは、その後、彼らは「もし-なしマッチ」ヘッダフィールドに現在のことを信じているエンティティのバージョンのためのエンティティタグを含めることができます。サーバーは、それが現在のもので、サーバーがクライアントのバージョンの一致を信じている場合は、応答にエンティティを再送抑制すると考えているエンティティに、このエンティティタグを比較することができます。つまり、サーバーは、クライアントがすでに受信した情報を再送信しません。
The SIP PUBLISH [RFC3903] method uses a similar mechanism, where a refresh of a publication is done by reference to its assigned entity-tag, instead of retransmitting the event state each time the publication expiration is extended.
SIPは、[RFC3903]メソッドを公開する類似の出版物のリフレッシュがその割り当てられたエンティティタグを参照することによって行われる機構、の代わりにイベント状態を出版期限が延長されるたびに再送信を使用します。
As a summary, here is the required functionality to solve the presented issues:
要約すると、ここで紹介する問題を解決するために必要な機能は以下のとおりです。
REQ1: It must be possible to suppress the NOTIFY request (or at a minimum, the event body therein) if the subscriber is already in possession of (or has previously received and discarded) the latest event state of the resource.
REQ1：加入者が所持で既に（または以前に受信して廃棄した）場合は、NOTIFYリクエスト（その中または最小で、イベント体）を抑制するためにリソースの最新イベント状態が可能でなければなりません。
REQ2: This mechanism must apply to initial subscriptions in which the subscriber is attempting to resume an earlier subscription that has been paused.
REQ2：このメカニズムは、加入者が一時停止された以前のサブスクリプションを再開しようとしている最初のサブスクリプションに適用する必要があります。
REQ3: This mechanism must apply to refreshing a subscription.
REQ3：このメカニズムは、サブスクリプションをリフレッシュするために適用する必要があります。
REQ4: This mechanism must apply to terminating a subscription (i.e., an unsubscribe).
REQ4：このメカニズムは、サブスクリプション（すなわち、解除）を終端に適用されなければなりません。
REQ5: This mechanism must apply to fetching or polling of resource state.
REQ5：このメカニズムは、リソースの状態のフェッチまたはポーリングに適用する必要があります。
Whenever a subscriber initiates a subscription, it issues a SUBSCRIBE request. The SUBSCRIBE request is sent, routed, and processed by the notifier normally, i.e., according to the Session Initiation Protocol [RFC3261] and SIP-Specific Event Notification [RFC3265].
加入者がサブスクリプションを開始するたびに、SUBSCRIBEリクエストを発行します。 SUBSCRIBEリクエストは、セッション開始プロトコル[RFC3261]とSIP固有のイベント通知[RFC3265]に従って、すなわち、送信されるルーティングされ、通常は通知によって処理されます。
If the notifier receiving the SUBSCRIBE request supports conditional subscriptions, it generates an entity-tag for the current entity, and includes it in a SIP-ETag header field of the NOTIFY request. The entity-tag is unique across all versions of all entities for a resource and event package. See Section 4 for more on this.
SUBSCRIBEリクエストを受信した通知条件サブスクリプションをサポートしている場合、それは現在のエンティティのエンティティタグを生成し、NOTIFY要求のSIP-ETagヘッダフィールドの中に含まれています。エンティティタグは、リソースおよびイベントパッケージのすべてのエンティティのすべてのバージョン間で一意です。これに関する詳細については、セクション4を参照してください。
Entity-tags are independent of subscriptions. This allows notifications generated to a fetch or a poll to have valid entity-tags even across subsequent fetches or polls.
エンティティタグは、サブスクリプションとは無関係です。これは、フェッチまたはポーリングに生成される通知も、後続のフェッチまたはポーリング間で有効なエンティティタグを持つことができます。
The subscriber will store the entity-tag received in the notification along with the resource state. It can then later use this entity-tag to make a SUBSCRIBE contain a condition in the form of a "Suppress-If-Match" header field. Unlike the "If-Match" condition in a PUBLISH [RFC3903] request, which applies to whether the PUBLISH succeeds or returns an error, this condition applies to the stream of notifications that are sent after the SUBSCRIBE request has been processed.
加入者は、リソースの状態とともに通知で受信したエンティティタグを格納します。これは、その後、「抑止-IF-マッチ」ヘッダフィールドの形で条件が含まれているSUBSCRIBE作るために、このエンティティタグを使用することができます。 PUBLISHがエラーを成功するか返すかどうかにも適用されるPUBLISH [RFC3903]の要求、で「もしマッチ」の条件とは異なり、この条件は、SUBSCRIBEリクエストが処理された後に送信される通知のストリームに適用されます。
The Suppress-If-Match header field contains the last entity-tag seen by the subscriber. This condition, if true, instructs the notifier to suppress either the body of a subsequent notification, or the entire notification.
抑制-If-Matchヘッダフィールドは、加入者によって見られる最後のエンティティタグを含みます。この条件は、trueの場合、後続の通知の本体、または全体通知のいずれかを抑制するために通知を指示します。
The condition is evaluated by matching the value of the header field against the entity-tag of the entity that would normally be sent in the associated NOTIFY message. There is also a wildcard entity-tag with a special value of "*" that always matches.
条件は、通常、関連するNOTIFYメッセージで送信されるエンティティのエンティティタグに対するヘッダ・フィールドの値を照合することによって評価されます。常に一致する「*」の特殊な値を持つワイルドカードエンティティタグもあります。
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 3600
<-------- (2) 200 (or 202)
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ffee2
(4) 200 -------->
... time passes ...
... 時を経て ...
(5) SUBSCRIBE --------> \ if "ffee2"
Suppress-If-Match: ffee2 | matches
Expires: 3600 | local
| entity-tag
|
<-------- (6) 204 / then
... time passes and resource state (entity) changes...
...時間が経過し、リソースの状態（エンティティ）の変更...
<-------- (7) NOTIFY
Subscription-State: active
SIP-ETag: ca89a
(8) 200 -------->
... time passes ...
... 時を経て ...
(9) SUBSCRIBE --------> \ if "ca89"
Suppress-If-Match: ca89a | matches
Expires: 0 | local
| entity-tag
|
<-------- (10) 204 / then
Figure 1: Example Message Flow
図1：例メッセージフロー
Figure 1 describes a typical message flow for conditional notification:
図1は、条件通知のための典型的なメッセージフローを示します。
(1) The subscriber initiates a subscription by sending a SUBSCRIBE request for a resource.
（1）加入者は、リソースに対するSUBSCRIBE要求を送信することによって、サブスクリプションを開始します。
(2) After proper authentication and authorization, the notifier accepts the subscription.
（2）適切な認証および承認した後、通知サブスクリプションを受け入れます。
(3) The notifier then immediately sends the initial event notification, including a unique entity-tag in a SIP-ETag header field.
（3）通知は、直ちにSIP-ETagヘッダフィールドの一意のエンティティタグを含む、初期のイベント通知を送信します。
(4) The subscriber accepts the notification and stores the entity-tag value along with the resource state.
（4）加入者が通知を受け付けると、リソース状態と共にエンティティタグ値を格納します。
(5) Later, the subscriber refreshes the subscription, and includes an entity-tag in a Suppress-If-Match header field.
（5）その後、加入者は、サブスクリプションを更新し、そして抑制-IF-Matchヘッダフィールドのエンティティタグを含みます。
(6) The notifier evaluates the condition by matching its local entity-tag value for the resource against the value of the Suppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that the notification will not be sent.
（6）通知は抑制-If-Matchヘッダフィールドの値に対してリソースのためにそのローカルエンティティタグ値を照合することによって、条件を評価します。条件が真と評価された場合、通知は、通知が送信されません加入者に通知します。
(7) At some point, the state of the resource changes, e.g., the presence status of a user changes from online to busy. This triggers an event notification with a new value in the SIP-ETag header field.
（7）ある時点で、リソースの状態が変化し、例えば、ユーザが変更のプレゼンス状態オンラインからビジーです。これは、SIP-ETagヘッダフィールドに新しい値を持つイベント通知をトリガします。
(8) The subscriber accepts the notification and stores the new entity-tag along with the resource state.
（8）加入者が通知を受け付けると、リソース状態と共に新しいエンティティタグを格納します。
(9) After a while, the subscriber decides to terminate the subscription. It adds a condition for Suppress-If-Match, and includes the entity-tag it received in the previous NOTIFY.
（9）しばらくして、加入者は、加入を終了することを決定します。それは抑制-IF-マッチのための条件を追加し、それは前のNOTIFYで受信エンティティタグを含んでいます。
(10) The notifier evaluates the condition by matching its entity-tag for the resource against the value of the Suppress-If-Match header field. If the condition evaluates to true, the notifier informs the subscriber that no notification will be sent. This concludes the subscription.
（10）通知は抑制-IF-Matchヘッダフィールドの値に対してリソースのそのエンティティタグを照合することによって、条件を評価します。条件が真と評価された場合、通知には、通知が送信されません加入者に通知します。これは、サブスクリプションを終了します。
The benefit of using conditional notification in this example is in the reduction of the number of NOTIFY requests the subscriber can expect to receive. Each event notification that the subscriber has already seen is suppressed by the notifier. This example illustrates only one use case for the mechanism; the same principles can be used to optimize the flow of messages related to other event notification use cases.
この例では、条件通知を使用する利点は、加入者が受け取ることを期待することができNOTIFY要求の数の減少です。加入者が既に見た各イベント通知は、通知によって抑制されます。この例では、メカニズムのための唯一の使用事例を示す図です。同じ原理は、他のイベント通知の使用事例に関連するメッセージの流れを最適化するために使用することができます。
The key to understanding how conditional notification works is understanding the underlying resource model of event notification. In general, this model is similar to the resource model of HTTP with some key differences. This section explains in detail the model as it applies to SIP events. Figure 2 illustrates the model.
条件付きの通知がどのように機能するかを理解する鍵は、イベント通知の基盤となるリソースモデルを理解することです。一般的に、このモデルは、いくつかの重要な違いを持つHTTPのリソースモデルに似ています。それは、イベントをSIPに適用されるこのセクションでは、詳細なモデルを説明しています。図2は、モデルを示します。
+-----+
............ | |
. . | URI |
. Represen . | |
. tation . +-----+
. . |*
............ |
. |
. V
. +----------+ +---------+
composition | |* | Event |
+------<>| Resource |----------->| Package |<----.
| | | | | |
| +----------+ +----.----+ |
| /_\ |
|* | classification
+--------+ | |
| | .----------------.------' |
| Entity | | | |
| | | | |*
+--------+ +----------+ +------------+ +----------+
^ | | | | | |
| | Presence | | Conference | | Template |
| | | | | | |
|1..* +----------+ +------------+ +----.-----+
+---------+ /_\
| | |
| Version | |
| | +---------+
+---------+ | Watcher |
|1 | Info |
| | |
V +---------+
+---------+
| Entity- |
| Tag |
| |
+---------+
Figure 2: Resource Model Diagram
図2：リソース・モデルダイアグラム
For a given event package, there is a single authoritative agent responsible for zero or more resources. That is, even for a distributed agent, the resource state is uniform across all instances. The resource itself can be a list of resources [RFC4662]. Conditional notification for list subscriptions is addressed in Section 6.5.
与えられたイベントパッケージの場合は、ゼロ以上のリソースを担当する単一の権威エージェントがあります。つまり、偶数分散剤については、リソースの状態がすべてのインスタンスにわたって均一です。リソース自体は資源[RFC4662]のリストを指定できます。リストサブスクリプションの条件付き通知は、セクション6.5で扱われています。
A resource is identified by zero or more URIs, which can be SIP URIs, pres URIs [RFC3859], or similar. Subscribers use this URI to subscribe to the resource for certain types of events, identified by the event package.
リソースは、SIP URIを、PRESのURI [RFC3859]、または同様のものとすることができるゼロ以上のURIによって識別されます。加入者は、イベントパッケージによって識別される特定の種類のイベントのためのリソースをサブスクライブするために、このURIを使用しています。
With a successful subscription, a subscriber receives event notifications that communicate the resource state and the changes thereto. Each event notification carries a representation of the current resource state. This representation is influenced by many factors, e.g., authorization and filtering rules, and the event composition rules of the notifier.
成功したサブスクリプションと、加入者は、リソースの状態及びそれに変更を伝えるイベント通知を受信します。各イベント通知は、現在のリソース状態の表現を運びます。この表現は、多くの要因、例えば、認可およびフィルタリングルール、および通知のイベント構成規則によって影響されます。
This representation is realized in an "entity". Each resource may be associated with zero or more entities. For example, there may be multiple subscribers to the presence information of a single user (a resource), and each subscriber may have a different filtered view of that resource, producing one entity per subscriber. However, each entity is associated with one and only one resource; there is no "compositing" of resources at the entity level. Resources may themselves be made up of information from other resources (be "composite resources"), but this does not change the one-resource-per-entity rule.
この表現は、「実体」で実現されています。各リソースは、ゼロ以上のエンティティと関連付けられてもよいです。例えば、単一ユーザ（リソース）のプレゼンス情報を複数の加入者が存在してもよいし、各加入者は、加入者ごとにエンティティを生成し、そのリソースの異なる濾過ビューを有していてもよいです。しかし、各エンティティは、唯一つのリソースに関連付けられています。エンティティレベルでの資源のない「合成」はありません。リソース自体は（「複合リソース」も）他のリソースからの情報で構成されてもよいが、これは1リソースあたりのエンティティのルールを変更しません。
An entity consists of the data carried in the body of a NOTIFY message and related meta-data in the message header. Whenever the data in the body or any of the meta-data changes, the notifier MUST produce a new entity-tag. This meta-data MUST include, but is not limited to the following SIP header fields defined in the Session Initiation Protocol [RFC3261] and SIP Specific Event Notification [RFC3265]:
エンティティは、メッセージヘッダーのNOTIFYメッセージと関連するメタデータの本体で搬送されたデータから構成されています。体内のデータやメタデータの変更のいずれかのたびに、通知は、新しいエンティティタグを生成しなければなりません。このメタデータには含まなければならないが、セッション開始プロトコル[RFC3261]とSIP特定のイベント通知[RFC3265]で定義された次のSIPヘッダーフィールドに限定されるものではありません。
Note that the Subscription-State is explicitly not part of the entity. In the future, event packages may define additional fields that implementations need to consider as part of the entity.
サブスクリプションのステートが明示的に実体の一部ではないことに注意してください。将来的には、イベントパッケージは、実装は、エンティティの一部として検討する必要がある追加のフィールドを定義することができます。
An entity has one or more versions of which only one is current and all others stale. Each version has an entity-tag, which uniquely identifies it across all versions of all entities pertaining to a single resource and event package.
実体は一つだけが、現在、他のすべての古いとなっている1つまたは複数のバージョンがあります。各バージョンは、一意に単一のリソースとイベントパッケージに関連するすべてのエンティティのすべてのバージョン間を識別するエンティティタグを有します。
Note that two entity-tags for different resources being equal does not indicate identical entities. In other words, if an entity-tag received for a subscription to a first resource matches an entity-tag received for a subscription to a second resource, the subscriber cannot assume that the two entity values are equal.
等しい異なるリソースのための2つのエンティティタグが同一の実体を示すものではありませんので注意してください。最初のリソースへのサブスクリプションのために受信エンティティタグは、第2のリソースへのサブスクリプションのために受信エンティティタグと一致する場合換言すれば、加入者は2つのエンティティの値が等しいと仮定することができません。
With partial event notification, the NOTIFY message only carries the delta state, or the set of changes to the previous version of the entity. In that case, implementations MUST consider the full event state as the version of the entity to which the entity-tag in the NOTIFY message applies.
部分的なイベント通知と、NOTIFYメッセージは、デルタ状態、またはエンティティの以前のバージョンに対する変更のセットを運びます。その場合、実装は、NOTIFYメッセージ内のエンティティタグが適用されるエンティティのバージョンとして完全なイベント状態を考慮しなければなりません。
The conditional notification mechanism is independent of the way in which subscriptions are installed. In other words, the mechanism supports implicit subscriptions, such as those associated with the REFER method [RFC3515].
条件付きの通知メカニズムは、サブスクリプションがインストールされている方法とは無関係です。換言すれば、機構は、REFERメソッド[RFC3515]に関連付けられているもののような暗黙的なサブスクリプションをサポートしています。
It is possible that the same resource is in some shape or form accessible through another mechanism in addition to SIP Event Notification, e.g., HTTP or the SIP PUBLISH method. In general, implementations MUST NOT expect the entity-tags to be shared between the mechanisms, unless event packages or specific applications of SIP events explicitly define such dependencies.
同じリソースは、いくつかの形状であることが可能であるか、またはSIPイベント通知に加えて、別の機構を介してアクセス可能な形態、例えば、HTTPまたはSIPメソッドを公開します。イベントパッケージまたはSIPイベントの特定のアプリケーションが明示的にそのような依存関係を定義しない限り、一般的に、実装は、エンティティタグは機構の間で共有されることを期待してはいけません。
This section augments the subscriber behavior defined in RFC 3265 [RFC3265]. It first discusses general issues related to indicating support for the mechanism (Section 5.1) and creating conditions in SUBSCRIBE requests (Section 5.2). Next, it describes subscriber behavior for receiving NOTIFY requests (Section 5.3), and specific client workflows for polling resource state (Section 5.4), resuming a subscription (Section 5.5), refreshing a subscription (Section 5.6), and terminating a subscription (Section 5.7). Finally, handling of transient errors is discussed (Section 5.8).
このセクションでは、RFC 3265 [RFC3265]で定義された加入者の挙動を増強します。これは、第一機構（セクション5.1）のサポートを示すとSUBSCRIBEリクエスト（セクション5.2）に条件を作成に関する一般的な問題について説明します。次に、（セクションを、ポーリングリソースの状態（5.4節）の要求（5.3節）、および特定のクライアントのワークフローをNOTIFY受信再開サブスクリプションを（5.5節）、リフレッシュサブスクリプションを（5.6節）、およびサブスクリプションを終了するための加入者の動作を説明します5.7）。最後に、一時的なエラーの取り扱い（セクション5.8）に説明があります。
The mechanism defined in this memo is backwards compatible with SIP events [RFC3265] in that a notifier supporting this mechanism will insert a SIP entity-tag in its NOTIFY requests, and a subscriber that understands this mechanism will know how to use it in creating a conditional request.
このメモで定義された機構がその中にSIPイベント[RFC3265]と下位互換性があり、このメカニズムをサポートする通知は、NOTIFYリクエストでSIPエンティティタグを挿入し、このメカニズムを理解し、加入者が作成でそれを使用する方法を知っているであろう条件付きリクエスト。
Unaware subscribers will simply ignore the entity-tag, make requests without conditions, and receive the default treatment from the notifier. Unaware notifiers will simply ignore the conditional header fields and continue normal operation.
気づいていない加入者は単に、エンティティタグを無視する条件なしで要求を作成し、通知からデフォルトの治療を受けます。気付か通知機能は、単に、条件付きヘッダフィールドを無視し、通常の動作を継続します。
When creating a conditional SUBSCRIBE request, the subscriber MUST include a single conditional header field including an entity-tag in the request. The condition is evaluated by comparing the entity-tag of the subscribed resource with the entity-tag carried in the conditional header field. If they match, the condition evaluates to true.
条件SUBSCRIBEリクエストを作成する場合、加入者は、要求内のエンティティタグを含む単一の条件付きヘッダフィールドを含まなければなりません。条件は、条件付きヘッダフィールド内で運ばエンティティタグを有する加入リソースのエンティティタグを比較することによって評価されます。それらが一致した場合、条件が真と評価されます。
Unlike the condition introduced for the SIP PUBLISH [RFC3903] method, these conditions do not apply to the SUBSCRIBE request itself, but to the resulting NOTIFY requests. When true, the condition drives the notifier to change its behavior with regard to sending the notifications after the SUBSCRIBE.
SIP PUBLISH [RFC3903]方法のために導入された状態とは異なり、これらの条件は、SUBSCRIBEリクエスト自体には適用され、結果として得られるNOTIFY要求にありません。 trueの場合、条件がSUBSCRIBE後に通知を送信に関して、その動作を変更する通知を駆動します。
This specification defines a new header field called Suppress-If-Match. This header field introduces a condition to the SUBSCRIBE request. If true, it instructs the notifier either to omit the body of the resulting NOTIFY message (if the SUBSCRIBE is not sent within an existing dialog) or to suppress (i.e., block) the NOTIFY request that would otherwise be triggered by the SUBSCRIBE (for an established dialog). In the latter case, the SUBSCRIBE message will be answered with a 204 (No Notification) response. As long as the condition remains true, it also instructs the notifier either to suppress any subsequent NOTIFY request or, if there are reportable changes in the NOTIFY header, e.g., the Subscription-State has changed, to suppress the body of any subsequent NOTIFY request.
この仕様は抑制-IF-マッチと呼ばれる新しいヘッダフィールドを定義します。このヘッダーフィールドは、SUBSCRIBEリクエストの状態を導入します。 trueの場合、得られる本体はNOTIFYメッセージ（SUBSCRIBEが既存のダイアログ内で送信されていない場合）、または他の方法のために（SUBSCRIBEによってトリガされることになる（すなわち、ブロック）NOTIFY要求を抑制するために省略するか通知を指示します設立ダイアログ）。後者の場合には、SUBSCRIBEメッセージ204は（No通知）応答で応答します。 NOTIFYヘッダ、例えば、サブスクリプション・ステートが変化したに報告変化がある場合であれば、条件が真のままとして、それはまた、後続のNOTIFYリクエストのボディを抑制するために、後続のNOTIFY要求を抑制するためのいずれかの通知を指示し、または。
If the condition is false, the notifier follows its default behavior.
条件がfalseの場合、通知は、そのデフォルトの動作に従います。
If the subscriber receives a 204 (No Notification) response to an in-dialog SUBSCRIBE, the subscriber MUST consider the event state and the subscription state unchanged.
加入者は、インダイアログSUBSCRIBEへの204（番号通知）応答を受信した場合、加入者はイベント状態とサブスクリプションの状態は変わらず考慮する必要があります。
The value of the Suppress-If-Match header field is an entity-tag, which is an opaque token that the subscriber simply copies (byte-wise) from a previously received NOTIFY request. Inclusion of an entity-tag in a Suppress-If-Match header field of a SUBSCRIBE request indicates that the client has a copy of, or is capable of recreating a copy of, the entity associated with that entity-tag.
抑制-If-Matchヘッダフィールドの値が以前にNOTIFY要求を受信したから不透明トークン加入者は単にコピー（バイト単位）があるエンティティタグ、です。 SUBSCRIBEリクエストの抑制-IF-Matchヘッダフィールドのエンティティタグを含めることは、クライアントのコピーを有することを示す、またはそのエンティティタグに関連付けられたエンティティのコピーを再作成することが可能です。
Example:
例：
Suppress-If-Match: b4cf7
抑制-IF-マッチ：b4cf7
The header field can also be wildcarded using the special "*" entity-tag value. Such a condition always evaluates to true regardless of the value of the current entity-tag for the resource.
ヘッダフィールドは、特別な「*」エンティティタグ値を使用してワイルドカードことができます。このような状態は関係なく、常にリソースの現在のエンティティタグの値のtrueに評価されます。
Example:
例：
Suppress-If-Match: *
抑制-IF-マッチ：*
Such a wildcard condition effectively quenches a subscription; the only notifications received are those reporting changes to the subscription state and those in response to a SUBSCRIBE message sent outside of an existing dialog. In both cases, the notifications will not contain a body.
このようなワイルドカードの条件は、効果的にサブスクリプションを消光します。受信通知のみでは、これらの報告のサブスクリプションの状態に変化し、既存のダイアログの外に送信SUBSCRIBEメッセージに応答したものがあります。どちらの場合も、通知は体が含まれません。
A subscription with a wildcard Suppress-If-Match condition is useful in scenarios where the subscriber wants to temporarily put a subscription in dormant mode. For example, a host may want to conserve bandwidth and power when it detects from screen or input device inactivity that the user isn't actively monitoring the presence statuses of contacts.
ワイルドカード抑制-IF-一致条件とサブスクリプションは、加入者が一時的に休止モードでサブスクリプションを入れたいのシナリオで有用です。それは、ユーザが積極的に連絡先のプレゼンス状態を監視していない画面や入力デバイスが非アクティブから検出した場合、例えば、ホストは、帯域幅と電力を節約することができます。
When a subscriber receives a NOTIFY request that contains a SIP-ETag header field, it MUST store the entity-tag if it wishes to make use of the conditional notification mechanism. The subscriber MUST be prepared to receive a NOTIFY with any entity-tag value, including a value that matches any previous value that the subscriber might have seen.
加入者がSIP-ETagヘッダフィールドを含むNOTIFYリクエストを受信すると、条件通知メカニズムを使用することを望む場合には、エンティティタグを格納しなければなりません。加入者は、加入者が見ている可能性のある以前の値に一致する値を含む、任意のエンティティタグ値とNOTIFY受信するように準備しなければなりません。
The subscriber MUST NOT infer any meaning from the value of an entity-tag; specifically, the subscriber MUST NOT assume identical entities (i.e., event state) for NOTIFYs with identical entity-tag values when those NOTIFYs result from subscription to different resources.
加入者は、エンティティタグの値から意味を推測してはなりません。それらのNOTIFYが異なるリソースへのサブスクリプションに起因する場合、具体的に、加入者が同一のエンティティタグ値とのNOTIFYに対して同一のエンティティ（即ち、イベント状態）を仮定してはいけません。
Note that there are valid cases for which identical entity-tag values on different resources may occur. For example, it is possible to generate entity-tag values using a one-way hash function, resulting in the possibility that two different resources having the same entity-value will also have the same entity-tag. Clients however MUST NOT assume that this is the case, as the algorithm for the generation of entity-tags is notifier-dependent and not negotiated with the subscriber. Consequently, the subscriber cannot differentiate between two entity-tags that have the same value because they are similar hashes of identical entities, or because two notifiers happen to have used the same sequential number as an entity-tag. Entity tags are only required to be unique for a given resource, not globally unique.
異なるリソース上で同じエンティティタグの値が起こり得るために有効な場合があることに留意されたいです。例えば、同じエンティティ値を有する二つの異なるリソースは、同じエンティティタグを有することが可能で、その結果、一方向ハッシュ関数を用いてエンティティタグ値を生成することができます。クライアントは、しかし、通知に依存しており、加入者と交渉していないエンティティタグを生成するためのアルゴリズムとして、これは、そうであると仮定してはいけません。したがって、加入者は、彼らが同じエンティティの同様のハッシュであるため、二ノーティファイアがエンティティタグと同じ連続番号を使用しているために起こるので、同じ値を有する2つのエンティティタグを区別することができません。エンティティタグは唯一のグローバルに一意ではない、与えられたリソースに対して一意であることが要求されています。
Polling with conditional notification allows a user agent to efficiently poll resource state. This is accomplished using the Suppress-If-Match condition:
条件通知にポーリングは、ユーザエージェントが効率的にリソースの状態をポーリングすることができます。これは、抑制-IF-一致条件を用いて達成されます。
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Expires: 0
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 17539
(4) 200 -------->
... poll interval elapses ...
...ポーリング間隔が経過します...
(5) SUBSCRIBE -------->
Suppress-If-Match: f2e45
Expires: 0
<-------- (6) 202
<-------- (7) NOTIFY
Subscription-State: terminated
SIP-ETag: f2e45
Content-Length: 0
(8) 200 -------->
Figure 3: Polling Resource State
図3：ポーリングリソースの状態
(1) The subscriber polls for resource state by sending a SUBSCRIBE with zero expiry (expires immediately).
（1）ゼロ満了（すぐに期限切れになる）とSUBSCRIBEを送信することによって、リソース状態のための加入者をポーリングを。
(2) The notifier accepts the SUBSCRIBE with a 202 (Accepted) response.
（2）通知202（承認）応答とSUBSCRIBE受け付けます。
(3) The notifier then immediately sends a first (and last) NOTIFY request with the current resource state and the current entity-tag in the SIP-ETag header field.
（3）通知は、直ちに現在のリソース状態とSIP-ETagヘッダフィールド内の現在のエンティティタグを有するNOTIFY第一（及び最後の）要求を送信します。
(4) The subscriber accepts the notification with a 200 (OK) response.
（4）加入者は、200（OK）応答で通知を受け付けます。
(5) After some arbitrary poll interval, the subscriber sends another SUBSCRIBE with a Suppress-If-Match header field that includes the entity-tag received in the previous NOTIFY.
（5）いくつかの任意のポーリング間隔の後、加入者は、別のは、前のNOTIFYで受信したエンティティタグを含む抑止-If-MatchヘッダフィールドとSUBSCRIBE送信します。
(6) The notifier accepts the SUBSCRIBE with a 202 (Accepted) response. (202 would be used to indicate that the subscription request was understood without also indicating that it was authorized, as per Section 3.1.6.1 of SIP-Specific Event Notification [RFC3265].)
（6）通知202（承認）応答とSUBSCRIBE受け付けます。 （202は、サブスクリプション要求はまた、それがSIP固有のイベント通知[RFC3265]のセクション3.1.6.1に従って、認可されたことを示すことなく、理解したことを示すために使用されるであろう。）
(7) Since the resource state has not changed since the previous poll occurred, the notifier sends a NOTIFY message with no body. It also mirrors the current entity-tag of the resource in the SIP-ETag header field.
以前のポーリングが発生したので、リソースの状態が変化していないので（7）、通知なし体とNOTIFYメッセージを送信します。また、SIP-ETagヘッダフィールド内のリソースの現在のエンティティタグを反映します。
(8) The subscriber accepts the notification with a 200 (OK) response.
（8）加入者は、200（OK）応答で通知を受け付けます。
Resuming a subscription means the ability to continue an earlier subscription that either closed abruptly or was explicitly terminated. When resuming, the subscription is established without transmitting the resource state. This is accomplished with conditional notification and the Suppress-If-Match header field:
サブスクリプションを再開するのいずれかに突然終了または明示的に終了した以前のサブスクリプションを継続する能力を意味します。再開する場合は、サブスクリプションは、リソースの状態を送信することなく、確立されています。これは条件付きの通知及び抑制-If-Matchヘッダフィールドを用いて達成されます。
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 3600
<-------- (2) 202
<-------- (3) NOTIFY
Subscription-State: active
SIP-ETag: ega23
Content-Length: 0
(4) 200 -------->
Figure 4: Resuming a Subscription
図4：サブスクリプションの再開
(1) The subscriber attempts to resume an earlier subscription by including a Suppress-If-Match header field with the entity-tag it last received.
（1）加入者は、それが最後に受信したエンティティタグと抑制-If-Matchヘッダフィールドを含むことによって、以前のサブスクリプションを再開しようと試みます。
(2) The notifier accepts the subscription after proper authentication and authorization, by sending a 202 (Accepted) response.
（2）通知202（承認）応答を送信することによって、適切な認証および認可後のサブスクリプションを受け入れます。
(3) Since the condition is true, the notifier then immediately sends an initial NOTIFY request that has no body. It also mirrors the current entity-tag of the resource in the SIP-ETag header field.
条件が真であるので、（3）、通知は、直ちに初期に本体がないNOTIFY要求を送信します。また、SIP-ETagヘッダフィールド内のリソースの現在のエンティティタグを反映します。
(4) The subscriber accepts the NOTIFY and sends a 200 (OK) response.
（4）加入者がNOTIFY受け入れ、200（OK）応答を送信します。
Had the entity-tag not been valid any longer, the condition would have evaluated to false, and the NOTIFY would have had a body containing the latest resource state.
エンティティタグは、もはや有効でなかったら、条件がfalseに評価され、NOTIFYているだろう、最新のリソースの状態を含むボディを持っていたでしょう。
To refresh a subscription using conditional notification, the subscriber creates a subscription refresh before the subscription expires, and uses the Suppress-If-Match header field:
条件付きの通知を使用してサブスクリプションを更新するには、加入者は、サブスクリプションの有効期限が切れる前に、サブスクリプションの更新を作成し、抑止-If-Matchヘッダフィールドを使用しています。
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: aba91
Expires: 3600
<-------- (2) 204
Expires: 3600
Figure 5: Refreshing a Subscription
図5：サブスクリプションのリフレッシュ
(1) Before the subscription expires, the subscriber sends a SUBSCRIBE request that includes the Suppress-If-Match header field with the latest entity-tag it has seen.
サブスクリプションの有効期限が切れる前に（1）、加入者は、それが見ている最新のエンティティタグと抑制-IF-Matchヘッダフィールドを含むSUBSCRIBE要求を送信します。
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response and sends no NOTIFY request. The Expires header field of the 204 (No Notification) response indicates the new expiry time.
条件が真と評価された場合（2）、通知204は（No通知）応答を送信しないNOTIFY要求を送信しません。 204（いいえ通知）のヘッダフィールド応答は新しい満了時間を示す有効期限。
To terminate a subscription using conditional notification, the subscriber creates a SUBSCRIBE request with a Suppress-If-Match condition:
条件付きの通知を使用してサブスクリプションを終了するには、加入者が抑制-IF-マッチ条件にSUBSCRIBEリクエストを作成します。
Subscriber Notifier
---------- --------
(1) SUBSCRIBE -------->
Suppress-If-Match: ega23
Expires: 0
<-------- (2) 204
Figure 6: Terminating a Subscription
図6：サブスクリプションの終了
(1) The subscriber decides to terminate the subscription and sends a SUBSCRIBE request with the Suppress-If-Match condition with the entity-tag it has last seen.
（1）加入者は、サブスクリプションを終了することを決定し、それが最後に見たエンティティタグと抑制-IF-マッチ条件にSUBSCRIBEリクエストを送信します。
(2) If the condition evaluates to true, the notifier sends a 204 (No Notification) response, which concludes the subscription, and the subscriber can clear all state related to the subscription.
条件が真と評価された場合（2）、通知サブスクリプションを終了する204（無通知）応答を送信し、加入者は、サブスクリプションに関連するすべての状態をクリアすることができます。
This section is non-normative.
このセクションでは、非規範的です。
In some deployments, there may be Back-to-Back User Agent (B2BUA) devices that track SIP dialogs such as subscription dialogs. These devices may be unaware of the conditional notification mechanism.
いくつかの展開では、このようなサブスクリプションダイアログなどのSIPダイアログを追跡するバックツーバックユーザエージェント（B2BUA）デバイスがあるかもしれません。これらのデバイスは、条件付き通知メカニズムを知らないかもしれません。
It is possible that some B2BUA devices may treat a NOTIFY with suppressed body as an error, or may expect all SUBSCRIBE messages to have an associated NOTIFY message.
いくつかのB2BUAデバイスはエラーとして抑制体でNOTIFY、またはすべてがNOTIFYメッセージを関連付けられているために、メッセージをSUBSCRIBE期待することを扱うことが可能です。
In general, there is very little that an endpoint can do to recover from such transient errors. The most that can be done is to try to detect such errors, and define a fallback behavior.
一般的には、エンドポイントは、このような一時的なエラーから回復するために行うことができることはほとんどあり。行うことができ、ほとんどのは、このようなエラーを検出しようとすると、フォールバック動作を定義することです。
If subscribers encounter transient errors in conditional notification, they should disable the feature and fall back to normal subscription behavior.
加入者が条件付きの通知に一時的なエラーが発生した場合、彼らは機能を無効にし、通常のサブスクリプションの動作にフォールバックする必要があります。
This section augments the notifier behavior as specified in RFC 3265 [RFC3265].
RFC 3265 [RFC3265]で指定されるように、このセクションでは、通知の動作を増強します。
An entity-tag is a token carried in the SIP-ETag header field, and it is opaque to the client. The notifier is free to decide on any means for generating the entity-tag. It can have any value, except for "*". For example, one possible method is to implement the entity-tag as a simple counter, incrementing it by one for each generated notification per resource.
エンティティタグは、SIP-ETagヘッダフィールド内で運ばトークンであり、それがクライアントに不透明です。通知は、エンティティタグを生成するための任意の手段を決定して自由です。これは、「*」を除き、任意の値を持つことができます。例えば、一つの可能な方法は、リソースごとにそれぞれ生成された通知のための1つによってそれをインクリメント、単純なカウンタとしてエンティティタグを実装することです。
A notifier MUST generate entity-tags for event notifications of all resources for which it is responsible. The entity-tag MUST be unique across all versions of all entities for each state of a resource as reported by a given event package. Otherwise said, for any subscription or sequence of subscriptions to a specific resource using a singular event package, each entity-tag produced MUST map to one and only one presentation of resource state (entity). Two identical entities for a specific resource might or might not have identical entity-tags; this decision is left to the notifier.
通知は、それが担当するすべてのリソースのイベント通知のためのエンティティタグを生成しなければなりません。与えられたイベントパッケージによって報告されるエンティティタグは、リソースの各状態のためのすべてのエンティティのすべてのバージョンで一意である必要があります。そうでなければ特異イベントパッケージを使用して、特定のリソースへのサブスクリプションのサブスクリプションまたは配列について、生成された各エンティティタグが1にマッピングしなければならないとリソースの状態（エンティティ）のいずれか一方のみのプレゼンテーション、と述べました。特定のリソースのための二つの同一の実体は、または同一のエンティティタグを持っていない場合があります。この決定は、通知に任されています。
An entity-tag is considered valid for as long as the entity exists. An entity becomes stale when its version is no longer the current one. The notifier MUST remember (or be able to recalculate) the entity-tag of an entity as long as the version of the entity is current. The notifier MAY remember the entity-tag longer than this, e.g., for implementing journaled state differentials (Section 6.4).
エンティティタグは限りエンティティが存在するために有効であると考えられます。そのバージョンは、もはや現在のものであるとき、エンティティが古くなりません。通知であれば、エンティティのバージョンが最新であるようにエンティティのエンティティタグを覚えて（または再計算できるように）しなければなりません。通知は、ジャーナルの状態の差（6.4節）を実現するために、例えば、これより長いエンティティタグを覚えているかもしれ。
The entity-tag values used in publications are not necessarily shared with the entity-tag values used in subscriptions. This is because there may not always be a one-to-one mapping between a publication and a notification of state change; there may be several sources to the event composition process, and a publication into a resource may not affect the resulting entity.
刊行物に使用されるエンティティタグ値は、必ずしもサブスクリプションで使用されるエンティティタグ値と共有されません。常に出版及び状態変化の通知との間に1対1のマッピングが存在しない場合があるからです。そこイベント合成プロセスにはいくつかの供給源であってもよく、リソースへの出版物は、得られたエンティティに影響を与えないかもしれません。
When a condition in a SUBSCRIBE request for suppressing notifications is true (i.e., the local entity-tag for the resource state and the entity-tag in a Suppress-If-Match header field are byte-wise identical) but there are reportable changes in the NOTIFY header (e.g., the Subscription-State has changed), the notifier MUST suppress the body of the NOTIFY request. That is, the resulting NOTIFY contains no Content-Type header field, the Content-Length is set to zero, and no payload is attached to the message.
抑制の通知のためのSUBSCRIBEリクエストの条件が真である場合（つまり、リソースの状態のためのローカルエンティティタグと除外-If-Matchヘッダフィールド内のエンティティタグは、バイト単位同じです）が、中に報告の変更がありますNOTIFYヘッダ（例えば、サブスクリプション・ステートが変更された）、通知は、NOTIFYリクエストのボディを抑制しなければなりません。すなわち、コンテンツ長がゼロに設定されているNOTIFY得ないContent-Typeヘッダフィールドを含まない、であり、いかなるペイロードがメッセージに添付されていません。
Additionally, when a condition in a SUBSCRIBE request for suppressing notifications is true and the SUBSCRIBE message is not sent within an established dialog, the notifier MUST send a NOTIFY request with a suppressed entity body.
通知を抑制するためのSUBSCRIBEリクエストの条件が真であるとSUBSCRIBEメッセージが確立ダイアログ内で送信されていない場合さらに、通知が抑制エンティティボディを持つNOTIFYリクエストを送らなければなりません。
Suppressing the entity body of a NOTIFY does not change the current entity-tag of the resource. Hence, the NOTIFY MUST contain a SIP-ETag header field that contains the unchanged entity-tag of the resource state.
NOTIFYのエンティティボディを抑制することは、リソースの現在のエンティティタグを変更しません。したがって、リソースの状態の変化しないエンティティタグを含むSIP-ETagヘッダフィールドを含まなければならないNOTIFY。
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
「*」の値を持つエンティティタグが含ま抑制-If-Matchヘッダフィールドは常にtrueに評価される必要があります。
When a condition in a SUBSCRIBE request to suppress notifications is true (i.e., the local entity-tag of the resource and the entity-tag in a Suppress-If-Match header field match), and the SUBSCRIBE is sent within an established dialog, then the notifier MUST suppress the resulting NOTIFY request, and generate a 204 (No Notification) response. As long as the condition remains true, and there are no reportable changes in the NOTIFY header, all subsequent NOTIFY requests MUST also be suppressed.
通知を抑制するSUBSCRIBE要求の条件が真である場合（すなわち、ローカルリソースと抑止-IF-マッチヘッダーフィールド一致内のエンティティタグのエンティティタグ）、および確立されたダイアログ内で送信されるSUBSCRIBE、その後、通知は、NOTIFY、得られた要求を抑制、および204（通知なし）応答を生成してはなりません。限り、条件が真のままであり、NOTIFYヘッダには報告の変化がないように、後続のすべてのNOTIFY要求も抑制しなければなりません。
Notifiers MUST NOT suppress a NOTIFY unless the corresponding SUBSCRIBE message was sent in an established dialog.
通知機能は、対応するSUBSCRIBEメッセージをしない限り、NOTIFY抑制するてはならない確立ダイアログに送られました。
A successful conditional SUBSCRIBE request MUST extend the subscription expiry time.
成功条件付きSUBSCRIBEリクエストは、サブスクリプションの有効期限を延長しなければなりません。
Suppressing the entire NOTIFY has no effect on the entity-tag of the resource. In other words, it remains unchanged.
全体を抑制することは、リソースのエンティティタグには影響しませんNOTIFY。言い換えれば、それは変わりません。
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
「*」の値を持つエンティティタグが含ま抑制-If-Matchヘッダフィールドは常にtrueに評価される必要があります。
Some event packages support a scheme where notifications contain state differentials, or state deltas [RFC3265], instead of complete resource state.
一部のイベントパッケージではなく完全なリソース状態の通知は、状態の差が含まれている方式で、または状態のデルタ[RFC3265]をサポートしています。
Further extensions could define means for notifiers to keep track of the state changes of a resource, e.g., storing the changes in a journal. If a condition fails, the notifier would then send a state differential in the NOTIFY rather than the full state of the event resource. This is only possible if the event package and the subscriber both support a payload format that has this capability.
さらなる拡張は、ジャーナルの変更を保存する、例えば、リソースの状態の変化を追跡するために、ノーティファイアのための手段を定義することができます。条件が失敗した場合、通知は、イベントリソースの完全な状態ではなく、NOTIFY状態の差を送信します。イベントパッケージと加入者がこの機能を持っているペイロードフォーマットをサポートし、両方の場合にのみ可能です。
When state differentials are sent, the SIP-ETag header field MUST contain an entity-tag that corresponds to the full resource state.
状態差が送信されると、SIP-ETagヘッダフィールドは、完全なリソースの状態に対応するエンティティタグを含まなければなりません。
The Event Notification Extension for Resource Lists [RFC4662] defines a mechanism for subscribing to a homogeneous list of resources using the SIP events framework.
リソースリストのイベント通知拡張[RFC4662]はSIPイベント・フレームワークを使用してリソースの均質なリストに加入するための機構を定義します。
A list subscription delivers event notifications that contain both Resource List Meta-Information (RLMI) documents as well as the resource state of the individual resources on the list.
リストのサブスクリプションは、両方のリソースリストメタ情報（RLMI）の文書と同様に、リスト上の個々のリソースのリソース状態が含まれているイベント通知を提供します。
Implementations MUST consider the full resource state of a resource list including RLMI and the entity-header as the entity to which the entity-tag applies.
実装は、エンティティタグが適用されるエンティティとしてRLMIとエンティティヘッダを含むリソースリストの完全なリソース状態を考慮しなければなりません。
This section describes the protocol extensions required for conditional notification.
このセクションでは、条件付きの通知に必要なプロトコルの拡張機能について説明します。
The 204 (No Notification) response code indicates that the request was successful, but the notification associated with the request will not be sent. It is valid only in response to a SUBSCRIBE message sent within an established dialog.
204（いいえ通知）応答コードは、要求が成功したことを示しているが、要求に関連付けられた通知が送信されません。それだけで確立し、ダイアログ内で送信SUBSCRIBEメッセージに応じて有効です。
The response code is added to the "Success" production rule in the SIP [RFC3261] message grammar.
応答コードはSIP [RFC3261]メッセージ文法における「成功」プロダクションルールに追加されます。
The Suppress-If-Match header field is added to the definition of the "message-header" rule in the SIP [RFC3261] grammar. Its use is described in Sections 5, 6.3, and 6.2.
抑制-IF-Matchヘッダフィールドは、SIP [RFC3261]文法における「メッセージヘッダ」ルールの定義に追加されます。その使用は、セクション5、6.3、および6.2に記載されています。
This header field is allowed to appear in any request, but its behavior is only defined for the SUBSCRIBE request.
このヘッダーフィールドは、すべての要求に表示されるように許可されているが、その動作は唯一のSUBSCRIBEリクエストのために定義されています。
This section defines the formal syntax for extensions described in this memo in Augmented BNF (ABNF) [RFC5234]. The rules defined here augment and reference the syntax defined in RFC 3261 [RFC3261] and RFC 3903 [RFC3903].
このセクションでは、拡張BNF（ABNF）[RFC5234]で、このメモに記載の拡張のための正式な構文を定義します。ここで定義されたルールは、RFC 3261 [RFC3261]及びRFC 3903 [RFC3903]で定義された構文を増強および参照します。
Success =/ "204" ; No Notification
成功= / "204";ません通知
; Success is defined in RFC 3261.
;成功は、RFC 3261で定義されています。
message-header =/ Suppress-If-Match
メッセージヘッダー= /抑止-IF-マッチ
; message-header is defined in RFC 3261.
;メッセージヘッダは、RFC 3261で定義されています。
Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" )
= "抑止-IF-マッチ" HCOLON-IF-マッチを抑制します（/エンティティタグ "*"）
; entity-tag is defined in RFC 3903.
;エンティティタグは、RFC 3903で定義されています。
This document registers a new response code and a new header field name.
この文書は、新しい応答コードと新しいヘッダーフィールド名を登録します。
This document registers a new response code. This response code is defined by the following information, which has been added to the methods and response-codes sub-registry available from http://www.iana.org.
この文書は、新しい応答コードを登録します。この応答コードはhttp://www.iana.orgからサブレジストリは利用可能な方法および応答コードに追加された次の情報によって定義されます。
This information has been added under "Successful 2xx" category.
この情報は、「成功の2xx」カテゴリの下に追加されました。
+---------------------+-----------+
| Response Code | Reference |
+---------------------+-----------+
| 204 No Notification | [RFC5839] |
+---------------------+-----------+
This document registers a new SIP header field called Suppress-If-Match. This header field is defined by the following information, which has been added to the header fields sub-registry available from http://www.iana.org.
この文書では、抑制-IF-マッチと呼ばれる新しいSIPヘッダフィールドを登録します。このヘッダフィールドはhttp://www.iana.orgから入手可能なヘッダフィールドのサブレジストリに追加された次の情報によって定義されます。
+-------------------+---------+-----------+
| Header Name | Compact | Reference |
+-------------------+---------+-----------+
| Suppress-If-Match | | [RFC5839] |
+-------------------+---------+-----------+
The security considerations for SIP event notification are extensively discussed in RFC 3265 [RFC3265]. This specification introduces an optimization to SIP event notification, which in itself does not alter the security properties of the protocol.
SIPイベント通知のためのセキュリティ問題は、広範囲RFC 3265 [RFC3265]に記載されています。この仕様は、プロトコルのセキュリティプロパティを変更しないそれ自体がSIPイベント通知への最適化を導入します。
The following people have contributed corrections and suggestions to this document: Adam Roach, Sean Olson, Johnny Vrancken, Pekka Pessi, Eva Leppanen, Krisztian Kiss, Peili Xu, Avshalom Houri, David Viamonte, Jonathan Rosenberg, Qian Sun, Dale Worley, Tolga Asveren, Brian Stucker, Eric Rescorla, Arun Arunachalam, and the SIP and SIMPLE working groups.
アダムローチ、ショーン・オルソン、ジョニーVrancken、ペッカPessi、エヴァLeppanen、Krisztianキス、Peili徐、Avshalomフーリー、デビッドビアモンテ、ジョナサン・ローゼンバーグ、銭日、デイル・ウォーリー、トルガAsveren：次の人は、この文書の修正や提案を貢献しています、ブライアンStucker、エリックレスコラ、アルンArunachalam、およびSIPおよびSIMPLEワーキンググループ。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[RFC3265]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515]スパークス、R.、 "セッション開始プロトコル（SIP）メソッドを参照してください"、RFC 3515、2003年4月。
[RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event Package for Registrations", RFC 3680, March 2004.
[RFC3680]ローゼンバーグ、J.、 "Aセッション開始プロトコル（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]マーイ、R.、RFC 3842「セッション開始プロトコル（SIP）のためのメッセージサマリとメッセージ待機表示イベントパッケージ」、2004年8月。
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3856]ローゼンバーグ、J.、 "セッション開始プロトコルのためのプレゼンスイベントパッケージ（SIP）"、RFC 3856、2004年8月。
[RFC3859] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[RFC3859]ピーターソン、J.、 "プレゼンスのための共通プロファイル（CPP）"、RFC 3859、2004年8月。
[RFC4662] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[RFC4662]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月。
Authors' Addresses
著者のアドレス
Aki Niemi Nokia P.O. Box 407 NOKIA GROUP, FIN 00045 Finland
安芸ニエミNokiaの私書箱ボックス407 NOKIA GROUP、FIN-00045フィンランド
Phone: +358 50 389 1644 EMail: aki.niemi@nokia.com
電話番号：+358 50 389 1644 Eメール：aki.niemi@nokia.com
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
ディーン・ウィリス（エディタ）Softarmorシステム3100独立パークウェイ＃311から164プラノ、TX 75075 USA
Phone: +1 214 504 1987 EMail: dean.willis@softarmor.com
電話：+1 214 504 1987 Eメール：dean.willis@softarmor.com