Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 5989 Tekelec
Category: Standards Track October 2010
ISSN: 2070-1721
A SIP Event Package for Subscribing to Changes to an HTTP Resource
HTTPリソースへの変更への登録のためのSIPイベントパッケージ
Abstract
抽象
The Session Initiation Protocol (SIP) is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) servers for a variety of reasons. In many of these cases, applications can benefit from being able to discover, in near real-time, when a specific HTTP resource is created, changed, or deleted. This document proposes a mechanism, based on the SIP Event Framework, for doing so.
セッション開始プロトコル（SIP）は、ますます密様々な理由で、ハイパーテキスト転送プロトコル（HTTP）サーバと接続されているシステムで使用されています。これらのケースの多くでは、アプリケーションは、特定のHTTPリソースが作成、変更、または削除され、ほぼリアルタイムで、発見することができるという恩恵を受けることができます。この文書では、そうするために、SIPイベント・フレームワークに基づいたメカニズムを提案しています。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。インターネット標準の詳細については、RFC 5741のセクション2で利用可能です。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5989.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5989で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Associating Monitoring SIP URIs with HTTP URLs ..................3
3.1. Monitoring a Single HTTP Resource ..........................4
3.2. Monitoring Multiple HTTP Resources .........................5
4. HTTP Change Event Package .......................................6
4.1. Event Package Name .........................................6
4.2. Event Package Parameters ...................................6
4.3. SUBSCRIBE Bodies ...........................................7
4.4. Subscription Duration ......................................7
4.5. NOTIFY Bodies ..............................................8
4.5.1. Use of message/http in HTTP Monitor Event Package ...8
4.6. Notifier Processing of SUBSCRIBE Requests ..................9
4.7. Notifier Generation of NOTIFY Requests .....................9
4.8. Subscriber Processing of NOTIFY Requests ...................9
4.9. Handling of Forked Requests ...............................10
4.10. Rate of Notifications ....................................10
4.11. State Agents .............................................10
5. Example Message Flow ...........................................10
6. Security Considerations ........................................14
7. IANA Considerations ............................................15
7.1. New Link Relations ........................................15
7.1.1. New Link Relation: monitor .........................15
7.1.2. New Link Relation: monitor-group ...................16
7.2. New SIP Event Package: http-monitor .......................16
7.3. New Event Header Field Parameter: body ....................16
8. Acknowledgements ...............................................16
9. References .....................................................17
9.1. Normative References ......................................17
9.2. Informative References ....................................18
Appendix A. Rationale: Other Approaches Considered ...............19
The Session Initiation Protocol (SIP) [3] is increasingly being used in systems that are tightly coupled with Hypertext Transport Protocol (HTTP) [2] servers for a variety of reasons. In many of these cases, applications can benefit from learning of changes to specified HTTP resources in near real-time. For example, user agent terminals may elect to store service-related data in an HTTP tree. When such configuration information is stored and retrieved using HTTP, clients may need to be informed when information changes, so as to make appropriate changes to their local behavior and user interface.
セッション開始プロトコル（SIP）は、[3]、ますます密ハイパーテキスト転送プロトコル（HTTP）に結合されているシステムで使用されている[2]様々な理由のためにサーバ。これらのケースの多くでは、アプリケーションは、ほぼリアルタイムで指定されたHTTPリソースへの変更の学習の恩恵を受けることができます。例えば、ユーザエージェント端末は、HTTPツリー内のサービスに関連するデータを格納することを選択することができます。このような構成情報が格納され、HTTPを使用して取得されたときに情報が変化した場合、ローカル行動およびユーザインタフェースに適切な変更を行うように、クライアントは、通知される必要があるかもしれません。
This document defines a mechanism, based on the SIP Event Framework [4], for subscribing to changes in the resource referenced by an HTTP server. Such subscriptions do not necessarily carry the content associated with the resource. In the cases that the content is not conveyed, the HTTP protocol is still used to transfer the contents of HTTP resources. This document further defines a mechanism by which the proper SIP and/or Session Initiation Protocol Secure (SIPS) URI to be used for such subscriptions can be determined from the HTTP server.
この文書では、HTTPサーバによって参照されるリソースの変更をサブスクライブするために、SIPイベント・フレームワークに基づくメカニズム、[4]を定義します。このようなサブスクリプションは、必ずしもリソースに関連付けられたコンテンツを運びません。コンテンツが搬送されていないと場合には、HTTPプロトコルは依然としてHTTPリソースの内容を転送するために使用されます。この文書は、さらに、適切なSIP及び/又はセッション開始プロトコルセキュア（SIPS）URIをHTTPサーバから決定することができるようなサブスクリプションのために使用すべきメカニズムを定義します。
The capitalized terms "MUST", "SHOULD", "MAY", "SHOULD NOT", and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [1].
大文字用語 "MUST"、 "SHOULD"、 "MAY"、 "SHOULD NOT"、および "MUST NOT" 本書ではRFC 2119に記載されるように解釈されるべきである[1]。
Note that this document discusses both SIP messages and HTTP messages. Because SIP's syntax was heavily based on HTTP's, the components of these messages have similar or identical names. When referring to message payloads, HTTP documents have historically preferred the hyphenated form "message-body", while SIP documents favor the unhyphenated form "message body". This document conforms to both conventions, using the hyphenated form for HTTP, and the unhyphenated form for SIP.
この文書は、SIPメッセージとHTTPメッセージの両方を説明していることに注意してください。 SIPの構文は重くHTTPのに基づいていたので、これらのメッセージのコンポーネントは、類似または同一の名前を持ちます。メッセージペイロードを参照する場合SIP文書はunhyphenatedフォーム「メッセージ本体を」好む一方で、HTTP文書は歴史的に、ハイフン付きのフォーム「メッセージボディ」を優先しています。この文書では、HTTPのためにハイフン形態、およびSIPのためunhyphenatedフォームを使用して、両方の規則に準拠しています。
One of the key challenges in subscribing to the changes of a resource indicated by an HTTP URL is determining which SIP URI corresponds to a specific HTTP URL. This specification takes the approach of having the HTTP server responsible for the URL in question select an appropriate SIP URI for the corresponding resource and return that URI within an HTTP transaction.
HTTPのURLにより示されるリソースの変更をサブスクライブにおける重要な課題の一つは、SIP URIが特定のHTTP URLに対応する決定されます。この仕様は、問題のURLを担当するHTTPサーバが対応するリソースに対する適切なSIP URIを選択して、HTTPトランザクション内そのURIを返したのアプローチを採用しています。
In particular, HTTP servers use link relations -- such as the HTTP Link header field [10], the HTML <link/> element [11], and the Atom <atom:link/> element [5] -- to convey the URI or URIs that can be used to discover changes to the resource. This document defines two new link relation types ("monitor" and "monitor-group") for this purpose, and specifies behavior for SIP and SIPS URIs in link relations of these types. Handling for other URI schemes is out of scope for the current document, although we expect future specifications to define procedures for monitoring via other protocols.
[5]要素 - 伝えるため：例えばHTTPリンクヘッダフィールドとして[10]、HTMLの<link />要素[11]、およびAtomの<link /原子> - 具体的には、HTTPサーバは、リンク関係を使用しますURIまたはリソースへの変更を発見するために使用することができたURI。この文書では、この目的のために（「モニター」と「グループを監視する」）二つの新しいリンク関係のタイプを定義し、これらのタイプのリンク関係にSIPとSIPS URIの動作を指定します。我々は将来の仕様が他のプロトコルを経由して監視するための手順を定義することが予想されるものの、他のURIスキームのための取り扱いは、現在のドキュメントの範囲外です。
Clients making use of the mechanism described in this document MUST support the HTTP Link header field. Those clients that support processing of HTML documents SHOULD support the HTML <link/> element; those that support processing of Atom documents SHOULD support Atom <atom:link/> elements. These requirements are not intended to preclude the use of any other means of conveying link relations.
このドキュメントで説明するメカニズムを利用したクライアントは、HTTPリンクヘッダフィールドをサポートしなければなりません。 HTML文書の処理をサポートしているクライアントは、HTMLの<link />要素を支持します。 <：リンク/アトム>要素を原子文書の処理をサポートしているものは、Atomをサポートすべきです。これらの要件は、リンク関係を伝える任意の他の手段の使用を排除することを意図していません。
The service that provides HTTP access to a resource might provide monitoring of that resource using multiple protocols, so it is perfectly legal for an HTTP response to contain multiple link relationships with relations that allow for monitoring of changes (see [10]). Implementors are cautioned to process all link relations to locate one that corresponds with their preferred change monitoring protocol.
リソースへのHTTPアクセスを提供するサービスは、複数のプロトコルを使用して、そのリソースの監視を提供するかもしれないので、（[10]を参照）の変更の監視を可能に関係を持つ複数のリンク関係を格納するためのHTTPレスポンスのための完全に合法です。実装者はそれらの好ましい変化の監視プロトコルに対応するものを見つけるために、すべてのリンク関係を処理するように警告されます。
These link relations are scoped to a single HTTP entity. When an HTTP resource is associated with multiple entities (for example, to facilitate content negotiation), the "monitor" and "monitor-group" link relations will generally be different for each entity.
これらのリンク関係は、単一のHTTPエンティティにスコープされています。 HTTPリソースが複数のエンティティ（例えば、コンテンツネゴシエーションを容易にするため）に関連付けられている場合、「監視」と「監視グループ」リンク関係は、一般に、各エンティティごとに異なるであろう。
If an HTTP server wishes to offer the ability to subscribe to changes in a resource's value using this event package, it returns a link relation containing a SIP or SIPS URI with a relation type of "monitor" in a successful response to a GET or HEAD request on that resource. If the server supports both SIP and SIPS access, it MAY return link relations for both kinds of access.
HTTPサーバがこのイベントパッケージを使用して、リソースの値の変化をサブスクライブする機能を提供することを希望する場合は、SIPを含むリンク関係を返すか、GETやHEADに成功した応答で「モニター」の関係タイプとURIをSIPSそのリソースへのリクエスト。サーバは、両方のSIPをサポートし、アクセスをSIPS場合は、アクセスの両方の種類のリンク関係を返す場合があります。
A client wishing to subscribe to the state change of an HTTP resource obtains a SIP or SIPS URI by sending a GET or HEAD request to the HTTP URL it wishes to monitor. This SIP or SIPS URI is then used in a SUBSCRIBE request, according to the event package defined in Section 4.
HTTPリソースの状態変化に加入を希望するクライアントは、SIPを取得したり、監視したいのHTTP URLにGETやHEADリクエストを送信することにより、URIをSIPS。このSIPまたはURIをSIPSは、その後、セクション4で定義されたイベントパッケージによれば、SUBSCRIBEリクエストに使用されます。
If a client wishes to subscribe to the state of multiple HTTP resources, it is free to make use of the mechanisms defined in RFC 4662 [6] and/or RFC 5367 [9]. This requires no special support by the server that provides resource state information. These approaches, however, require the addition of a Resource List Server (RLS) as defined in RFC 4662, which will typically subscribe to the state of resources on behalf of the monitoring user. In many cases, this is not a particularly efficient means of monitoring several resources, particularly when such resources reside on the same HTTP server.
クライアントは複数のHTTPリソースの状態に加入することを望む場合は、RFC 4662で定義されたメカニズムを利用することが自由である[6]および/またはRFC 5367 [9]。これは、リソースの状態情報を提供するサーバによって、特別な支援を必要としません。これらのアプローチは、しかし、一般的に監視、ユーザーに代わってリソースの状態に加入されますとRFC 4662で定義されたリソースリストサーバ（RLS）の添加を必要とします。多くの場合、これは、そのようなリソースが同一のHTTPサーバ上に存在する場合は特に、いくつかのリソースを監視する特に効率的な手段ではありません。
As a more efficient alternative, if an HTTP server wishes to offer the ability to subscribe to the state of several HTTP resources in a single SUBSCRIBE request, it returns a link relation containing a SIP or SIPS URI with a relation type of "monitor-group" in a successful response to a GET or HEAD request on any monitorable resource. In general, this monitor-group URI will be the same for all resources on the same HTTP server.
HTTPサーバは、単一のSUBSCRIBEリクエストで複数のHTTPリソースの状態に加入する能力を提供することを望む場合、より効率的な代替手段として、それは、SIPを含むリンク関係を返すまたは「モニタ・グループの関係タイプとURIをSIPS 「任意の監視可能なリソースのGETやHEADリクエストに対する正常な応答インチ一般的には、このモニター・グループURIは、同じHTTPサーバー上のすべてのリソースに対して同じになります。
The monitor-group URI corresponds to an RLS service associated with the HTTP server. This RLS service MUST support subscriptions to request-contained resource lists, as defined in RFC 5367 [9]. This RLS service MAY, but is not required to, accept URI lists that include monitoring URIs that are not associated with resources served by its related HTTP server. Not requiring such functionality allows the RLS to be implemented without requiring back-end subscriptions. If a server wishes to reject such requests, the "403" (Forbidden) response code is appropriate. Any "403" responses generated for this reason SHOULD contain a message body of type "application/ resource-lists+xml"; this message body lists the offending URI or URIs. See RFC 4826 [7] for the definition of the "application/ resource-lists+xml" MIME type.
モニタグループURIはHTTPサーバに関連付けられたRLSサービスに対応します。 RFC 5367で定義されるように、このRLSサービスは、リクエストに含まれるリソースのリストにサブスクリプションをサポートしなければならない[9]。このRLSサービスかもしれませんが、その関連するHTTPサーバが提供するリソースに関連付けられていない監視URIを含めるURIリストを受け入れるために必要とされていません。このような機能を必要としないことRLSバックエンドサブスクリプションを必要とすることなく実施されることを可能にします。サーバは、要求を拒否したい場合、「403」（禁止）応答コードが適切です。この理由のために生成された任意の「403」の応答はタイプのメッセージ本体「+ xmlのアプリケーション/リソース・リスト」を含むべきです。このメッセージ本体は、問題URIまたはURIを示しています。 「アプリケーション/リソース・リスト+ xml」での定義MIMEタイプについては、RFC 4826 [7]を参照してください。
The HTTP server MUST also return a SIP and/or SIPS link relation with a relation type of "monitor" whenever it returns a SIP and/or SIPS link relation with a relation type of "monitor-group". The monitor-group URI corresponds only to an RLS, and never an HTTP resource or fixed set of HTTP resources.
HTTPサーバは、SIPを返す、および/またはそれがSIPを返しおよび/または「監視グループ」の関係タイプとのリンク関係をSIPSたびに「監視」の関係タイプとのリンク関係をSIPSしなければなりません。モニター・グループURIはRLSに対応していない、と決してHTTPリソースまたはHTTPリソースの固定セット。
If a client wishes to subscribe to the state of multiple HTTP resources, and has received monitor-group URIs for each of them, it may use the monitor-group URIs to subscribe to multiple resources in the same subscription. To do so, it starts with the set of HTTP resources it wishes to monitor. It then groups these resources by their respective monitor-group URIs. Finally, for each such group, it initiates a subscription to the group's monitor-group URI; this subscription includes a URI list, as described in RFC 5367. The URI list contains all of the URIs in the group.
クライアントが複数のHTTPリソースの状態に加入することを希望し、それらのそれぞれのモニター・グループのURIを受信した場合、それは同じサブスクリプションに複数のリソースを購読するモニター・グループのURIを使用することができます。そのためには、それが監視したいHTTPリソースのセットから始まります。それぞれのモニター・グループのURIによって、その後のグループこれらのリソースを。最後に、このような各グループのために、それがグループのモニター・グループURIへのサブスクリプションを開始します。 URIリストは、グループ内のURIのすべてが含まれているRFC 5367.に記載されているように、このサブスクリプションは、URIのリストが含まれています。
For example: consider the case in which a client wishes to monitor the resources http://www.example.com/goat, http://www.example.com/sheep, http://www.example.org/llama, and http://www.example.org/alpaca. It would use HTTP to perform HEAD and/or GET operations on these resources. The responses to these operations will contain link relations for both monitor and monitor-type for each of the four resources. Assume the monitor link for http://www.example.com/goat is sip:a94aa000@example.com; for http://www.example.com/sheep, sip:23ec24c5@example.com; for http://www.example.org/llama, sip:yxbO-UHYxyizU2H3dnEerQ@example.org; and for http://www.example.org/alpaca, sip:-J0piC0ihB9hfNaJc7GCBg@example.org. Further, assume the monitor-group link for http://www.example.com/goat and http://www.example.com/sheep are both sip:httpmon@rls.example.com, while the monitor-group link for http://www.example.org/llama and http://www.example.org/alpaca are both sip:rls@example.org.
たとえば、クライアントがリソースを監視したい場合を考えるhttp://www.example.com/goat、http://www.example.com/sheep、http://www.example.org/llama 、およびhttp://www.example.org/alpaca。これは、HEADを実行するためにHTTPを使用し、および/または、これらのリソース上での操作になるだろう。これらの操作への応答は、4つの各リソースのための両方のモニタとモニタ・タイプのリンク関係が含まれています。 http://www.example.com/goat用モニタのリンクがSIPであると仮定します。a94aa000@example.com。 http://www.example.com/sheepため、SIP：23ec24c5@example.com。 http://www.example.org/llamaため、SIP：yxbO-UHYxyizU2H3dnEerQ@example.org。そしてhttp://www.example.org/alpacaため、SIP：-J0piC0ihB9hfNaJc7GCBg@example.org。さらに、http://www.example.com/goatとhttp://www.example.com/sheepするモニタグループリンクを想定SIPともに：モニター・グループ・リンクが、httpmon@rls.example.com rls@example.org：http://www.example.org/llamaとhttp://www.example.org/alpaca用のSIPの両方があります。
Because they share a common monitor-group link, the client would group together http://www.example.com/goat and http://www.example.com/sheep in a single subscription. It sends this subscription to the monitor-group URI (sip:httpmon@rls.example.com), with a resource-list containing the relevant monitor URIs (sip:a94aa000@example.com and sip:23ec24c5@example.com). It then repeats this process for the remaining two HTTP resources, using their monitor-group and monitor URIs in the same way.
彼らは一般的なモニター・グループのリンクを共有しているため、クライアントの単一のサブスクリプションで一緒にグループhttp://www.example.com/goatとhttp://www.example.com/sheepだろう。関連するモニターのURI（：a94aa000@example.comとSIP：23ec24c5@example.com SIP）を含むリソース・リストで、：それは、モニター・グループURI（httpmon@rls.example.com SIP）にこのサブスクリプションを送信します。その後、同じように自分のモニター・グループおよびモニターのURIを使用して、残りの2つのHTTPリソースに対してこの処理を繰り返します。
The name of this event package is "http-monitor".
このイベントパッケージの名前は、「HTTPモニター」です。
This event package defines a single parameter to be used with the Event header field. The syntax for this parameter is shown below, using the ABNF format defined in RFC 5234 [8]. The use of the construction "EQUAL" is as defined by RFC 3261 [3].
このイベントパッケージは、イベントヘッダフィールドで使用する単一のパラメータを定義します。このパラメータの構文は、RFC 5234で定義されたABNF形式を使用して、以下に示されている[8]。 [3] RFC 3261によって定義されるように構成「EQUAL」の使用です。
body-event-param = "body" EQUAL ( "true" / "false" )
ボディ・イベントのparam =「身体」EQUAL（「真」/「偽」）
If present and set to "true" in a SUBSCRIBE request, this parameter indicates to the server that the client wishes to receive a message-body component in the message/http message bodies sent in NOTIFY messages.
現在とSUBSCRIBEリクエストに「真」に設定されている場合、このパラメータは、クライアントがNOTIFYメッセージで送信されたメッセージ/ HTTPメッセージ本文にメッセージ・ボディ・コンポーネントを受信したいサーバに示します。
If a server receives a SUBSCRIBE message with an Event header field "body" parameter set to "true", it MAY choose to include a message-body component in the message/http message bodies that it sends in NOTIFY messages. Alternatively, it MAY decline to send such message-bodies, even when this parameter is present, based on local policy. In particular, it would be quite reasonable for servers to have a policy of not including HTTP message-bodies larger than a relatively small number of bytes.
サーバが「真」に設定され、イベントヘッダフィールド「体」のパラメータを持つSUBSCRIBEメッセージを受信した場合、それはNOTIFYメッセージで送信するメッセージ/ HTTPメッセージ本文にメッセージボディコンポーネントを含めることを選択するかもしれません。また、それはローカルポリシーに基づいて、このパラメータが存在する場合でも、このようなメッセージ・ボディを送信するために低下する可能性があります。サーバはバイトの比較的小さな数よりも多いHTTPメッセージ・ボディを含めない方針を持っているため、特に、それは非常に合理的です。
When absent, the value of this parameter is assumed to be "false".
場合は欠席、このパラメータの値が「偽」であると仮定されます。
Note that this parameter refers to the message-body component of the HTTP message, not the message body component of the SIP message.
このパラメータは、HTTPメッセージではなく、SIPメッセージのメッセージボディコンポーネントのメッセージ・ボディの構成要素を指すことに留意されたいです。
This event package defines no message bodies to be used in the SUBSCRIBE message.
このイベントパッケージは、SUBSCRIBEメッセージで使用すべきメッセージ本文を定義しません。
Reasonable values for the duration of subscriptions to the http-monitor event package vary widely with the nature of the HTTP resource being monitored. Some HTTP resources change infrequently (if ever), while others can change comparatively rapidly. For rapidly changing documents, the ability to recover more rapidly from a subscription failure is relatively important, so implementations will be well served by selecting smaller durations for their subscriptions, on the order of 1800 to 3600 seconds (30 minutes to an hour).
HTTPモニタイベントパッケージへのサブスクリプションの期間のための合理的な値は、監視されているHTTPリソースの性質によって大きく異なります。他の人が比較的急速に変化することができますしながら、いくつかのHTTPリソースは、（これまでであれば）あまり変化しません。実装はよく3600秒（時間に30分）1800の順に、そのサブスクリプションの小さい期間を選択することにより、提供されますので、急速に変化するドキュメントの場合、サブスクリプションの障害からより迅速に回復する能力は、比較的重要です。
Subscriptions to slower-changing resources lack this property, and the need to periodically refresh subscriptions render short subscriptions wasteful. For these types of subscriptions, expirations as long as 604800 seconds (one week) or even longer may well make sense.
遅く変化するリソースへのサブスクリプションは、このプロパティを欠いており、定期的にサブスクリプションをリフレッシュする必要が無駄な短いスクリプションをレンダリングします。サブスクリプションのこれらのタイプのために、有効期限は限り604800秒（1週間）、またはさらに長いとしても意味をなすことがあります。
The subscriber is responsible for selecting an expiration time that is appropriate for its purposes, taking the foregoing considerations into account. Keep in mind that the goal behind selecting subscription durations is to balance server load against time to recover in the case of a failure. In particular, short subscription expiration times guard against the loss of subscription server state, albeit at the expense of additional load on the server.
加入者のアカウントに、上記の考慮を取って、その目的のために適切な有効期限を選択する責任があります。サブスクリプション期間を選択の背後にある目標は、障害が発生した場合の回復に時間に対してサーバーの負荷を分散することであることに留意してください。具体的には、短いサブスクリプションの有効期限は、サーバー上の追加の負荷を犠牲にしながらも、サブスクリプションサーバーの状態の損失を防ぎます。
In the absence of an expires value in a subscription, the notifier can assume a default expiration period according to local policy. This local policy might choose to take various aspects of the monitored resource into account, such as its age and presumed period of validity. Absent any other information, it would not be unreasonable for a server to assume a default expiration value of 86400 seconds (one day) when the client fails to provide one.
が存在しない場合、サブスクリプションの値を満了するには、通知は、ローカルポリシーに従って、デフォルトの有効期限をとることができます。このローカルポリシーは、その年齢や有効性の推定期間として、考慮に監視対象リソースのさまざまな側面を取ることもできます。クライアントが1つを提供するために失敗した場合、サーバーは86400秒（1日）のデフォルトの有効期限値を仮定するため、他の情報がなければ、不合理ではないでしょう。
By default, the message bodies of NOTIFY messages for the http-monitor event package will be of content-type "message/http," as defined in RFC 2616 [2].
RFC 2616で定義されるように、デフォルトで、HTTPモニタイベントパッケージのためのNOTIFYメッセージのメッセージ本文は、コンテンツタイプ「メッセージ/ HTTP、」であろう[2]。
The message/http NOTIFY message bodies used in the HTTP monitor event package reflect a subset of the response that would be returned if the client performed an HTTP HEAD operation on the HTTP resource.
メッセージ/ HTTP HTTPモニターイベントパッケージに使用されるメッセージ本文をNOTIFYクライアントはHTTPリソース上のHTTP HEAD操作を行った場合に返される応答のサブセットを反映しています。
An example of a message/http message body as used in this event package is shown below.
このイベント・パッケージで使用されるメッセージ/ HTTPメッセージボディの例を以下に示します。
HTTP/1.1 200 OK Date: Sat, 13 Nov 2010 17:18:52 GMT ETag: 38fe6-58b-1840e7d0 Content-MD5: 4e3b50421829c7c379a5c6154e560449 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT Accept-Ranges: bytes Content-Location: http://www.example.com/pet-profiles/alpacas/ Content-Length: 12511 Content-Type: text/html
HTTP / 1.1 200 OK日：土、2010年11月13日夜05時18分52秒GMTのETagを：38fe6-58b-1840e7d0のContent-MD5：4e3b50421829c7c379a5c6154e560449最終-更新：土、2010年11月13日3時29分00秒GMTのAccept-範囲：バイトコンテンツ所在地：http://www.example.com/pet-profiles/alpacas/のContent-Length：12511のContent-Type：text / htmlの
When used in the HTTP monitor event package defined in this document, the message/http SHOULD contain at least one of an ETag or Content-MD5 header field, unless returning a null state as described in Section 4.7. Inclusion of a Last-Modified header field is also RECOMMENDED. Additionally, the message/http message body MUST contain a Content-Location field that identifies the resource being monitored. Note that this is not necessarily the same URL from which the link association was originally obtained; see RFC 2616 [2] for details.
この文書で定義されたHTTPモニターイベントパッケージで使用される場合、メッセージ/ HTTPは、セクション4.7で説明したように、ヌル状態を復帰しない限り、のETagまたはContent-MD5ヘッダフィールドのうち少なくとも一つを含むべきです。 Last-Modifiedヘッダフィールドを含めることも推奨されます。また、メッセージ/ HTTPメッセージのボディは監視されているリソースを特定のContent-Locationフィールドを含まなければなりません。これはリンク・アソシエーションが最初に取得された同じURLが必ずしもないことに留意されたいです。詳細については、RFC 2616 [2]を参照してください。
Except for the foregoing normative requirements, the decision regarding which HTTP header fields to include is at the discretion of the notifier.
上記規定の要件を除いて、含めるためにどのHTTPヘッダフィールドに関する決定は、通知の裁量です。
When used in the HTTP monitor event package, the message/http MUST NOT contain a message-body component, unless the corresponding subscription has explicitly indicated the desire to receive such bodies as described in Section 4.2.
HTTPモニタイベントパッケージで使用される場合、対応するサブスクリプションは、明示的セクション4.2に記載されているようなボディを受信しようとすることを示していない限り、メッセージ/ HTTPは、メッセージボディの成分を含んではなりません。
If the change to the resource being communicated represents a renaming of the HTTP resource, the message/http start line will contain the same 3xx-class HTTP response that would be returned if a user agent attempted to access the relocated HTTP resource with a HEAD request (e.g., "301 Moved Permanently"). The message/http also SHOULD contain a Location header field that communicates the new name of the resource.
通信されているリソースへの変更は、HTTPリソースの名前の変更を表す場合、メッセージ/ HTTPスタートラインには、ユーザエージェントがHEADリクエストで再配置HTTPリソースにアクセスしようとした場合に返されるのと同じ3xxのクラスのHTTPレスポンスが含まれています（例えば、 "301は永久に移動しました"）。メッセージ/ HTTPは、リソースの新しい名前を伝えるLocationヘッダーフィールドを含むべきです。
If the change to the resource being communicated represents a deletion of the HTTP resource, the start line will contain the same 4xx-class HTTP response that would be returned if a user agent attempted to access the missing HTTP resource with a HEAD request (e.g., "404 Not Found" or "410 Gone").
通信されているリソースへの変更は、HTTPリソースの削除を表す場合、スタートラインには、ユーザエージェントはHEAD要求（例えばとともに不足してHTTPリソースにアクセスしようとした場合に返されるのと同じ4xxのクラスのHTTPレスポンスが含まれています）「404見つかりません」または「410ゴーン」。
Upon receipt of a SUBSCRIBE request, the notifier applies authorization according to local policy. Typically, this policy will be aligned with the HTTP server authorization policies regarding access to the resource whose change state is being requested.
SUBSCRIBEリクエストを受信すると、通知は、ローカルポリシーに従って許可を適用します。一般的に、このポリシーが変更状態要求されているリソースへのアクセスに関するHTTPサーバの認可ポリシーと一致します。
NOTIFY messages are generated whenever the underlying resource indicated by the corresponding HTTP URL has been modified.
対応するHTTP URLで示される下層のリソースが変更されたときはいつでも、NOTIFYメッセージが生成されます。
In the case that the notifier has insufficient information to return any useful information about the underlying HTTP resource, it MUST return a message body that is zero bytes long (subject to any mechanisms that would suppress sending of a NOTIFY message).
通知は、基礎となるHTTPリソースに関する有用な情報を返すために十分な情報を有している場合には、長いゼロバイト（NOTIFYメッセージの送信を抑制する任意の機構による）であるメッセージ本文を返さなければなりません。
Upon receipt of a NOTIFY message, the subscriber applies any information in the message/http to update its view of the underlying HTTP resource. In most cases, this results in an invalidation of its view of the HTTP resource. It is up to the subscriber implementation to decide whether it is appropriate to fetch a new copy of the HTTP resource as a reaction to a NOTIFY message.
NOTIFYメッセージを受信すると、加入者は、基礎となるHTTPリソースのビューを更新するためにメッセージ/ HTTPの任意の情報を適用します。ほとんどの場合、これは、HTTPリソースのビューの無効化につながります。 NOTIFYメッセージに対する反応として、HTTPリソースの新しいコピーを取得することが適切であるかどうかを決定するために、加入者の実装に任されています。
Multiple notifiers for a single HTTP resource is semantically nonsensical. In the aberrant circumstance that a SUBSCRIBE request is forked, the subscriber SHOULD terminate all but one subscription, as described in Section 4.4.9 of RFC 3265 [4].
単一のHTTPリソースのための複数のNotifierは、意味的に無意味です。 RFC 3265のセクション4.4.9に記載したようにSUBSCRIBEリクエストをフォークしていることを異常な状況では、加入者は、[4]、すべてが、1つのサブスクリプションを終了すべきです。
Because the data stored in HTTP for the purpose of SIP services may change rapidly due to user input, and because it may potentially be rendered to users and/or used to impact call routing, a high degree of responsiveness is appropriate. However, for the protection of the network, notifiers for the http-monitor event package SHOULD NOT send notifications more frequently than once every second.
SIPサービスのためにHTTPに格納されたデータが原因ユーザ入力に迅速に変更されることがあり、それは潜在的にユーザにレンダリングおよび/またはコールルーティングに影響を与えるために使用することができるので、応答性の高い程度が適切であるためです。しかし、ネットワークの保護のために、HTTPモニタイベントパッケージの通知者は、1秒に1回よりも頻繁に通知を送るべきではありません。
Decomposition of the authority for the HTTP resource into an HTTP server and a SIP Events server is likely to be useful, due to the potentially different scaling properties associated with serving HTTP resources and managing subscriptions. In the case of such decomposition, implementors are encouraged to familiarize themselves with the PUBLISH mechanism described in RFC 3903 [14].
HTTPサーバとSIPのイベントサーバへのHTTPリソースに対する権限の分解は、HTTPリソースを提供し、サブスクリプションの管理に関連した潜在的に異なるスケーリング特性に起因する、便利である可能性が高いです。そのような分解の場合、実装は、RFC 3903 [14]に記載のPUBLISH機構に慣れることが奨励されます。
The following is a simple example message flow, to aid in understanding how this event package can be used. It is included for illustrative purposes only, and does not form any portion of the specification of the mechanisms defined in this document.
以下では、このイベントパッケージを使用することができますどのように理解を助けるために、簡単な例のメッセージフローです。これは例示の目的のみのために含まれ、この文書で定義されたメカニズムの仕様の一部を形成しません。
Client HTTP Server SIP Events Server
| | |
| | |
|(1) HTTP GET | |
|------------------>| |
|(2) HTTP 200 OK | |
|<------------------| |
|(3) SIP SUBSCRIBE | |
|-------------------------------------->|
|(4) SIP 200 OK | |
|<--------------------------------------|
|(5) SIP NOTIFY | |
|<--------------------------------------|
|(6) SIP 200 OK | |
|-------------------------------------->|
| | |
| | |
| [HTTP document changes] |
| | |
| | |
| |(7) SIP PUBLISH |
| |------------------>|
| |(8) SIP 200 OK |
| |<------------------|
|(9) SIP NOTIFY | |
|<--------------------------------------|
|(10) SIP 200 | |
|-------------------------------------->|
| | |
| | |
The following messages illustrate only the portions of the messages that are relevant to the example. They intentionally elide fields that, while typical or mandatory, are not key to understanding the foregoing message flow.
次のメッセージは、例に関連するメッセージの部分のみを示しています。彼らは意図的に、典型的な又は必須ながら、前述のメッセージ・フローを理解するための鍵ではなく、フィールドをElideの。
1. The client issues a GET request to retrieve the document identified by the URL "http://www.example.com/pet-profiles/alpacas/".
1.クライアントは、URL「http://www.example.com/pet-profiles/alpacas/」で識別されるドキュメントを取得するためのGETリクエストを発行します。
GET /pet-profiles/alpacas/ HTTP/1.1 Host: www.example.com
GET /ペットのプロフィール/アルパカ/ HTTP / 1.1ホスト：www.example.com
2. The HTTP server responds with the document, and several relevant pieces of meta-data. Of key interest for this example is the Link header field with a "rel" parameter of "monitor". This is the SIP URL that the client will use to monitor changes to the state of the HTTP resource. Note that, since the message-body is an HTML document, the "monitor" link relation could alternately be indicated in the HTML document itself, through the use of a <link/> element.
2. HTTPサーバは、ドキュメント、およびメタデータのいくつかの関連部分で応答します。この例のキー興味深いのは、「監視」の「REL」パラメータを使用してリンクヘッダフィールドです。これは、クライアントがHTTPリソースの状態への変更を監視するために使用するSIP URLです。メッセージ本体がHTML文書であるため、「監視」リンク関係が交互の<link />要素の使用を介して、HTMLドキュメント自体で示すことができ、ことに留意されたいです。
Note also the presence of the ETag, Content-MD5, and Last-Modified header fields. These can be used by the client to identify the version of the entity returned by the HTTP server.
またETagを、コンテンツ-MD5、および最終-Modifiedヘッダフィールドの存在に注意してください。これらは、HTTPサーバから返されたエンティティのバージョンを識別するために、クライアントで使用することができます。
HTTP/1.1 200 OK ETag: 38fe6-58b-1840e7d0 Content-MD5: 4e3b50421829c7c379a5c6154e560449 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT Content-Location: http://www.example.com/pet-profiles/alpacas/ Link: <sip:23ec24c5@example.com>; rel="monitor" Link: <sip:httpmon@rls.example.com>; rel="monitor-group" Content-Length: 12511 Content-Type: text/html
HTTP / 1.1 200 OKのETag：38fe6-58b-1840e7d0のContent-MD5：4e3b50421829c7c379a5c6154e560449のLast-Modified：土、2010年11月13日午前3時29分00秒GMTコンテンツ - ロケーション：http://www.example.com/pet-profiles/アルパカ/リンク：<SIP：23ec24c5@example.com>。 REL = "モニター" リンク：<SIP：httpmon@rls.example.com>。 REL = "モニター・グループ" のContent-Length：12511のContent-Type：text / htmlの
[HTML message-body]
[HTMLメッセージボディ]
3. The client sends a SUBSCRIBE request to the SIP URI indicated in the "monitor" link relation, indicating an event type of "http-monitor".
3.クライアントは、SIP URIにSUBSCRIBEリクエストを送信する「HTTPモニター」のイベントタイプを示す、リンク関係を「監視」に示されます。
SUBSCRIBE sip:23ec24c5@example.com SIP/2.0 To: <sip:23ec24c5@example.com> From: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 Event: http-monitor Contact: <sip:adam@198.51.100.17:2487>
HTTPモニターの連絡先：：<SIP; 23ec24c5@example.com SIP / 2.0に：<SIP：23ec24c5@example.com>から：タグ= 57dac993-0b5b-4f04イベント：<SIP adam@example.org>一口SUBSCRIBE ：adam@198.51.100.17：2487>
4. The SIP Events server acknowledges receipt of the subscription request, and establishes a dialog for the resulting subscription.
4. SIPイベント・サーバは、サブスクリプション要求の受信を確認し、そして得られたサブスクリプションのためのダイアログを確立します。
SIP/2.0 200 OK To: <sip:23ec24c5@example.com>;tag=907A953576E6 From: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 Contact: <sip:23ec24c5@203.0.113.72>
SIP / 2.0 200 OK <SIP：23ec24c5@example.com>;タグ= 907A953576E6から<SIP：adam@example.org>;タグ= 57dac993-0b5b-4f04問い合わせ：<SIP：23ec24c5@203.0.113.72>
5. The SIP Events server sends a NOTIFY message containing the current state of the HTTP resource. The client can compare the contents of the ETag, Content-MD5, or Last-Modified header fields against those received in the HTTP "200" response to verify that it has the most recent version of the entity.
5. SIPイベント・サーバは、HTTPリソースの現在の状態を含むNOTIFYメッセージを送信します。クライアントは、エンティティの最新バージョンを持っていることを確認するためのETag、コンテンツ-MD5、またはHTTP「200」応答で受信したものに対してのLast-Modifiedヘッダフィールドの内容を比較することができます。
NOTIFY sip:adam@198.51.100.17:2487 SIP/2.0 To: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 From: <sip:23ec24c5@example.com>;tag=907A953576E6 Contact: <sip:23ec24c5@203.0.113.72> Event: http-monitor Subscription-State: active Content-Type: message/http
adam@198.51.100.17：SIPのNOTIFY 2487 SIP / 2.0 <SIP：adam@example.org>;タグ= 57dac993-0b5b-4f04から<SIP：23ec24c5@example.com>;タグ= 907A953576E6問い合わせ< SIP：23ec24c5@203.0.113.72>イベント：HTTP-モニタースクリプション・ステート：アクティブのContent-Type：メッセージ/ HTTP
HTTP/1.1 200 OK ETag: 38fe6-58b-1840e7d0 Content-MD5: 4e3b50421829c7c379a5c6154e560449 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT Content-Location: http://www.example.com/pet-profiles/alpacas/ Content-Length: 12511 Content-Type: text/html
HTTP / 1.1 200 OKのETag：38fe6-58b-1840e7d0のContent-MD5：4e3b50421829c7c379a5c6154e560449のLast-Modified：土、2010年11月13日午前3時29分00秒GMTコンテンツ - ロケーション：http://www.example.com/pet-profiles/アルパカ/のContent-Length：12511のContent-Type：text / htmlの
SIP/2.0 200 OK To: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 From: <sip:23ec24c5@example.com>;tag=907A953576E6 Contact: <sip:adam@198.51.100.17:2487>
SIP / 2.0 200 OKに<SIP：adam@example.org>;タグ= 57dac993-0b5b-4f04から<SIP：23ec24c5@example.com>;タグ= 907A953576E6問い合わせ：<SIP：adam@198.51.100.17： 2487年>
7. At some point after the subscription has been established, the entity hosted by the HTTP server changes. It can convey this information to a SIP Events server using a SIP PUBLISH request. The PUBLISH message body contains information regarding the state of the entity.
加入後のある時点で7は、HTTPサーバの変更によってホストされているエンティティを確立してきました。これは、SIP PUBLISHリクエストを使用してSIPイベント・サーバにこの情報を伝えることができます。 PUBLISHメッセージのボディは、エンティティの状態に関する情報が含まれています。
Note that SIP PUBLISH is one of many ways such information could be conveyed -- any other means of communicating this information would also be valid.
この情報を通信する他の手段も有効だろう - SIPは、そのような情報を伝えることができる多くの方法の一つですPUBLISHことに注意してください。
PUBLISH sip:23ec24c5@example.com SIP/2.0 To: <sip:23ec24c5@example.com> From: <sip:webserver@example.com>;tag=03-5gbK652_jNMr-b8-11Z_G-NsLR Contact: <sip:webserver@203.0.113.99> Event: http-monitor Content-Type: message/http
23ec24c5@example.com SIP / 2.0：SIPのPUBLISH <SIP：23ec24c5@example.com>から<SIP：webserver@example.com>;タグ= 03-5gbK652_jNMr-b8-11Z_G-NsLR問い合わせ：<SIP： webserver@203.0.113.99>イベント：HTTP-モニターのContent-Type：メッセージ/ HTTP
HTTP/1.1 200 OK ETag: 3238e-1a3-b83be580 Content-MD5: 10a1ef5b223577059fafba867829abf8 Last-Modified: Sat, 17 Nov 2010 08:17:39 GMT Content-Location: http://www.example.com/pet-profiles/alpacas/ Content-Length: 17481 Content-Type: text/html
HTTP / 1.1 200 OKのETag：3238e-1A3-b83be580のContent-MD5：10a1ef5b223577059fafba867829abf8のLast-Modified：土、2010年11月17日8時17分39秒GMTコンテンツ - ロケーション：http://www.example.com/pet-profiles/アルパカ/のContent-Length：17481のContent-Type：text / htmlの
8. The SIP Events server acknowledges the changed entity state. Note that the value of the SIP-ETag header field is not related to the ETag header field associated with the HTTP entity.
8. SIPイベント・サーバは、変更されたエンティティの状態を認めます。 SIP-ETagヘッダフィールドの値は、HTTPエンティティに関連付けられているETagヘッダフィールドに関連していないことに注意してください。
SIP/2.0 200 OK To: <sip:23ec24c5@example.com> From: <sip:webserver@example.com>;tag=03-5gbK652_jNMr-b8-11Z_G-NsLR SIP-ETag: 3psbqi1o5633
SIP / 2.0 200 OK <SIP：23ec24c5@example.com>から<SIP：webserver@example.com>;タグ= 03-5gbK652_jNMr-b8-11Z_G-NsLR SIP-のETag：3psbqi1o5633
9. The SIP events server informs the client of the change in state for the subscribed resource using a NOTIFY message.
9. SIPイベント・サーバは、NOTIFYメッセージを使用して登録し、リソースの状態の変化をクライアントに通知します。
NOTIFY sip:adam@198.51.100.17:2487 SIP/2.0 To: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 From: <sip:23ec24c5@example.com>;tag=907A953576E6 Contact: <sip:23ec24c5@203.0.113.72> Event: http-monitor Subscription-State: active Content-Type: message/http
adam@198.51.100.17：SIPのNOTIFY 2487 SIP / 2.0 <SIP：adam@example.org>;タグ= 57dac993-0b5b-4f04から<SIP：23ec24c5@example.com>;タグ= 907A953576E6問い合わせ< SIP：23ec24c5@203.0.113.72>イベント：HTTP-モニタースクリプション・ステート：アクティブのContent-Type：メッセージ/ HTTP
HTTP/1.1 200 OK ETag: 3238e-1a3-b83be580 Content-MD5: 10a1ef5b223577059fafba867829abf8 Last-Modified: Sat, 17 Nov 2010 08:17:39 GMT Content-Location: http://www.example.com/pet-profiles/alpacas/ Content-Length: 17481 Content-Type: text/html
HTTP / 1.1 200 OKのETag：3238e-1A3-b83be580のContent-MD5：10a1ef5b223577059fafba867829abf8のLast-Modified：土、2010年11月17日8時17分39秒GMTコンテンツ - ロケーション：http://www.example.com/pet-profiles/アルパカ/のContent-Length：17481のContent-Type：text / htmlの
10. The client acknowledges receipt of the changed state. At this point, the client may choose to retrieve a fresh copy of the document so that it can act on the new content. Alternately, it may simply mark the previously retrieved document as out of date or discard it, choosing to retrieve a new copy at a later point in time.
10.クライアントが変更された状態の受信を確認します。この時点で、クライアントは、それが新しいコンテンツに基づいて行動できるように、ドキュメントの新しいコピーを取得することもできます。代わりに、それは単に日付のうち、以前に検索された文書をマークしたり、後の時点で新しいコピーを取得することを選択、それを捨てます。
SIP/2.0 200 OK To: <sip:adam@example.org>;tag=57dac993-0b5b-4f04 From: <sip:23ec24c5@example.com>;tag=907A953576E6 Contact: <sip:adam@198.51.100.17:2487>
SIP / 2.0 200 OKに<SIP：adam@example.org>;タグ= 57dac993-0b5b-4f04から<SIP：23ec24c5@example.com>;タグ= 907A953576E6問い合わせ：<SIP：adam@198.51.100.17： 2487年>
Unless secured using Transport Layer Security (TLS), IPsec, or a similar technology, the content of the Link header field is not secure, private, or integrity-protected.
トランスポート層セキュリティ（TLS）、IPsecの、または同様の技術を使用して固定していない限り、リンクヘッダフィールドの内容は、セキュアなプライベート、あるいは完全性保護されていません。
Because an unencrypted Link header field can be intercepted, server implementations are cautioned not to use the value sent in the Link header field as a security token that authenticates a subscriber, or that demonstrates authorization to subscribe to a particular resource.
暗号化されていないリンクヘッダフィールドを傍受することができるので、サーバの実装は、加入者を認証するセキュリティトークンとしてリンクヘッダフィールドで送信された値を使用しないように警告された、またはそれが特定のリソースにサブスクライブする権限を示しています。
Because an unsecured Link header field can be tampered with -- or inserted -- in transit, client implementations need to consider the interaction between their application and a forged set of notifications. This issue becomes particularly problematic when the change notifications include entity state (using "body=true").
無担保リンクヘッダフィールドが改ざんすることができますので - または挿入 - 輸送中に、クライアント実装は、アプリケーションおよび通知の鍛造セットの間の相互作用を考慮する必要があります。変更通知は、（「ボディ= true」を使用して）エンティティの状態が含まれている場合、この問題が特に問題となります。
This mechanism introduces the means to learn information about the state of an HTTP resource using an alternate protocol, and potentially a different server. If the HTTP resource is restricted using some form of access control, special care MUST be taken to ensure that the SIP means of subscribing to the resource state is also restricted in the same way. Otherwise, unauthorized users may learn information that was intended to be confidential (including the actual resource value, in some cases).
このメカニズムは、代替プロトコル、および潜在的に異なるサーバを使用してHTTPリソースの状態に関する情報を学習する手段を導入します。 HTTPリソースがアクセス制御のいくつかのフォームを使用して制限されている場合は、特別なケアは、リソースの状態に加入のSIP手段も同じように制限されているように注意する必要があります。それ以外の場合、権限のないユーザーは、（いくつかのケースでは、実際のリソース値を含む）機密であることを意図していた情報を知ることがあります。
Similarly, if the HTTP resource is encrypted or integrity protected in transit -- for example, by using HTTP over TLS [12] -- then the SIP means of subscribing to the HTTP resource MUST also have appropriate encryption or integrity protection applied. Examples of mechanisms for providing such protection include the use of the SIPS URI scheme [17], and the use of S/MIME bodies [13].
同様に、HTTPリソースは、暗号化または完全性は輸送中に保護されている場合 - 例えば、TLS [12] over HTTPを使用して、 - 次いで、HTTPリソースにサブスクライブのSIP手段をも適用適切な暗号化または完全性保護がなければなりません。そのような保護を提供するためのメカニズムの例は、SIPS URIスキーム[17]、及びS / MIMEボディの使用[13]の使用を含みます。
The following entries have been added to the "Link Relation Types" registry, as created by the "Web Linking" specification [10].
「ウェブリンク」仕様[10]によって作成された次のエントリは、「リンクの関係タイプ」レジストリに追加されました。
o Relation Name: monitor
Oリレーション名：モニター
o Description: Refers to a resource that can be used to monitor changes in an HTTP resource.
O説明：HTTPリソースの変化を監視するために使用することができるリソースを参照します。
o Reference: RFC 5989
Oリファレンス：RFC 5989
o Relation Name: monitor-group
Oリレーション名：モニター・グループ
o Description: Refers to a resource that can be used to monitor changes in a specified group of HTTP resources.
O説明：HTTPリソースの指定されたグループの変化を監視するために使用することができるリソースを参照します。
o Reference: RFC 5989
Oリファレンス：RFC 5989
The following entry is to be added to the "SIP Events" registry, as created by the SIP Event Framework [4].
次のエントリは、SIPイベント・フレームワーク[4]によって作成され、「SIPイベント」レジストリに追加されます。
Package Name: http-monitor
パッケージ名：HTTPモニター
Type: package
タイプ：パッケージ
Contact: Adam Roach, adam@nostrum.com
連絡先：アダムローチ、adam@nostrum.com
Reference: RFC 5989
参考：RFC 5989
The following entry is to be added to the SIP "Header Field Parameters and Parameter Values" registry, as created by the SIP Change Framework [15].
次のエントリは、SIPの変更枠組み[15]によって作成されたとして、SIP「ヘッダーフィールドパラメータとパラメータ値」レジストリに追加されます。
Header Field: Event
ヘッダーフィールド：イベント
Parameter Name: body
パラメータ名：ボディ
Predefined Values: yes
定義済みの値：はい
Reference: RFC 5989
参考：RFC 5989
Thanks to Lisa Dusseault and Mark Nottingham for significant input on the mechanisms to bind an HTTP URL to a SIP URI. Thanks also to Mark Nottingham and Theo Zourzouvillys for thorough feedback on early versions of this document. Thanks to Martin Thompson, Shida Schubert, John Elwell, and Scott Lawrence for their careful reviews and feedback.
SIP URIへのHTTP URLをバインドするためのメカニズムに重要な入力のためのリサDusseaultとマーク・ノッティンガムに感謝します。このドキュメントの初期バージョンを徹底的にフィードバックのためにもマーク・ノッティンガムとテオZourzouvillysに感謝します。彼らの慎重なレビューとフィードバックのためのマーティン・トンプソン、志田シューベルト、ジョンエルウェル、そしてスコットローレンスに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] 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.
[2]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[3] 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.
[3]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4]ローチ、A.、 "セッション開始プロトコル（SIP）特異的イベント通知"、RFC 3265、2002年6月。
[5] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[5]ノッティンガム、M.、エド。そして、R.セイヤー、エド。、 "Atom配信フォーマット"、RFC 4287、2005年12月。
[6] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists", RFC 4662, August 2006.
[6]ローチ、A.、キャンベル、B.、およびJ.ローゼンバーグ、 "リソースリストのAのセッション開始プロトコル（SIP）イベント通知拡張"、RFC 4662、2006年8月を。
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[7]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）リソースリストを表現するための形式"、RFC 4826、2007年5月。
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.
[8]クロッカー、D.、およびP. Overell、 "増補BNF構文仕様のため：ABNF"、STD 68、RFC 5234、2008年1月。
[9] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)", RFC 5367, October 2008.
[9]キャマリロ、G.、ローチ、A.、およびO.レヴィン、RFC 5367、2008年10月 "サブスクリプションは、セッション開始プロトコル（SIP）でリソースリストを含有要求に"。
[10] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[10]ノッティンガム、M.、 "ウェブリンク"、RFC 5988、2010年10月。
[11] Jacobs, I., Hors, A., and D. Raggett, "HTML 4.01 Specification", World Wide Web Consortium Recommendation REC-html401-19991224, December 1999, <http://www.w3.org/TR/1999/REC-html401-19991224>.
[11]ジェイコブス、I.、オードブル、A.、およびD. Raggett、 "HTML 4.01仕様書"、World Wide Web Consortium（W3C）の勧告REC-html401-19991224、1999年12月、<http://www.w3.org/TR / 1999 / REC-html401-19991224>。
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12]レスコラ、E.、 "HTTPオーバーTLS"、RFC 2818、2000年5月。
[13] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[13] Ramsdell、B.、およびS.ターナー、 "/セキュア多目的インターネットメール拡張（S / MIME）バージョン3.2メッセージ仕様"、RFC 5751、2010年1月。
[14] Niemi, A., "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004.
[14]ニエミ、A.、 "イベント状態の出版のためのセッション開始プロトコル（SIP）の拡張"、RFC 3903、2004年10月。
[15] Camarillo, G., "The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)", BCP 98, RFC 3968, December 2004.
[15]キャマリロ、G.、BCP 98、RFC 3968、2004月 "セッション開始プロトコル（SIP）の番号機関（IANA）ヘッダーフィールドパラメータレジストリ割り当てインターネット"。
[16] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[16] Dusseault、L.、RFC 4918、2007年6月 "Web分散オーサリングとバージョン管理（WebDAV）のためのHTTP拡張機能"。
[17] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[17] Audet、F.、RFC 5630、2009年10月 "セッション開始プロトコル（SIP）におけるSIPS URIスキームの使用"。
[18] Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill, "Extensible Resource Identifier (XRI) Resolution V2.0", February 2008, <http://docs.oasis-open.org/xri/2.0/specs/ xri-resolution-V2.0.html>.
[18] Wachob、G.、リード、D.、茶筅、L.、タン、W.、およびS.チャーチル、 "拡張リソース識別子（XRI）解像度V2.0"、2008年2月、<のhttp：//ドキュメント.oasis-open.org / XRI / 2.0 /スペック/ XRI解像度-V2.0.html>。
Appendix A. Rationale: Other Approaches Considered
付録A.根拠：考慮される他のアプローチ
Several potential mechanisms for retrieving the SIP URI from the HTTP server were evaluated. Of them, link relations were determined to have the most favorable set of properties. Two key candidates that were considered but rejected in favor of link relations are discussed below.
HTTPサーバからSIP URIを取得するためのいくつかの潜在的なメカニズムを評価しました。このうち、リンク関係は性質の最も有利なセットを持っていると判断されました。リンク関係を支持して考えられたが拒否された2つのキー候補が以下に議論されています。
The HTTP PROPFIND method ([16], Section 9.1) can be used to retrieve the value of a specific property associated with an HTTP URL. However, this cannot be done in conjunction with retrieval of the document itself, which is usually desirable. If a PROPFIND approach is employed, clients will typically perform both a GET and a PROPFIND on resources of interest. Additionally, the use of PROPFIND requires support of the PROPFIND method in HTTP user agents -- which, although fairly well implemented, still lacks the penetration of GET implementations.
HTTP PROPFINDメソッド（[16]、セクション9.1）のHTTP URLに関連付けられた特定のプロパティの値を取得するために使用することができます。しかし、これは通常望ましい文書自体の検索に関連して行うことができません。 PROPFINDのアプローチが採用されている場合は、クライアントは通常GETや関心の資源にPROPFINDの両方を実行します。かなりよく実現するが、依然としてGET実装の侵入を欠く、 - また、PROPFINDの使用は、HTTPユーザエージェントでPROPFINDメソッドのサポートを必要とします。
Similar to PROPFIND, XRDS (Extensible Resource Descriptor Sequence) [18] can be used to retrieve properties associated with an HTTP URL. It has the advantage of using GET instead of PROPFIND; however, it suffers from both the two-round-trip issue discussed above, as well as an unfortunately large number of options in specifying how to retrieve the properties.
PROPFIND、XRDS（拡張可能なリソース記述子シーケンス）[18]と同様のHTTP URLに関連付けられたプロパティを取得するために使用することができます。これは、代わりにPROPFINDのGETを使用することの利点を持っています。しかし、上述の二往復の問題、ならびにプロパティを取得する方法を指定のオプション残念ながら多数の両方に苦しんでいます。
Author's Address
著者のアドレス
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
アダムローチTekelec 17210キャンベルRdを。スイート250、ダラス、TX 75252米国
EMail: adam@nostrum.com
メールアドレス：adam@nostrum.com