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
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.
著作権（C）インターネット協会（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とインターネットインターネットワーキング（PINT）[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.
サブスクリプションの有効期限が切れていると、その後のSUBSCRIBEメッセージで更新する必要があります。
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]）は、基準セクション内のエントリの一つへの参照を表します。セクション8および9を参照してください。
The all-capital terms "MUST", "SHOULD", "MAY", "SHOULD NOT", "MUST NOT", and "RECOMMENDED" are used as defined in RFC 2119 [5].
RFC 2119で定義されているすべての資本用語 "MUST" は、 "SHOULD NOT"、 "MUST NOT"、および "推奨" 使用されている "MAY"、 "すべきである" [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.
通知：通知は、リソースの状態の加入者に通知するために、加入者にNOTIFYメッセージを送信する通知の行為です。
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.
通知：通知は、リソースの状態の加入者に通知するために、NOTIFYリクエストを生成し、ユーザエージェントです。通知機能はまた、典型的には、サブスクリプションを作成するためのSUBSCRIBEリクエスト受け入れます。
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.
加入者：加入者はノーティファイアからNOTIFYリクエストを受信するユーザ・エージェントです。これらの要求は、加入者が関心を持っているリソースの状態に関する情報が含まれていNOTIFY。加入者はまた、典型的には、SUBSCRIBEリクエストを生成し、サブスクリプションを作成するために、通知者に送信します。
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.
サブスクリプションの移行：サブスクリプションの移行は別の通知に1つの通知からサブスクリプションを移動する行為です。
The SUBSCRIBE method is used to request current state and state updates from a remote node.
SUBSCRIBEメソッドは、リモートノードから現在の状態と状態の更新を要求するために使用されます。
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]で定義された）「有効期限」ヘッダを含むべきであるSUBSCRIBE。この値は、サブスクリプションの期間を示す有効期限が切れます。 「有効期限」ヘッダで通信継続時間を超えて有効なサブスクリプションを維持するために、加入者は、SIPで定義されたものと同じダイアログで新たなSUBSCRIBEメッセージを使用して、定期的にサブスクリプションを更新する必要がある[1]。
If no "Expires" header is present in a SUBSCRIBE request, the implied default is defined by the event package being used.
何ヘッダーがSUBSCRIBEリクエストに存在する「有効期限」場合、暗黙のデフォルトが使用されているイベントパッケージによって定義されていません。
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クラスの応答は、「有効期限」ヘッダを含まなければならないもSUBSCRIBE要求します。応答時間の期間が短くなることがありますが、要求に指定されたよりも長くてはなりません。応答時間は、サブスクリプションの継続時間を定義するものです。
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.
「連絡先」の「期限が切れる」パラメータは、ヘッダーがSUBSCRIBEには意味を持たず、明示的に等価ではないSUBSCRIBEリクエストまたはレスポンスのヘッダー「有効期限」。
A natural consequence of this scheme is that a SUBSCRIBE with an "Expires" of 0 constitutes a request to unsubscribe from an event.
このスキームの自然な結果が0の「有効期限」とSUBSCRIBEということであるイベントからの退会リクエストを構成しています。
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の「有効期限」とSUBSCRIBEメッセージは、状態のフェッチを引き起こします。セクション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).
SUBSCRIBEリクエストのリクエストURIは、最も重要なのは、経路にSIPで概説リクエストルーティング手順に従って適切なエンティティに要求を十分な情報を含んでいる[1]。また、イベント通知を希望するリソースを識別するために十分な情報が含まれているが、必ずしも十分ではない情報が一意にイベントの性質を識別するために（例えば、「SIP：adam@dynamicsoft.comは」のために加入するために、適切なURIになります私のプレゼンス状態;また、私のボイスメールボックスの状態に加入するために、適切な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.
加入者は、まさに彼らが加入しているイベントのどのイベントやクラスに示すSUBSCRIBE要求の内の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.
イベントトークンが対応するイベントパッケージは、そのSUBSCRIBEリクエストのボディに関連付けられた動作を定義している場合、これらのセマンティクスが適用されます。
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]で定義されたリクエストがダイアログを作成するSUBSCRIBEので、それらは「同意する」ヘッダを含むかもしれません。このヘッダーは、存在する場合、後続のNOTIFYリクエストで許可ボディフォーマットを示しています。イベントパッケージは、「同意する」ヘッダーなしSUBSCRIBE要求のための動作を定義しなければなりません。通常、これは、単一の、デフォルトのボディタイプを暗示します。
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].
SUBSCRIBE 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.
加入者は、リソースの特定の状態に加入することを望む場合には、SUBSCRIBEメッセージを形成します。 SUBSCRIBE初期ダイアログの外部要求を表している場合（それ典型的には、のように）、その構造は、ダイアログの外側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.
このSUBSCRIBEリクエストは、最終的な応答で確認されます。 200クラスの応答は、サブスクリプションが受け入れられたことを示しており、すぐに送信されますNOTIFYこと。 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).
SUBSCRIBE 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クラスの最終応答には、サブスクリプションまたはダイアログが作成されていないことを示し、後続のNOTIFYメッセージが送信されません。 （本明細書に記載の「489」を除いて、）すべての非200クラス応答は、同じ意味を有し、SIPで説明したように処理[1]。
A SUBSCRIBE request MAY include an "id" parameter in its "Event" header to allow differentiation between multiple subscriptions in the same dialog.
SUBSCRIBEリクエストは、同じダイアログで複数のサブスクリプションとの間の区別を可能にするために、その「イベント」ヘッダに「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.
サブスクリプションの期限が切れる前に、任意の時点で、加入者は、1つの中に存在した場合、別の既存のサブスクリプションとして、同一の「イベント」ヘッダ、「ID」パラメータ（と同じダイアログでSUBSCRIBEリクエストを送信することによって、そのようなサブスクリプションにタイマーを更新してもよいです最初のサブスクリプション）。そのような要求のための処理は、以下に記載されている場合を除き、サブスクリプションの初期作成の場合と同じです。
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」パラメータが含まSUBSCRIBE場合、サブスクリプションのリフレッシュはまた、同じ「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.)
サブスクリプションをリフレッシュするSUBSCRIBEリクエストは「481」レスポンスを受信した場合、これは、サブスクリプションが終了し、加入者がこの事実の通知を受け取っていないことをされていることを示しています。この場合、加入者は、無効なサブスクリプションを検討すべきです。加入者が状態に再加入することを希望する場合、彼はそう無関係な初期は新たに生成されたコールIDとタグの「From」の新しい、ユニークでSUBSCRIBEリクエストを合成して（セクション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.
サブスクリプションをリフレッシュするSUBSCRIBEリクエストは、非481応答に失敗した場合は、元のサブスクリプションは、まだ最近SUBSCRIBEとその回答によって交渉された値を「有効期限」、またはにNOTIFYによって通信として知られているの期間に有効であると考えられます「サブスクリプション・ステート」ヘッダは、パラメータを「期限が切れます」。
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.
多くのこのようなエラーは、ネットワークに問題またはそれ以上のメッセージが受信されるNOTIFYないような通知があるかもしれないことを示していることに注意してください。
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」に設定して退会は、サブスクリプションのリフレッシュと同じ方法で処理されます。成功退会も最終NOTIFYメッセージをトリガすることに注意してください。
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.
アウトオブオーダーメッセージとフォークの両方のための潜在的に、加入者はSUBSCRIBEトランザクションが完了する前にNOTIFYメッセージを受け取るために準備しなければなりません。
Except as noted above, processing of this NOTIFY is the same as in section 3.2.4.
上述されている場合を除き、このNOTIFYの処理は、セクション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.
プロキシは、[1] SUBSCRIBEサポートするために、SIPに記載したもの以外の追加の動作を必要としません。プロキシが与えられたダイアログのSUBSCRIBEとNOTIFYリクエストのすべてを見たい場合は、レコードルートをしなければならない初期のSUBSCRIBEと任意のダイアログ確立要求を通知します。このようなプロキシは、他のすべてのSUBSCRIBEとNOTIFYリクエストを、記録した経路すべきです。
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].
加入者とノーティファイアはSUBSCRIBEとNOTIFYリクエストの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.
いかなる場合にSUBSCRIBEトランザクションは、自動処理のために必要な時間よりもはやために拡張する必要があります。特に、ノーティファイアはSUBSCRIBEリクエストに対する最終応答を返す前に、ユーザーの応答を待ってはなりません。
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秒を超えてしまうことから、SUBSCRIBEトランザクション中に発射から（[1]を参照）非INVITEトランザクションのタイムアウトタイマーFを防ぐために、主に課されています。
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.
通知は、「イベント」ヘッダで指定されたイベントパッケージが理解されていることを確認する必要があります。そうでない場合、通知は、指定されたイベント/イベントクラスが理解されていないことを示すために、「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].
通知はまた、「有効期限」の期間は、ヘッダが小さすぎないことを確認すること。有効期間は、通知構成最小値よりゼロより大きく1より小さい時間未満である場合にのみ、通知は、「Minは、有効期限」ヘッダフィールドを含む「423間隔が小さすぎる」エラーを返すことがあります。 「ミン期限切れ」ヘッダフィールドは、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.
サブスクリプションが通知で作成されたとき、それは、サブスクリプション情報の一部としてイベントパッケージ名と「イベント」ヘッダ「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.
彼らはREGISTER応答でそうであるようにSUBSCRIBE 200クラスの応答に存在する値は、同じように振る舞う「たExpires」：サーバは間隔を短くするかもしれないが、それが長くてはなりません。
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.
SUBSCRIBEメッセージで指定された時間が許容できないほど短い場合、通知は、前にこのセクションで説明したように、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.
一般的に、サブスクリプション期間を超えた任意の有用な情報が含まれていませんSUBSCRIBE要求する200クラスの応答;彼らの主な目的は、信頼性のメカニズムとして機能することです。状態情報は、通知からの後続のNOTIFYリクエストを介して通信します。
The other response codes defined in SIP [1] may be used in response to SUBSCRIBE requests, as appropriate.
SIP [1]で定義された他のレスポンスコードは、必要に応じて、SUBSCRIBE要求に応答して使用することができます。
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メッセージを送信しなければなりません。このNOTIFYメッセージは、SUBSCRIBE応答によって作成されたものと同じダイアログ上で送信されます。リソースは、SUBSCRIBEメッセージが処理された時点で意味のある状態を持っていない場合は、このNOTIFYメッセージは空または中性体を含むかもしれません。セクション3.2.2を参照してください。 NOTIFYメッセージの生成の詳細について。
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.
NOTIFYメッセージは関係なく、常にサブスクリプションが既に認可されているかどうかの、SUBSCRIBEリクエストに任意の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]。なお、通知ノードは、典型的には、プロキシとして動作しても、SUBSCRIBE要求の認証が常に「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を使用して）通常のプロキシ認証を実行します。以上の説明は、ノーティファイアは常にのUAであり、そのように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.
認証は、アクセスリストまたはその他の自動化されたメカニズム（すなわち、自動的に正式加入者が加入することを許可されていないと判断することができる）に基づいて失敗した場合、通知は「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同意する」応答が即座に返されます。前のセクションで説明したようにNOTIFYメッセージが、形成されており、これらの状況下で送信されることに留意されたいです。
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.
通知は、加入者がまだ承認されていることを仮定して、サブスクリプションの更新を受信すると、通知は、サブスクリプションの有効期限を更新します。最初のサブスクリプションと同じように、サーバが満了するまでの時間を短縮するかもしれないが、それを増加させてはなりません。最終的な有効期限が応答で「期限切れ」ヘッダ内に配置されます。 SUBSCRIBEメッセージで指定された期間が許容できないほど短い場合、通知は「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.
通知アドレスのためのリフレッシュは、その有効期限の前に受信されない場合は、サブスクリプションが削除されます。サブスクリプションを削除する場合は、通知がサブスクリプションが削除されていることを知らせるために、「終了」の「サブスクリプション・ステート」の値でNOTIFYメッセージを送信する必要があります。そのようなメッセージが送信される場合、「サブスクリプション状態」ヘッダは、「理由=タイムアウト」パラメータを含むべきです。
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.
NOTIFYメッセージは、加入者が加入している先の状態の変化の加入者に通知するために送信されます。サブスクリプションは通常SUBSCRIBEメソッドを使用して所定の位置に置かれます。しかし、他の手段が使用されている可能性があります。
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.
任意の非SUBSCRIBEメカニズムはサブスクリプションを作成するために定義されている場合、対応するサブスクリプションにNOTIFYメッセージの相関を確実にするために、これらのメカニズムを定義する当事者の責任であることが可能です。そのような機構の設計者はまた、サブスクリプションを認識している加入者にNOTIFYメッセージを送信し、疑いを持たないノードにNOTIFYメッセージを送信する間の区別を行うことが警告されています。後者の動作は無効であり、（いくつかの他の400-または500クラスのエラーコードは、より適用可能である場合を除く）セクション3.2.4に記載されているように、「481サブスクリプションが存在しない」応答を受信しなければなりません。言い換えれば、サブスクリプションの知識は非SUBSCRIBEメカニズムを介してインストールした場合でも、有効であると加入者と通知の両方に存在している必要があります。
A NOTIFY does not terminate its corresponding subscription; in other words, a single SUBSCRIBE request may trigger several NOTIFY requests.
A NOTIFYそれに対応するサブスクリプションを終了しません。言い換えれば、単一SUBSCRIBEリクエストには、いくつかのNOTIFYリクエストをトリガすることができます。
3.2.1. Identification of Reported Events, Event Classes, and Current State
3.2.1. 報告されたイベント、イベントクラス、および現状の同定
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.
NOTIFY、SUBSCRIBE要求のように「イベント」のヘッダーは、通知が生成されている単一のイベントパッケージ名が含まれています。 「イベント」ヘッダ内のパッケージ名は、対応するSUBSCRIBEメッセージ内の「イベント」ヘッダに一致しなければなりません。 「ID」パラメータは、SUBSCRIBEメッセージ中に存在した場合、それは「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.
イベントパッケージは、そのNOTIFYリクエストのボディに関連付けられた意味を定義します。彼らがそうするならば、これらのセマンティクスが適用されます。 NOTIFY体は、発生したイベントの性質と結果のリソースの状態に関する追加の詳細を提供することが期待されています。
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リクエストのボディには、対応するSUBSCRIBEリクエストのヘッダーを「受諾」に指定された身体のいずれかの形式にフォーマットされなければなりません。この体が加入資源の状態又は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.
SUBSCRIBEリクエストが200クラスの応答と回答された場合、通知はすぐに構築し、加入者にNOTIFYリクエストを送らなければなりません。加入状態の変化が発生した場合、通知はすぐに構築し、認可、ローカルポリシー、およびスロットリングの考慮の対象とNOTIFYリクエストを送るべきです。
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リクエストが実行応答時間あれば失敗、または非200クラス応答コードがない「リトライ後」ヘッダと要求を再試行するために撮影することができない暗黙さらなるアクション（例えば、「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.
タイムアウト状態に（上記で定義した通り）、およびサブスクリプション（例えばSUBSCRIBEなど）ソフトステートメカニズムを使用してインストールされたNOTIFYリクエストが失敗した場合、通知は、サブスクリプションを削除してください。
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.
ソフトステートメカニズムを使用してエラーにより応答に（上記で定義した通り）NOTIFYリクエストが失敗し、サブスクリプションがインストールされた場合、通知は、対応するサブスクリプションを削除する必要があります。
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.
通知エラー応答は、一般的に何かが加入者または加入者に途中でいくつかのプロキシと間違っていることを示します。加入者が誤りである場合には、エラー条件が処理された後、加入者が（再加入することによって）状況を是正することを可能にするために、最も理にかなっています。プロキシが誤りである場合は、定期的にネットワークの問題が解決された後のリフレッシュは、サブスクリプションの状態を再インストールしますSUBSCRIBE。
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).
NOTIFYリクエストが481応答を受信した場合、通知は、サブスクリプションが（例えば、管理インターフェースのような）非SUBSCRIBEによってインストールされた場合でも、対応するサブスクリプションを削除する必要があります。
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.
上記の動作が要求されていなかった場合は、未知のサブスクリプションの通知を受けた加入者には通知し、また、サブスクリプションを削除するSUBSCRIBEリクエストを送信するに応じて、エラーステータスコードを送信する必要があります。この動作は、サービス拒否攻撃でアンプとして使用するための加入者が利用できるようになるので、我々は代わりに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.
「サブスクリプション状態」ヘッダの値が「アクティブ」または「保留中」である場合、通知はまた、サブスクリプションの残り時間を示すパラメータを「満了する」ヘッダ「サブスクリプションの状態」に含めるべきです。通知は、サブスクリプションを短縮するために、このメカニズムを使用することができます。しかし、このメカニズムは、サブスクリプションを長くするために使用してはいけません。
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.
SUBSCRIBEフォークに対する応答が加入者によって受信されなくてもよいので、アクティブおよび保留中のサブスクリプションの有効期限情報を含むことは、SUBSCRIBEリクエストフォーク場合に有用です。この値は、「サブスクリプション・ステート」ヘッダのパラメータ、ヘッダ「有効期限」ではない「期限が切れる」ことにも注意してください。
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.
「サブスクリプション・ステート」ヘッダの値が「終了」した場合、通知は「理由」パラメータを含めるべきです。通知はまた、適切な「リトライ-後に」パラメータを含むことができます。値の詳細と「理由」の意味と「リトライ・後」のパラメータについては、セクション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.
プロキシは、[1] NOTIFYサポートするために、SIPに記載したもの以外の追加の動作を必要としません。プロキシが与えられたダイアログのSUBSCRIBEとNOTIFYリクエストのすべてを見たい場合は、レコードルートをしなければならない初期のSUBSCRIBEと任意のダイアログ確立要求を通知します。このようなプロキシは、他のすべてのSUBSCRIBEとNOTIFYリクエストを、記録した経路すべきです。
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].
加入者とノーティファイアはSUBSCRIBEとNOTIFYリクエストの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.)
NOTIFY要求を受信すると、加入者は、その優れたサブスクリプションの少なくとも一つと一致することを確認しなければなりません。いない場合、それは別の400-または500クラスの応答がより適切でない限り、「481のサブスクリプションが存在しません」応答返さなければなりません。新しいダイアログを作成するサブスクリプションとNOTIFYリクエストをマッチングするための規則はセクション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不良イベント」応答で応答します。
To prevent spoofing of events, NOTIFY requests SHOULD be authenticated, using any defined SIP authentication mechanism.
イベントのなりすましを防ぐために、NOTIFYリクエストは、任意の定義されたSIP認証メカニズムを使用して、認証されるべきです。
NOTIFY requests MUST contain "Subscription-State" headers which indicate the status of the subscription.
NOTIFYリクエストは、サブスクリプションのステータスを示す「サブスクリプション・ステート」ヘッダを含まなければなりません。
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".
非アクティブ：サブスクリプションは終了したが、加入者は、新しいサブスクリプションをすぐに再試行する必要があります。このようなステータスコードの一の主要用途は、ノード間のサブスクリプションの移行を可能にすることです。 「リトライ-後」パラメータが「無効」には意味を持ちません。
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.
ギブアップ：通知がタイムリーに承認を取得できなかったため、サブスクリプションが終了しました。 「リトライ-後」パラメータも存在している場合、クライアントは再サブスクライブを試みる前に、そのパラメータで指定された秒の少なくとも数を待つ必要があります。そうでない場合、クライアントはすぐに再試行するかもしれないが、おそらく保留状態に戻されます。
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リクエストが含まれている場合しかし、彼らは、ヘッダの「同意する」かもしれません。
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]で定義された他の応答はまた、必要に応じて、戻すことができます。いかなる場合にNOTIFYトランザクションは、自動処理のために必要な時間よりもはやために拡張する必要があります。具体的には、加入者はNOTIFYリクエストに対する最終的な応答を返す前に、ユーザーの応答を待ってはなりません。
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].
SUBSCRIBEもなく、NOTIFYどちらが「必要」または「プロキシ要求する」ヘッダの使用を必要と。同様に、「サポート」のヘッダーのために定義されたトークンはありません。必要であれば、クライアントは、[1] SUBSCRIBE及びSIPで定義されたOPTIONS要求を使用してNOTIFYをサポートするためにプローブすることができます。
The presence of the "Allow-Events" header in a message is sufficient to indicate support for SUBSCRIBE and NOTIFY.
「許可・イベント」の存在は、メッセージのヘッダは、SUBSCRIBE及びNOTIFYのためのサポートを示すのに十分です。
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).
問い合わせのための「方法」パラメータも登録する際に、具体的SUBSCRIBEおよびNOTIFYメッセージのサポートを発表するために使用することができます。 （「メソッド」パラメータの詳細については参考文献[8]を参照）。
No semantics are associated with cancelling SUBSCRIBE or NOTIFY.
何の意味がSUBSCRIBEまたは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で定義された非INVITEリクエストをプロキシするためのルールに従って、[1]、成功した要求は唯一200クラス応答を受信するSUBSCRIBE。しかし、フォークのために、サブスクリプションは、複数のノードに受け入れられている可能性があります。 「：を」異なるタグSUBSCRIBE 200クラス応答で受信したタグ：加入者は、したがって、「から」とNOTIFYリクエストを受信するように準備しなければなりません。
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.
複数のNOTIFYメッセージを単一のSUBSCRIBEメッセージに応答して、異なるダイアログボックスで受信される場合、各ダイアログはSUBSCRIBEリクエストがフォークされたために、異なる宛先を表します。このような状況での加入者の取り扱いの詳細については、セクション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.
最初の要求が既存のダイアログ上で送信されていないSUBSCRIBE場合、加入者はNOTIFY SUBSCRIBEリクエストやマッチングへの応答を待ちます。
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).
彼らは同じが含まれている場合の応答は、このようなSUBSCRIBE要求に適合しているのと同じ、同じ「から」ヘッダー「タグ」、および同「のCSeq」「-IDを呼び出します」。これらのヘッダーの比較のためのルールは、SIPに記載されている[1]。 200クラスの応答は、このようなSUBSCRIBEリクエストに一致した場合、それは新しいサブスクリプションと新しいダイアログを作成します（これらはすでにマッチングによって作成されていない限り、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).
彼らは同じ「コールID」、SUBSCRIBEのヘッダの「From」「タグ」パラメータ、および同じ「イベント」ヘッダに一致する「を」ヘッダ「タグ」パラメータが含まれている場合、要求は、このようなSUBSCRIBE要求に適合しているNOTIFYフィールド。 「イベント」のヘッダーの比較のためのルールはセクション7.2.1で説明されています。マッチングは、要求が「アクティブ」または「保留」の「サブスクリプション・ステート」が含まNOTIFY場合は、新しいサブスクリプションと新しいダイアログを（上記のように、彼らはすでに、マッチングの応答によって作成されていない）を作成します。
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クラスの応答を送信するSUBSCRIBEまたは成功した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).
複数のサブスクリプションは、単一のダイアログに関連付けることができます。サブスクリプションはまた、他の仕様で定義されたメカニズムによって作成されたINVITE作成アプリケーションの状態と他のアプリケーションの状態に関連付けられたダイアログで存在してもよいです。アプリケーションの状態のこれらのセットは、ダイアログ（例えば、ルートセットの処理）のために説明した動作を超えて相互作用しません。
A subscription is destroyed when a notifier sends a NOTIFY request with a "Subscription-State" of "terminated".
通知は、「終了」の「サブスクリプション・ステート」とNOTIFYリクエストを送信したときにサブスクリプションが破棄されます。
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.
そのようなNOTIFY要求の送信をトリガするために0のヘッダを「有効期限」と加入者は、SUBSCRIBEリクエストを送信することができます。ただし、サブスクリプション、ダイアログ寿命の目的のために、サブスクリプションが送られ、「終了」の「サブスクリプション・ステート」とNOTIFYまで終了とはみなされません。
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.
サブスクリプションの破壊は、ダイアログに関連した他のアプリケーションの状態を残さない場合は、ダイアログが終了します。サブスクリプションがまだそのダイアログに関連付けられている場合（例えば、INVITEによって作成されたもののような）他のアプリケーション状態の破壊は、ダイアログを終了しないであろう。
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.
上記の動作がINVITEで作成したダイアログが必ずしもBYEの受信時に終了しないことを意味することに注意してください。その中のすべてのサブスクリプションが破壊されるまで同様に、いくつかのサブスクリプションは、単一のダイアログに関連付けられている場合には、ダイアログは終了しません。
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
状態エージェントは、（セクション4.4.11を参照。）が使用される場合、状態剤およびそれらが（たとえ、様々な状態のエージェント間又は）状態の集合を提供しているノード間のサブスクリプションの移行を可能にするためにしばしば有用です。そのような移行は送信することによって行うことができます
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.
「終了」の「サブスクリプション・ステート」ヘッダ、および「無効」の理由パラメータでNOTIFYメッセージを。この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.
（前のセクションで説明したように）、このNOTIFYメッセージを受信すると、加入者が再加入を試みます。このサブスクリプションは、新しいダイアログ上で確立され、以前のサブスクリプションのダイアログからルートセットを再使用しないことに注意してください。
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.
実際の移行は、そのSUBSCRIBEリクエストが異なるノードがSUBSCRIBE要求に応答してしまうような方法で送信される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の「有効期限」とSUBSCRIBE送信することによって行うことができる永続的な加入せずにフェッチすることです。
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.
もちろん、即時は、サブスクリプションがアクティブである間フェッチサブスクリプション内に残っている秒数と等しい「有効期限」とSUBSCRIBEを送信することによって行うことができます。
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.
このSUBSCRIBEリクエストを受信し、通知すると（又は通知機能、SUBSCRIBEリクエストがフォークされた場合）、同じダイアログでリソースの状態を含むNOTIFYリクエストを送信します。
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のヘッダは、「終了」の「サブスクリプション・ステート」値、および「タイムアウト」の「理由」パラメータが含まれています「有効期限」とのSUBSCRIBEメッセージによってトリガメッセージを通知することを注意してください。
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.
「許可・イベント」ヘッダが存在する場合は、クライアント（リクエストで送信された場合）または（応答で送信された場合）、サーバによってサポートされるイベントパッケージを示すトークンのリストを含みます。言い換えれば、「許可 - イベント」を送信ノードは、ヘッダは、それがSUBSCRIBE要求し、そのヘッダに記載されているイベントパッケージのすべてのための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つ以上のイベント・パッケージを実装する任意のノードは、ダイアログおよびそれらの（例えばINVITEなど）応答とOPTIONSの応答を開始するすべての方法でサポートされているすべてのイベントを示す適切な「許可・イベント」ヘッダを含むべきです。
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.
「許可 - イベント」ヘッダーはプロキシが挿入されてはならないことに注意してください。
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]参照）PINTとの互換性を維持するために、サーバは、イベントをPINTへのサブスクリプションを要求するようNO「イベント」ヘッダを持つSUBSCRIBEリクエストを解釈することができます。サーバーがPINTをサポートしていない場合、それは「イベント」ヘッダなしにはSUBSCRIBEメッセージに「489不良イベント」を返すべきです。
This section covers several issues which should be taken into consideration when event packages based on SUBSCRIBE and NOTIFY are proposed.
このセクションでは、SUBSCRIBEとNOTIFYに基づいてイベントパッケージが提案されている時に考慮すべきいくつかの問題をカバーしています。
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の適切な使用に関する更なるガイダンスについては[7]「SIP拡張の作者のためのガイドライン」の開発に追従するように付勢されています。
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ネットワークは、一般的に合理的なシグナリング・ボリュームにプロビジョニングされようとしています。通知に100分の1秒によって、ユーザーのGPS位置の変更は、このようなネットワークを簡単に過負荷になる可能性がありたびに送信します。
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」「プレゼンス」と呼ばれるパッケージ、「イベント」と「許可 - イベント」で使用されるイベントトークンに適用されていた場合は、「presence.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キロバイト程度のオーダーで）合理的に小さい状態情報を伝えるパッケージの場合には、イベントが発生したときに完全な状態情報を送信するようにイベントパッケージが設計されていることが示唆されます。
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".
いくつかの状況において、単独で現在の状態を伝達することは、イベントの特定のクラスには不十分であってもよいです。これらのケースでは、イベントパッケージは、発生したイベントと一緒に完全な状態情報を含むべきです。例えば、「NO顧客サービス担当者が利用できる」搬送する搬送ないほど有用ではないかもしれない、「利用可能な顧客サービス担当者と、代表SIP：46@cs.xyz.intだけログオフ」。
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.
搬送される状態情報が大きい場合には、イベントパッケージを詳細にメッセージが代わりに、完全な状態の状態デルタを含むNOTIFYれるスキームを選択することができます。
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.
次のようにこのような方式は動作します：いずれかがSUBSCRIBEへの即時応答で送信されたNOTIFY満杯状態情報が含まれています。変更されただけの状態情報が含まれていますので、状態変化の送信されたメッセージをNOTIFY。加入者は、リソースの状態に関する現在の知識には、この情報をマージします。
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.
状態にデルタの変更をサポートする任意のイベントパッケージは、サブスクリプションでトランザクションをNOTIFYごとに、正確に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.
NOTIFYは、それが複数のインクリメントされたバージョン番号を持って到着した場合、加入者は状態のデルタが見逃されていることを知っています。それは（それがメッセージの損失を検出するために保持するバージョン番号を除く）状態デルタを含むNOTIFYメッセージを無視し、完全な状態のスナップショットを含むNOTIFY強制するSUBSCRIBE再送信します。
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.
どんな行動がまたはこのドキュメントの拡張文書によって弱体化することを許可されていない「MUST」、「すべきである」と指定されたことに注意してください。しかし、そのような文書は、そのアプリケーションに必要な場合は、「しなければならない」強さ「すべきである」要件を強化するために選ぶことができます。
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.
ほとんどが、すべてではなく、イベントパッケージは、メソッド本体をSUBSCRIBEための構文とセマンティクスを定義することが期待されます。これらの機関は、通常、変更展開し、フィルタ、スロットル、および/または要求されているイベントのクラスのしきい値を設定します。イベントパッケージの設計者は、強くどこ実用的なメッセージボディのために既存の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.
イベントパッケージのこの必須セクションでは、SUBSCRIBE要求（あるいは全くイベント体が期待されていないことを指定）に期待されているどのような種類やイベント体の種類が定義されます。これは、すべての参照のボディタイプのための構文とセマンティクスの詳細な定義を指している必要があります。
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本体は監視されているリソースに状態を報告するために使用されます。各パッケージには、NOTIFYリクエストをして期待されているどのような種類やイベント体のタイプを定義しなければなりません。このようなパッケージには、このようなイベントボディに関連付けられた構文とセマンティクスの詳細な仕様を指定したり、引用しなければなりません。
Event packages also MUST define which MIME type is to be assumed if none are specified in the "Accept" header of the SUBSCRIBE request.
イベントパッケージはまた、いずれもSUBSCRIBEリクエストのヘッダーを「受諾」に指定されていない場合に想定されるべきMIMEタイプを定義しなければなりません。
This section describes the processing to be performed by the notifier upon receipt of a SUBSCRIBE request. Such a section is required.
このセクションでは、SUBSCRIBEリクエストの受信時に通知することによって実行される処理について説明します。このようなセクションが必要です。
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.).
このセクションの情報は、パッケージの加入者と承認の問題を認証する方法の詳細が含まれます。このような認証の問題はすべて、このパッケージのSUBSCRIBEリクエストするかどうかを、例えば、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リクエストを送信するプロセスを記載しています。これは、中の状態情報を計算する方法を、送信するNOTIFY原因何のイベントに関する詳細な情報を含んでいるユーザーからの承認の遅れや判断を隠すために、中性または偽の状態情報を生成する方法を、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).
イベントパッケージのこのセクションでは、コヒーレントリソース状態（該当する場合）を形成するために必要なロジックを含むNOTIFYリクエストを受け取ると、加入者が続く方法を記載しています。
Each event package MUST specify whether forked SUBSCRIBE requests are allowed to install multiple subscriptions.
各イベントパッケージは、SUBSCRIBEフォーク要求が複数のサブスクリプションをインストールするために許可されているかどうかを指定しなければなりません。
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.
そのような行動が許可されていない場合は、第一の電位のダイアログ確立メッセージダイアログを作成します。 SUBSCRIBEメッセージ（すなわち、マッチ「を」、「から」、ヘッダの「From」「タグ」パラメータ、「コールID」を、「のCSeq」、「イベント」、及び「イベント」ヘッダに対応するすべての後続のNOTIFYメッセージダイアログに一致しない「ID」パラメータ）が、481応答で拒否されるだろう。マッチングが受信されたNOTIFY後SUBSCRIBE 200クラス応答が到着することができることに留意されたいです。そのような応答は、NOTIFYによって確立された同じダイアログに相関しない場合があります。 SUBSCRIBEトランザクションを完了するために必要なものを除き、このような非マッチング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.
各イベントパッケージは、通知は、単一の通知によって生成することが許可されている速度に絶対最大値を規定する要件（SHOULDまたはMUST強度）を定義することが期待されます。
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認証メカニズムを使用して、選択的に（アクセス制御リストに基づいて）加入者識別情報に基づいてサブスクリプションを除去する能力を有するべきです。このようなアクセス制御リストの作成と配布のための方法は、この文書の範囲外です。
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.
SUBSCRIBE要求する200または特定の4xxとの6xx応答を返すの単なる行為は、特定の状況下で、機密ポリシー情報を明らかにすることにより、プライバシーの問題を作成することができます。これらのケースでは、通知は、常に202レスポンスを返すべきです。その後のNOTIFYメッセージが真の状態を伝えないかもしれないが、有効な応答と区別できない加入者の観点からデータの潜在的に正確なピースを含むように表示される必要があります。ユーザーが要求された状態に加入することが許可されているかどうかについての情報は、このような状況下で、元のユーザーに戻って伝えされることはありません。
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 [6] 2779によって義務付けられています。
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.
現在のモデル（一方の要求がSUBSCRIBE応答および1つまたは複数のNOTIFY要求をトリガSUBSCRIBE）は、スマーフ攻撃で使用される増幅器ノードのための古典的な設定です。
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.
また、SUBSCRIBEリクエストを受信したときの状態の作成は、それが使用できなくなる、被害者のマシン上のリソースを消費するために攻撃者によって使用することができます。
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.
SUBSCRIBEまたはNOTIFYのいずれかの再生は、有害な影響を持つことができます。
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.
SUBSCRIBEメッセージの場合、攻撃者は、それが過去にいくつかの点に設置されている目撃し、任意のサブスクリプションをインストールすることができるかもしれません。 （NOTIFYメッセージのボディに優れたバージョン管理メカニズムがこのような攻撃を軽減するのに役立つかもしれないが）NOTIFYメッセージの再生が古い状態情報を偽装するために使用することができます。イベントに加入していないノードに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.
でも認証で、SUBSCRIBE使用してman-in-the-middle攻撃は、ハイジャック既存のサブスクリプション、任意のサブスクリプションをインストールするために使用され、優れたサブスクリプションを終了、またはサブスクリプションが行われてされているリソースを変更することができます。このような攻撃を防ぐために、実装は、「連絡先」、「ルート」を越え完全性保護を提供すべきで、「イベント」を「有効期限」、および最低でもSUBSCRIBEメッセージの「へ」のヘッダー。 SUBSCRIBE体がコールの状態に関する更なる情報を定義するために使用されている場合、それらは、完全性保護スキームに含まれるべきです。
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.
man-in-the-middle攻撃はまた、任意の状態情報を偽装するNOTIFYメッセージを使用しようとする、および/または優れたサブスクリプションを終了することができます。このような攻撃を防ぐために、実装は、「のCSeq」、および「サブスクリプション・ステート」「-IDを呼び出し、」ヘッダーおよび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.
可能性が低いが、SUBSCRIBEメッセージに含まれる情報は、ユーザーが明らかになっているしたくないかもしれないという情報が含まれていることも可能です。実装は、機密性を確保するために、このような情報を暗号化してもよいです。
To allow the remote party to hide information it considers sensitive, all implementations SHOULD be able to handle encrypted SUBSCRIBE and NOTIFY messages.
相手はそれが機密と考えられる情報を非表示にできるようにするには、すべての実装は、暗号化されたSUBSCRIBEとNOTIFYメッセージを処理できる必要があります。
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).
この文書は、中央調整機関を必要とするイベント型の名前空間を定義します。この調整のために選ばれたボディは、Internet Assigned Numbers Authority（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.
まず務め、イベントテンプレートパッケージ識別トークンはIETFコンセンサスベースで割り当てられている最初に来るよう「RFCsにIANA問題部に書くためのガイドライン」で概説された方針に続いて、[4]、通常のイベントパッケージ識別トークンが割り当てられています。
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
To：ietf-sip-events@iana.org件名：新しいSIPイベントパッケージの登録
Package Name:
パッケージ名：
(Package names must conform to the syntax described in
section 7.2.1.)
Is this registration for a Template Package:
テンプレートのパッケージのためのこの登録は、次のとおりです。
(indicate yes or no)
（yesまたはnoを示していません）
Published Specification(s):
公開明細書（S）：
(Template packages require a published RFC. Other packages
may reference a specification when appropriate).
Person & email address to contact for further information:
詳細のために連絡する人とEメールアドレス：
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
ヘッダー名：許可 - イベントコンパクト形：U
Header Name: Subscription-State Compact Form: (none)
ヘッダー名：サブスクリプション・ステート・コンパクトなフォーム：（なし）
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のイベント通知に必要な構文の拡張機能について説明します。セマンティクスは、この文書に記載され正式な構文定義はSIP [1]で使用されるABNF形式で表現されていること部3注記に記載されており、その中に定義された要素への参照が含まれています。
This document describes two new SIP methods: SUBSCRIBE and NOTIFY.
この文書では、2つの新しいSIP方法について説明しますSUBSCRIBEとNOTIFY。
This table expands on tables 2 and 3 in SIP [1].
このテーブルは、SIPの表2及び3 [1]に拡張します。
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
2XX ooには、405ミリメートルの認証・情報の2xx OO承認R ooにコール-ID CMMの接触Rのミリメートルお問い合わせの1xx OOコンタクト2XX MO問い合わせの3xxミリメートルお問い合わせ485 OOのContent-処分ooにコンテンツ・エンコーディングooのコンテンツ言語のオブジェクト指向のContent-Lengthを許可ROO許可許可TTのContent-Type * *のCSeq CMM日ooにエラー-情報300から699 OOはO有効期限は - の2xxメートル期限 - CMMから、返信先R - - MIME-バージョンのオブジェクト指向機構 - マックス・フォワードRのmmの423メートルをMinは、有効期限O - 優先R 0 - プロキシ認証407ミリメートルプロキシ許可Rは、オブジェクト指向のR OOラックRをプロキシ要求 - - レコードルートRのオブジェクト指向のレコードルート2XX、401484オブジェクト指向の返信には、 - - リトライ後OO 404413480486 OOリトライ要求 - サポートされているR ooにサポートされているの2xx OOのタイムスタンプOO C（1）mmでサポートされていない420 OO - 500503オブジェクト指向の再試行後600603 OOルートRのCC RSEQ 1XXのOOサーバROO件名R -after
User-Agent o o Via c m m Warning R - o Warning r o o WWW-Authenticate 401 m m
ユーザエージェント、O、C、M mを警告Rを介してO - WWW認証401メートルのM O oをR警告O
"SUBSCRIBE" is added to the definition of the element "Method" in the SIP message grammar.
「SUBSCRIBE」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メソッド名と同様に、SUBSCRIBEメソッド名は大文字と小文字が区別されます。 SUBSCRIBEメソッドは、後で非同期イベントの通知またはイベントのセットを要求するために使用されます。
"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メソッドは、以前のSUBSCRIBEメソッドによって要求されたイベントが発生した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の表2及び3 [1]に拡張します。
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.
SUBSCRIBEメッセージでメッセージを応答に一致し、NOTIFYの目的のため、「イベント」ヘッダのイベント型部分は、バイトごとに比較され、「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).
なお、前述のテキストは、その "イベント：FOO; ID = 1234" を意味していることと一致するだろう "イベントを：FOO; PARAM = ABCD; ID = 1234" ではなく、 "イベント：foo" という（IDが一致しない）または「イベント：フー; 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.
イベントヘッダーごとに列挙された正確に一つのイベントタイプがあるに違いありません。メッセージごとに複数のイベントが許可されていません。
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.
許可・イベントは、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応答は、「成功」ヘッダフィールド定義に追加されます。 [3] HTTP / 1.1で定義されたものと同じ意味を有し、「202が受け入れ」。
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不良イベントは、」サーバーが「イベント」ヘッダフィールドで指定されたイベントパッケージを理解していなかったことを示すために使用されます。
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
SUBSCRIBEm =％x53.55.42.53.43.52.49.42.45。キャップにSUBSCRIBE NOTIFYm =％x4E.4F.54.49.46.59。キャップ拡張方式= SUBSCRIBEm / NOTIFYm /トークンにNOTIFY
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 )
イベント=（「イベント」/「O」）HCOLONイベント型*（SEMIイベントのparam）イベント型=イベントパッケージ*（「」イベントテンプレート）イベント・パッケージ=トークンnodotイベント・テンプレート=トークン-nodotトークンnodot = 1 *（alphanum / " - " "！" / / "％" / "*" / "_" / "+" / "`"/ "'"/ "〜"）イベントのparam = GENERIC-PARAM /（ "ID" EQUALトークン）
Allow-Events = ( "Allow-Events" / "u" ) HCOLON event-type *(COMMA event-type)
許可 - イベント=（「許可 - イベント」/「U」）HCOLONイベント型*（COMMAイベント型）
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
サブスクリプション・ステート= "サブスクリプション・ステート" HCOLONサブ状態値*（SEMI subexp-のparams）サブステート値= "アクティブ" / "保留" / "終了" /拡張サブステート延長-サブステート=トークンsubexp-のparams =（」理由は "EQUALイベント-理由値）/（ "期限が切れる"）EQUALデルタ秒/（ "リトライ-後に" EQUALデルタ秒）/ジェネリック-PARAMイベント-理由-値は= "非アクティブ化"/ "執行猶予"/" 「/ 『タイムアウト』 / 『ギブアップ』 / 『NORESOURCE』 /イベント-理由拡張イベントの理由-延長=トークン拒否
[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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[2] Petrack, S. and L. Conroy, "The PINT Service Protocol", RFC 2848, June 2000.
[2] 2000 Petrackと、S.とL.コンロイ、 "パイントサービスプロトコル"、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]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - 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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[6日目、M.、アガルワル、S.、モール、G。およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[7] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors of SIP Extensions", Work in Progress.
[7]ローゼンバーグ、J.、およびH. Schulzrinneと、 "SIP拡張の作者のためのガイドライン" を、進行中の作業。
[8] Schulzrinne, H. and J. Rosenberg, "SIP Caller Preferences and Callee Capabilities", Work in Progress.
[8] Schulzrinneと、H.およびJ.ローゼンバーグ、 "SIP発信者の設定と呼び出し先機能"、ProgressのWork。
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イベントにアイデアや提案を与えた人たちの参加者に感謝します。特に、私は-00草案の徹底的なスクラブのための最終的な3階層イベント識別方式で、雑多な指導のためのショーン・オルソン、ジョナサン・ローゼンバーグを考え出すためにコロンビア大学のヘニングSchulzrinneとに感謝したい、と「SIPの著者彼らの入力のためのプレゼンス」文書のための拡張機能は、SUBSCRIBEリクエストのセマンティクスに通知します。
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
アダムローチdynamicsoft 5100テニソンパークウェイスイート1200プラノ、TX 75024 USA
EMail: adam@dynamicsoft.com Voice: sip:adam@dynamicsoft.com
電子メール：adam@dynamicsoft.com声：SIP：adam@dynamicsoft.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。