[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 5989

SIP WG                                                       A. B. Roach
Internet-Draft                                                   Tekelec
Expires: May 24, 2009                                  November 20, 2008


   A SIP Event Package for Subscribing to Changes to an HTTP Resource
                   draft-roach-sip-http-subscribe-00

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 24, 2009.

Copyright Notice

   Copyright (C) The IETF Trust (2008).

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 events
   framework, for doing so.

   This document further proposes that the HTTP work necessary to make



Roach                     Expires May 24, 2009                  [Page 1]

Internet-Draft           SIP HTTP Subscriptions            November 2008


   such a mechanism work be extensible to support protocols other than
   SIP for monitoring HTTP resources.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Associating a Monitoring URI with an HTTP URL  . . . . . . . .  3
   3.  HTTP Change Event Package  . . . . . . . . . . . . . . . . . .  4
     3.1.  Event Package Name . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Event Package Parameters . . . . . . . . . . . . . . . . .  4
     3.3.  SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . .  5
     3.4.  Subscription Duration  . . . . . . . . . . . . . . . . . .  5
     3.5.  NOTIFY Bodies  . . . . . . . . . . . . . . . . . . . . . .  5
       3.5.1.  Formal definition of message/httpfrag  . . . . . . . .  5
       3.5.2.  Use of message/httpfrag in HTTP Monitor Event
               Package  . . . . . . . . . . . . . . . . . . . . . . .  6
     3.6.  Notifier processing of SUBSCRIBE requests  . . . . . . . .  7
     3.7.  Notifier generation of NOTIFY requests . . . . . . . . . .  7
     3.8.  Subscriber processing of NOTIFY requests . . . . . . . . .  7
     3.9.  Handling of forked requests  . . . . . . . . . . . . . . .  7
     3.10. Rate of notifications  . . . . . . . . . . . . . . . . . .  8
     3.11. State Agents . . . . . . . . . . . . . . . . . . . . . . .  8
   4.  Example Message Flow . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
     5.1.  New Link Relation  . . . . . . . . . . . . . . . . . . . .  9
     5.2.  New SIP Event Package  . . . . . . . . . . . . . . . . . .  9
     5.3.  New message/httpfrag MIME Type . . . . . . . . . . . . . .  9
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
   Intellectual Property and Copyright Statements . . . . . . . . . . 12

















Roach                     Expires May 24, 2009                  [Page 2]

Internet-Draft           SIP HTTP Subscriptions            November 2008


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, such as is
   described in [8] and [9].  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.  It further defines a mechanism by which the proper SIP
   and/or SIPS URI to be used for such subscriptions can be determined
   from the HTTP server.


2.  Associating a Monitoring URI with an HTTP URL

   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 to return
   that URI within an HTTP transaction.

   In particular, HTTP servers use the HTTP Link: header [5] with a
   relation type of "monitor" to convey the URI that can be used to
   discover changes to the resource.  This document defines behavior for
   SIP and SIPS URIs in this header.  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.

   Because a single resource may have the ability to be monitored via
   multiple protocols, it is perfectly legal for an HTTP response to
   contain multiple "Link:" headers with a relation type of "monitor".
   Implementors are cautioned to search the entire HTTP response header
   block to locate a "Link:" header that corresponds with their
   preferred change monitoring protocol.

   If an HTTP server provides the ability to subscribe to a changes in a
   resource's value using this event package, it MUST return a Link:
   header containing a SIP or SIPS URI with a relation type of "monitor"
   in any successful response to a GET or HEAD request on that resource.



Roach                     Expires May 24, 2009                  [Page 3]

Internet-Draft           SIP HTTP Subscriptions            November 2008


   It MAY return both.

   A client wishing to subscribe to the change state 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 Section 3.


      [This indented text to be removed before publication as an RFC]

      Several potential mechanisms for retrieving the SIP URI from the
      HTTP server were evaluated.  Of them, the HTTP Link: header was
      determined to have the most favorable set of properties.  Two key
      candidates that were considered but rejected in favor of Link: are
      discussed below.

      The HTTP PROPFIND method ([7], 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 [10] 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.


3.  HTTP Change Event Package

3.1.  Event Package Name

   The name of this event package is "http-monitor".

3.2.  Event Package Parameters

   This event package defines no parameters.  [TODO: should we define a
   simple filter that allows subscribers to request the body be sent in
   notifications?  Something like "body=true"?]






Roach                     Expires May 24, 2009                  [Page 4]

Internet-Draft           SIP HTTP Subscriptions            November 2008


3.3.  SUBSCRIBE Bodies

   This event package defines no bodies to be used in the SUBSCRIBE
   message.  Future extensions may define filter criteria to be sent in
   the SUBSCRIBE bodies.

3.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 other 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 type of subscriptions, expirations
   as long as 604800 (one week) or even longer may well make sense.

   Given the broad range of reasonable expirations involved, selecting a
   single default expiration is somewhat tricky.  However, in the
   absence of an expires value in a subscription, the notifier shall
   assume a default expiration value of 86400 (one day).

3.5.  NOTIFY Bodies

   By default, the bodies of NOTIFY messages for the http-monitor event
   package will be of content-type "message/httpfrag".  This content-
   type is defined below, as is its use in the http-monitor event
   package.

3.5.1.  Formal definition of message/httpfrag

   A valid message/httpfrag part is one that could be obtained by
   starting with some valid HTTP message and deleting any of the
   following:

   o  the entire start line
   o  one or more entire header fields
   o  the body

   The following Augmented Backus-Naur Form (ABNF) [1] rule describes a
   message/httpfrag part using the HTTP grammar elements defined in [2].
   The expansion of any element is subject to the restrictions on valid



Roach                     Expires May 24, 2009                  [Page 5]

Internet-Draft           SIP HTTP Subscriptions            November 2008


   HTTP message syntax defined in [2].

        httpfrag = [ start-line ]
                   *(message-header CRLF)
                   [ CRLF [ message-body ] ]

   If the message/httpfrag part contains a body, it MUST also contain
   the appropriate header fields describing that body (such as Content-
   Length) and the blank line separating the headers from the body.

3.5.2.  Use of message/httpfrag in HTTP Monitor Event Package

   The message/httpfrag NOTIFY bodies used in the HTTP monitor event
   package represent a subset of the HTTP response that would be
   returned if the client used an HTTP GET to retrieve the HTTP
   resource.  Except for the normative constraints described in the
   remainder of this section, the notifier MAY include any arbitrary
   subset of the HTTP response, including the entire set of headers.

   An example of a message/httpfrag body as used in this event package
   is shown below.

     ETag: 38fe6-58b-1840e7d0
     Last-Modified: Sat, 13 Nov 2010 23:29:00 GMT
     Content-MD5: 4e3b50421829c7c379a5c6154e560449

   When used in the HTTP monitor event package defined in this document,
   the message/httpfrag MUST contain at least one of an ETag or Content-
   MD5 header, unless returning a null state as described in
   Section 3.7.  It MAY contain both.  Inclusion of a Last-Modified
   header is also RECOMMENDED.

   When used in the HTTP monitor event package, the message/httpfrag
   MUST NOT contain a message-body component, unless the corresponding
   subscription has explicitly indicated the desire to receive such
   bodies in the form of a filter.  Filters for this event package are
   out of scope for this specification.

   If the change to the resource being communicated represents a
   modification of the resource's value, the message/httpfrag MAY
   contain a start line.  If present, this start line will contain a the
   same 2xx-class HTTP response that would be returned if a user agent
   attempted to access the HTTP resource with a GET request (e.g., "200
   OK").

   If the change to the resource being communicated represents a
   renaming of the HTTP resource, the message/httpfrag MUST contain a
   start line; this start line will contain a the same 3xx-class HTTP



Roach                     Expires May 24, 2009                  [Page 6]

Internet-Draft           SIP HTTP Subscriptions            November 2008


   response that would be returned if a user agent attempted to access
   the relocated HTTP resource with a GET request (e.g., "301 Moved
   Permanently").  The message/httpfrag also SHOULD contain a Location:
   header that communicates the new name of the resource.

   If the change to the resource being communicated represents a
   deletion of the HTTP resource, the message/httpfrag MUST contain a
   start line; this start line will contain a the same 4xx-class HTTP
   response that would be returned if a user agent attempted to access
   the missing HTTP resource with a GET request (e.g., "404 Not Found"
   or "410 Gone").

3.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.

3.7.  Notifier generation of NOTIFY requests

   NOTIFY messages should be 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 may
   return a message/httpfrag that is zero bytes long (which is a proper
   empty subset of the syntax described in section Section 3.5.1).

3.8.  Subscriber processing of NOTIFY requests

   Upon receipt of a NOTIFY message, subscriber should use any
   information in the message/httpfrag 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.

3.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].






Roach                     Expires May 24, 2009                  [Page 7]

Internet-Draft           SIP HTTP Subscriptions            November 2008


3.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.

3.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 [6].


4.  Example Message Flow

        Subscriber          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     |                   |
             |-------------------------------------->|
             |                   |(7) SIP PUBLISH    |
             |                   |------------------>|
             |                   |(8) SIP 200 OK     |
             |                   |<------------------|
             |(9) SIP NOTIFY     |                   |
             |<--------------------------------------|
             |(10) SIP 200       |                   |
             |-------------------------------------->|
             |                   |                   |
             |                   |                   |

   [TBD: include full example messages]



Roach                     Expires May 24, 2009                  [Page 8]

Internet-Draft           SIP HTTP Subscriptions            November 2008


5.  IANA Considerations

   [TBD: these sections need some prose to describe which registry we're
   putting the values in to]

5.1.  New Link Relation

   o  Relation Name: monitor
   o  Description: Refers to a resource that can be used to monitor
      changes.
   o  Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC
      number for this specification]]

5.2.  New SIP Event Package

   Package Name: http-monitor
   Type: package
   Contact: Adam Roach, adam.roach@tekelec.com
   Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC number
      for this specification]]

