One document matched: draft-roach-sip-http-subscribe-05.xml
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.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 rfc3968 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3968.xml'>
<!ENTITY rfc4287 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4287.xml'>
<!ENTITY rfc4662 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4662.xml'>
<!ENTITY rfc4826 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4826.xml'>
<!ENTITY rfc4918 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml'>
<!ENTITY rfc5367 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5367.xml'>
<!ENTITY draft-nottingham-http-link-header PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-nottingham-http-link-header-06.xml'>
<!ENTITY html401 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml4/reference.W3C.REC-html401-19991224.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="no" ?>
<?rfc symrefs="no"?>
<rfc ipr="trust200902" docName="draft-roach-sip-http-subscribe-05">
<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="December" day="2" year="2009" />
<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>
</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-http-api"/>.
-->
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.
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 SIPS URI to be
used for such subscriptions can be determined from the HTTP
server.
</t>
</section>
<section title="Terminology">
<t>
The capitalized terms "MUST," "SHOULD," "MAY," "SHOULD NOT," and "MUST NOT"
in this document are to be interpreted as described in RFC 2119
<xref target="RFC2119"/>.
</t>
<t>
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.
</t>
</section>
<section title="Associating Monitoring SIP URIs with HTTP URLs">
<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 link relations --
such as the HTTP Link: header field
<xref target="I-D.nottingham-http-link-header"/>,
the HTML <link/> element <xref target="W3C.REC-html401-19991224"/>,
and the Atom <atom:link/> element <xref target="RFC4287"/> --
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.
</t>
<t>
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.
</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 relationships with relations that allow for
monitoring of changes.
Implementors are cautioned to process all link relations
to locate a one that corresponds with
their preferred change monitoring protocol.
</t>
<t>
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.
</t>
<section title="Monitoring a Single HTTP Resource">
<t>
If an HTTP server wishes to offer the ability to subscribe to a
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.
</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 <xref target="package"/>.
</t>
</section>
<section title="Monitoring Multiple HTTP Resources">
<t>
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 <xref target="RFC4662"/> and/or
RFC 5367 <xref target="RFC5367"/>. 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.
</t>
<t>
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.
</t>
<t>
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 <xref target="RFC5367"/>.
This RLS service is not, however, required to accept URI lists
that include monitoring URIs that are not associated with
resources served by its related HTTP server. This allows
RLS functionality 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
<xref target="RFC4826"/> for the definition of the
"application/resource-lists+xml" MIME type.
</t>
<t>
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.
</t>
<t>
If a client wishes to subscribe to the state of multiple HTTP
resources, and has received monitor-group URIs for each of them,
it may use the monitor-group URIs to subscribe to multiple
resources in the same subscription. To do so, it starts with the
set of HTTP resources it wishes to monitor. It then groups
these resources by their respective monitor-group URIs. Finally,
for each such group, it initiates a subscription to the group's
monitor-group URI; this subscription includes a URI list,
as described in RFC 5367. The URI list contains all of the
URIs in the group.
</t>
<t>
<list style="hanging">
<t>
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.
</t>
<t>
<vspace/>
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.
</t>
</list>
</t>
</section>
<section title="Rationale: Other Approaches Considered">
<!-- <t><list style="hanging"> -->
<t>
<vspace blankLines="1"/>
[This section will be removed before publication
as an RFC]
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<!-- </list></t> -->
</section>
</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" anchor="event-parameters">
<t>
This event package defines a single parameter
to be used with the "Event" header field. The ABNF
for this parameter is shown below. The use of the
construction "EQUAL" is as defined by RFC 3261
<xref target="RFC3261"/>.
<figure><artwork>
body-event-param = "body" EQUAL ( "true" / "false" )
</artwork></figure>
</t>
<t>
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.
</t>
<t>
If a server receives a SUBSCRIBE message with a "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.
</t>
<t>
When absent, the value of this parameter is assumed to be "false".
</t>
<list style="hanging"><t>
<vspace/>
Note that this parameter refers to the message-body
component of the HTTP message, not the message body
component of the SIP message.
</t></list>
</section>
<section title="SUBSCRIBE Bodies">
<t>
This event package defines no message bodies to be used
in the SUBSCRIBE message. Future extensions
may define filter criteria to be sent in the
SUBSCRIBE message 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 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).
</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>
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.
</t>
<t>
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 may 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
(one day) when the client fails to provide one.
</t>
</section>
<section title="NOTIFY Bodies" anchor="notify-bodies">
<t>
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 <xref target="RFC2616"/>.
</t>
<section title="Use of message/http in HTTP Monitor Event Package">
<t>
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.
</t>
<t>
An example of a message/http message body as used in this
event package is shown below.
</t>
<figure><artwork>
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
</artwork></figure>
<t>
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 <xref
target='notifier-subscribe'/>.
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
<xref target="RFC2616"/>
for details.
</t>
<t>
Except for the foregoing normative requirements,
The decision regarding which HTTP header fields to
include is at the discretion of the notifier.
</t>
<t>
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 <xref target='event-parameters'/>.
</t>
<t>
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.
</t>
<t>
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").
</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 body that is zero
bytes long.
</t>
</section>
<section title="Subscriber processing of NOTIFY requests">
<t>
Upon receipt of a NOTIFY message, the subscriber should use
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.
</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">
<t>
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.
</t>
<figure> <artwork><![CDATA[
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 | |
|-------------------------------------->|
| | |
| | |
]]></artwork> </figure>
<t>
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.
</t>
<t><list style="numbers">
<t>
The client issues a GET request to retrieve
the document identified by the URL
"http://www.example.com/pet-profiles/alpacas/".
</t>
<figure><artwork><![CDATA[
GET /pet-profiles/alpacas/ HTTP/1.1
Host: www.example.com
]]></artwork></figure>
<t>
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. It should be
noted that, since the message-body is an HTML document,
the "monitor" link relation could alternately
be indicated in the HTML document itself, through
the use of a <link/> element.
<vspace blankLines="1"/>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.
</t>
<figure><artwork><![CDATA[
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]
]]></artwork></figure>
<t>
The client sends a SUBSCRIBE request to the
SIP URI indicated in the "monitor" link relation,
indicating an event type of "http-monitor".
</t>
<figure><artwork><![CDATA[
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>
]]></artwork></figure>
<t>
The SIP Events server acknowledges receipt
of the subscription request, and establishes
a dialog for the resulting subscription.
</t>
<figure><artwork><![CDATA[
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>
]]></artwork></figure>
<t>
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.
</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>
The client acknowledges receipt of the NOTIFY message.
</t>
<figure><artwork><![CDATA[
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>
]]></artwork></figure>
<t>
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.
<vspace blankLines="1"/>
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.
</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>
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.
</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>
The SIP events server informs the client of the change in
state for the subscribed resource using a NOTIFY message.
</t>
<figure><artwork><![CDATA[
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
]]></artwork></figure>
<t>
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.
</t>
<figure><artwork><![CDATA[
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>
]]></artwork></figure>
</list></t>
</section>
<section title="Security Considerations">
<t>
Unless secured using TLS, IPSEC, or a similar technology, the content of
the Link header field is not secure, private or integrity-guaranteed.
</t>
<t>
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.
</t>
<t>
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").
</t>
<t>
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).
</t>
</section>
<section title="IANA Considerations">
<section title="New Link Relations">
<t>
The following entries are to be added to the "Link Relation Type
Registry," as created by the "Web Linking" specification
<xref target="I-D.nottingham-http-link-header"/>.
<list style="hanging">
<t>
<vspace/>
Note: In the case that
the final, published version of "Web Linking"
<xref target="I-D.nottingham-http-link-header"/>
does not deprecate the registry defined in RFC4287
<xref target="RFC4287"/>, this section
will be changed to add the link relations to the registry
defined by RFC 4287.
[This note to be removed prior to publication as an RFC]
</t>
</list>
</t>
<section title="New Link Relation: monitor">
<t><list style="symbols">
<t> Relation Name: monitor</t>
<t> Description: Refers to a resource that can be used to monitor
changes in an HTTP resource.</t>
<t> Reference: RFC XXXX [[Note to RFC Editor: replace
with the RFC number for this specification]]</t>
</list></t>
</section>
<section title="New Link Relation: monitor-group">
<t><list style="symbols">
<t> Relation Name: monitor-group</t>
<t> Description: Refers to a resource that can be used to monitor
changes in a specified group of HTTP resources.</t>
<t> Reference: RFC XXXX [[Note to RFC Editor: replace
with the RFC number for this specification]]</t>
</list></t>
</section>
</section>
<section title="New SIP Event Package: http-monitor">
<t>
The following entry is to be added to the "SIP Events" registry,
as created by the SIP Event Framework <xref target="RFC3265"/>.
</t>
<t><list style="hanging">
<t hangText="Package Name:">http-monitor</t>
<t hangText="Type:">package</t>
<t hangText="Contact:">Adam Roach, adam@nostrum.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 Event Header Field Parameter: body">
<t>
The following entry is to be added to the SIP
"Header Field Parameters and Parameter Values" registry,
as created by the SIP Change Framework <xref target="RFC3968"/>.
</t>
<t><list style="hanging">
<t hangText="Header Field:">Event</t>
<t hangText="Parameter Name:">body</t>
<t hangText="Predefined Values:">yes</t>
<t hangText="Reference:">RFC XXXX [[Note to RFC Editor: replace
with the RFC number for this specification]]</t>
</list></t>
</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 also to Mark Nottingham and Theo Zourzouvillys for
thorough feedback on early versions of this document.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
&rfc2119;
&rfc2616;
&rfc3261;
&rfc3265;
&rfc4287;
&rfc4662;
&rfc4826;
&rfc5367;
&draft-nottingham-http-link-header;
&html401;
</references>
<references title='Informative References'>
&rfc3903;
&rfc3968;
&rfc4918;
<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>
<date month="February" day="28" year="2008" />
</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:05:01 |