[要約] RFC 5989は、HTTPリソースの変更を購読するためのSIPイベントパッケージに関する仕様です。このRFCの目的は、SIPプロトコルを使用してHTTPリソースの変更を監視し、通知するための標準化を提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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および/またはセッション開始プロトコルセキュア（SIP）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].
このドキュメントの「必須」、「必要」、「may」、「may」、 "not"、 "not" 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に大きく基づいているため、これらのメッセージのコンポーネントには類似または同一の名前があります。メッセージペイロードを参照する場合、HTTPドキュメントは歴史的にハイフン化されたフォーム「メッセージボディ」を好んでいましたが、SIPドキュメントは非定形のフォーム「メッセージ本文」を支持しています。このドキュメントは、HTTPのハイフン型フォームとSIPに非定義された形式を使用して、両方の規則に準拠しています。
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によって示されるリソースの変更に登録する際の重要な課題の1つは、特定のHTTP URLにどのSIP URIが対応するかを決定することです。この仕様では、問題のURLのHTTPサーバーに責任を負わせるというアプローチが必要です。HTTPトランザクション内でURIを返すための適切なSIP 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.
特に、HTTPサーバーは、HTTPリンクヘッダーフィールド[10]、HTML <link/>要素[11]、Atom <atom：link/> element [5]などのリンク関係を使用します。リソースの変更を発見するために使用できるURIまたはURI。このドキュメントでは、この目的のために2つの新しいリンク関係タイプ（「モニター」と「モニターグループ」）を定義し、これらのタイプのリンク関係におけるSIPおよびSIP 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ドキュメントの処理をサポートするものは、Atom <Atom：link/>要素をサポートする必要があります。これらの要件は、リンク関係を伝える他の手段の使用を排除することを意図したものではありません。
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アクセスを提供するサービスは、複数のプロトコルを使用してそのリソースの監視を提供する可能性があるため、HTTP応答が変更の監視を可能にする関係と複数のリンク関係を含めることは完全に合法です（[10]を参照）。実装者は、すべてのリンク関係を処理して、好みの変更モニタリングプロトコルに対応する関係を見つけるように注意してください。
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サーバーが、このイベントパッケージを使用してリソースの値の変更をサブスクライブする機能を提供したい場合、GETまたはヘッドへの成功した応答で「モニター」タイプの「モニター」を持つSIPまたはSIPS URIを含むリンク関係を返します。そのリソースをリクエストします。サーバーがSIPとSIPの両方のアクセスをサポートする場合、両方の種類のアクセスに対してリンク関係を返す場合があります。
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リソースの状態変更を購読したいクライアントは、監視したいHTTP URLにGETまたはヘッドリクエストを送信することにより、SIPまたはSIPS URIを取得します。このSIPまたはSIPS URIは、セクション4で定義されているイベントパッケージに従って、購読リクエストで使用されます。
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サーバーが単一のサブスクライブリクエストで複数のHTTPリソースの状態を購読する機能を提供したい場合、SIPまたはSIPS URIを含むリンク関係を「モニターグループとSIPS URI」を返します。「監視可能なリソースの取得またはヘッドリクエストに対する応答が成功しました。一般に、このモニターグループ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サービスに対応しています。このRLSサービスは、RFC 5367 [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および/または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のサブスクリプションを開始します。このサブスクリプションには、RFC 5367で説明されているURIリストが含まれています。URIリストには、グループ内のすべての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。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：-j0picihb9hfnajc7gcbg@example.orgさらに、http：//www.example.com/goat and http://www.example.com/sheepのモニターグループリンクは両方ともsip：httpmon@rls.example.comであると仮定します。http://www.example.org/llamaおよびhttp://www.example.org/alpacaは両方ともsip：rls@example.orgです。
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を単一のサブスクリプションでグループ化します。このサブスクリプションは、関連するモニターURIS（sip：a94aa000@example.comおよびsip：23ec24c5@example.com）を含むリソースリストを使用して、モニターグループURI（sip：httpmon@rls.example.com）に送信します。次に、モニターグループとモニターURIを同じ方法で使用して、残りの2つのHTTPリソースに対してこのプロセスを繰り返します。
The name of this event package is "http-monitor".
このイベントパッケージの名前は「http-monitor」です。
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 [8]で定義されているABNF形式を使用して、以下に示します。「等しい」構造の使用は、RFC 3261 [3]によって定義されています。
body-event-param = "body" EQUAL ( "true" / "false" )
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.
サブスクライブリクエストで存在して「true」に設定した場合、このパラメーターは、通知メッセージで送信されたメッセージ/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.
サーバーが「true」に設定されたイベントヘッダーフィールド「body」パラメーターを使用してサブスクライブメッセージを受信すると、メッセージボディコンポーネントをメッセージ/httpメッセージボディに通知メッセージに送信することを選択できます。あるいは、ローカルポリシーに基づいて、このパラメーターが存在している場合でも、そのようなメッセージボディを送信することを拒否する場合があります。特に、サーバーが比較的少数のバイトよりも大きいHTTPメッセージボディを含めないというポリシーがあることは非常に合理的です。
When absent, the value of this parameter is assumed to be "false".
不在の場合、このパラメーターの値は「false」であると想定されます。
Note that this parameter refers to the message-body component of the HTTP message, not the message body component of the SIP message.
このパラメーターは、SIPメッセージのメッセージボディコンポーネントではなく、HTTPメッセージのメッセージボディコンポーネントを指していることに注意してください。
This event package defines no message bodies to be used in the SUBSCRIBE message.
このイベントパッケージは、サブスクライブメッセージで使用されるメッセージ本文を定義しません。
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-monitorイベントパッケージへのサブスクリプションの期間の合理的な値は、監視されているHTTPリソースの性質によって大きく異なります。一部のHTTPリソースは（これまでも）まれに変化しますが、他のリソースは比較的迅速に変化する可能性があります。急速に変化するドキュメントの場合、サブスクリプションの障害からより迅速に回復する能力は比較的重要であるため、1800〜3600秒（30分から1時間）に、サブスクリプション用のより少ない期間を選択することにより、実装を十分に提供します。
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.
サブスクリプションに有効期限が切れている場合、通知者はローカルポリシーに応じてデフォルトの有効期限を想定できます。このローカルポリシーは、監視対象のリソースのさまざまな側面を考慮に入れて、その年齢や妥当性の期間などを考慮することを選択する場合があります。他の情報がなければ、サーバーがクライアントが提供できない場合に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].
デフォルトでは、http-monitorイベントパッケージのnotifyメッセージのメッセージ本文は、RFC 2616 [2]で定義されているように、コンテンツタイプの「メッセージ/HTTP」のものです。
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モニターイベントパッケージで使用されているメッセージ本文を通知します。クライアントがHTTPリソースでHTTPヘッド操作を実行した場合に返される応答のサブセットを反映しています。
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
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で説明されているようにヌル状態を返しない限り、メッセージ/HTTPには少なくとも1つのETAGまたはMD5ヘッダーフィールドが含まれている必要があります。ラスト変更されたヘッダーフィールドを含めることもお勧めします。さらに、メッセージ/HTTPメッセージ本文には、監視対象のリソースを識別するコンテンツロケーションフィールドを含める必要があります。これは、リンク関連が元々取得された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モニターイベントパッケージで使用される場合、メッセージ/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スタート行には、ユーザーエージェントがヘッドリクエストで再配置されたHTTPリソースにアクセスしようとした場合に返される同じ3XXクラスのHTTP応答が含まれます。（例えば、「301は永続的に移動しました」）。メッセージ/HTTPには、リソースの新しい名前を伝えるロケーションヘッダーフィールドも含める必要があります。
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リソースの削除を表している場合、スタートラインには、ユーザーエージェントがヘッドリクエストで不足しているHTTPリソースにアクセスしようとした場合に返される同じ4xxクラスのHTTP応答が含まれます（例えば、「404は見つかりません」または「410 GONE」）。
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.
購読要求を受け取ると、宛先は現地ポリシーに従って許可を適用します。通常、このポリシーは、変更状態が要求されているリソースへのアクセスに関するHTTPサーバー認証ポリシーと一致します。
NOTIFY messages are generated whenever the underlying resource indicated by the corresponding HTTP URL has been modified.
対応するHTTP URLで示される基礎となるリソースが変更された場合、通知メッセージは生成されます。
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リソースに関する有用な情報を返すために不十分な情報を持っている場合、ゼロバイトのメッセージ本文を返す必要があります（通知メッセージの送信を抑制するメカニズムの対象となります）。
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.
通知メッセージを受信すると、サブスクライバーはメッセージ/HTTPに情報を適用して、基礎となるHTTPリソースのビューを更新します。ほとんどの場合、これによりHTTPリソースのビューが無効になります。通知メッセージへの反応として、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リソースの複数の通知者は、意味的に無意味です。サブスクライブリクエストがフォークされるという異常な状況では、RFC 3265のセクション4.4.9 [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-Monitorイベントパッケージの通知者は、毎秒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]に記載されている公開メカニズムに慣れることが奨励されています。
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.
次のメッセージは、例に関連するメッセージの部分のみを示しています。彼らは、典型的または必須ではあるが、前述のメッセージフローを理解するための鍵ではないフィールドを意図的に拡大します。
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/pet-profiles/alpacas/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、Content-MD5、およびLastModified Headerフィールドの存在にも注意してください。これらは、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
[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にサブスクライブリクエストを送信し、イベントタイプの「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>
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>
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メッセージを送信します。クライアントは、HTTP「200」の応答で受信したものとETAG、Content-MD5、またはLastModifiedヘッダーフィールドのコンテンツを比較して、最新バージョンのエンティティがあることを確認できます。
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
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
6. The client acknowledges receipt of the NOTIFY message.
6. クライアントは、Notifyメッセージの受信を確認します。
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>
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パブリッシュリクエストを使用して、この情報をSIPイベントサーバーに伝えることができます。出版メッセージ本文には、エンティティの状態に関する情報が含まれています。
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パブリッシュは、そのような情報を伝えることができる多くの方法の1つであることに注意してください。この情報を伝える他の手段も有効です。
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
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
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-TETAGヘッダーフィールドの値は、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
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
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
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>
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").
無担保リンクヘッダーフィールドは、輸送中に改ざん、または挿入される可能性があるため、クライアントの実装は、アプリケーションと偽造された通知セットとの相互作用を考慮する必要があります。この問題は、変更通知にエンティティ状態（「body = 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]を介して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].
「Webリンク」仕様[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-monitor
Type: package
タイプ：パッケージ
Contact: Adam Roach, adam@nostrum.com
連絡先：Adam Roach、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.
Lisa DusseaultとMark Nottinghamに、HTTP URLをSIP URIに結合するメカニズムに関する重要な入力に感謝します。このドキュメントの初期バージョンに関する徹底的なフィードバックをしてくれたMark NottinghamとTheo Zourzouvillysにも感謝します。マーティン・トンプソン、シダ・シューベルト、ジョン・エルウェル、スコット・ローレンスの慎重なレビューとフィードバックに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-HTTP/1.1"、RFC 2616、1999年6月。
[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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach、A。、「セッション開始プロトコル（SIP）特異的イベント通知」、RFC 3265、2002年6月。
[5] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[5] ノッティンガム、M。、編and R. Sayre、ed。、「The Atom Syndication Format」、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] Roach、A.、Campbell、B。、およびJ. Rosenberg、「セッション開始プロトコル（SIP）イベント通知拡張機能の拡張機能」、RFC 4662、2006年8月。
[7] Rosenberg, J., "Extensible Markup Language (XML) Formats for Representing Resource Lists", RFC 4826, May 2007.
[7] Rosenberg、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] Crocker、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] Camarillo、G.、Roach、A。、およびO. Levin、「セッション開始プロトコル（SIP）で要求されたリソースリストへのサブスクリプション」、RFC 5367、2008年10月。
[10] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[10] ノッティンガム、M。、「Web Linking」、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] Jacobs、I.、Hors、A。、およびD. Raggett、「HTML 4.01仕様」、World Wide Web Consortiumの推奨REC-HTML401-19991224、1999年12月、<http://www.w3.org/tr/1999/rec-html401-1991224>。
[12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[12] Rescorla、E。、「TLS上のHTTP」、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. Turner、「Secure/Multipurpose Internet Mail Extensions（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] Niemi、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] Camarillo、G。、「インターネットは、セッション開始プロトコル（SIP）のための数字権機関（IANA）ヘッダーフィールドパラメーターレジストリ」、BCP 98、RFC 3968、2004年12月。
[16] Dusseault, L., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007.
[16] Dusseault、L。、「Web分散オーサリングおよびバージョン（WebDav）のHTTP拡張機能」、RFC 4918、2007年6月。
[17] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[17]
[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.、Reed、D.、Chasen、L.、Tan、W。、およびS. Churchill、「Extensible Resource Identifier（XRI）Resolution V2.0」、2008年2月、<http：//docs.oasis-open.org/xri/2.0/specs/ xri-resolution-v2.0.html>。
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の両方を実行します。さらに、Propfindの使用には、HTTPユーザーエージェントのPropfindメソッドのサポートが必要です。これは、かなり十分に実装されていますが、GET実装の浸透がまだ欠けています。
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を使用するという利点があります。ただし、上記の2つのラウンドの問題の問題と、残念ながらプロパティを取得する方法を指定するための多数のオプションの両方に苦しんでいます。
Author's Address
著者の連絡先
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
Adam Roach Tekelec 17210 Campbell Rd。スイート250ダラス、テキサス州75252 US
EMail: adam@nostrum.com