doc: Add RFC documents

1 files changed, 1067 insertions, 0 deletions

diff --git a/doc/rfc/rfc5989.txt b/doc/rfc/rfc5989.txt
new file mode 100644
index 0000000..6991114
--- /dev/null
+++ b/doc/rfc/rfc5989.txt
@@ -0,0 +1,1067 @@
+
+
+
+
+
+
+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
+
+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.
+
+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.
+
+   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.
+
+Copyright Notice
+
+   Copyright (c) 2010 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   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.
+
+
+
+
+
+Roach                        Standards Track                    [Page 1]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 2]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+1.  Introduction
+
+   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.
+
+   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.
+
+2.  Terminology
+
+   The capitalized terms "MUST", "SHOULD", "MAY", "SHOULD NOT", and
+   "MUST NOT" in this document are to be interpreted as described in 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.
+
+3.  Associating Monitoring SIP URIs with HTTP URLs
+
+   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.
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 3]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+3.1.  Monitoring a Single HTTP Resource
+
+   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.
+
+   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.
+
+
+
+
+
+
+Roach                        Standards Track                    [Page 4]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+3.2.  Monitoring Multiple HTTP Resources
+
+   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.
+
+   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.
+
+   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.
+
+   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.
+
+   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,
+
+
+
+
+Roach                        Standards Track                    [Page 5]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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.
+
+      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.
+
+      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.
+
+4.  HTTP Change Event Package
+
+4.1.  Event Package Name
+
+   The name of this event package is "http-monitor".
+
+4.2.  Event Package Parameters
+
+   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].
+
+     body-event-param = "body" EQUAL ( "true" / "false" )
+
+
+
+
+
+Roach                        Standards Track                    [Page 6]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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.
+
+   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.
+
+   When absent, the value of this parameter is assumed to be "false".
+
+      Note that this parameter refers to the message-body component of
+      the HTTP message, not the message body component of the SIP
+      message.
+
+4.3.  SUBSCRIBE Bodies
+
+   This event package defines no message bodies to be used in the
+   SUBSCRIBE message.
+
+4.4.  Subscription Duration
+
+   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).
+
+   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.
+
+   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
+
+
+
+
+Roach                        Standards Track                    [Page 7]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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.
+
+4.5.  NOTIFY Bodies
+
+   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].
+
+4.5.1.  Use of message/http in HTTP Monitor Event Package
+
+   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.
+
+   An example of a message/http message body as used in this event
+   package is shown below.
+
+     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.
+
+
+
+
+
+Roach                        Standards Track                    [Page 8]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   Except for the foregoing normative requirements, the decision
+   regarding which HTTP header fields to include is at the discretion of
+   the notifier.
+
+   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.
+
+   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.
+
+   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").
+
+4.6.  Notifier Processing of SUBSCRIBE Requests
+
+   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.
+
+4.7.  Notifier Generation of NOTIFY Requests
+
+   NOTIFY messages are generated whenever the underlying resource
+   indicated by the corresponding HTTP URL has been modified.
+
+   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).
+
+4.8.  Subscriber Processing of NOTIFY Requests
+
+   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.
+
+
+
+Roach                        Standards Track                    [Page 9]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+4.9.  Handling of Forked Requests
+
+   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].
+
+4.10.  Rate of Notifications
+
+   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.
+
+4.11.  State Agents
+
+   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].
+
+5.  Example Message Flow
+
+   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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 10]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+          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/".
+
+     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
+
+
+
+Roach                        Standards Track                   [Page 11]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+      is an HTML document, the "monitor" link relation could alternately
+      be indicated in the HTML document itself, through the use of a
+      <link/> element.
+
+      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.
+
+     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]
+
+   3. The client sends a SUBSCRIBE request to the SIP URI indicated in
+      the "monitor" link relation, indicating an event type of "http-
+      monitor".
+
+     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.
+
+     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.
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 12]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+     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.
+
+     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.
+
+      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.
+
+     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
+
+
+
+
+Roach                        Standards Track                   [Page 13]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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.
+
+     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.
+
+     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.
+
+     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>
+
+6.  Security Considerations
+
+   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.
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 14]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+   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").
+
+   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).
+
+   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].
+
+7.  IANA Considerations
+
+7.1.  New Link Relations
+
+   The following entries have been added to the "Link Relation Types"
+   registry, as created by the "Web Linking" specification [10].
+
+7.1.1.  New Link Relation: monitor
+
+   o  Relation Name: monitor
+
+   o  Description: Refers to a resource that can be used to monitor
+      changes in an HTTP resource.
+
+   o  Reference: RFC 5989
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 15]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+7.1.2.  New Link Relation: monitor-group
+
+   o  Relation Name: monitor-group
+
+   o  Description: Refers to a resource that can be used to monitor
+      changes in a specified group of HTTP resources.
+
+   o  Reference: RFC 5989
+
+7.2.  New SIP Event Package: http-monitor
+
+   The following entry is to be added to the "SIP Events" registry, as
+   created by the SIP Event Framework [4].
+
+   Package Name:  http-monitor
+
+   Type:  package
+
+   Contact:  Adam Roach, adam@nostrum.com
+
+   Reference:  RFC 5989
+
+7.3.  New Event Header Field Parameter: body
+
+   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].
+
+   Header Field:  Event
+
+   Parameter Name:  body
+
+   Predefined Values:  yes
+
+   Reference:  RFC 5989
+
+8.  Acknowledgements
+
+   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.
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 16]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+9.  References
+
+9.1.  Normative References
+
+   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
+         Levels", BCP 14, RFC 2119, March 1997.
+
+   [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.
+
+   [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.
+
+   [4]   Roach, A., "Session Initiation Protocol (SIP)-Specific Event
+         Notification", RFC 3265, June 2002.
+
+   [5]   Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
+         Format", RFC 4287, December 2005.
+
+   [6]   Roach, A., Campbell, B., and J. Rosenberg, "A Session
+         Initiation Protocol (SIP) Event Notification Extension for
+         Resource Lists", RFC 4662, August 2006.
+
+   [7]   Rosenberg, J., "Extensible Markup Language (XML) Formats for
+         Representing Resource Lists", RFC 4826, May 2007.
+
+   [8]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
+         Specifications: ABNF", STD 68, RFC 5234, January 2008.
+
+   [9]   Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
+         Request-Contained Resource Lists in the Session Initiation
+         Protocol (SIP)", RFC 5367, October 2008.
+
+   [10]  Nottingham, M., "Web Linking", RFC 5988, October 2010.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 17]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+9.2.  Informative References
+
+   [12]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
+
+   [13]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail
+         Extensions (S/MIME) Version 3.2 Message Specification",
+         RFC 5751, January 2010.
+
+   [14]  Niemi, A., "Session Initiation Protocol (SIP) Extension for
+         Event State Publication", RFC 3903, October 2004.
+
+   [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.
+
+   [16]  Dusseault, L., "HTTP Extensions for Web Distributed Authoring
+         and Versioning (WebDAV)", RFC 4918, June 2007.
+
+   [17]  Audet, F., "The Use of the SIPS URI Scheme in the Session
+         Initiation Protocol (SIP)", RFC 5630, October 2009.
+
+   [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 18]
+
+RFC 5989                 SIP HTTP Subscriptions             October 2010
+
+
+Appendix A.  Rationale: Other Approaches Considered
+
+   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.
+
+   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.
+
+   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.
+
+Author's Address
+
+   Adam Roach
+   Tekelec
+   17210 Campbell Rd.
+   Suite 250
+   Dallas, TX  75252
+   US
+
+   EMail: adam@nostrum.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Roach                        Standards Track                   [Page 19]
+