[要約] RFC 3265は、SIPに特化したイベント通知のためのプロトコルです。その目的は、SIPセッションの状態変化を監視し、関連するイベントを通知することです。
Network Working Group A. B. Roach
Request for Comments: 3265 dynamicsoft
Updates: 2543 June 2002
Category: Standards Track
Session Initiation Protocol (SIP)-Specific Event Notification
セッション開始プロトコル（SIP）特異的イベント通知
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
Abstract
概要
This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred.
このドキュメントでは、セッション開始プロトコル（SIP）の拡張機能について説明します。この拡張機能の目的は、SIPノードが特定のイベントが発生したことを示すリモートノードから通知を要求できる拡張可能なフレームワークを提供することです。
Concrete uses of the mechanism described in this document may be standardized in the future.
このドキュメントで説明されているメカニズムの具体的な使用は、将来的に標準化される可能性があります。
Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification.
本明細書で定義されているイベント通知メカニズムは、すべてのクラスのイベントサブスクリプションと通知の汎用インフラストラクチャではないことに注意してください。
Table of Contents
目次
1. Introduction........................................... 3
1.1. Overview of Operation.................................. 4
1.2. Documentation Conventions.............................. 4
2. Definitions............................................ 5
3. Node Behavior.......................................... 6
3.1. Description of SUBSCRIBE Behavior...................... 6
3.1.1. Subscription Duration.................................. 6
3.1.2. Identification of Subscribed Events and Event Classes.. 6
3.1.3. Additional SUBSCRIBE Header Values..................... 7
3.1.4. Subscriber SUBSCRIBE Behavior.......................... 7
3.1.5. Proxy SUBSCRIBE Behavior............................... 9
3.1.6. Notifier SUBSCRIBE Behavior............................ 10
3.2. Description of NOTIFY Behavior......................... 13
3.2.1. Identification of Reported Events, Event Classes, and
Current State.......................................... 13
3.2.2. Notifier NOTIFY Behavior............................... 14
3.2.3. Proxy NOTIFY Behavior.................................. 15
3.2.4. Subscriber NOTIFY Behavior............................. 16
3.3. General................................................ 18
3.3.1. Detecting support for SUBSCRIBE and NOTIFY............. 18
3.3.2. CANCEL requests........................................ 18
3.3.3. Forking................................................ 18
3.3.4. Dialog creation and termination........................ 18
3.3.5. State Agents and Notifier Migration.................... 19
3.3.6. Polling Resource State................................. 20
3.3.7. Allow-Events header usage.............................. 21
3.3.8. PINT Compatibility..................................... 21
4. Event Packages......................................... 21
4.1. Appropriateness of Usage............................... 21
4.2. Event Template-packages................................ 22
4.3. Amount of State to be Conveyed......................... 22
4.3.1. Complete State Information............................. 23
4.3.2. State Deltas........................................... 23
4.4. Event Package Responsibilities......................... 24
4.4.1. Event Package Name..................................... 24
4.4.2. Event Package Parameters............................... 24
4.4.3. SUBSCRIBE Bodies....................................... 24
4.4.4. Subscription Duration.................................. 25
4.4.5. NOTIFY Bodies.......................................... 25
4.4.6. Notifier processing of SUBSCRIBE requests.............. 25
4.4.7. Notifier generation of NOTIFY requests................. 25
4.4.8. Subscriber processing of NOTIFY requests............... 26
4.4.9. Handling of forked requests............................ 26
4.4.10. Rate of notifications.................................. 26
4.4.11. State Agents........................................... 27
4.4.12. Examples............................................... 27
4.4.13. Use of URIs to Retrieve State.......................... 27
5. Security Considerations................................ 28
5.1. Access Control......................................... 28
5.2. Notifier Privacy Mechanism............................. 28
5.3. Denial-of-Service attacks.............................. 28
5.4. Replay Attacks......................................... 29
5.5. Man-in-the middle attacks.............................. 29
5.6. Confidentiality........................................ 29
6. IANA Considerations.................................... 30
6.1. Registration Information............................... 30
6.2. Registration Template.................................. 31
6.3. Header Field Names..................................... 31
6.4. Response Codes......................................... 32
7. Syntax................................................. 32
7.1. New Methods............................................ 32
7.1.1. SUBSCRIBE method....................................... 34
7.1.2. NOTIFY method.......................................... 34
7.2. New Headers............................................ 34
7.2.1. "Event" header......................................... 34
7.2.2. "Allow-Events" Header.................................. 35
7.2.3. "Subscription-State" Header............................ 35
7.3. New Response Codes..................................... 35
7.3.1. "202 Accepted" Response Code........................... 35
7.3.2. "489 Bad Event" Response Code.......................... 35
7.4. Augmented BNF Definitions.............................. 35
8. Normative References................................... 36
9. Informative References................................. 37
10. Acknowledgements....................................... 37
11. Notice Regarding Intellectual Property Rights.......... 37
12. Author's Address....................................... 37
13. Full Copyright Statement............................... 38
The ability to request asynchronous notification of events proves useful in many types of SIP services for which cooperation between end-nodes is required. Examples of such services include automatic callback services (based on terminal state events), buddy lists (based on user presence events), message waiting indications (based on mailbox state change events), and PSTN and Internet Internetworking (PINT) [2] status (based on call state events).
イベントの非同期通知を要求する機能は、エンドノード間の協力が必要な多くのタイプのSIPサービスで有用であることが証明されます。このようなサービスの例には、自動コールバックサービス（ターミナルステートイベントに基づく）、バディリスト（ユーザーの存在イベントに基づく）、メッセージ待機表示（メールボックス状態変更イベントに基づく）、PSTNおよびインターネットインターネットワーク（パイント）[2]ステータス（コールステートイベントに基づく）。
The methods described in this document provide a framework by which notification of these events can be ordered.
このドキュメントで説明されている方法は、これらのイベントの通知を注文できるフレームワークを提供します。
The event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. Meeting requirements for the general problem set of subscription and notification is far too complex for a single protocol. Our goal is to provide a SIP-specific framework for event notification which is not so complex as to be unusable for simple features, but which is still flexible enough to provide powerful services. Note, however, that event packages based on this framework may define arbitrarily elaborate rules which govern the subscription and notification for the events or classes of events they describe.
本明細書で定義されているイベント通知メカニズムは、すべてのクラスのイベントサブスクリプションと通知の汎用インフラストラクチャであることを意図したものではありません。サブスクリプションと通知の一般的な問題セットの要件を満たすことは、単一のプロトコルではあまりにも複雑です。私たちの目標は、イベント通知のためのSIP固有のフレームワークを提供することです。これは、単純な機能には使用できないほど複雑ではありませんが、強力なサービスを提供するほど柔軟です。ただし、このフレームワークに基づいたイベントパッケージは、説明するイベントまたはクラスのサブスクリプションと通知を支配する任意の精巧なルールを定義する場合があることに注意してください。
This document does not describe an extension which may be used directly; it must be extended by other documents (herein referred to as "event packages"). In object-oriented design terminology, it may be thought of as an abstract base class which must be derived into an instantiatable class by further extensions. Guidelines for creating these extensions are described in section 4.
このドキュメントでは、直接使用できる拡張機能については説明していません。他のドキュメントによって拡張する必要があります（ここでは「イベントパッケージ」と呼ばれます）。オブジェクト指向の設計用語では、さらなる拡張により即座のクラスに導き出されなければならない抽象的なベースクラスと考えられるかもしれません。これらの拡張機能を作成するためのガイドラインについては、セクション4で説明します。
The general concept is that entities in the network can subscribe to resource or call state for various resources or calls in the network, and those entities (or entities acting on their behalf) can send notifications when those states change.
一般的な概念は、ネットワーク内のエンティティがネットワーク内のさまざまなリソースまたは呼び出しのリソースを購読したり、状態を呼び出したり、それらのエンティティ（またはそれに代わって行動するエンティティ）がそれらの状態が変更されたときに通知を送信できることです。
A typical flow of messages would be:
メッセージの典型的な流れは次のとおりです。
Subscriber Notifier
|-----SUBSCRIBE---->| Request state subscription
|<-------200--------| Acknowledge subscription
|<------NOTIFY----- | Return current state information
|--------200------->|
|<------NOTIFY----- | Return current state information
|--------200------->|
Subscriptions are expired and must be refreshed by subsequent SUBSCRIBE messages.
サブスクリプションの有効期限が切れ、後続のサブスクライブメッセージで更新する必要があります。
There are several paragraphs throughout this document which provide motivational or clarifying text. Such passages are non-normative, and are provided only to assist with reader comprehension. These passages are set off from the remainder of the text by being indented thus:
このドキュメント全体に、動機付けまたは明確化を提供するいくつかの段落があります。このような文章は非規範的であり、読者の理解を支援するためにのみ提供されます。これらの文章は、このようにインデントされることにより、テキストの残りの部分から引き起こされます。
This is an example of non-normative explanatory text. It does not form part of the specification, and is used only for clarification.
これは、非規範的な説明テキストの例です。仕様の一部を形成せず、明確化にのみ使用されます。
Numbers in square brackets (e.g., [1]) denote a reference to one of the entries in the reference sections; see sections 8 and 9.
正方形の括弧内の数字（[1]）は、参照セクションのエントリの1つへの参照を示します。セクション8および9を参照してください。
The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].
すべての資本用語は、「必須」、「は」、「may」、「may」、「not "not」、" nut nut "、および「推奨」は、RFC 2119 [5]で定義されているように使用されます。
The use of quotation marks next to periods and commas follows the convention used by the American Mathematical Society; although contrary to traditional American English convention, this usage lends clarity to certain passages.
時代とコンマの横にある引用符の使用は、アメリカ数学協会が使用する条約に続きます。アメリカの伝統的な英語条約に反して、この使用法は特定の文章を明確にします。
Event Package: An event package is an additional specification which defines a set of state information to be reported by a notifier to a subscriber. Event packages also define further syntax and semantics based on the framework defined by this document required to convey such state information.
イベントパッケージ：イベントパッケージは、サブスクライバーに通知者が報告する一連の状態情報を定義する追加の仕様です。イベントパッケージは、このような状態情報を伝えるために必要なこのドキュメントで定義されたフレームワークに基づいて、さらなる構文とセマンティクスを定義します。
Event Template-Package: An event template-package is a special kind of event package which defines a set of states which may be applied to all possible event packages, including itself.
イベントテンプレートパッケージ：イベントテンプレートパッケージは、それ自体を含むすべての可能なイベントパッケージに適用できる一連の状態を定義する特別な種類のイベントパッケージです。
Notification: Notification is the act of a notifier sending a NOTIFY message to a subscriber to inform the subscriber of the state of a resource.
通知：通知とは、通知者がサブスクライバーに通知メッセージを送信して、リソースの状態をサブスクライバーに通知する行為です。
Notifier: A notifier is a user agent which generates NOTIFY requests for the purpose of notifying subscribers of the state of a resource. Notifiers typically also accept SUBSCRIBE requests to create subscriptions.
Notifier：Notifierは、リソースの状態を購読者に通知する目的で通知リクエストを生成するユーザーエージェントです。通常、通知者はサブスクライブリクエストを受け入れてサブスクリプションを作成します。
State Agent: A state agent is a notifier which publishes state information on behalf of a resource; in order to do so, it may need to gather such state information from multiple sources. State agents always have complete state information for the resource for which they are creating notifications.
州のエージェント：州のエージェントは、リソースに代わって州情報を公開する通知者です。そのためには、複数のソースからそのような状態情報を収集する必要がある場合があります。州のエージェントは、通知を作成しているリソースの完全な州情報を常に持っています。
Subscriber: A subscriber is a user agent which receives NOTIFY requests from notifiers; these NOTIFY requests contain information about the state of a resource in which the subscriber is interested. Subscribers typically also generate SUBSCRIBE requests and send them to notifiers to create subscriptions.
サブスクライバー：サブスクライバーは、通知者からの通知リクエストを受信するユーザーエージェントです。これらの通知リクエストには、サブスクライバーが興味を持っているリソースの状態に関する情報が含まれています。サブスクライバーは通常、サブスクライブリクエストを生成し、それらを通知者に送信してサブスクリプションを作成します。
Subscription: A subscription is a set of application state associated with a dialog. This application state includes a pointer to the associated dialog, the event package name, and possibly an identification token. Event packages will define additional subscription state information. By definition, subscriptions exist in both a subscriber and a notifier.
サブスクリプション：サブスクリプションは、ダイアログに関連付けられたアプリケーション状態のセットです。このアプリケーション状態には、関連するダイアログへのポインター、イベントパッケージ名、および場合によっては識別トークンが含まれています。イベントパッケージは、追加のサブスクリプション状態情報を定義します。定義上、サブスクライバーと通知者の両方にサブスクリプションが存在します。
Subscription Migration: Subscription migration is the act of moving a subscription from one notifier to another notifier.
サブスクリプション移行：サブスクリプション移行は、サブスクリプションをある通知者から別の通知者に移動する行為です。
The SUBSCRIBE method is used to request current state and state updates from a remote node.
サブスクライブメソッドは、リモートノードから現在の状態および状態の更新を要求するために使用されます。
SUBSCRIBE requests SHOULD contain an "Expires" header (defined in SIP [1]). This expires value indicates the duration of the subscription. In order to keep subscriptions effective beyond the duration communicated in the "Expires" header, subscribers need to refresh subscriptions on a periodic basis using a new SUBSCRIBE message on the same dialog as defined in SIP [1].
サブスクライブリクエストには、「期限切れ」ヘッダー（SIP [1]で定義）を含める必要があります。この値は、サブスクリプションの持続時間を示します。「期限切れ」ヘッダーで通信された期間を超えてサブスクリプションを効果的に保つために、サブスクライバーは、SIP [1]で定義された同じダイアログ上の新しいサブスクライブメッセージを使用して、サブスクリプションを定期的に更新する必要があります[1]。
If no "Expires" header is present in a SUBSCRIBE request, the implied default is defined by the event package being used.
サブスクライブリクエストに「有効期限が切れる」ヘッダーが存在しない場合、暗黙のデフォルトは、使用されているイベントパッケージによって定義されます。
200-class responses to SUBSCRIBE requests also MUST contain an "Expires" header. The period of time in the response MAY be shorter but MUST NOT be longer than specified in the request. The period of time in the response is the one which defines the duration of the subscription.
サブスクライブリクエストに対する200クラスの応答には、「期限切れ」ヘッダーも含まれている必要があります。応答の期間は短い場合がありますが、リクエストで指定されているよりも長くてはなりません。応答の期間は、サブスクリプションの期間を定義する期間です。
An "expires" parameter on the "Contact" header has no semantics for SUBSCRIBE and is explicitly not equivalent to an "Expires" header in a SUBSCRIBE request or response.
「連絡先」ヘッダーの「有効期限」パラメーターには、購読のセマンティクスがなく、購読要求または応答で「有効期限が切れる」ヘッダーに明示的に同等ではありません。
A natural consequence of this scheme is that a SUBSCRIBE with an "Expires" of 0 constitutes a request to unsubscribe from an event.
このスキームの自然な結果は、0の「有効期限」のある購読がイベントからの登録解除の要求を構成することです。
In addition to being a request to unsubscribe, a SUBSCRIBE message with "Expires" of 0 also causes a fetch of state; see section 3.3.6.
登録解除のリクエストであることに加えて、0の「有効期限」のサブスクライブメッセージは、状態のフェッチを引き起こします。セクション3.3.6を参照してください。
Notifiers may also wish to cancel subscriptions to events; this is useful, for example, when the resource to which a subscription refers is no longer available. Further details on this mechanism are discussed in section 3.2.2.
また、通知者はイベントのサブスクリプションをキャンセルすることもできます。これは、たとえば、サブスクリプションが参照するリソースが利用できなくなった場合に役立ちます。このメカニズムの詳細については、セクション3.2.2で説明します。
Identification of events is provided by three pieces of information: Request URI, Event Type, and (optionally) message body.
イベントの識別は、3つの情報によって提供されます：リクエストURI、イベントタイプ、および（オプションで）メッセージ本文。
The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [1]. It also contains enough information to identify the resource for which event notification is desired, but not necessarily enough information to uniquely identify the nature of the event (e.g., "sip:adam@dynamicsoft.com" would be an appropriate URI to subscribe to for my presence state; it would also be an appropriate URI to subscribe to the state of my voice mailbox).
サブスクライブリクエストのリクエストURIは、最も重要なことに、SIP [1]で概説されている要求ルーティング手順に従って、リクエストを適切なエンティティにルーティングするのに十分な情報が含まれています。また、イベント通知が望まれるリソースを識別するのに十分な情報も含まれていますが、必ずしもイベントの性質を一意に識別するのに十分な情報ではありません（例：「sip：adam@dynamicsoft.com」は、私の存在状態。また、ボイスメールボックスの状態を購読するのに適したURIでもあります）。
Subscribers MUST include exactly one "Event" header in SUBSCRIBE requests, indicating to which event or class of events they are subscribing. The "Event" header will contain a token which indicates the type of state for which a subscription is being requested. This token will be registered with the IANA and will correspond to an event package which further describes the semantics of the event or event class. The "Event" header MAY also contain an "id" parameter. This "id" parameter, if present, contains an opaque token which identifies the specific subscription within a dialog. An "id" parameter is only valid within the scope of a single dialog.
購読者は、購読要求に1つの「イベント」ヘッダーを1つの「イベント」ヘッダーに含める必要があります。「イベント」ヘッダーには、サブスクリプションが要求されている状態のタイプを示すトークンが含まれます。このトークンはIANAに登録され、イベントまたはイベントクラスのセマンティクスをさらに説明するイベントパッケージに対応します。「イベント」ヘッダーには、「ID」パラメーターも含まれている場合があります。この「ID」パラメーターは、存在する場合、ダイアログ内の特定のサブスクリプションを識別する不透明なトークンが含まれています。「ID」パラメーターは、単一のダイアログの範囲内でのみ有効です。
If the event package to which the event token corresponds defines behavior associated with the body of its SUBSCRIBE requests, those semantics apply.
イベントトークンが対応するイベントパッケージが、購読要求の本文に関連付けられた動作を定義する場合、それらのセマンティクスが適用されます。
Event packages may also define parameters for the Event header; if they do so, they must define the semantics for such parameters.
イベントパッケージは、イベントヘッダーのパラメーターを定義することもできます。そうすれば、そのようなパラメーターのセマンティクスを定義する必要があります。
Because SUBSCRIBE requests create a dialog as defined in SIP [1], they MAY contain an "Accept" header. This header, if present, indicates the body formats allowed in subsequent NOTIFY requests. Event packages MUST define the behavior for SUBSCRIBE requests without "Accept" headers; usually, this will connote a single, default body type.
SIP [1]で定義されているダイアログを作成するサブスクライブリクエストは、「受け入れる」ヘッダーを含む場合があります。このヘッダーは、存在する場合、その後の通知リクエストで許可されているボディ形式を示します。イベントパッケージは、ヘッダーを「受け入れる」ことなく、購読要求の動作を定義する必要があります。通常、これは単一のデフォルトのボディタイプを暗示します。
Header values not described in this document are to be interpreted as described in SIP [1].
このドキュメントで説明されていないヘッダー値は、SIP [1]で説明されているように解釈されます。
SUBSCRIBE is a dialog-creating method, as described in SIP [1].
sip [1]で説明されているように、購読はダイアログ作成方法です。
When a subscriber wishes to subscribe to a particular state for a resource, it forms a SUBSCRIBE message. If the initial SUBSCRIBE represents a request outside of a dialog (as it typically will), its construction follows the procedures outlined in SIP [1] for UAC request generation outside of a dialog.
サブスクライバーがリソースのために特定の状態を購読したい場合、サブスクライブメッセージを形成します。最初の購読がダイアログの外側のリクエストを表している場合（通常はそうするように）、その構造は、ダイアログ外のUAC要求生成のSIP [1]で概説されている手順に従います。
This SUBSCRIBE request will be confirmed with a final response. 200-class responses indicate that the subscription has been accepted, and that a NOTIFY will be sent immediately. A 200 response indicates that the subscription has been accepted and that the user is authorized to subscribe to the requested resource. A 202 response merely indicates that the subscription has been understood, and that authorization may or may not have been granted.
この購読要求は、最終的な応答で確認されます。200クラスの回答は、サブスクリプションが受け入れられ、通知がすぐに送信されることを示しています。200の回答は、サブスクリプションが受け入れられ、ユーザーが要求されたリソースを購読することを許可されていることを示しています。202の応答は、サブスクリプションが理解されていること、および認可が認められた場合と承認されていない可能性があることを示しているだけです。
The "Expires" header in a 200-class response to SUBSCRIBE indicates the actual duration for which the subscription will remain active (unless refreshed).
サブスクライブに対する200クラスの応答の「有効期限」ヘッダーは、サブスクリプションがアクティブのままである実際の期間（更新されない限り）を示します。
Non-200 class final responses indicate that no subscription or dialog has been created, and no subsequent NOTIFY message will be sent. All non-200 class responses (with the exception of "489", described herein) have the same meanings and handling as described in SIP [1].
非200クラスの最終応答は、サブスクリプションまたはダイアログが作成されておらず、その後の通知メッセージが送信されないことを示しています。SIP [1]に記載されているように、すべての非200のクラス応答（本明細書に記載されている「489」を除く）には同じ意味と取り扱いがあります。
A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog.
サブスクライブリクエストには、「イベント」ヘッダーに「ID」パラメーターが含まれて、同じダイアログ内の複数のサブスクリプション間の区別を可能にすることができます。
At any time before a subscription expires, the subscriber may refresh the timer on such a subscription by sending another SUBSCRIBE request on the same dialog as the existing subscription, and with the same "Event" header "id" parameter (if one was present in the initial subscription). The handling for such a request is the same as for the initial creation of a subscription except as described below.
サブスクリプションが期限切れになる前のいつでも、サブスクライバーは、既存のサブスクリプションと同じダイアログで別のサブスクライブリクエストを送信し、同じ「イベント」ヘッダー「ID」パラメーターを使用して、そのようなサブスクリプションのタイマーを更新できます（最初のサブスクリプション）。このようなリクエストの処理は、以下に説明する場合を除き、サブスクリプションの初期作成の場合と同じです。
If the initial SUBSCRIBE message contained an "id" parameter on the "Event" header, then refreshes of the subscription must also contain an identical "id" parameter; they will otherwise be considered new subscriptions in an existing dialog.
最初の購読メッセージに「イベント」ヘッダーに「ID」パラメーターが含まれている場合、サブスクリプションのリフレッシュには、同一の「ID」パラメーターも含まれている必要があります。そうでなければ、既存のダイアログで新しいサブスクリプションと見なされます。
If a SUBSCRIBE request to refresh a subscription receives a "481" response, this indicates that the subscription has been terminated and that the subscriber did not receive notification of this fact. In this case, the subscriber should consider the subscription invalid. If the subscriber wishes to re-subscribe to the state, he does so by composing an unrelated initial SUBSCRIBE request with a freshly-generated Call-ID and a new, unique "From" tag (see section 3.1.4.1.) If a SUBSCRIBE request to refresh a subscription fails with a non-481 response, the original subscription is still considered valid for the duration of the most recently known "Expires" value as negotiated by SUBSCRIBE and its response, or as communicated by NOTIFY in the "Subscription-State" header "expires" parameter.
サブスクリプションのリクエストが「481」応答を受信する場合、これはサブスクリプションが終了し、サブスクライバーがこの事実の通知を受け取らなかったことを示します。この場合、サブスクライバーはサブスクリプションが無効であると考える必要があります。加入者が州に再登録することを望む場合、彼は、新たに生成されたCall-IDと「タグからの新しいユニークな「」（セクション3.1.4.1を参照）を使用して無関係の初期購読要求を作成することでそうしますサブスクリプションを更新するリクエストは、481以外の応答で失敗します。元のサブスクリプションは、サブスクライブとその応答によって交渉された、または「サブスクリプション - の通知によって通知されるように、最近既知の「有効期限が切れる」値の期間中に有効であると見なされます。状態「ヘッダー」パラメーターの有効期限が切れます。
Note that many such errors indicate that there may be a problem with the network or the notifier such that no further NOTIFY messages will be received.
そのようなエラーの多くは、ネットワークまたは通知者に問題がある可能性があることを示しているため、メッセージが受信されないことを示しています。
Unsubscribing is handled in the same way as refreshing of a subscription, with the "Expires" header set to "0". Note that a successful unsubscription will also trigger a final NOTIFY message.
登録解除は、サブスクリプションのリフレッシュと同じ方法で処理され、「有効期限」ヘッダーが「0」に設定されています。サブスクリプションを成功させると、最終的な通知メッセージがトリガーされることに注意してください。
The subscriber can expect to receive a NOTIFY message from each node which has processed a successful subscription or subscription refresh. Until the first NOTIFY message arrives, the subscriber should consider the state of the subscribed resource to be in a neutral state. Documents which define new event packages MUST define this "neutral state" in such a way that makes sense for their application (see section 4.4.7.).
サブスクライバーは、サブスクリプションまたはサブスクリプションの更新を成功させた各ノードからNotifyメッセージを受信することを期待できます。最初のNotifyメッセージが届くまで、サブスクライバーは、購読されたリソースの状態が中立状態にあると考える必要があります。新しいイベントパッケージを定義するドキュメントは、この「中立状態」を、アプリケーションにとって意味のある方法で定義する必要があります（セクション4.4.7を参照）。
Due to the potential for both out-of-order messages and forking, the subscriber MUST be prepared to receive NOTIFY messages before the SUBSCRIBE transaction has completed.
秩序外のメッセージとフォーキングの両方の可能性があるため、サブスクライバーは、サブスクライブトランザクションが完了する前に通知メッセージを受信する準備をする必要があります。
Except as noted above, processing of this NOTIFY is the same as in section 3.2.4.
上記の場合を除き、この通知の処理はセクション3.2.4と同じです。
Proxies need no additional behavior beyond that described in SIP [1] to support SUBSCRIBE. If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests.
プロキシは、購読をサポートするためにSIP [1]に記載されているものを超えて追加の動作を必要としません。プロキシがすべてのサブスクライブを確認し、特定のダイアログのリクエストを通知したい場合、最初のサブスクライブとダイアログ確立の通知リクエストを記録する必要があります。このようなプロキシは、他のすべてのサブスクライブと通知リクエストも記録する必要があります。
Note that subscribers and notifiers may elect to use S/MIME encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies cannot rely on being able to access any information that is not explicitly required to be proxy-readable by SIP [1].
サブスクライバーと通知者は、サブスクライブのS/MIME暗号化を使用し、リクエストを通知することを選択できることに注意してください。したがって、プロキシは、SIPによってプロキシ読み取り可能であることを明示的に必要としない情報にアクセスできることに依存することはできません[1]。
In no case should a SUBSCRIBE transaction extend for any longer than the time necessary for automated processing. In particular, notifiers MUST NOT wait for a user response before returning a final response to a SUBSCRIBE request.
いかなる場合でも、サブスクライブトランザクションは、自動処理に必要な時間よりも長く延長されません。特に、通知者は、購読要求に対する最終応答を返す前に、ユーザーの応答を待ってはなりません。
This requirement is imposed primarily to prevent the non-INVITE transaction timeout timer F (see [1]) from firing during the SUBSCRIBE transaction, since interaction with a user would often exceed 64*T1 seconds.
この要件は、ユーザーとのやり取りが64*T1秒を超えることが多いため、サブスクライブトランザクション中に非インバイトトランザクションタイムアウトタイマーF（[1]を参照）を防止するのを防ぐために主に課されます。
The notifier SHOULD check that the event package specified in the "Event" header is understood. If not, the notifier SHOULD return a "489 Bad Event" response to indicate that the specified event/event class is not understood.
Notifierは、「イベント」ヘッダーで指定されたイベントパッケージが理解されていることを確認する必要があります。そうでない場合、通知者は「489の悪いイベント」応答を返して、指定されたイベント/イベントクラスが理解されていないことを示します。
The notifier SHOULD also perform any necessary authentication and authorization per its local policy. See section 3.1.6.3.
また、通知者は、ローカルポリシーごとに必要な認証と承認を実行する必要があります。セクション3.1.6.3を参照してください。
The notifier MAY also check that the duration in the "Expires" header is not too small. If and only if the expiration interval is greater than zero AND smaller than one hour AND less than a notifier-configured minimum, the notifier MAY return a "423 Interval too small" error which contains a "Min-Expires" header field. The "Min-Expires" header field is described in SIP [1].
また、Notifierは、「有効期限が切れる」ヘッダーの期間が小さすぎないことを確認する場合があります。有効期限間隔がゼロを超えて1時間未満で、紹介者が構成された最小値よりも小さい場合にのみ、通知者は「最小」ヘッダーフィールドを含む「423間隔が小さすぎる」エラーを返すことができます。「Min-Expires」ヘッダーフィールドは、SIP [1]で説明されています。
If the notifier is able to immediately determine that it understands the event package, that the authenticated subscriber is authorized to subscribe, and that there are no other barriers to creating the subscription, it creates the subscription and a dialog (if necessary), and returns a "200 OK" response (unless doing so would reveal authorization policy in an undesirable fashion; see section 5.2.).
通知者がイベントパッケージを理解していること、認証されたサブスクライバーが購読する権限があり、サブスクリプションを作成する他の障壁がないことをすぐに判断できる場合、サブスクリプションとダイアログ（必要に応じて）を作成し、返します「200 ok」応答（そうしないと、許可ポリシーが望ましくない方法で明らかになります。セクション5.2を参照してください。）。
If the notifier cannot immediately create the subscription (e.g., it needs to wait for user input for authorization, or is acting for another node which is not currently reachable), or wishes to mask authorization policy, it will return a "202 Accepted" response. This response indicates that the request has been received and understood, but does not necessarily imply that the subscription has been authorized yet.
紹介者がすぐにサブスクリプションを作成できない場合（たとえば、認証のためにユーザー入力を待つ必要があるか、現在到達できない別のノードに作用する必要があります）、または認可ポリシーをマスクしたい場合、「202の受け入れられた」応答を返します。この応答は、リクエストが受信および理解されたことを示していますが、サブスクリプションがまだ承認されていることを必ずしも意味するわけではありません。
When a subscription is created in the notifier, it stores the event package name and the "Event" header "id" parameter (if present) as part of the subscription information.
notifierでサブスクリプションが作成されると、サブスクリプション情報の一部としてイベントパッケージ名と「イベント」ヘッダー "ID"パラメーター（存在する場合）を保存します。
The "Expires" values present in SUBSCRIBE 200-class responses behave in the same way as they do in REGISTER responses: the server MAY shorten the interval, but MUST NOT lengthen it.
サブスクライブ200クラスの応答に存在する「有効期限」の値は、レジスタ応答と同じように動作します。サーバーは間隔を短くすることができますが、延長してはなりません。
If the duration specified in a SUBSCRIBE message is unacceptably short, the notifier may be able to send a 423 response, as described earlier in this section.
サブスクライブメッセージで指定された期間が容認できないほど短い場合、このセクションで前述したように、通知者は423の応答を送信できる場合があります。
200-class responses to SUBSCRIBE requests will not generally contain any useful information beyond subscription duration; their primary purpose is to serve as a reliability mechanism. State information will be communicated via a subsequent NOTIFY request from the notifier.
サブスクライブリクエストに対する200クラスの回答には、通常、サブスクリプション期間を超えた有用な情報は含まれません。彼らの主な目的は、信頼性メカニズムとして機能することです。州の情報は、通知者からの後続の通知要求を介して伝えられます。
The other response codes defined in SIP [1] may be used in response to SUBSCRIBE requests, as appropriate.
SIP [1]で定義されている他の応答コードは、必要に応じて、サブスクライブリクエストに応じて使用できます。
Upon successfully accepting or refreshing a subscription, notifiers MUST send a NOTIFY message immediately to communicate the current resource state to the subscriber. This NOTIFY message is sent on the same dialog as created by the SUBSCRIBE response. If the resource has no meaningful state at the time that the SUBSCRIBE message is processed, this NOTIFY message MAY contain an empty or neutral body. See section 3.2.2. for further details on NOTIFY message generation.
サブスクリプションを正常に受け入れたり更新したりすると、通知者はすぐに通知メッセージを送信して、現在のリソース状態をサブスクライバーに通信する必要があります。この通知メッセージは、サブスクライブ応答によって作成されたのと同じダイアログで送信されます。サブスクライブメッセージが処理された時点でリソースに意味のある状態がない場合、このNotifyメッセージには空またはニュートラルのボディが含まれている場合があります。セクション3.2.2を参照してください。通知メッセージ生成の詳細については。
Note that a NOTIFY message is always sent immediately after any 200- class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized.
サブスクリプションが既に承認されているかどうかに関係なく、サブスクライブリクエストに対する200クラスの応答の直後に通知メッセージは常に送信されることに注意してください。
Privacy concerns may require that notifiers apply policy to determine whether a particular subscriber is authorized to subscribe to a certain set of events. Such policy may be defined by mechanisms such as access control lists or real-time interaction with a user. In general, authorization of subscribers prior to authentication is not particularly useful.
プライバシーの懸念は、特定のサブスクライバーが特定の一連のイベントを購読することを許可されているかどうかを判断するために、通知者がポリシーを適用することを要求する場合があります。このようなポリシーは、アクセス制御リストやユーザーとのリアルタイムのやり取りなどのメカニズムによって定義される場合があります。一般に、認証前の加入者の承認は特に有用ではありません。
SIP authentication mechanisms are discussed in SIP [1]. Note that, even if the notifier node typically acts as a proxy, authentication for SUBSCRIBE requests will always be performed via a "401" response, not a "407;" notifiers always act as a user agents when accepting subscriptions and sending notifications.
SIP認証メカニズムについては、SIP [1]で説明します。通常、通知者ノードがプロキシとして機能する場合でも、サブスクライブリクエストの認証は常に「407」ではなく「401」応答を介して実行されることに注意してください。通知者は、サブスクリプションを受け入れて通知を送信する際に、常にユーザーエージェントとして機能します。
Of course, when acting as a proxy, a node will perform normal proxy authentication (using 407). The foregoing explanation is a reminder that notifiers are always UAs, and as such perform UA authentication.
もちろん、プロキシとして機能する場合、ノードは通常のプロキシ認証を実行します（407を使用）。前述の説明は、通知者が常にUASであり、そのためUA認証を実行することを思い出させるものです。
If authorization fails based on an access list or some other automated mechanism (i.e., it can be automatically authoritatively determined that the subscriber is not authorized to subscribe), the notifier SHOULD reply to the request with a "403 Forbidden" or "603 Decline" response, unless doing so might reveal information that should stay private; see section 5.2.
アクセスリストまたはその他の自動化されたメカニズムに基づいて承認が失敗した場合（つまり、サブスクライバーが購読することを許可されていないことを自動的に信頼できると判断することができます）、notifierは「403禁止」または「603減少」でリクエストに返信する必要があります。応答は、そうしない限り、プライベートを維持する必要がある情報を明らかにする可能性があります。セクション5.2を参照してください。
If the notifier owner is interactively queried to determine whether a subscription is allowed, a "202 Accept" response is returned immediately. Note that a NOTIFY message is still formed and sent under these circumstances, as described in the previous section.
通知者の所有者がインタラクティブにクエリされてサブスクリプションが許可されているかどうかを判断すると、「202 Accept」応答がすぐに返されます。前のセクションで説明されているように、これらの状況に基づいて、通知メッセージがまだ形成され、送信されることに注意してください。
If subscription authorization was delayed and the notifier wishes to convey that such authorization has been declined, it may do so by sending a NOTIFY message containing a "Subscription-State" header with a value of "terminated" and a reason parameter of "rejected".
サブスクリプション承認が遅れ、通知者がそのような承認が拒否されたことを伝えたい場合、「終了」の値を持つ「サブスクリプションステート」ヘッダーを含むnotifyメッセージを送信することにより、「拒否された」という理由のパラメーターを送信することでそうすることができます。。
When a notifier receives a subscription refresh, assuming that the subscriber is still authorized, the notifier updates the expiration time for the subscription. As with the initial subscription, the server MAY shorten the amount of time until expiration, but MUST NOT increase it. The final expiration time is placed in the "Expires" header in the response. If the duration specified in a SUBSCRIBE message is unacceptably short, the notifier SHOULD respond with a "423 Subscription Too Brief" message.
Subscriberがまだ許可されていると仮定して、紹介者がサブスクリプションの更新を受信した場合、Notifierはサブスクリプションの有効期限を更新します。最初のサブスクリプションと同様に、サーバーは有効期限まで時間を短くすることができますが、それを増やしてはなりません。最後の有効期限は、応答の「有効期限が切れる」ヘッダーに配置されます。サブスクライブメッセージで指定された期間が容認できないほど短い場合、Notifierは「423サブスクリプションが簡単すぎる」メッセージで応答する必要があります。
If no refresh for a notification address is received before its expiration time, the subscription is removed. When removing a subscription, the notifier SHOULD send a NOTIFY message with a "Subscription-State" value of "terminated" to inform it that the subscription is being removed. If such a message is sent, the "Subscription-State" header SHOULD contain a "reason=timeout" parameter.
有効期限が切れる前に通知アドレスの更新が受信されない場合、サブスクリプションは削除されます。サブスクリプションを削除する場合、notifierは「サブスクリプションステート」値の「終了」の値を持つ通知メッセージを送信して、サブスクリプションが削除されていることを通知する必要があります。そのようなメッセージが送信される場合、「サブスクリプション状態」ヘッダーには「理由=タイムアウト」パラメーターが含まれている必要があります。
The sending of a NOTIFY when a subscription expires allows the corresponding dialog to be terminated, if appropriate.
サブスクリプションの有効期限が切れるときの通知の送信により、必要に応じて対応するダイアログを終了させます。
NOTIFY messages are sent to inform subscribers of changes in state to which the subscriber has a subscription. Subscriptions are typically put in place using the SUBSCRIBE method; however, it is possible that other means have been used.
通知メッセージは、サブスクライバーがサブスクリプションを持っている状態の変更を加入者に通知するために送信されます。サブスクリプションは通常、サブスクライブメソッドを使用して導入されます。ただし、他の手段が使用されている可能性があります。
If any non-SUBSCRIBE mechanisms are defined to create subscriptions, it is the responsibility of the parties defining those mechanisms to ensure that correlation of a NOTIFY message to the corresponding subscription is possible. Designers of such mechanisms are also warned to make a distinction between sending a NOTIFY message to a subscriber who is aware of the subscription, and sending a NOTIFY message to an unsuspecting node. The latter behavior is invalid, and MUST receive a "481 Subscription does not exist" response (unless some other 400- or 500-class error code is more applicable), as described in section 3.2.4. In other words, knowledge of a subscription must exist in both the subscriber and the notifier to be valid, even if installed via a non-SUBSCRIBE mechanism.
サブスクリプションを作成するために非サブスクライブメカニズムが定義されている場合、対応するサブスクリプションと通知メッセージの相関が可能であることを保証するメカニズムを定義する当事者の責任です。このようなメカニズムの設計者は、サブスクリプションを認識しているサブスクライバーに通知メッセージを送信することと、疑いを持たないノードにnotifyメッセージを送信することとを区別することも警告されています。後者の動作は無効であり、セクション3.2.4で説明されているように、「481サブスクリプションが存在しない」応答を受け取る必要があります（他の400クラスまたは500クラスのエラーコードがより適用されない限り）。言い換えれば、サブスクライバーと通知者の両方に、非サブスクライブメカニズムを介してインストールされた場合でも、サブスクライバーと通信機の両方に有効になるように存在する必要があります。
A NOTIFY does not terminate its corresponding subscription; in other words, a single SUBSCRIBE request may trigger several NOTIFY requests.
Notifyは、対応するサブスクリプションを終了しません。言い換えれば、単一の購読要求は、いくつかの通知要求をトリガーする場合があります。
Identification of events being reported in a notification is very similar to that described for subscription to events (see section 3.1.2.).
通知で報告されているイベントの識別は、イベントのサブスクリプションについて説明したものと非常に似ています（セクション3.1.2を参照）。
As in SUBSCRIBE requests, NOTIFY "Event" headers will contain a single event package name for which a notification is being generated. The package name in the "Event" header MUST match the "Event" header in the corresponding SUBSCRIBE message. If an "id" parameter was present in the SUBSCRIBE message, that "id" parameter MUST also be present in the corresponding NOTIFY messages.
購読リクエストのように、「イベント」ヘッダーに通知されるには、通知が生成されている単一のイベントパッケージ名が含まれます。「イベント」ヘッダーのパッケージ名は、対応するサブスクライブメッセージの「イベント」ヘッダーと一致する必要があります。サブスクライブメッセージに「ID」パラメーターが存在する場合、その「ID」パラメーターも対応するNotifyメッセージに存在する必要があります。
Event packages may define semantics associated with the body of their NOTIFY requests; if they do so, those semantics apply. NOTIFY bodies are expected to provide additional details about the nature of the event which has occurred and the resultant resource state.
イベントパッケージは、通知要求の本文に関連するセマンティクスを定義する場合があります。そうすれば、これらのセマンティクスが適用されます。通知機関は、発生したイベントの性質と結果として得られるリソース状態に関する追加の詳細を提供することが期待されています。
When present, the body of the NOTIFY request MUST be formatted into one of the body formats specified in the "Accept" header of the corresponding SUBSCRIBE request. This body will contain either the state of the subscribed resource or a pointer to such state in the form of a URI (see section 4.4.13).
存在する場合、Notifyリクエストの本文は、対応するサブスクライブリクエストの「Accept」ヘッダーで指定されたボディ形式の1つにフォーマットする必要があります。この本体には、購読されたリソースの状態またはURIの形でそのような状態へのポインターが含まれます（セクション4.4.13を参照）。
When a SUBSCRIBE request is answered with a 200-class response, the notifier MUST immediately construct and send a NOTIFY request to the subscriber. When a change in the subscribed state occurs, the notifier SHOULD immediately construct and send a NOTIFY request, subject to authorization, local policy, and throttling considerations.
サブスクライブリクエストが200クラスの応答で応答された場合、通知者はすぐにサブスクライバーに通知要求を作成して送信する必要があります。購読された状態の変更が発生した場合、通知者はすぐに通知要求を作成して送信する必要があります。
A NOTIFY request is considered failed if the response times out, or a non-200 class response code is received which has no "Retry-After" header and no implied further action which can be taken to retry the request (e.g., "401 Authorization Required".)
応答がタイムアウトした場合、または「再試行後」のヘッダーがなく、リクエストを再試行するために黙示するさらなる措置を講じることができない場合、notifyリクエストが失敗したと見なされます（例：401承認必須"。）
If the NOTIFY request fails (as defined above) due to a timeout condition, and the subscription was installed using a soft-state mechanism (such as SUBSCRIBE), the notifier SHOULD remove the subscription.
タイムアウト条件のために通知要求が（上記で定義されているように）失敗し、サブスクリプションがソフトステートメカニズム（サブスクライブなど）を使用してインストールされた場合、notifierはサブスクリプションを削除する必要があります。
This behavior prevents unnecessary transmission of state information for subscribers who have crashed or disappeared from the network. Because such transmissions will be sent multiple times, per the retransmission algorithm defined in SIP [1] (instead of the typical single transmission for functioning clients), continuing to service them when no client is available to acknowledge them could place undue strain on a network. Upon client restart or reestablishment of a network connection, it is expected that clients will send SUBSCRIBE messages to refresh potentially stale state information; such messages will re-install subscriptions in all relevant nodes.
この動作は、ネットワークからクラッシュしたり消えたりした加入者の州情報の不必要な送信を防ぎます。そのような送信は、SIP [1]で定義された再送信アルゴリズムに従って複数回送信されるため（機能するクライアントの典型的な単一伝送の代わりに）、クライアントがネットワークに過度の負担をかけることができない場合は、それらをサービスを継続し続けます。。クライアントがネットワーク接続を再開または再確立すると、クライアントが登録メッセージを送信して、潜在的に古い状態情報を更新することが期待されます。このようなメッセージは、関連するすべてのノードでサブスクリプションを再インストールします。
If the NOTIFY request fails (as defined above) due to an error response, and the subscription was installed using a soft-state mechanism, the notifier MUST remove the corresponding subscription.
エラー応答のために通知要求が（上記で定義されているように）失敗し、サブスクリプションがソフトステートメカニズムを使用してインストールされた場合、紹介者は対応するサブスクリプションを削除する必要があります。
A notify error response would generally indicate that something has gone wrong with the subscriber or with some proxy on the way to the subscriber. If the subscriber is in error, it makes the most sense to allow the subscriber to rectify the situation (by re-subscribing) once the error condition has been handled. If a proxy is in error, the periodic SUBSCRIBE refreshes will re-install subscription state once the network problem has been resolved.
一般に、通知エラー応答は、サブスクライバーまたはサブスクライバーに向かう途中で何かが問題になっていることを示します。サブスクライバーが誤っている場合、エラー条件が処理されたら、サブスクライバーが状況を（再吸収することにより）是正できるようにすることが最も理にかなっています。プロキシが誤っている場合、定期的なサブスクライブリフレッシュは、ネットワークの問題が解決するとサブスクリプション状態を再インストールします。
If a NOTIFY request receives a 481 response, the notifier MUST remove the corresponding subscription even if such subscription was installed by non-SUBSCRIBE means (such as an administrative interface).
通知要求が481の応答を受信した場合、通知者は、そのようなサブスクリプションが非サブスクライブ手段（管理インターフェイスなど）によってインストールされた場合でも、対応するサブスクリプションを削除する必要があります。
If the above behavior were not required, subscribers receiving a notify for an unknown subscription would need to send an error status code in response to the NOTIFY and also send a SUBSCRIBE request to remove the subscription. Since this behavior would make subscribers available for use as amplifiers in denial of service attacks, we have instead elected to give the 481 response special meaning: it is used to indicate that a subscription must be cancelled under all circumstances.
上記の動作が不要な場合、未知のサブスクリプションの通知を受け取ったサブスクライバーは、通知に応じてエラーステータスコードを送信し、サブスクライブリクエストを送信してサブスクリプションを削除する必要があります。この動作は、サービス拒否攻撃でアンプとして使用できるようになるため、代わりに481の応答に特別な意味を与えることを選択しました。すべての状況でサブスクリプションをキャンセルする必要があることを示すために使用されます。
NOTIFY requests MUST contain a "Subscription-State" header with a value of "active", "pending", or "terminated". The "active" value indicates that the subscription has been accepted and has been authorized (in most cases; see section 5.2.). The "pending" value indicates that the subscription has been received, but that policy information is insufficient to accept or deny the subscription at this time. The "terminated" value indicates that the subscription is not active.
Notifyリクエストには、「アクティブ」、「保留中」、または「終了」の値を持つ「サブスクリプション状態」ヘッダーが含まれている必要があります。「アクティブ」値は、サブスクリプションが受け入れられ、許可されていることを示します（ほとんどの場合、セクション5.2を参照）。「保留中の」値は、サブスクリプションが受信されたことを示していますが、そのポリシー情報は現時点でサブスクリプションを受け入れるか拒否していないことを示しています。「終了」値は、サブスクリプションがアクティブでないことを示します。
If the value of the "Subscription-State" header is "active" or "pending", the notifier SHOULD also include in the "Subscription-State" header an "expires" parameter which indicates the time remaining on the subscription. The notifier MAY use this mechanism to shorten a subscription; however, this mechanism MUST NOT be used to lengthen a subscription.
「サブスクリプション状態」ヘッダーの値が「アクティブ」または「保留中」である場合、Notifierは「サブスクリプション状態」ヘッダーに、サブスクリプションの残り時間を示す「有効期限が切れる」パラメーターにも含める必要があります。通知者は、このメカニズムを使用してサブスクリプションを短くすることができます。ただし、このメカニズムを使用してサブスクリプションを延長してはなりません。
Including expiration information for active and pending subscriptions is useful in case the SUBSCRIBE request forks, since the response to a forked SUBSCRIBE may not be received by the subscriber. Note well that this "expires" value is a parameter on the "Subscription-State" header, NOT an "Expires" header.
アクティブおよび保留中のサブスクリプションの有効期限情報を含めることは、サブスクライブサブスクライブへの応答がサブスクライバーが受信しない可能性があるため、購読要求フォークの場合に役立ちます。この「有効期限」値は、「サブスクリプション状態」ヘッダーのパラメーターであり、「有効期限が切れる」ヘッダーではないことに注意してください。
If the value of the "Subscription-State" header is "terminated", the notifier SHOULD also include a "reason" parameter. The notifier MAY also include a "retry-after" parameter, where appropriate. For details on the value and semantics of the "reason" and "retry-after" parameters, see section 3.2.4.
「サブスクリプション状態」ヘッダーの値が「終了」されている場合、Notifierには「理由」パラメーターも含める必要があります。通知者には、必要に応じて「再試行後の」パラメーターを含めることもできます。「理由」および「再試行後」パラメーターの値とセマンティクスの詳細については、セクション3.2.4を参照してください。
Proxies need no additional behavior beyond that described in SIP [1] to support NOTIFY. If a proxy wishes to see all of the SUBSCRIBE and NOTIFY requests for a given dialog, it MUST record-route the initial SUBSCRIBE and any dialog-establishing NOTIFY requests. Such proxies SHOULD also record-route all other SUBSCRIBE and NOTIFY requests.
プロキシは、通知をサポートするためにSIP [1]に記載されているものを超えて追加の動作を必要としません。プロキシがすべてのサブスクライブを確認し、特定のダイアログのリクエストを通知したい場合、最初のサブスクライブとダイアログ確立の通知リクエストを記録する必要があります。このようなプロキシは、他のすべてのサブスクライブと通知リクエストも記録する必要があります。
Note that subscribers and notifiers may elect to use S/MIME encryption of SUBSCRIBE and NOTIFY requests; consequently, proxies cannot rely on being able to access any information that is not explicitly required to be proxy-readable by SIP [1].
サブスクライバーと通知者は、サブスクライブのS/MIME暗号化を使用し、リクエストを通知することを選択できることに注意してください。したがって、プロキシは、SIPによってプロキシ読み取り可能であることを明示的に必要としない情報にアクセスできることに依存することはできません[1]。
Upon receiving a NOTIFY request, the subscriber should check that it matches at least one of its outstanding subscriptions; if not, it MUST return a "481 Subscription does not exist" response unless another 400- or 500-class response is more appropriate. The rules for matching NOTIFY requests with subscriptions that create a new dialog are described in section 3.3.4. Notifications for subscriptions which were created inside an existing dialog match if they are in the same dialog and the "Event" headers match (as described in section 7.2.1.)
通知リクエストを受信すると、サブスクライバーは、その未解決のサブスクリプションの少なくとも1つと一致することを確認する必要があります。そうでない場合は、別の400クラスまたは500クラスの応答がより適切でない限り、「481サブスクリプションが存在しない」応答を返す必要があります。新しいダイアログを作成するサブスクリプションと通知リクエストを一致させるためのルールは、セクション3.3.4で説明されています。既存のダイアログマッチ内で作成されたサブスクリプションの通知は、同じダイアログと「イベント」ヘッダーマッチ（セクション7.2.1で説明されているように）にある場合です。
If, for some reason, the event package designated in the "Event" header of the NOTIFY request is not supported, the subscriber will respond with a "489 Bad Event" response.
何らかの理由で、Notifyリクエストの「イベント」ヘッダーに指定されたイベントパッケージがサポートされていない場合、サブスクライバーは「489 Bad Event」応答で応答します。
To prevent spoofing of events, NOTIFY requests SHOULD be authenticated, using any defined SIP authentication mechanism.
イベントのスプーフィングを防ぐには、定義されたSIP認証メカニズムを使用して、リクエストを認証する必要があります。
NOTIFY requests MUST contain "Subscription-State" headers which indicate the status of the subscription.
通知リクエストには、サブスクリプションのステータスを示す「サブスクリプション状態」ヘッダーが含まれている必要があります。
If the "Subscription-State" header value is "active", it means that the subscription has been accepted and (in general) has been authorized. If the header also contains an "expires" parameter, the subscriber SHOULD take it as the authoritative subscription duration and adjust accordingly. The "retry-after" and "reason" parameters have no semantics for "active".
「サブスクリプション状態」ヘッダー値が「アクティブ」である場合、サブスクリプションが受け入れられ、（一般的に）承認されていることを意味します。ヘッダーに「有効期限が切れる」パラメーターも含まれている場合、サブスクライバーはそれを権威あるサブスクリプションの期間として受け取り、それに応じて調整する必要があります。「再試行後」および「理由」パラメーターには、「アクティブ」のセマンティクスはありません。
If the "Subscription-State" value is "pending", the subscription has been received by the notifier, but there is insufficient policy information to grant or deny the subscription yet. If the header also contains an "expires" parameter, the subscriber SHOULD take it as the authoritative subscription duration and adjust accordingly. No further action is necessary on the part of the subscriber. The "retry-after" and "reason" parameters have no semantics for "pending".
「サブスクリプション状態」値が「保留中」である場合、サブスクリプションは監視員によって受信されましたが、サブスクリプションを許可または拒否するにはポリシー情報が不十分です。ヘッダーに「有効期限が切れる」パラメーターも含まれている場合、サブスクライバーはそれを権威あるサブスクリプションの期間として受け取り、それに応じて調整する必要があります。サブスクライバーの側では、それ以上のアクションは必要ありません。「再試行後」および「理由」パラメーターには、「保留中」のセマンティクスはありません。
If the "Subscription-State" value is "terminated", the subscriber should consider the subscription terminated. The "expires" parameter has no semantics for "terminated". If a reason code is present, the client should behave as described below. If no reason code or an unknown reason code is present, the client MAY attempt to re- subscribe at any time (unless a "retry-after" parameter is present, in which case the client SHOULD NOT attempt re-subscription until after the number of seconds specified by the "retry-after" parameter). The defined reason codes are:
「サブスクリプション状態」値が「終了」である場合、サブスクライバーはサブスクリプションが終了したことを検討する必要があります。「有効期限」パラメーターには、「終了」のセマンティクスはありません。理由コードが存在する場合、クライアントは以下に説明するように動作する必要があります。理由コードや不明な理由コードが存在しない場合、クライアントはいつでも登録を試みることができます（「再試行後」パラメーターが存在しない限り、その場合、クライアントは数の後まで再サブスクリプションを試みるべきではありません「再試行後」パラメーターで指定された秒）。定義された理由コードは次のとおりです。
deactivated: The subscription has been terminated, but the subscriber SHOULD retry immediately with a new subscription. One primary use of such a status code is to allow migration of subscriptions between nodes. The "retry-after" parameter has no semantics for "deactivated".
非アクティブ化：サブスクリプションは終了しましたが、サブスクライバーは新しいサブスクリプションですぐに再試行する必要があります。このようなステータスコードの主要な使用の1つは、ノード間のサブスクリプションの移行を許可することです。「再試行後」パラメーターには、「非アクティブ化」のセマンティクスはありません。
probation: The subscription has been terminated, but the client SHOULD retry at some later time. If a "retry-after" parameter is also present, the client SHOULD wait at least the number of seconds specified by that parameter before attempting to re-subscribe.
保護観察：サブスクリプションは終了しましたが、クライアントは後で再試行する必要があります。「再試行後」パラメーターも存在する場合、クライアントは、再サブスクライブを試みる前に、少なくともそのパラメーターで指定された秒数を待つ必要があります。
rejected: The subscription has been terminated due to change in authorization policy. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "rejected".
拒否：承認ポリシーの変更により、サブスクリプションは終了しました。クライアントは、再登録を試みてはいけません。「再試行後」パラメーターには、「拒否」のセマンティクスはありません。
timeout: The subscription has been terminated because it was not refreshed before it expired. Clients MAY re-subscribe immediately. The "retry-after" parameter has no semantics for "timeout".
タイムアウト：サブスクリプションは、期限切れになる前に更新されなかったため終了しました。クライアントはすぐに再登録することができます。「再試行後」パラメーターには、「タイムアウト」のセマンティクスはありません。
giveup: The subscription has been terminated because the notifier could not obtain authorization in a timely fashion. If a "retry-after" parameter is also present, the client SHOULD wait at least the number of seconds specified by that parameter before attempting to re-subscribe; otherwise, the client MAY retry immediately, but will likely get put back into pending state.
giveup：通知者がタイムリーな方法で承認を取得できなかったため、サブスクリプションは終了しました。「再試行後の」パラメーターも存在する場合、クライアントは、再サブスクライブを試みる前に、少なくともそのパラメーターで指定された秒数を待つ必要があります。それ以外の場合、クライアントはすぐに再試行する可能性がありますが、保留中の状態に戻される可能性があります。
noresource: The subscription has been terminated because the resource state which was being monitored no longer exists. Clients SHOULD NOT attempt to re-subscribe. The "retry-after" parameter has no semantics for "noresource".
noresource：監視されていたリソース状態が存在しなくなったため、サブスクリプションが終了しました。クライアントは、再登録を試みてはいけません。「再試行後」パラメーターには、「noresource」のセマンティクスはありません。
Once the notification is deemed acceptable to the subscriber, the subscriber SHOULD return a 200 response. In general, it is not expected that NOTIFY responses will contain bodies; however, they MAY, if the NOTIFY request contained an "Accept" header.
通知が加入者に受け入れられるとみなされると、サブスクライバーは200の応答を返す必要があります。一般に、通知の回答には身体が含まれることは予想されていません。ただし、Notifyリクエストに「Accept」ヘッダーが含まれている場合は、それらがあります。
Other responses defined in SIP [1] may also be returned, as appropriate. In no case should a NOTIFY transaction extend for any longer than the time necessary for automated processing. In particular, subscribers MUST NOT wait for a user response before returning a final response to a NOTIFY request.
SIP [1]で定義されている他の回答も返される場合があります。いかなる場合でも、通知トランザクションは、自動処理に必要な時間よりも長く拡張されてはなりません。特に、サブスクライバーは、通知リクエストに対する最終的な応答を返す前に、ユーザーの応答を待ってはなりません。
Neither SUBSCRIBE nor NOTIFY necessitate the use of "Require" or "Proxy-Require" headers; similarly, there is no token defined for "Supported" headers. If necessary, clients may probe for the support of SUBSCRIBE and NOTIFY using the OPTIONS request defined in SIP [1].
サブスクライブも通知も、「要求」または「プロキシリクイア」ヘッダーの使用を必要としません。同様に、「サポートされた」ヘッダーに対して定義されたトークンはありません。必要に応じて、クライアントは購読のサポートのために調査し、SIP [1]で定義されたオプション要求を使用して通知することができます。
The presence of the "Allow-Events" header in a message is sufficient to indicate support for SUBSCRIBE and NOTIFY.
メッセージ内の「Allow-Ivents」ヘッダーの存在は、購読と通知のサポートを示すのに十分です。
The "methods" parameter for Contact may also be used to specifically announce support for SUBSCRIBE and NOTIFY messages when registering. (See reference [8] for details on the "methods" parameter).
連絡先の「メソッド」パラメーターを使用して、登録時にサブスクライブのサポートを具体的に発表し、メッセージを通知することもできます。（「メソッド」パラメーターの詳細については、参照[8]を参照してください）。
No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
購読または通知のキャンセルに関連するセマンティクスはありません。
In accordance with the rules for proxying non-INVITE requests as defined in SIP [1], successful SUBSCRIBE requests will receive only one 200-class response; however, due to forking, the subscription may have been accepted by multiple nodes. The subscriber MUST therefore be prepared to receive NOTIFY requests with "From:" tags which differ from the "To:" tag received in the SUBSCRIBE 200-class response.
SIP [1]で定義されている非インバイト要求をプロキシするための規則に従って、サブスクライブリクエストの成功は200クラスの応答のみを受け取ります。ただし、フォーキングにより、サブスクリプションは複数のノードによって受け入れられている可能性があります。したがって、サブスクライバーは、 "from：" to "to："タグ200クラスの応答で受信したタグで通知リクエストを受信する準備をする必要があります。
If multiple NOTIFY messages are received in different dialogs in response to a single SUBSCRIBE message, each dialog represents a different destination to which the SUBSCRIBE request was forked. For information on subscriber handling in such situations, see section 4.4.9.
単一の購読メッセージに応じて異なるダイアログで複数の通知メッセージが受信されると、各ダイアログは、サブスクライブリクエストがフォークされた異なる宛先を表します。このような状況での加入者の取り扱いについては、セクション4.4.9を参照してください。
If an initial SUBSCRIBE request is not sent on a pre-existing dialog, the subscriber will wait for a response to the SUBSCRIBE request or a matching NOTIFY.
既存のダイアログで最初の購読要求が送信されない場合、サブスクライバーはサブスクライブリクエストまたは一致する通知への応答を待ちます。
Responses are matched to such SUBSCRIBE requests if they contain the same the same "Call-ID", the same "From" header "tag", and the same "CSeq". Rules for the comparison of these headers are described in SIP [1]. If a 200-class response matches such a SUBSCRIBE request, it creates a new subscription and a new dialog (unless they have already been created by a matching NOTIFY request; see below).
応答は、同じ「call-id」、「ヘッダー」タグから同じ「call-id」、および同じ「CSEQ」と同じ「call-id」を含む場合、そのようなサブスクライブリクエストに一致します。これらのヘッダーを比較するためのルールは、SIP [1]で説明されています。200クラスの応答がこのようなサブスクライブリクエストと一致する場合、新しいサブスクリプションと新しいダイアログが作成されます（一致するNotifyリクエストによって既に作成されていない限り、以下を参照）。
NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header "tag" parameter which matches the "From" header "tag" parameter of the SUBSCRIBE, and the same "Event" header field. Rules for comparisons of the "Event" headers are described in section 7.2.1. If a matching NOTIFY request contains a "Subscription-State" of "active" or "pending", it creates a new subscription and a new dialog (unless they have already been created by a matching response, as described above).
通知リクエストは、サブスクライブの「ヘッダー」タグ "パラメーターと同じ「ヘッダー」タグパラメーターと同じ「イベント」「ヘッダー」と一致する同じ「call-id」、「ヘッダー」タグ"パラメーターを含む場合、そのようなサブスクライブリクエストに一致します。分野。「イベント」ヘッダーの比較の規則については、セクション7.2.1で説明します。一致する通知要求に「アクティブ」または「保留中」の「サブスクリプション状態」が含まれている場合、新しいサブスクリプションと新しいダイアログが作成されます（上記のように、それらが既に一致する応答によって作成されている場合を除く）。
If an initial SUBSCRIBE is sent on a pre-existing dialog, a matching 200-class response or successful NOTIFY request merely creates a new subscription associated with that dialog.
初期サブスクライブが既存のダイアログで送信される場合、一致する200クラスの応答または成功したNotifyリクエストは、そのダイアログに関連付けられた新しいサブスクリプションを作成するだけです。
Multiple subscriptions can be associated with a single dialog. Subscriptions may also exist in dialogs associated with INVITE-created application state and other application state created by mechanisms defined in other specifications. These sets of application state do not interact beyond the behavior described for a dialog (e.g., route set handling).
複数のサブスクリプションは、単一のダイアログに関連付けられます。サブスクリプションは、招待されたアプリケーション状態および他の仕様で定義されたメカニズムによって作成されたその他のアプリケーション状態に関連付けられたダイアログにも存在する場合があります。これらのアプリケーション状態のセットは、ダイアログ（例：ルートセット処理）について説明されている動作を超えて相互作用しません。
A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated".
[終了]の「サブスクリプション状態」で通知者が通知要求を送信すると、サブスクリプションが破壊されます。
A subscriber may send a SUBSCRIBE request with an "Expires" header of 0 in order to trigger the sending of such a NOTIFY request; however, for the purposes of subscription and dialog lifetime, the subscription is not considered terminated until the NOTIFY with a "Subscription-State" of "terminated" is sent.
サブスクライバーは、そのような通知要求の送信をトリガーするために、0の「有効期限」ヘッダーを含むサブスクライブリクエストを送信する場合があります。ただし、サブスクリプションとダイアログの寿命の目的のために、サブスクリプションは、「終了」の「サブスクリプション状態」が送信されるまでの通知が送信されるまで終了するとは見なされません。
If a subscription's destruction leaves no other application state associated with the dialog, the dialog terminates. The destruction of other application state (such as that created by an INVITE) will not terminate the dialog if a subscription is still associated with that dialog.
サブスクリプションの破壊がダイアログに関連する他のアプリケーション状態を残していない場合、ダイアログは終了します。サブスクリプションがまだそのダイアログに関連付けられている場合、他のアプリケーション状態（招待によって作成されたものなど）の破壊はダイアログを終了しません。
Note that the above behavior means that a dialog created with an INVITE does not necessarily terminate upon receipt of a BYE. Similarly, in the case that several subscriptions are associated with a single dialog, the dialog does not terminate until all the subscriptions in it are destroyed.
上記の動作は、招待状で作成されたダイアログが、さようならを受け取ったときに必ずしも終了しないことを意味することに注意してください。同様に、いくつかのサブスクリプションが単一のダイアログに関連付けられている場合、ダイアログはすべてのサブスクリプションが破壊されるまで終了しません。
When state agents (see section 4.4.11.) are used, it is often useful to allow migration of subscriptions between state agents and the nodes for which they are providing state aggregation (or even among various state agents). Such migration may be effected by sending a NOTIFY message with a "Subscription-State" header of "terminated", and a reason parameter of "deactivated". This NOTIFY request is otherwise normal, and is formed as described in section 3.2.2.
州のエージェント（セクション4.4.11を参照）を使用する場合、州のエージェントと州の集約を提供しているノード（またはさまざまな州のエージェント間）の間のサブスクリプションの移行を許可することがしばしば役立ちます。このような移行は、「終了」の「サブスクリプション状態」ヘッダーと「非アクティブ化」の理由パラメーターを含むNotifyメッセージを送信することにより行われる場合があります。この通知要求はそれ以外の場合は正常であり、セクション3.2.2で説明されているように形成されます。
Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to re-subscribe (as described in the preceding sections). Note that this subscription is established on a new dialog, and does not re-use the route set from the previous subscription dialog.
この通知メッセージを受信すると、サブスクライバーは（前のセクションで説明されているように）再登録を試みる必要があります。このサブスクリプションは新しいダイアログで確立されており、以前のサブスクリプションダイアログからルートセットを再利用しないことに注意してください。
The actual migration is effected by making a change to the policy (such as routing decisions) of one or more servers to which the SUBSCRIBE request will be sent in such a way that a different node ends up responding to the SUBSCRIBE request. This may be as simple as a change in the local policy in the notifier from which the subscription is migrating so that it serves as a proxy or redirect server instead of a notifier.
実際の移行は、1つ以上のサーバーのポリシー（ルーティング決定など）を変更することで行われます。これにより、サブスクライブリクエストが別のノードが最終的にサブスクライブリクエストに応答するように送信されます。これは、サブスクリプションが移行している通知者のローカルポリシーの変更と同じくらい簡単である可能性があり、通知者の代わりにプロキシまたはリダイレクトサーバーとして機能するようになります。
Whether, when, and why to perform notifier migrations may be described in individual event packages; otherwise, such decisions are a matter of local notifier policy, and are left up to individual implementations.
通知者の移行を実行するかどうか、いつ、そしてその理由は、個々のイベントパッケージで説明できるかどうか。それ以外の場合、そのような決定はローカル宛先ポリシーの問題であり、個々の実装に委ねられています。
A natural consequence of the behavior described in the preceding sections is that an immediate fetch without a persistent subscription may be effected by sending a SUBSCRIBE with an "Expires" of 0.
前のセクションで説明されている動作の自然な結果は、0の「有効期限が切れる」とサブスクライブを送信することにより、永続的なサブスクリプションのない即時フェッチが影響を受ける可能性があることです。
Of course, an immediate fetch while a subscription is active may be effected by sending a SUBSCRIBE with an "Expires" equal to the number of seconds remaining in the subscription.
もちろん、サブスクリプションがアクティブになっている間に即時フェッチは、サブスクリプションに残っている秒数に等しい「有効期限」のサブスクライブを送信することで行われる場合があります。
Upon receipt of this SUBSCRIBE request, the notifier (or notifiers, if the SUBSCRIBE request was forked) will send a NOTIFY request containing resource state in the same dialog.
このサブスクライブリクエストを受信すると、通知者（または通知者、サブスクライブリクエストがフォークされた場合）は、同じダイアログにリソース状態を含む通知リクエストを送信します。
Note that the NOTIFY messages triggered by SUBSCRIBE messages with "Expires" headers of 0 will contain a "Subscription-State" value of "terminated", and a "reason" parameter of "timeout".
0の「有効期限」のヘッダーを含むサブスクライブメッセージによってトリガーされたNotifyメッセージには、「終了」の「サブスクリプション」値と「理由」パラメーターが「タイムアウト」の「理由」パラメーターが含まれていることに注意してください。
Polling of event state can cause significant increases in load on the network and notifiers; as such, it should be used only sparingly. In particular, polling SHOULD NOT be used in circumstances in which it will typically result in more network messages than long-running subscriptions.
イベント状態のポーリングは、ネットワークおよび通知者の負荷の大幅な増加を引き起こす可能性があります。そのため、控えめに使用する必要があります。特に、ポーリングは、通常、長期にわたるサブスクリプションよりも多くのネットワークメッセージをもたらす状況で使用すべきではありません。
When polling is used, subscribers SHOULD attempt to cache authentication credentials between polls so as to reduce the number of messages sent.
投票を使用する場合、加入者は、送信されるメッセージの数を減らすために、投票間の認証資格情報をキャッシュしようとする必要があります。
The "Allow-Events" header, if present, includes a list of tokens which indicates the event packages supported by the client (if sent in a request) or server (if sent in a response). In other words, a node sending an "Allow-Events" header is advertising that it can process SUBSCRIBE requests and generate NOTIFY requests for all of the event packages listed in that header.
「Allow-Events」ヘッダーには、存在する場合、クライアントがサポートするイベントパッケージ（リクエストで送信された場合）またはサーバー（応答で送信された場合）を示すトークンのリストが含まれています。言い換えれば、「Allow-Events」ヘッダーを送信するノードは、そのヘッダーにリストされているすべてのイベントパッケージのリクエストを処理し、Notifyリクエストを生成できるという広告です。
Any node implementing one or more event packages SHOULD include an appropriate "Allow-Events" header indicating all supported events in all methods which initiate dialogs and their responses (such as INVITE) and OPTIONS responses.
1つ以上のイベントパッケージを実装するノードには、ダイアログとその応答（招待など）とオプションの応答を開始するすべての方法でサポートされているすべてのイベントを示す適切な「Allow-Ivents」ヘッダーを含める必要があります。
This information is very useful, for example, in allowing user agents to render particular interface elements appropriately according to whether the events required to implement the features they represent are supported by the appropriate nodes.
この情報は、たとえば、ユーザーエージェントが特定のインターフェイス要素を適切にレンダリングできるようにすることで非常に便利です。それらが表す機能を実装するために必要なイベントが適切なノードでサポートされているかどうかに応じて。
Note that "Allow-Events" headers MUST NOT be inserted by proxies.
「Allow-Ivents」ヘッダーをプロキシによって挿入してはならないことに注意してください。
The "Event" header is considered mandatory for the purposes of this document. However, to maintain compatibility with PINT (see [2]), servers MAY interpret a SUBSCRIBE request with no "Event" header as requesting a subscription to PINT events. If a server does not support PINT, it SHOULD return "489 Bad Event" to any SUBSCRIBE messages without an "Event" header.
「イベント」ヘッダーは、このドキュメントの目的のために必須と見なされます。ただし、パイントとの互換性を維持するため（[2]を参照）、サーバーはパイントイベントのサブスクリプションを要求する「イベント」ヘッダーなしでサブスクライブリクエストを解釈する場合があります。サーバーがパイントをサポートしていない場合、「イベント」ヘッダーなしで「489 Bad Event」をサブスクライブメッセージに返す必要があります。
This section covers several issues which should be taken into consideration when event packages based on SUBSCRIBE and NOTIFY are proposed.
このセクションでは、購読に基づいてイベントパッケージが提案されている場合に考慮すべきいくつかの問題について説明します。
When designing an event package using the methods described in this document for event notification, it is important to consider: is SIP an appropriate mechanism for the problem set? Is SIP being selected because of some unique feature provided by the protocol (e.g., user mobility), or merely because "it can be done?" If you find yourself defining event packages for notifications related to, for example, network management or the temperature inside your car's engine, you may want to reconsider your selection of protocols.
イベント通知のためにこのドキュメントで説明されている方法を使用してイベントパッケージを設計する場合、考慮することが重要です。SIPは問題セットの適切なメカニズムですか？SIPは、プロトコル（ユーザーモビリティなど）によって提供されるユニークな機能のために選択されていますか、それとも単に「それができるのか」という理由だけで選択されていますか？たとえば、ネットワーク管理や車のエンジン内の温度に関連する通知のイベントパッケージを定義している場合は、プロトコルの選択を再検討することをお勧めします。
Those interested in extending the mechanism defined in this document are urged to follow the development of "Guidelines for Authors of SIP Extensions" [7] for further guidance regarding appropriate uses of SIP.
このドキュメントで定義されているメカニズムを拡張することに関心のある人は、SIPの適切な用途に関するさらなるガイダンスについて、「SIP拡張の著者のガイドライン」[7]の開発に従うことが求められます。
Further, it is expected that this mechanism is not to be used in applications where the frequency of reportable events is excessively rapid (e.g., more than about once per second). A SIP network is generally going to be provisioned for a reasonable signalling volume; sending a notification every time a user's GPS position changes by one hundredth of a second could easily overload such a network.
さらに、このメカニズムは、報告可能なイベントの頻度が過度に速い（たとえば、1秒あたり約1回以上）アプリケーションでは使用されないことが予想されます。通常、SIPネットワークは、合理的なシグナリングボリュームのためにプロビジョニングされます。ユーザーのGPS位置が100分の1秒ずつ変更するたびに通知を送信すると、そのようなネットワークを簡単に過負荷する可能性があります。
Normal event packages define a set of state applied to a specific type of resource, such as user presence, call state, and messaging mailbox state.
通常のイベントパッケージは、ユーザーの存在、コール状態、メッセージングメールボックス状態など、特定のタイプのリソースに適用される一連の状態を定義します。
Event template-packages are a special type of package which define a set of state applied to other packages, such as statistics, access policy, and subscriber lists. Event template-packages may even be applied to other event template-packages.
イベントテンプレートパッケージは、統計、アクセスポリシー、サブスクライバーリストなど、他のパッケージに適用される一連の状態を定義する特別なタイプのパッケージです。イベントテンプレートパッケージは、他のイベントテンプレートパッケージにも適用される場合があります。
To extend the object-oriented analogy made earlier, event template-packages can be thought of as templatized C++ packages which must be applied to other packages to be useful.
以前に作成されたオブジェクト指向のアナロジーを拡張するために、イベントテンプレートパッケージは、他のパッケージに適用する必要があるテンプル化されたCパッケージと考えることができます。
The name of an event template-package as applied to a package is formed by appending a period followed by the event template-package name to the end of the package. For example, if a template-package called "winfo" were being applied to a package called "presence", the event token used in "Event" and "Allow-Events" would be "presence.winfo".
パッケージに適用されるイベントテンプレートパッケージの名前は、パッケージの最後にイベントテンプレートパッケージ名を追加することにより形成されます。たとえば、「Winfo」と呼ばれるテンプレートパッケージが「存在感」と呼ばれるパッケージに適用されている場合、「イベント」と「Allow-Ivents」で使用されるイベントトークンは「finess.winfo」になります。
Event template-packages must be defined so that they can be applied to any arbitrary package. In other words, event template-packages cannot be specifically tied to one or a few "parent" packages in such a way that they will not work with other packages.
イベントテンプレートパッケージは、任意のパッケージに適用できるように定義する必要があります。言い換えれば、イベントテンプレートパッケージは、他のパッケージで動作しないように、1つまたはいくつかの「親」パッケージに特に結び付けることはできません。
When designing event packages, it is important to consider the type of information which will be conveyed during a notification.
イベントパッケージを設計するときは、通知中に伝達される情報の種類を考慮することが重要です。
A natural temptation is to convey merely the event (e.g., "a new voice message just arrived") without accompanying state (e.g., "7 total voice messages"). This complicates implementation of subscribing entities (since they have to maintain complete state for the entity to which they have subscribed), and also is particularly susceptible to synchronization problems.
自然な誘惑は、状態（例：「7つの合計音声メッセージ」など）なしで、単にイベント（たとえば、「新しい音声メッセージが到着した」）を伝えることです。これは、購読エンティティの実装を複雑にします（サブスクライブしたエンティティの完全な状態を維持する必要があるため）。また、同期の問題の影響を特に複雑にします。
There are two possible solutions to this problem that event packages may choose to implement.
この問題には、イベントパッケージが実装することを選択する可能性のある2つの解決策があります。
For packages which typically convey state information that is reasonably small (on the order of 1 kb or so), it is suggested that event packages are designed so as to send complete state information when an event occurs.
通常、合理的に小さい状態情報を伝えるパッケージの場合（1 kb程度）、イベントが発生したときに完全な状態情報を送信するように設計されていることが示唆されています。
In some circumstances, conveying the current state alone may be insufficient for a particular class of events. In these cases, the event packages should include complete state information along with the event that occurred. For example, conveying "no customer service representatives available" may not be as useful as conveying "no customer service representatives available; representative sip:46@cs.xyz.int just logged off".
状況によっては、現在の状態だけを伝えることは、特定のクラスのイベントでは不十分である可能性があります。これらの場合、イベントパッケージには、発生したイベントとともに完全な状態情報を含める必要があります。たとえば、「利用可能なカスタマーサービスの代表者」を伝えることは、「カスタマーサービスの代表者は利用できない。
In the case that the state information to be conveyed is large, the event package may choose to detail a scheme by which NOTIFY messages contain state deltas instead of complete state.
伝達される状態情報が大きい場合、イベントパッケージは、通知が完全な状態ではなく状態デルタを含むスキームを詳細に詳細にすることができます。
Such a scheme would work as follows: any NOTIFY sent in immediate response to a SUBSCRIBE contains full state information. NOTIFY messages sent because of a state change will contain only the state information that has changed; the subscriber will then merge this information into its current knowledge about the state of the resource.
このようなスキームは次のように機能します。購読に即座に応答して送信された通知には、完全な状態情報が含まれています。州の変更のために送信されたメッセージの通知には、変更された州の情報のみが含まれます。サブスクライバーは、この情報をリソースの状態に関する現在の知識に統合します。
Any event package that supports delta changes to states MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription. Note that the state version number appears in the body of the message, not in a SIP header.
州へのデルタの変更をサポートするイベントパッケージには、サブスクリプションの通知トランザクションごとに1つだけ増加するバージョン番号を含める必要があります。SIPヘッダーではなく、メッセージの本文に状態バージョン番号が表示されることに注意してください。
If a NOTIFY arrives that has a version number that is incremented by more than one, the subscriber knows that a state delta has been missed; it ignores the NOTIFY message containing the state delta (except for the version number, which it retains to detect message loss), and re-sends a SUBSCRIBE to force a NOTIFY containing a complete state snapshot.
複数のバージョン番号を持つ通知が到着した場合、加入者は州のデルタが見逃されていることを知っています。State Deltaを含むNotifyメッセージ（メッセージの損失を検出するために保持されるバージョン番号を除く）を無視し、完全な状態スナップショットを含む通知を強制するようにサブスクライブを再送信します。
Event packages are not required to reiterate any of the behavior described in this document, although they may choose to do so for clarity or emphasis. In general, though, such packages are expected to describe only the behavior that extends or modifies the behavior described in this document.
イベントパッケージは、このドキュメントで説明されている動作を繰り返す必要はありませんが、明確さや強調のためにそうすることを選択する場合があります。ただし、一般に、このようなパッケージは、このドキュメントに記載されている動作を拡張または変更する動作のみを記述することが期待されています。
Note that any behavior designated with "SHOULD" or "MUST" in this document is not allowed to be weakened by extension documents; however, such documents may elect to strengthen "SHOULD" requirements to "MUST" strength if required by their application.
このドキュメントの「必須」または「必須」で指定された動作は、拡張ドキュメントによって弱体化することは許可されていないことに注意してください。ただし、そのような文書は、アプリケーションで要求された場合、「必要な」要件を「必要とする」要件を強化することを選択する場合があります。
In addition to the normal sections expected in standards-track RFCs and SIP extension documents, authors of event packages need to address each of the issues detailed in the following subsections, whenever applicable.
標準トラックRFCおよびSIP拡張ドキュメントで予想される通常のセクションに加えて、イベントパッケージの著者は、該当する場合はいつでも、以下のサブセクションで詳述されている各問題に対処する必要があります。
This section, which MUST be present, defines the token name to be used to designate the event package. It MUST include the information which appears in the IANA registration of the token. For information on registering such types, see section 6.
存在する必要があるこのセクションでは、イベントパッケージの指定に使用するトークン名を定義します。トークンのIANA登録に表示される情報を含める必要があります。そのようなタイプの登録については、セクション6を参照してください。
If parameters are to be used on the "Event" header to modify the behavior of the event package, the syntax and semantics of such headers MUST be clearly defined.
イベントパッケージの動作を変更するために「イベント」ヘッダーでパラメーターを使用する場合、そのようなヘッダーの構文とセマンティクスを明確に定義する必要があります。
It is expected that most, but not all, event packages will define syntax and semantics for SUBSCRIBE method bodies; these bodies will typically modify, expand, filter, throttle, and/or set thresholds for the class of events being requested. Designers of event packages are strongly encouraged to re-use existing MIME types for message bodies where practical.
すべてではなく、ほとんどの、しかしすべてではありませんが、サブスクライブメソッドボディの構文とセマンティクスを定義することが期待されています。これらのボディは通常、要求されるイベントのクラスのしきい値を変更、拡張、フィルタリング、スロットル、および/または設定します。イベントパッケージのデザイナーは、実用的なメッセージボディの既存のMIMEタイプを再利用することを強くお勧めします。
This mandatory section of an event package defines what type or types of event bodies are expected in SUBSCRIBE requests (or specify that no event bodies are expected). It should point to detailed definitions of syntax and semantics for all referenced body types.
イベントパッケージのこの必須セクションでは、サブスクライブリクエストで予想されるイベントボディの種類または種類を定義します（または、イベントボディが予想されないことを指定します）。参照されたすべてのボディタイプの構文とセマンティクスの詳細な定義を指し示すはずです。
It is RECOMMENDED that event packages give a suggested range of times considered reasonable for the duration of a subscription. Such packages MUST also define a default "Expires" value to be used if none is specified.
イベントパッケージは、サブスクリプションの期間中、合理的と見なされる推奨範囲の範囲を与えることをお勧めします。このようなパッケージは、何も指定されていない場合に使用するデフォルトの「有効期限」値を定義する必要があります。
The NOTIFY body is used to report state on the resource being monitored. Each package MUST define what type or types of event bodies are expected in NOTIFY requests. Such packages MUST specify or cite detailed specifications for the syntax and semantics associated with such event body.
Notify Bodyは、監視対象のリソースに関する状態を報告するために使用されます。各パッケージは、通知リクエストで予想されるイベントボディの種類または種類を定義する必要があります。このようなパッケージは、そのようなイベント本体に関連する構文とセマンティクスの詳細な仕様を指定または引用する必要があります。
Event packages also MUST define which MIME type is to be assumed if none are specified in the "Accept" header of the SUBSCRIBE request.
イベントパッケージは、サブスクライブリクエストの「受け入れ」ヘッダーに何も指定されていない場合、どのMIMEタイプを想定するかを定義する必要があります。
This section describes the processing to be performed by the notifier upon receipt of a SUBSCRIBE request. Such a section is required.
このセクションでは、購読リクエストを受け取ったときに通知者によって実行される処理について説明します。このようなセクションが必要です。
Information in this section includes details of how to authenticate subscribers and authorization issues for the package. Such authorization issues may include, for example, whether all SUBSCRIBE requests for this package are answered with 202 responses (see section 5.2.).
このセクションの情報には、パッケージの購読者と承認の問題を認証する方法の詳細が含まれています。このような承認の問題には、たとえば、このパッケージのすべての購読要求が202回の応答で回答されるかどうかが含まれる場合があります（セクション5.2を参照）。
This section of an event package describes the process by which the notifier generates and sends a NOTIFY request. This includes detailed information about what events cause a NOTIFY to be sent, how to compute the state information in the NOTIFY, how to generate neutral or fake state information to hide authorization delays and decisions from users, and whether state information is complete or deltas for notifications; see section 4.3. Such a section is required.
イベントパッケージのこのセクションでは、通知者がNotifyリクエストを生成および送信するプロセスについて説明します。これには、どのイベントが送信される原因の原因に関する詳細情報、通知の状態情報を計算する方法、ユーザーからの認可の遅延と決定を非表示にするための中立または偽の状態情報を生成する方法、および州情報が完全またはデルタがあるかどうか通知;セクション4.3を参照してください。このようなセクションが必要です。
This section may optionally describe the behavior used to process the subsequent response.
このセクションでは、後続の応答を処理するために使用される動作についてオプションで説明できます。
This section of an event package describes the process followed by the subscriber upon receipt of a NOTIFY request, including any logic required to form a coherent resource state (if applicable).
イベントパッケージのこのセクションでは、コヒーレントリソース状態（該当する場合）を形成するために必要なロジックを含む、通知リクエストを受信したときにサブスクライバーが続くプロセスについて説明します。
Each event package MUST specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions.
各イベントパッケージは、Forkedサブスクライブリクエストが複数のサブスクリプションをインストールできるかどうかを指定する必要があります。
If such behavior is not allowed, the first potential dialog-establishing message will create a dialog. All subsequent NOTIFY messages which correspond to the SUBSCRIBE message (i.e., match "To", "From", "From" header "tag" parameter, "Call-ID", "CSeq", "Event", and "Event" header "id" parameter) but which do not match the dialog would be rejected with a 481 response. Note that the 200-class response to the SUBSCRIBE can arrive after a matching NOTIFY has been received; such responses might not correlate to the same dialog established by the NOTIFY. Except as required to complete the SUBSCRIBE transaction, such non-matching 200-class responses are ignored.
そのような動作が許可されていない場合、最初の潜在的なダイアログ確立のメッセージがダイアログを作成します。サブスクライブメッセージに対応するすべての後続のメッセージ（つまり、「to」、「from」、「from "header」タグ「パラメーター」、「call-id」、「cseq」、「event」、「event」ヘッダーに対応するメッセージが通知します「id」パラメーター）ただし、ダイアログと一致しないものは、481の応答で拒否されます。サブスクライブに対する200クラスの応答は、一致するNotifyが受信された後に到着できることに注意してください。そのような応答は、Notifyによって確立された同じダイアログと相関しない場合があります。購読トランザクションを完了するために必要な場合を除き、このような一致しない200クラスの応答は無視されます。
If installing of multiple subscriptions by way of a single forked SUBSCRIBE is allowed, the subscriber establishes a new dialog towards each notifier by returning a 200-class response to each NOTIFY. Each dialog is then handled as its own entity, and is refreshed independent of the other dialogs.
単一のフォークサブスクライブを使用して複数のサブスクリプションをインストールすることが許可されている場合、サブスクライバーは、各通知に対する200クラスの応答を返すことにより、各通知者に対する新しいダイアログを確立します。各ダイアログは、独自のエンティティとして処理され、他のダイアログとは無関係に更新されます。
In the case that multiple subscriptions are allowed, the event package MUST specify whether merging of the notifications to form a single state is required, and how such merging is to be performed. Note that it is possible that some event packages may be defined in such a way that each dialog is tied to a mutually exclusive state which is unaffected by the other dialogs; this MUST be clearly stated if it is the case.
複数のサブスクリプションが許可されている場合、イベントパッケージは、単一の状態を形成するために通知をマージするかどうか、およびそのようなマージを実行する方法を指定する必要があります。一部のイベントパッケージは、各ダイアログが他のダイアログの影響を受けない相互に排他的な状態に結び付けられるように定義される可能性があることに注意してください。事実である場合、これは明確に述べられなければなりません。
Each event package is expected to define a requirement (SHOULD or MUST strength) which defines an absolute maximum on the rate at which notifications are allowed to be generated by a single notifier.
各イベントパッケージは、単一の通知者によって通知を生成することが許可されているレートの絶対最大値を定義する要件（強度が必要または必須）を定義することが期待されます。
Each package MAY further define a throttle mechanism which allows subscribers to further limit the rate of notification.
各パッケージは、サブスクライバーが通知率をさらに制限できるようにするスロットルメカニズムをさらに定義する場合があります。
Designers of event packages should consider whether their package can benefit from network aggregation points (state agents) and/or nodes which act on behalf of other nodes. (For example, nodes which provide state information about a resource when such a resource is unable or unwilling to provide such state information itself). An example of such an application is a node which tracks the presence and availability of a user in the network.
イベントパッケージの設計者は、パッケージがネットワーク集約ポイント（状態エージェント）および/または他のノードに代わって機能するノードから利益を得ることができるかどうかを検討する必要があります。（たとえば、そのようなリソースがそのような状態情報自体を提供することができない、または不本意な場合にリソースに関する状態情報を提供するノード）。このようなアプリケーションの例は、ネットワーク内のユーザーの存在と可用性を追跡するノードです。
If state agents are to be used by the package, the package MUST specify how such state agents aggregate information and how they provide authentication and authorization.
州のエージェントをパッケージで使用する場合、パッケージは、そのような州のエージェントが情報をどのように集約するか、および認証と承認を提供する方法を指定する必要があります。
Event packages MAY also outline specific scenarios under which notifier migrations take place.
また、イベントパッケージは、通知者の移行が行われる特定のシナリオの概要も概説する場合があります。
Event packages SHOULD include several demonstrative message flow diagrams paired with several typical, syntactically correct, and complete messages.
イベントパッケージには、いくつかの典型的な、構文的に正しい、完全なメッセージと組み合わせたいくつかの実証メッセージフロー図を含める必要があります。
It is RECOMMENDED that documents describing event packages clearly indicate that such examples are informative and not normative, with instructions that implementors refer to the main text of the document for exact protocol details.
イベントパッケージを説明するドキュメントは、そのような例が有益であり、規範的ではないことを明確に示すことをお勧めします。
Some types of event packages may define state information which is potentially too large to reasonably send in a SIP message. To alleviate this problem, event packages may include the ability to convey a URI instead of state information; this URI will then be used to retrieve the actual state information.
一部のタイプのイベントパッケージは、SIPメッセージを合理的に送信するには大きすぎる可能性がある状態情報を定義する場合があります。この問題を軽減するために、イベントパッケージには、状態情報の代わりにURIを伝える機能が含まれる場合があります。このURIは、実際の状態情報を取得するために使用されます。
The precise mechanisms for conveying such URIs are out of the scope of this document.
このようなURIを伝えるための正確なメカニズムは、このドキュメントの範囲外です。
The ability to accept subscriptions should be under the direct control of the notifier's user, since many types of events may be considered sensitive for the purposes of privacy. Similarly, the notifier should have the ability to selectively reject subscriptions based on the subscriber identity (based on access control lists), using standard SIP authentication mechanisms. The methods for creation and distribution of such access control lists is outside the scope of this document.
サブスクリプションを受け入れる機能は、プライバシーの目的のために多くのタイプのイベントが敏感であると見なされる可能性があるため、通知者のユーザーの直接制御下にある必要があります。同様に、通知者は、標準のSIP認証メカニズムを使用して、サブスクライバーID（アクセス制御リストに基づく）に基づいてサブスクリプションを選択的に拒否する機能を持つ必要があります。このようなアクセス制御リストの作成と配布の方法は、このドキュメントの範囲外です。
The mere act of returning a 200 or certain 4xx and 6xx responses to SUBSCRIBE requests may, under certain circumstances, create privacy concerns by revealing sensitive policy information. In these cases, the notifier SHOULD always return a 202 response. While the subsequent NOTIFY message may not convey true state, it MUST appear to contain a potentially correct piece of data from the point of view of the subscriber, indistinguishable from a valid response. Information about whether a user is authorized to subscribe to the requested state is never conveyed back to the original user under these circumstances.
サブスクライブリクエストに対する200または特定の4xxおよび6xxの応答を返すという単なる行為は、特定の状況では、機密性の高いポリシー情報を明らかにすることにより、プライバシーの懸念を引き起こす可能性があります。これらの場合、Notifierは常に202の応答を返す必要があります。後続の通知メッセージは真の状態を伝えない場合がありますが、有効な応答と区別できない、サブスクライバーの観点から潜在的に正しいデータを含むように見える必要があります。ユーザーが要求された状態を購読する権限を与えられているかどうかに関する情報は、これらの状況下で元のユーザーに戻されることはありません。
Individual packages and their related documents for which such a mode of operation makes sense can further describe how and why to generate such potentially correct data. For example, such a mode of operation is mandated by RFC 2779 [6] for user presence information.
このような操作モードが理にかなっている個々のパッケージとその関連ドキュメントは、そのような潜在的に正しいデータを生成する方法と理由をさらに説明できます。たとえば、このような動作モードは、ユーザーの存在情報についてRFC 2779 [6]によって義務付けられています。
The current model (one SUBSCRIBE request triggers a SUBSCRIBE response and one or more NOTIFY requests) is a classic setup for an amplifier node to be used in a smurf attack.
現在のモデル（1つの購読要求がサブスクライブ応答をトリガーし、1つ以上の通知リクエストをトリガーします）は、スマーフ攻撃で使用されるアンプノードの古典的なセットアップです。
Also, the creation of state upon receipt of a SUBSCRIBE request can be used by attackers to consume resources on a victim's machine, rendering it unusable.
また、購読要求を受け取ったときに州の作成は、攻撃者が被害者のマシンでリソースを消費するために使用することができ、使用できません。
To reduce the chances of such an attack, implementations of notifiers SHOULD require authentication. Authentication issues are discussed in SIP [1].
このような攻撃の可能性を減らすには、宛先の実装が認証を必要とするはずです。認証の問題は、SIP [1]で説明されています。
Replaying of either SUBSCRIBE or NOTIFY can have detrimental effects.
サブスクライブまたは通知のいずれかのリプレイは、有害な効果をもたらす可能性があります。
In the case of SUBSCRIBE messages, attackers may be able to install any arbitrary subscription which it witnessed being installed at some point in the past. Replaying of NOTIFY messages may be used to spoof old state information (although a good versioning mechanism in the body of the NOTIFY messages may help mitigate such an attack). Note that the prohibition on sending NOTIFY messages to nodes which have not subscribed to an event also aids in mitigating the effects of such an attack.
購読メッセージの場合、攻撃者は、過去のある時点でインストールされているのが目撃された任意のサブスクリプションをインストールできる場合があります。通知メッセージの再生は、古い状態情報をスプーフィングするために使用される場合があります（ただし、Notifyメッセージの本体の優れたバージョンメカニズムは、そのような攻撃を軽減するのに役立つ場合があります）。イベントにサブスクライブしていないノードに通知メッセージを送信することの禁止は、そのような攻撃の影響を軽減するのにも役立つことに注意してください。
To prevent such attacks, implementations SHOULD require authentication with anti-replay protection. Authentication issues are discussed in SIP [1].
このような攻撃を防ぐために、実装はレプレイ防止を伴う認証が必要です。認証の問題は、SIP [1]で説明されています。
Even with authentication, man-in-the-middle attacks using SUBSCRIBE may be used to install arbitrary subscriptions, hijack existing subscriptions, terminate outstanding subscriptions, or modify the resource to which a subscription is being made. To prevent such attacks, implementations SHOULD provide integrity protection across "Contact", "Route", "Expires", "Event", and "To" headers of SUBSCRIBE messages, at a minimum. If SUBSCRIBE bodies are used to define further information about the state of the call, they SHOULD be included in the integrity protection scheme.
認証があっても、サブスクライブを使用した中間の攻撃を使用して、任意のサブスクリプションをインストールしたり、既存のサブスクリプションをハイジャックしたり、未払いサブスクリプションを終了したり、サブスクリプションが作成されているリソースを変更したりすることができます。このような攻撃を防ぐために、実装は「連絡先」、「ルート」、「有効期限」、「イベント」、および「「イベント」から「」のヘッダーを最小限に抑えて整合性保護を提供する必要があります。サブスクライブボディを使用して、コールの状態に関するさらなる情報を定義する場合、整合性保護スキームに含める必要があります。
Man-in-the-middle attacks may also attempt to use NOTIFY messages to spoof arbitrary state information and/or terminate outstanding subscriptions. To prevent such attacks, implementations SHOULD provide integrity protection across the "Call-ID", "CSeq", and "Subscription-State" headers and the bodies of NOTIFY messages.
中間攻撃は、通知メッセージを使用してarbitrary意的な状態情報をスプーフィングしたり、未解決のサブスクリプションを終了しようとする場合もあります。このような攻撃を防ぐために、実装は「Call-ID」、「CSEQ」、および「サブスクリプション状態」ヘッダーとNotifyメッセージの本体全体に整合性保護を提供する必要があります。
Integrity protection of message headers and bodies is discussed in SIP [1].
メッセージヘッダーとボディの整合性保護については、SIP [1]で説明しています。
The state information contained in a NOTIFY message has the potential to contain sensitive information. Implementations MAY encrypt such information to ensure confidentiality.
Notifyメッセージに含まれる状態情報には、機密情報が含まれる可能性があります。実装は、そのような情報を暗号化して機密性を確保する場合があります。
While less likely, it is also possible that the information contained in a SUBSCRIBE message contains information that users might not want to have revealed. Implementations MAY encrypt such information to ensure confidentiality.
可能性は低いですが、購読メッセージに含まれる情報には、ユーザーが明らかにしたくない可能性のある情報が含まれている可能性もあります。実装は、そのような情報を暗号化して機密性を確保する場合があります。
To allow the remote party to hide information it considers sensitive, all implementations SHOULD be able to handle encrypted SUBSCRIBE and NOTIFY messages.
リモートパーティが機密情報を非表示にすることを許可するために、すべての実装は暗号化されたサブスクライブを処理し、メッセージを通知できる必要があります。
The mechanisms for providing confidentiality are detailed in SIP [1].
機密性を提供するためのメカニズムは、SIP [1]で詳しく説明されています。
This document defines an event-type namespace which requires a central coordinating body. The body chosen for this coordination is the Internet Assigned Numbers Authority (IANA).
このドキュメントでは、中央の調整本体を必要とするイベントタイプの名前空間を定義します。この調整のために選ばれた機関は、インターネットが割り当てられた数字の権限（IANA）です。
There are two different types of event-types: normal event packages, and event template-packages; see section 4.2. To avoid confusion, template-package names and package names share the same namespace; in other words, an event template-package MUST NOT share a name with a package.
イベントタイプには、通常のイベントパッケージとイベントテンプレートパッケージの2つの異なるタイプがあります。セクション4.2を参照してください。混乱を避けるために、テンプレートパッケージ名とパッケージ名は同じ名前空間を共有します。言い換えれば、イベントテンプレートパッケージは、パッケージと名前を共有してはなりません。
Following the policies outlined in "Guidelines for Writing an IANA Considerations Section in RFCs" [4], normal event package identification tokens are allocated as First Come First Served, and event template-package identification tokens are allocated on a IETF Consensus basis.
「RFCSでIANAの考慮事項セクションを作成するためのガイドライン」[4]に概説されているポリシーに続いて、通常のイベントパッケージ識別トークンが最初に提供されるように割り当てられ、イベントテンプレートパッケージ識別トークンはIETFコンセンサスベースに割り当てられます。
Registrations with the IANA MUST include the token being registered and whether the token is a package or a template-package. Further, packages MUST include contact information for the party responsible for the registration and/or a published document which describes the event package. Event template-package token registrations MUST include a pointer to the published RFC which defines the event template-package.
IANAへの登録には、登録されているトークンと、トークンがパッケージまたはテンプレートパッケージであるかどうかを含める必要があります。さらに、パッケージには、イベントパッケージを説明する登録および/または公開されたドキュメントを担当する当事者の連絡先情報を含める必要があります。イベントテンプレートパッケージトークン登録には、イベントテンプレートパッケージを定義する公開されたRFCへのポインターを含める必要があります。
Registered tokens to designate packages and template-packages MUST NOT contain the character ".", which is used to separate template-packages from packages.
登録されたトークンパッケージとテンプレートパッケージを指定するためのトークンは、キャラクターを含めてはなりません。「」。これは、パッケージからテンプレートパッケージを分離するために使用されます。
As this document specifies no package or template-package names, the initial IANA registration for event types will be empty. The remainder of the text in this section gives an example of the type of information to be maintained by the IANA; it also demonstrates all five possible permutations of package type, contact, and reference.
このドキュメントはパッケージまたはテンプレートパッケージ名を指定していないため、イベントタイプの最初のIANA登録が空になります。このセクションの残りのテキストは、IANAによって維持される情報の種類の例を示しています。また、パッケージタイプ、連絡先、および参照の5つの可能な順列すべてを示しています。
The table below lists the event packages and template-packages defined in "SIP-Specific Event Notification" [RFC3265]. Each name is designated as a package or a template-package under "Type".
以下の表には、「SIP固有のイベント通知」[RFC3265]で定義されているイベントパッケージとテンプレートパッケージを示します。各名前は、「タイプ」の下のパッケージまたはテンプレートパッケージとして指定されます。
Package Name Type Contact Reference
------------ ---- ------- ---------
example1 package [Roach]
example2 package [Roach] [RFC3265]
example3 package [RFC3265]
example4 template [Roach] [RFC3265]
example5 template [RFC3265]
PEOPLE
------
[Roach] Adam Roach <adam@dynamicsoft.com>
REFERENCES
----------
[RFC3265] Roach, A., "SIP-Specific Event Notification", RFC 3265,
June 2002.
To: ietf-sip-events@iana.org Subject: Registration of new SIP event package
宛先：ietf-sip-events@iana.org件名：新しいSIPイベントパッケージの登録
Package Name:
パッケージ名：
(Package names must conform to the syntax described in section 7.2.1.)
（パッケージ名は、セクション7.2.1で説明した構文に準拠する必要があります。）
Is this registration for a Template Package:
このテンプレートパッケージの登録は次のとおりです。
(indicate yes or no)
（「はい」またはいいえを示します）
Published Specification(s):
公開された仕様：
(Template packages require a published RFC. Other packages may reference a specification when appropriate).
（テンプレートパッケージには公開されたRFCが必要です。他のパッケージは、必要に応じて仕様を参照する場合があります）。
Person & email address to contact for further information:
詳細については、連絡先への個人およびメールアドレス：
This document registers three new header field names, described elsewhere in this document. These headers are defined by the following information, which is to be added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは、このドキュメントの他の場所で説明されている3つの新しいヘッダーフィールド名を登録します。これらのヘッダーは、http://www.iana.org/assignments/sip-parametersに基づいてヘッダーサブレジストリに追加される次の情報で定義されます。
Header Name: Allow-Events Compact Form: u Header Name: Subscription-State Compact Form: (none)
ヘッダー名：Allow-Eventsコンパクトフォーム：Uヘッダー名：サブスクリプションステートコンパクトフォーム：（なし）
Header Name: Event Compact Form: o
ヘッダー名：イベントコンパクトフォーム：o
This document registers two new response codes. These response codes are defined by the following information, which is to be added to the method and response-code sub-registry under http://www.iana.org/assignments/sip-parameters.
このドキュメントは、2つの新しい応答コードを登録します。これらの応答コードは、次の情報によって定義されます。これは、http：//www.iana.org/assignments/sip-parametersに基づいてメソッドおよび応答コードサブレジストリに追加されます。
Response Code Number: 202 Default Reason Phrase: Accepted
応答コード番号：202デフォルトの理由フレーズ：受け入れられました
Response Code Number: 489 Default Reason Phrase: Bad Event
応答コード番号：489デフォルトの理由フレーズ：悪いイベント
This section describes the syntax extensions required for event notification in SIP. Semantics are described in section 3. Note that the formal syntax definitions described in this document are expressed in the ABNF format used in SIP [1], and contain references to elements defined therein.
このセクションでは、SIPでのイベント通知に必要な構文拡張機能について説明します。セマンティクスについては、セクション3で説明します。このドキュメントで説明されている正式な構文定義は、SIP [1]で使用されているABNF形式で表現され、そこに定義された要素への参照が含まれていることに注意してください。
This document describes two new SIP methods: SUBSCRIBE and NOTIFY.
このドキュメントでは、2つの新しいSIPメソッドについて説明します：購読と通知。
This table expands on tables 2 and 3 in SIP [1].
この表は、SIP [1]の表2および3で展開されます。
Header Where SUB NOT
------ ----- --- ---
Accept R o o
Accept 2xx - -
Accept 415 o o
Accept-Encoding R o o
Accept-Encoding 2xx - -
Accept-Encoding 415 o o
Accept-Language R o o
Accept-Language 2xx - -
Accept-Language 415 o o
Alert-Info R - -
Alert-Info 180 - -
Allow R o o
Allow 2xx o o
Allow r o o
Allow 405 m m
Authentication-Info 2xx o o
Authorization R o o
Call-ID c m m
Contact R m m
Contact 1xx o o
Contact 2xx m o
Contact 3xx m m
Contact 485 o o
Content-Disposition o o
Content-Encoding o o
Content-Language o o
Content-Length t t
Content-Type * *
CSeq c m m
Date o o
Error-Info 300-699 o o
Expires o -
Expires 2xx m -
From c m m
In-Reply-To R - -
Max-Forwards R m m
Min-Expires 423 m -
MIME-Version o o
Organization o -
Priority R o -
Proxy-Authenticate 407 m m
Proxy-Authorization R o o
Proxy-Require R o o
RAck R - -
Record-Route R o o
Record-Route 2xx,401,484 o o
Reply-To - -
Require o o
Retry-After 404,413,480,486 o o
Retry-After 500,503 o o
Retry-After 600,603 o o
Route R c c
RSeq 1xx o o
Server r o o
Subject R - -
Supported R o o
Supported 2xx o o
Timestamp o o
To c(1) m m
Unsupported 420 o o
User-Agent o o
Via c m m
Warning R - o
Warning r o o
WWW-Authenticate 401 m m
"SUBSCRIBE" is added to the definition of the element "Method" in the SIP message grammar.
「購読」は、SIPメッセージ文法の要素「メソッド」の定義に追加されます。
Like all SIP method names, the SUBSCRIBE method name is case sensitive. The SUBSCRIBE method is used to request asynchronous notification of an event or set of events at a later time.
すべてのSIPメソッド名と同様に、サブスクライブメソッド名はケースに敏感です。購読メソッドは、後でイベントまたは一連のイベントの非同期通知を要求するために使用されます。
"NOTIFY" is added to the definition of the element "Method" in the SIP message grammar.
「Notify」は、SIPメッセージ文法の要素「メソッド」の定義に追加されます。
The NOTIFY method is used to notify a SIP node that an event which has been requested by an earlier SUBSCRIBE method has occurred. It may also provide further details about the event.
Notifyメソッドは、以前の購読メソッドによって要求されたイベントが発生したことをSIPノードに通知するために使用されます。また、イベントに関する詳細を提供する場合があります。
This table expands on tables 2 and 3 in SIP [1], as amended by the changes described in section 7.1.
この表は、セクション7.1で説明されている変更によって修正されているように、SIP [1]の表2および3で展開されます。
Header field where proxy ACK BYE CAN INV OPT REG PRA SUB NOT
-----------------------------------------------------------------
Allow-Events R o o - o o o o o o
Allow-Events 2xx - o - o o o o o o
Allow-Events 489 - - - - - - - m m
Event R - - - - - - - m m
Subscription-State R - - - - - - - - m
Event is added to the definition of the element "message-header" in the SIP message grammar.
イベントは、SIPメッセージ文法の要素「メッセージヘッダー」の定義に追加されます。
For the purposes of matching responses and NOTIFY messages with SUBSCRIBE messages, the event-type portion of the "Event" header is compared byte-by-byte, and the "id" parameter token (if present) is compared byte-by-byte. An "Event" header containing an "id" parameter never matches an "Event" header without an "id" parameter. No other parameters are considered when performing a comparison.
応答を一致させる目的で、メッセージをサブスクライブメッセージで通知するために、「イベント」ヘッダーのイベントタイプの部分がバイトごとに比較され、「id」パラメータートークン（存在する場合）はバイトごとに比較されます。。「ID」パラメーターを含む「イベント」ヘッダーは、「ID」パラメーターなしで「イベント」ヘッダーと一致することはありません。比較を実行するときに他のパラメーターは考慮されません。
Note that the forgoing text means that "Event: foo; id=1234" would match "Event: foo; param=abcd; id=1234", but not "Event: foo" (id does not match) or "Event: Foo; id=1234" (event portion does not match).
上訴テキストは、「event：foo; id = 1234」がイベントに一致することを意味することに注意してください：foo; param = abcd; id = 1234 "が「イベント：foo」（idが一致しない）または「イベント：foo; id = 1234 "（イベント部分が一致しません）。
This document does not define values for event-types. These values will be defined by individual event packages, and MUST be registered with the IANA.
このドキュメントは、イベントタイプの値を定義しません。これらの値は、個々のイベントパッケージによって定義され、IANAに登録する必要があります。
There MUST be exactly one event type listed per event header. Multiple events per message are disallowed.
イベントヘッダーごとに1つのイベントタイプがリストされている必要があります。メッセージごとの複数のイベントは許可されていません。
Allow-Events is added to the definition of the element "general-header" in the SIP message grammar. Its usage is described in section 3.3.7.
Allow-Iventsは、SIPメッセージ文法の要素「一般的なヘッダー」の定義に追加されます。その使用法は、セクション3.3.7で説明されています。
Subscription-State is added to the definition of the element "request-header" in the SIP message grammar. Its usage is described in section 3.2.4.
SIPメッセージ文法の要素「リクエストヘッダー」の定義にサブスクリプションステートが追加されます。その使用法は、セクション3.2.4で説明されています。
The 202 response is added to the "Success" header field definition. "202 Accepted" has the same meaning as that defined in HTTP/1.1 [3].
202の応答は、「成功」ヘッダーフィールド定義に追加されます。「202は受け入れられた」という意味は、HTTP/1.1 [3]で定義されているものと同じ意味を持っています。
The 489 event response is added to the "Client-Error" header field definition. "489 Bad Event" is used to indicate that the server did not understand the event package specified in a "Event" header field.
489のイベント応答は、「クライアントエラー」ヘッダーフィールド定義に追加されます。「489 Bad Event」は、サーバーが「イベント」ヘッダーフィールドで指定されたイベントパッケージを理解していないことを示すために使用されます。
The Augmented BNF definitions for the various new and modified syntax elements follows. The notation is as used in SIP [1], and any elements not defined in this section are as defined in SIP and the documents to which it refers.
さまざまな新しい修正された構文要素の拡張BNF定義が続きます。表記はSIP [1]で使用されているとおりであり、このセクションで定義されていない要素は、SIPおよびそれが参照するドキュメントで定義されているとおりです。
SUBSCRIBEm = %x53.55.42.53.43.52.49.42.45 ; SUBSCRIBE in caps
NOTIFYm = %x4E.4F.54.49.46.59 ; NOTIFY in caps
extension-method = SUBSCRIBEm / NOTIFYm / token
Event = ( "Event" / "o" ) HCOLON event-type
*( SEMI event-param )
event-type = event-package *( "." event-template )
event-package = token-nodot
event-template = token-nodot
token-nodot = 1*( alphanum / "-" / "!" / "%" / "*"
/ "_" / "+" / "`" / "'" / "~" )
event-param = generic-param / ( "id" EQUAL token )
Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type
*(COMMA event-type)
Subscription-State = "Subscription-State" HCOLON substate-value
*( SEMI subexp-params )
substate-value = "active" / "pending" / "terminated"
/ extension-substate
extension-substate = token
subexp-params = ("reason" EQUAL event-reason-value)
/ ("expires" EQUAL delta-seconds)
/ ("retry-after" EQUAL delta-seconds)
/ generic-param
event-reason-value = "deactivated"
/ "probation"
/ "rejected"
/ "timeout"
/ "giveup"
/ "noresource"
/ event-reason-extension
event-reason-extension = token
[1] 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.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、E。Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Petrack, S. and L. Conroy, "The PINT Service Protocol", RFC 2848, June 2000.
[2] Petrack、S。and L. Conroy、「The Pint Service Protocol」、RFC 2848、2000年6月。
[3] 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.
[3] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。and T. Berners-Lee、「HyperText Transfer Protocol-HTTP/1.1」、RFC 2616、1999年6月。
[4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[4] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[5] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[6] Day、M.、Aggarwal、S.、Mohr、G。、およびJ. Vincent、「インスタントメッセージング/存在プロトコル要件」、RFC 2779、2000年2月。
[7] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", Work in Progress.
[7] Rosenberg、J。およびH. Schulzrinne、「SIP拡張の著者のためのガイドライン」、作業中。
[8] Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[8] Schulzrinne、H。およびJ. Rosenberg、「SIP Callerの好みとCallee機能」は進行中です。
Thanks to the participants in the Events BOF at the 48th IETF meeting in Pittsburgh, as well as those who gave ideas and suggestions on the SIP Events mailing list. In particular, I wish to thank Henning Schulzrinne of Columbia University for coming up with the final three-tiered event identification scheme, Sean Olson for miscellaneous guidance, Jonathan Rosenberg for a thorough scrubbing of the -00 draft, and the authors of the "SIP Extensions for Presence" document for their input to SUBSCRIBE and NOTIFY request semantics.
ピッツバーグで開催された第48回IETF会議でのBOFの参加者と、SIPイベントメーリングリストでアイデアや提案をしたイベントの参加者に感謝します。特に、コロンビア大学のヘニング・シュルツリンが、最終的な3段のイベント識別スキーム、その他の指導のためのショーン・オルソン、ジョナサン・ローゼンバーグ、-00ドラフトの徹底的なスクラブ、および「sipipの著者に感謝したいと思います。存在のための拡張機能 "入力のドキュメントは、要求セマンティクスをサブスクライブして通知します。
The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information, consult the online list of claimed rights at http://www.ietf.org/ipr.html
IETFは、このドキュメントに含まれる仕様の一部またはすべてに関して請求された知的財産権について通知されています。詳細については、http：//www.ietf.org/ipr.htmlで請求権のオンラインリストを参照してください
Adam Roach dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
Adam Roach Dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano、TX 75024 USA
EMail: adam@dynamicsoft.com
Voice: sip:adam@dynamicsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（2002）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。