5.3.  New message/httpfrag MIME Type

   This document proposes a new message/httpfrag Message Media Type, to
   be registered at
   http://www.iana.org/assignments/media-types/message/.  This body type
   is described in section Section 3.5

   Media Type name:         message
   Media subtype name:      httpfrag
   Required parameters:     none
   Optional parameters:     version, msgtype

   version: The HTTP-Version number of the enclosed message (e.g.,
      "1.1").  If not present, the version can be determined from the
      first line of the body.
   msgtype: The message type -- "request" or "response".

   Encoding considerations: only "7bit", "8bit", or "binary" are
                            permitted
   Security considerations: none


6.  Acknowledgements

   Thanks to Lisa Dusseault and Mark Nottingham for significant input on
   the mechanisms to bind an HTTP URL to a SIP URI.  Thanks to Robert
   Sparks for the message/sipfrag specification, from which the message/



Roach                     Expires May 24, 2009                  [Page 9]

Internet-Draft           SIP HTTP Subscriptions            November 2008


   httpfrag definition was lifted wholesale.


7.  References

7.1.  Normative References

   [1]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 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., "HTTP Header Linking",
        draft-nottingham-http-link-header-02 (work in progress),
        July 2008.

7.2.  Informative References

   [6]   Niemi, A., "Session Initiation Protocol (SIP) Extension for
         Event State Publication", RFC 3903, October 2004.

   [7]   Dusseault, L., "HTTP Extensions for Web Distributed Authoring
         and Versioning (WebDAV)", RFC 4918, June 2007.

   [8]   Griffin, K. and J. Rosenberg, "Representational State Transfer
         (REST) for Feature Configuration in Session  Initiation
         Protocol (SIP)", draft-griffin-bliss-rest-00 (work in
         progress), October 2008.

   [9]   Zourzouvillys, T., "Automatic Call Handling (ACH) Configuration
         Requirements",
         draft-zourzouvillys-bliss-ach-config-requirements-00 (work in
         progress), October 2008.

   [10]  Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill,
         "Extensible Resource Identifier (XRI) Resolution V2.0", <http:/
         /docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html>.





Roach                     Expires May 24, 2009                 [Page 10]

Internet-Draft           SIP HTTP Subscriptions            November 2008


Author's Address

   Adam Roach
   Tekelec
   17210 Campbell Rd.
   Suite 250
   Dallas, TX  75252
   US

   Email: adam@nostrum.com









































Roach                     Expires May 24, 2009                 [Page 11]

Internet-Draft           SIP HTTP Subscriptions            November 2008


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The IETF Trust (2008).  This document is subject to the
   rights, licenses and restrictions contained in BCP 78, and except as
   set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Roach                     Expires May 24, 2009                 [Page 12]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/