[要約] RFC 5839は、SIPイベントの条件付きイベント通知のための拡張です。目的は、SIPイベントの通知をより効率的に行うために、条件付きのイベント通知メカニズムを提供することです。
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
条件付きイベント通知のためのセッション開始プロトコル（SIP）イベントへの拡張
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 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
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リクエストを生成します。通常、サブスクライバーがサブスクリプションをインストール、定期的に更新、または終了する必要がある場合はいつでも、サブスクライバーがサブスクライブリクエストを発行します。サブスクリプションがインストールされると、サブスクリプションリフレッシュによって生成された通知の大部分は不必要になります。サブスクライバーは通常、状態が定期的なサブスクリプションの更新と正確に一致する可能性が低い場合を除き、すでにイベント状態を所有しています。ほとんどの場合、サブスクリプションを終了すると生成された最終的なイベント状態には、同様にサブスクライバーがすでに持っているリソース状態が含まれています。
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.
リソース状態の取得または投票は、以前の世論調査が発生して以来、状態が変更されていない場合に同様に最適な方法で動作します。一般に、問題は、購読要求全体で状態を維持できないことにあります。
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イベントフレームワークを最適化するための拡張機能を定義します。この拡張機能により、Notifierは通知をタグ付けできます（Entity-Tags以下と呼ばれます）とサブスクライバーは、エンティティタグが発行された通知が発行されたため、実際の変更の後続のサブスクライブリクエストを条件付けます。このソリューションは、ハイパーテキスト転送プロトコル（HTTP）[RFC2616]で定義されている条件付き要求に似ており、条件付きイベント出版物を発行するためのパブリッシュ[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.
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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メッセージの本文にある状態データと、メッセージヘッダーに関連するメタデータで構成されています。エンティティには多くのバージョンがあり、1つの現在のバージョンと他のバージョンが古くなっています。エンティティの各バージョンは、エンティティタグによって識別されます。エンティティタグは、リソースおよびイベントパッケージのすべてのエンティティのすべてのバージョンで一意であることが保証されています。
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.
購読要求は、有限の寿命のサブスクリプションを作成します。この寿命は、有効期限のあるヘッダーフィールドを使用して交渉され、有効期限が満たされる前にサブスクライバーによってサブスクリプションが更新されない限り、サブスクリプションは終了します。これらのサブスクリプションリフレッシュの頻度はイベントパッケージに依存し、通常は数分から数時間の範囲です。
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ダイアログの内外のフェッチを開始および終了するためのさまざまなプロトコルメソッドは含まれていません。サブスクライブメソッドは、これらすべての機能を実行するために過負荷になります。（永続的な）サブスクリプションを作成しないフェッチと、サブスクライブの有効期限がヘッダーフィールド値にあるサブスクライブを作成するサブスクライブの違い。Zero-Expiryの購読は、単一のNotifyのみを生成し、その後サブスクリプションはすぐに終了します。持続するサブスクリプションには通常、比較的短い有効期限があり、サブスクリプションを更新するために新しいサブスクライブリクエストを定期的に送信する必要があります。
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.
新しいサブスクライブリクエストは、最新のリソース状態を含むNotifyリクエストを生成します。状態が変更されていない場合でも、各投票またはサブスクリプションの更新に応じて再び送信されます。これは、リソースで繰り返される操作を繰り返すというHTTP [RFC2616]の問題に非常に似ています。HTTPは、条件付きリクエストを使用して問題を解決します。サーバーバージョンの各エンティティは、そのエンティティの特定のインスタンスを識別するエンティティタグを使用します。Get Requestsを作成するクライアントには、「IF-None-Match」ヘッダーフィールドで最新であると考えているエンティティのバージョンのエンティティタグを含めることができます。サーバーは、このエンティティタグを最新のエンティティと比較し、クライアントのバージョンが一致するとサーバーが信頼している場合、応答のエンティティを控えることを抑制します。言い換えれば、サーバーはクライアントがすでに受信している情報を再送信しません。
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 Publish [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：サブスクライバーがすでにリソースの最新のイベント状態を所有している（または以前に受け取った）場合に、通知要求（または少なくともそのイベント本文）を抑制することが可能である必要があります。
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].
サブスクライバーがサブスクリプションを開始するたびに、サブスクライブリクエストを発行します。サブスクライブリクエストは、通知者によって通常送信、ルーティング、および処理されます。つまり、セッション開始プロトコル[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.
サブスクライブリクエストを受信する通知者が条件付きサブスクリプションをサポートする場合、現在のエンティティのエンティティタグを生成し、NotifyリクエストのSIP-TETAGヘッダーフィールドに含めます。エンティティタグは、リソースとイベントパッケージのすべてのエンティティのすべてのバージョンにわたって一意です。詳細については、セクション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.
サブスクライバーは、リソース状態とともに通知で受信したエンティティタグを保存します。その後、このエンティティタグを使用して、サブスクライブに「試合中」ヘッダーフィールドの形で条件を含めるようにすることができます。パブリッシュがエラーを成功または返すかどうかに適用されるパブリッシュ[RFC3903]リクエストの「IF-Match」条件とは異なり、この条件は、購読要求が処理された後に送信される通知のストリームに適用されます。
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.
Suppress-If-Matchヘッダーフィールドには、サブスクライバーが見た最後のエンティティタグが含まれています。この条件は、真の場合、通知者に、後続の通知の本文または通知全体を抑制するように指示します。
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) サブスクライバーは、リソースのサブスクライブリクエストを送信することにより、サブスクリプションを開始します。
(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) その後、Notifierは、SIP-TETAGヘッダーフィールドでの一意のエンティティタグを含む、すぐに最初のイベント通知を送信します。
(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) その後、サブスクライバーはサブスクリプションを更新し、抑制状のヘッダーフィールドにエンティティタグを含みます。
(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) Notifierは、リソースのローカルエンティティタグ値を、マッチイストマッチヘッダーフィールドの値と一致させることにより、条件を評価します。条件がtrueに評価された場合、通知者は、通知が送信されないことを加入者に通知します。
(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-TETAGヘッダーフィールドに新しい値があるイベント通知がトリガーされます。
(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) しばらくして、サブスクライバーはサブスクリプションを終了することを決定しました。試合中の抑制の条件を追加し、以前の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）Notifierは、抑制状のヘッダーフィールドの値に対してリソースのエンティティタグを一致させることにより、条件を評価します。条件がtrueに評価された場合、通知者は、通知が送信されないことを加入者に通知します。これでサブスクリプションが終了します。
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.
この例で条件付き通知を使用する利点は、サブスクライバーが受け取ることができる通知要求の数の減少です。サブスクライバーが既に見たという各イベント通知は、通知者によって抑制されます。この例は、メカニズムの1つのユースケースのみを示しています。同じ原則を使用して、他のイベント通知ユースケースに関連するメッセージの流れを最適化することができます。
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.
リソースは、ゼロ以上のurisによって識別されます。これは、uris、pres uris [rfc3859]、または同様です。加入者は、この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つのエンティティを生成する場合があります。ただし、各エンティティは、1つのリソースのみに関連付けられています。エンティティレベルでのリソースの「合成」はありません。リソース自体は、他のリソースからの情報（「複合リソース」）で構成されている場合がありますが、これは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]:
エンティティは、メッセージヘッダー内の通知メッセージと関連するメタデータの本文に搭載されているデータで構成されています。ボディ内のデータまたはメタデータのいずれかが変更されるたびに、Notifierは新しいエンティティタグを作成する必要があります。このメタデータを含める必要がありますが、セッション開始プロトコル[RFC3261]およびSIP固有のイベント通知[RFC3265]で定義されている次のSIPヘッダーフィールドに限定されません。
1. Content-Disposition
1. コンテンツディスポジション
2. Content-Encoding
2. コンテンツエンコード
3. Content-Language
3. コンテンツ言語
4. Content-Length
4. コンテンツレングス
5. Content-Type 6. Event
5. コンテンツタイプ6.イベント
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つ以上のバージョンがあり、そのうち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].
条件付き通知メカニズムは、サブスクリプションがインストールされる方法とは無関係です。言い換えれば、メカニズムは、参照法[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）と、購読要求の条件の作成（セクション5.2）について説明します。次に、通知要求を受信するためのサブスクライバーの動作（セクション5.3）、およびポーリングリソース状態の特定のクライアントワークフロー（セクション5.4）、サブスクリプションの再開（セクション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エンティティタグを挿入するという点で、SIPイベント[RFC3265]との逆方向に互換性があり、このメカニズムを理解するサブスクライバーは、作成に使用する方法を知る方法を知ることができます。条件付きリクエスト。
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.
条件付きサブスクライブリクエストを作成する場合、サブスクライバーには、リクエストにエンティティタグを含む単一の条件付きヘッダーフィールドを含める必要があります。条件は、購読されたリソースのエンティティタグを条件付きヘッダーフィールドに掲載されたエンティティタグと比較することにより評価されます。それらが一致した場合、条件はtrueに評価されます。
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パブリッシュ[RFC3903]メソッドに導入された条件とは異なり、これらの条件はサブスクライブリクエスト自体ではなく、結果のNotifyリクエストに適用されます。Trueの場合、条件は通知者を駆動し、購読後に通知を送信することに関して動作を変更します。
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.
この仕様では、suppress-if-matchと呼ばれる新しいヘッダーフィールドを定義します。このヘッダーフィールドは、サブスクライブリクエストに条件を導入します。trueの場合、notifierに、結果の通知メッセージの本文を省略し（subscribeが既存のダイアログ内で送信されない場合）、またはサブスクライブによってトリガーされる通知要求を抑制する（つまり、ブロック）するように指示します（subscribeによってトリガーされる（確立されたダイアログ）。後者の場合、購読メッセージは204（通知なし）応答で回答されます。条件が真実のままである限り、通知者に後続の通知要求を抑制するように指示します。たとえば、通知ヘッダーに報告可能な変更がある場合、例えば、サブスクリプション状態が変更され、後続の通知リクエストの本文を抑制します。。
If the condition is false, the notifier follows its default behavior.
条件が偽の場合、通知者はデフォルトの動作に従います。
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.
サブスクライバーがダイアログ内サブスクライブに対する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.
抑制-IT-IT-MATCHヘッダーフィールドの値はエンティティタグです。これは、サブスクライバーが以前に受信した通知リクエストから単純に（バイトごとに）コピーする不透明なトークンです。サブスクライブリクエストの抑制期間ヘッダーフィールドにエンティティタグを含めることは、クライアントがそのエンティティタグに関連付けられているエンティのコピーまたはコピーを再作成できることを示しています。
Example:
例：
Suppress-If-Match: b4cf7
抑制-MATCH-IF-MATCH：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.
ヘッダーフィールドは、特別な "*"エンティティタグ値を使用してワイルドカードを使用することもできます。このような条件は、リソースの現在のエンティティタグの価値に関係なく、常に真のように評価されます。
Example:
例：
Suppress-If-Match: *
抑制 - 試合後： *
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.
このようなワイルドカード状態は、サブスクリプションを効果的に消します。受け取った唯一の通知は、サブスクリプション状態の変更を報告するものと、既存のダイアログの外部で送信されたサブスクライブメッセージに応じたものです。どちらの場合も、通知には本体が含まれていません。
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.
ワイルドカード抑制状態のサブスクリプションは、サブスクライバーが一時的にサブスクリプションを休眠モードに配置したいシナリオで役立ちます。たとえば、ホストは、ユーザーが連絡先の存在状態を積極的に監視していないという画面または入力デバイスの不活性から検出されたときに、帯域幅とパワーを節約したい場合があります。
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-TETAGヘッダーフィールドを含む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.
サブスクライバーは、エンティティタグの価値から意味を推測してはなりません。具体的には、サブスクライバーは、これらの通知が異なるリソースのサブスクリプションから生じる場合、同一のエンティティタグ値を持つ通知の同一のエンティティ（つまり、イベント状態）を想定してはなりません。
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つの異なるリソースにも同じエンティティタグがある可能性があります。ただし、エンティティタグの生成のアルゴリズムは通知者に依存し、サブスクライバーと交渉されていないため、クライアントはそうであると仮定してはなりません。したがって、サブスクライバーは、同じエンティティの類似のハッシュであるため、または2つの通知者がエンティティタグと同じシーケンシャル数を使用したため、同じ値を持つ2つのエンティティタグを区別することはできません。エンティティタグは、グローバルに一意ではなく、特定のリソースに対して一意であることのみが必要です。
Polling with conditional notification allows a user agent to
efficiently poll resource state. This is accomplished using the
Suppress-If-Match condition:
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) ゼロ有効期限がゼロでサブスクライブを送信することにより、リソース状態の加入者投票（すぐに有効期限が切れます）。
(2) The notifier accepts the SUBSCRIBE with a 202 (Accepted) response.
(2) Notifierは、202（受け入れられた）応答でサブスクライブを受け入れます。
(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-TETAGヘッダーフィールドの現在のリソース状態と現在のエンティティタグで最初の（および最後の）通知リクエストを送信します。
(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で受信したエンティティタグを含む、抑制状のヘッダーフィールドで別のサブスクライブを送信します。
(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) Notifierは、202（受け入れられた）応答でサブスクライブを受け入れます。（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) 以前の投票が発生して以来、リソース状態が変更されていないため、通知者はボディのない通知メッセージを送信します。また、SIP-TETAGヘッダーフィールドのリソースの現在のエンティティタグを反映しています。
(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:
サブスクリプションの再開とは、突然閉じたか、明示的に終了した以前のサブスクリプションを継続する機能を意味します。再開すると、サブスクリプションはリソース状態を送信せずに確立されます。これは、条件付き通知と試合後のヘッダーフィールドで達成されます。
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) サブスクライバーは、最後に受け取ったエンティティタグに抑制期間ヘッダーフィールドを含めることにより、以前のサブスクリプションを再開しようとします。
(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-TETAGヘッダーフィールドのリソースの現在のエンティティタグを反映しています。
(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.
エンティティタグがもう有効でない場合、条件は虚偽に評価され、通知には最新のリソース状態を含むボディがありました。
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:
条件付き通知を使用してサブスクリプションを更新するために、サブスクライバーはサブスクリプションが期限切れになる前にサブスクリプション更新を作成し、マッチ期ヘッダーフィールドを使用します。
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) サブスクリプションが期限切れになる前に、サブスクライバーは、見た最新のエンティティタグを使用して、抑制性ヘッダーフィールドを含むサブスクライブリクエストを送信します。
(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) 条件がtrueに評価された場合、Notifierは204（通知なし）応答を送信し、No Notifyリクエストを送信します。204（通知なし）応答のヘッダーフィールドの有効期限は、新しい有効期限を示します。
To terminate a subscription using conditional notification, the subscriber creates a SUBSCRIBE request with a Suppress-If-Match condition:
条件付き通知を使用してサブスクリプションを終了するために、サブスクライバーは、試合中の条件を抑制するサブスクライブリクエストを作成します。
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) サブスクライバーは、サブスクリプションを終了することを決定し、最後に見たエンティティタグを使用して、抑制状の条件でサブスクライブリクエストを送信します。
(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) 条件がtrueに評価された場合、notifierは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デバイスは、抑制されたボディで通知をエラーとして扱うか、すべての購読メッセージが関連付けられた通知メッセージがあることを期待する可能性があります。
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-TETAGヘッダーフィールドに運ばれるトークンであり、クライアントにとって不透明です。通知者は、エンティティタグを生成するためのあらゆる手段を自由に決定できます。「*」を除いて、あらゆる価値を持つことができます。たとえば、可能な方法の1つは、エンティティタグを単純なカウンターとして実装し、リソースごとに生成された通知ごとに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つのプレゼンテーションのみにマッピングする必要があります。特定のリソース用の2つの同一のエンティティは、同一のエンティティタグを持っている場合があります。この決定は通知者に任されています。
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.
通知を抑制するサブスクライブリクエストの条件が真である場合（つまり、リソース状態のローカルエンティティタグと、抑制状のマッチヘッダーフィールドのエンティティタグが同一です）が、報告可能な変更があります。Notify Header（例：サブスクリプション状態が変更されました）、NotifierはNotifyリクエストの本文を抑制する必要があります。つまり、結果のNotifyにはコンテンツタイプのヘッダーフィールドが含まれておらず、コンテンツ長がゼロに設定され、ペイロードはメッセージに添付されていません。
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.
さらに、通知を抑制するためのサブスクライブリクエストの条件が真であり、サブスクライブメッセージが確立されたダイアログ内で送信されない場合、通知者は抑制されたエンティティ本体で通知要求を送信する必要があります。
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-TETAGヘッダーフィールドを含める必要があります。
A Suppress-If-Match header field that includes an entity-tag with the value of "*" MUST always evaluate to true.
「*」の値を持つエンティティタグを含む抑制 - マッチのヘッダーフィールドは、常に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.
通知を抑制するためのサブスクライブリクエストの条件がTRUE（つまり、マッチ後のヘッダーフィールドマッチの抑制のリソースとエンティティタグのローカルエンティティタグ）、およびサブスクライブは確立されたダイアログ内で送信されます。次に、notifierは結果の通知要求を抑制し、204（通知なし）応答を生成する必要があります。条件が真実のままであり、Notifyヘッダーに報告可能な変更がない限り、その後のすべての通知要求も抑制する必要があります。
Notifiers MUST NOT suppress a NOTIFY unless the corresponding SUBSCRIBE message was sent in an established dialog.
対応するサブスクライブメッセージが確立されたダイアログで送信されない限り、通知者は通知を抑制してはなりません。
A successful conditional SUBSCRIBE request MUST extend the subscription expiry time.
条件付きサブスクライブリクエストが成功するには、サブスクリプションの有効期限を延長する必要があります。
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.
「*」の値を持つエンティティタグを含む抑制 - マッチのヘッダーフィールドは、常に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-TETAGヘッダーフィールドには、完全なリソース状態に対応するエンティティタグを含める必要があります。
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（通知なし）応答コードは、リクエストが成功したことを示していますが、リクエストに関連する通知は送信されません。確立されたダイアログ内で送信された購読メッセージに応答してのみ有効です。
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.
Suppress-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.
このヘッダーフィールドは、任意のリクエストで表示されることが許可されていますが、その動作は購読要求に対してのみ定義されます。
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
; Success is defined in RFC 3261.
;成功はRFC 3261で定義されています。
message-header =/ Suppress-If-Match
; message-header is defined in RFC 3261.
;Message-HeaderはRFC 3261で定義されています。
Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" )
; 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.
このドキュメントでは、suppress-if-matchと呼ばれる新しい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.
次の人々は、この文書に修正と提案を提供しています：アダム・ローチ、ショーン・オルソン、ジョニー・ヴランケン、ペッカ・ペッシ、エヴァ・レパネン、クリスティアン・キス、ペリ・XU、アヴシャロム・ホイ、デビッド・ヴィアモンテ、ジョナサン・ローゼンバーグ、キアン・ウアリー、ブライアン・スタッカー、エリック・レスコルラ、アルン・アルナチャラム、およびSIPおよびシンプルなワーキンググループ。
[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月。
[RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[RFC3903] Niemi、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] Crocker、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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, April 2003.
[RFC3515] Sparks、R。、「セッション開始プロトコル（SIP）参照法」、RFC 3515、2003年4月。
[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月。
[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] Roach、A.、Campbell、B。、およびJ. Rosenberg、「リソースリストのセッション開始プロトコル（SIP）イベント通知拡張」、RFC 4662、2006年8月。
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
Dean Willis (editor) Softarmor Systems 3100 Independence Pkwy #311-164 Plano, TX 75075 USA
Dean Willis（編集者）SoftArmor Systems 3100 Independence PKWY＃311-164 Plano、TX 75075 USA
Phone: +1 214 504 1987
EMail: dean.willis@softarmor.com