Internet Engineering Task Force (IETF) A.B. Roach
Request for Comments: 5989 Tekelec
Category: Standards Track October 2010
ISSN: 2070-1721
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信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第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
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.
本文档基于SIP事件框架[4]定义了一种机制，用于订阅HTTP服务器引用的资源中的更改。此类订阅不一定包含与资源关联的内容。在内容未被传输的情况下，HTTP协议仍然用于传输HTTP资源的内容。本文档进一步定义了一种机制，通过该机制可以从HTTP服务器确定用于此类订阅的适当SIP和/或会话启动协议安全（SIPS）URI。
The capitalized terms "MUST", "SHOULD", "MAY", "SHOULD NOT", and "MUST NOT" in this document are to be interpreted as described in RFC 2119 [1].
本文件中大写的术语“必须”、“应该”、“可以”、“不应该”和“不得”应按照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指示的资源更改的关键挑战之一是确定哪个SIPURI对应于特定的HTTP URL。该规范采用的方法是让负责相关URL的HTTP服务器为相应的资源选择适当的SIPURI，并在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.
具体而言，HTTP服务器使用链接关系——如HTTP链接头字段[10]、HTML<link/>元素[11]和Atom<Atom:link/>元素[5]——来传递可用于发现资源更改的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文档处理的应该支持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或HEAD请求的成功响应中返回一个包含SIP或SIPS URI且关系类型为“monitor”的链接关系。如果服务器同时支持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资源状态更改的客户端通过向其希望监视的HTTP URL发送GET或HEAD请求来获得SIP或SIPS URI。然后，根据第4节中定义的事件包，在订阅请求中使用该SIP或SIPS URI。
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资源的状态的能力，那么它将在对任何可监视资源上的GET或HEAD请求的成功响应中返回一个包含SIP或SIPS URI的链接关系，其关系类型为“monitor group”。通常，对于同一HTTP服务器上的所有资源，此监视组URI都是相同的。
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服务可以（但不是必需的）接受URI列表，该列表包括与其相关HTTP服务器提供的资源不关联的监视URI。不需要此类功能允许在不需要后端订阅的情况下实现RLS。如果服务器希望拒绝此类请求，“403”（禁止）响应代码是合适的。为此原因生成的任何“403”响应都应包含“应用程序/资源列表+xml”类型的消息体；此消息正文列出了有问题的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服务器还必须返回关系类型为“monitor”的SIP和/或SIPS链接关系，只要它返回关系类型为“monitor group”的SIP和/或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,
如果客户机希望订阅多个HTTP资源的状态，并且已收到每个HTTP资源的监控组URI，则它可以使用监控组URI订阅同一订阅中的多个资源。为此，它从希望监视的HTTP资源集开始。然后，它通过各自的监视组URI对这些资源进行分组。最后，对于每个这样的群体，
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.
它发起对组的监控组URI的订阅；此订阅包括一个URI列表，如RFC 5367中所述。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对这些资源执行HEAD和/或GET操作。对这些操作的响应将包含四个资源中每个资源的监视器和监视器类型的链接关系。假设监视器链接为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，而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 在一次订阅中。它将此订阅发送到监控组URI（sip:httpmon@rls.example.com)，以及包含相关监控器URI的资源列表（sip:a94aa000@example.com及sip:23ec24c5@example.com). 然后，它对其余两个HTTP资源重复此过程，以相同的方式使用它们的监视组和监视URI。
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[8]中定义的ABNF格式。构造“EQUAL”的使用如RFC 3261[3]所定义。
body-event-param = "body" EQUAL ( "true" / "false" )
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”，则此参数向服务器指示客户端希望接收在NOTIFY messages中发送的message/http message body中的message body组件。
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.
如果服务器接收到事件头字段“body”参数设置为“true”的订阅消息，它可以选择在其在NOTIFY messages中发送的消息/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.
请注意，此参数指的是HTTP消息的消息体组件，而不是SIP消息的消息体组件。
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秒（一周）甚至更长的过期时间可能是有意义的。
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.
在订阅中没有expires值的情况下，通知程序可以根据本地策略假定默认的过期期限。该本地政策可能会选择考虑受监控资源的各个方面，例如其年龄和假定有效期。在没有任何其他信息的情况下，当客户端无法提供默认过期值时，服务器假定默认过期值为86400秒（一天）是合理的。
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监视器事件包的NOTIFY消息的消息体将为RFC 2616[2]中定义的内容类型“message/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 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
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应至少包含一个ETag或Content-MD5头字段，除非如第4.7节所述返回空状态。还建议包含上次修改的标题字段。此外，消息/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节所述的此类正文。
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起始行将包含相同的3xx类HTTP响应，如果用户代理尝试使用HEAD请求访问重新定位的HTTP资源（例如，“301永久移动”），将返回该3xx类HTTP响应。message/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资源，则起始行将包含相同的4xx类HTTP响应，如果用户代理尝试使用HEAD请求访问丢失的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.
收到订阅请求后，通知程序根据本地策略应用授权。通常，此策略将与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.
在收到NOTIFY消息后，订户应用消息/http中的任何信息来更新其对底层http资源的视图。在大多数情况下，这会导致其HTTP资源视图无效。由订户实现决定是否适合获取HTTP资源的新副本作为对NOTIFY消息的响应。
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.4.9节所述，在订阅请求被分叉的异常情况下，订阅方应终止除一个订阅外的所有订阅。
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监视器事件包的通知程序发送通知的频率不应超过每秒一次。
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资源的权限分解为HTTP服务器和SIP事件服务器可能很有用，因为与服务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 | |
|-------------------------------------->|
| | |
| | |
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. 客户端发出GET请求以检索URL标识的文档“http://www.example.com/pet-profiles/alpacas/".
GET /pet-profiles/alpacas/ HTTP/1.1
Host: www.example.com
GET /pet-profiles/alpacas/ HTTP/1.1
Host: 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
2. HTTP服务器用文档和一些相关的元数据进行响应。本例的关键关注点是带有“rel”参数“monitor”的Link header字段。这是客户端将用于监视HTTP资源状态更改的SIPURL。注意，由于消息体
is an HTML document, the "monitor" link relation could alternately be indicated in the HTML document itself, through the use of a <link/> element.
如果是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和Last-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: 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. 客户端向“监视器”链接关系中指示的SIPURI发送订阅请求，指示“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>
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>
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资源当前状态的通知消息。客户端可以将ETag、Content-MD5或Last-Modified报头字段的内容与HTTP“200”响应中接收到的内容进行比较，以验证其是否具有实体的最新版本。
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
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
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. 客户确认收到通知消息。
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
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发布是传递此类信息的多种方式之一——任何其他传递此信息的方式都是有效的。
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
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
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 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
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
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
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>
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上的HTTP[12]），那么订阅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 关系名称：monitor
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事件框架创建的“SIP事件”注册表中[4]。
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变更框架创建的SIP“Header Field Parameters and Parameter Values”注册表中[15]。
Header Field: Event
标题字段：事件
Parameter Name: body
参数名称：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对本文档早期版本的全面反馈。感谢Martin Thompson、Shida Schubert、John Elwell和Scott Lawrence的仔细评论和反馈。
[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] 菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC2616，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：会话启动协议”，RFC 3261，2002年6月。
[4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002.
[4] Roach，A.，“会话启动协议（SIP）-特定事件通知”，RFC3265，2002年6月。
[5] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005.
[5] 诺丁汉，M.，Ed.和R.Sayre，Ed.，“原子联合格式”，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）格式”，RFC4826，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.，“网络链接”，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规范”，万维网联盟建议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] 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，“安全/多用途Internet邮件扩展（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）的Internet分配号码管理局（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扩展”，RFC4918，2007年6月。
[17] Audet, F., "The Use of the SIPS URI Scheme in the Session Initiation Protocol (SIP)", RFC 5630, October 2009.
[17] Audet，F.，“会话启动协议（SIP）中SIPS URI方案的使用”，RFC 5630，2009年10月。
[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，“可扩展资源标识符（XRI）决议V2.0”，2008年2月<http://docs.oasis-open.org/xri/2.0/specs/ xri-resolution-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服务器检索SIPURI的几种可能机制。其中，链接关系被确定为具有最有利的属性集。下面将讨论两个关键候选项，这两个候选项已被考虑，但因链接关系而被拒绝。
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类似，XRD（可扩展资源描述符序列）[18]可用于检索与HTTP URL关联的属性。它的优点是使用GET而不是PROPFIND；但是，它同时受到上面讨论的两个往返问题的影响，而且不幸的是，在指定如何检索属性时有大量的选项。
Author's Address
作者地址
Adam Roach Tekelec 17210 Campbell Rd. Suite 250 Dallas, TX 75252 US
美国德克萨斯州达拉斯坎贝尔路17210号Adam Roach Tekelec 250套房，邮编75252
EMail: adam@nostrum.com
EMail: adam@nostrum.com