One document matched: draft-roach-sip-http-subscribe-00.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2234 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2234.xml'>
<!ENTITY rfc2616 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml'>
<!ENTITY rfc3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY rfc3265 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3265.xml'>
<!ENTITY rfc3903 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3903.xml'>
<!ENTITY rfc4918 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'>
<!ENTITY draft-nottingham-http-link-header PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-http-link-header-02.xml'>
<!ENTITY draft-griffin-bliss-rest PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-griffin-bliss-rest-00.xml'>
<!ENTITY draft-zourzouvillys-bliss-ach-config-requirements PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-zourzouvillys-bliss-ach-config-requirements-00.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<rfc ipr="full3978" docName="draft-roach-sip-http-subscribe-00">
<front>
<title abbrev="SIP HTTP Subscriptions">A SIP Event Package for Subscribing to Changes to an HTTP Resource</title>
<author initials="A. B." surname="Roach" fullname="Adam Roach">
<organization>Tekelec</organization>
<address>
<postal>
<street>17210 Campbell Rd.</street>
<street>Suite 250</street>
<city>Dallas</city> <region>TX</region> <code>75252</code>
<country>US</country>
</postal>
<email>adam@nostrum.com</email>
</address>
</author>
<date month="November" day="20" year="2008" />
<area>Real Time Applications and Infrastructure</area>
<workgroup>SIP WG</workgroup>
<abstract>
<t>
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.
</t>
<t>
This document further proposes that the HTTP work necessary
to make such a mechanism work be extensible to support protocols
other than SIP for monitoring HTTP resources.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
The Session Initiation Protocol (SIP)
<xref target="RFC3261"/>
is increasingly being
used in systems that are tightly coupled with Hypertext
Transport Protocol (HTTP)
<xref target="RFC2616"/>
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
<xref target="I-D.griffin-bliss-rest"/>
and
<xref target="I-D.zourzouvillys-bliss-ach-config-requirements"/>.
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.
</t>
<t>
This document defines a mechanism, based on the SIP Event Framework
<xref target="RFC3265"/>, 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.
</t>
</section>
<section title="Associating a Monitoring URI with an HTTP URL">
<t>
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.
</t>
<t>
In particular, HTTP servers use the HTTP Link: header
<xref target="I-D.nottingham-http-link-header"/>
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.
</t>
<t>
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.
</t>
<t>
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. It MAY return both.
</t>
<t>
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 <xref target="package"/>.
</t>
<t><list style="hanging">
<t>
<vspace blanklines="1"/>
[This indented text to be removed before publication
as an RFC]
<vspace blanklines="1"/>
</t>
<t>
<vspace blanklines="1"/>
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.
<vspace blanklines="1"/>
</t>
<t>
<vspace blanklines="1"/>
The HTTP PROPFIND method (<xref target="RFC4918"/>, 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.
<vspace blanklines="1"/>
</t>
<t>
<vspace blanklines="1"/>
Similar to PROPFIND, XRDS
<xref target="XRI_Resolution_2.0"/>
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.
<vspace blanklines="1"/>
</t>
</list></t>
</section>
<section title="HTTP Change Event Package" anchor="package">
<t>
</t>
<section title="Event Package Name">
<t>
The name of this event package is "http-monitor".
</t>
</section>
<section title="Event Package Parameters">
<t>
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"?]
</t>
</section>
<section title="SUBSCRIBE Bodies">
<t>
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.
</t>
</section>
<section title="Subscription Duration">
<t>
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).
</t>
<t>
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.
</t>
<t>
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).
</t>
</section>
<section title="NOTIFY Bodies" anchor="notify-bodies">
<t>
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.
</t>
<section title="Formal definition of message/httpfrag"
anchor="httpfrag">
<t>
A valid message/httpfrag part is one that could be
obtained by starting with some valid HTTP message and
deleting any of the following:
</t>
<t><list style="symbols">
<t>the entire start line</t>
<t>one or more entire header fields</t>
<t>the body</t>
</list></t>
<t>
The following Augmented Backus-Naur Form (ABNF)
<xref target="RFC2234"/> rule
describes a message/httpfrag part using the HTTP grammar
elements defined in <xref target="RFC2616"/>.
The expansion of any element
is subject to the restrictions on valid HTTP message
syntax defined in <xref target="RFC2616"/>.
</t>
<figure><artwork>
httpfrag = [ start-line ]
*(message-header CRLF)
[ CRLF [ message-body ] ]
</artwork></figure>
<t>
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.
</t>
</section>
<section title="Use of message/httpfrag in HTTP Monitor Event Package">
<t>
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.
</t>
<t>
An example of a message/httpfrag body as used in this
event package is shown below.
</t>
<figure><artwork>
ETag: 38fe6-58b-1840e7d0
Last-Modified: Sat, 13 Nov 2010 23:29:00 GMT
Content-MD5: 4e3b50421829c7c379a5c6154e560449
</artwork></figure>
<t>
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
<xref target='notifier-subscribe'/>. It MAY contain
both. Inclusion of a Last-Modified header is
also RECOMMENDED.
</t>
<t>
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.
</t>
<t>
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").
</t>
<t>
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
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.
</t>
<t>
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").
</t>
</section>
</section>
<section title="Notifier processing of SUBSCRIBE requests">
<t>
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.
</t>
</section>
<section title="Notifier generation of NOTIFY requests"
anchor='notifier-subscribe'>
<t>
NOTIFY messages should be generated whenever the
underlying resource indicated by the corresponding
HTTP URL has been modified.
</t>
<t>
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 <xref target='httpfrag'/>).
</t>
</section>
<section title="Subscriber processing of NOTIFY requests">
<t>
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.
</t>
</section>
<section title="Handling of forked requests">
<t>
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 <xref target="RFC3265"/>.
</t>
</section>
<section title="Rate of notifications">
<t>
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.
</t>
</section>
<section title="State Agents">
<t>
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
<xref target="RFC3903"/>.
</t>
</section>
</section>
<section title="Example Message Flow">
<figure> <artwork><![CDATA[
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 | |
|-------------------------------------->|
| | |
| | |
]]></artwork> </figure>
<t>
[TBD: include full example messages]
</t>
</section>
<section title="IANA Considerations">
<t>
[TBD: these sections need some prose to describe
which registry we're putting the values in to]
</t>
<section title="New Link Relation">
<t><list style="symbols">
<t> Relation Name: monitor</t>
<t> Description: Refers to a resource that can be used to monitor
changes.</t>
<t> Reference: RFC XXXX [[Note to RFC Editor: replace
with the RFC number for this specification]]</t>
</list></t>
</section>
<section title="New SIP Event Package">
<t><list style="hanging">
<t hangText="Package Name:"> http-monitor</t>
<t hangText="Type:"> package</t>
<t hangText="Contact:"> Adam Roach, adam.roach@tekelec.com</t>
<t hangText="Reference:"> RFC XXXX [[Note to RFC Editor: replace
with the RFC number for this specification]]</t>
</list></t>
</section>
<section title="New message/httpfrag MIME Type">
<t>
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
<xref target="notify-bodies"/>
</t>
<figure><artwork>
Media Type name: message
Media subtype name: httpfrag
Required parameters: none
Optional parameters: version, msgtype
</artwork></figure>
<t><list style="hanging">
<t hangText="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.</t>
<t hangText="msgtype:">The message type -- "request" or "response".</t>
</list></t>
<figure><artwork>
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
Security considerations: none
</artwork></figure>
</section>
</section>
<section title="Acknowledgements">
<t>
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/httpfrag definition
was lifted wholesale.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2234;
&rfc2616;
&rfc3261;
&rfc3265;
&draft-nottingham-http-link-header;
</references>
<references title='Informative References'>
&rfc3903;
&rfc4918;
&draft-griffin-bliss-rest;
&draft-zourzouvillys-bliss-ach-config-requirements;
<reference anchor="XRI_Resolution_2.0"
target="http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html" >
<front>
<title>Extensible Resource Identifier (XRI) Resolution V2.0</title>
<author initials='G.W' surname='Wachob' fullname="Gabe Wachob">
<organization>Visa International</organization>
</author>
<author initials='D.R' surname='Reed' fullname="Drummond Reed">
<organization>Cordance</organization>
</author>
<author initials='L.C' surname='Chasen' fullname="Les Chasen">
<organization>NeuStar</organization>
</author>
<author initials='W.T' surname='Tan' fullname="William Tan">
<organization>NeuStar</organization>
</author>
<author initials='S.C' surname='Churchill' fullname="Steve Churchill">
<organization>XDI.ORG</organization>
</author>
</front>
<format type="PDF" target="http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.pdf" />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:04:57 |