A SIP Event Package for Subscribing to Changes to an HTTP Resource
Extracted elements (25)
Decomposition of authority for HTTP resources into a separate HTTP server and SIP Events server is anticipated as useful for scalability. The PUBLISH mechanism (RFC 3903) is recommended for communicating state changes from the HTTP server to the SIP Events server in such deployments.
Link relations were chosen over HTTP PROPFIND and XRDS for associating monitoring SIP URIs with HTTP URLs because link relations allow the SIP URI to be returned in the same GET/HEAD transaction that retrieves the document, avoiding an extra round trip. PROPFIND requires a separate request and wider (but still incomplete) client support; XRDS also requires two round trips and has an excessive number of retrieval options.
The SIP-ETag returned by the SIP Events server in response to a PUBLISH message is not related to the ETag header field associated with the HTTP entity; implementors must not conflate these two separate identifiers.
To monitor multiple HTTP resources efficiently, clients may use the 'monitor-group' URI to group resources sharing a common monitor-group link into a single SUBSCRIBE request per group, using request-contained resource lists per RFC 5367. This avoids the overhead of a separate subscription per resource.
Clients making use of the http-monitor mechanism MUST support the HTTP Link header field. Clients that support HTML SHOULD support the HTML <link/> element; those supporting Atom SHOULD support Atom <atom:link/> elements.
If an HTTP resource is restricted using 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, to prevent unauthorized information disclosure.
If the HTTP resource is encrypted or integrity-protected in transit (e.g., via HTTPS), then the SIP means of subscribing MUST also have appropriate encryption or integrity protection applied, such as SIPS URI or S/MIME bodies.
If 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.
In the aberrant circumstance that a SUBSCRIBE request is forked, the subscriber SHOULD terminate all but one subscription, as described in RFC 3265 Section 4.4.9, since multiple notifiers for a single HTTP resource is semantically nonsensical.
Notifiers for the http-monitor event package SHOULD NOT send notifications more frequently than once every second, to protect the network from excessive load.
NOTIFY message bodies for the http-monitor event package SHOULD contain at least one of an ETag or Content-MD5 header field (unless returning null state), and including a Last-Modified header field is RECOMMENDED. The message/http body MUST contain a Content-Location field identifying the monitored resource.
The message/http body in NOTIFY messages MUST NOT contain a message-body component unless the subscription has explicitly indicated the desire to receive such bodies via the 'body=true' parameter.
The monitor-group URI MUST correspond to an RLS service that supports subscriptions to request-contained resource lists as defined in RFC 5367. The HTTP server MUST also return a 'monitor' link relation whenever it returns a 'monitor-group' link relation.
The 'body' Event header field parameter (ABNF: body-event-param = 'body' EQUAL ('true' / 'false')) controls whether NOTIFY messages include the HTTP message-body component. When absent, defaults to 'false'.
The 'http-monitor' SIP event package enables clients to subscribe to changes in HTTP resources. Subscriptions are initiated via SUBSCRIBE requests to a SIP/SIPS URI obtained from the HTTP server's link relations.
The 'monitor-group' link relation type conveys a SIP or SIPS URI corresponding to an RLS service that supports subscriptions to multiple HTTP resources from the same server in a single SUBSCRIBE request.
The 'monitor' link relation type is used in HTTP responses (via Link header, HTML <link/>, or Atom <atom:link/>) to convey the SIP or SIPS URI that can be used to subscribe to changes in a single HTTP resource.
The subscription duration for http-monitor should balance server load against failure recovery time. Rapidly changing resources warrant 1800–3600 seconds; slowly changing resources may use up to 604800 seconds (one week) or longer. Default server assumption in the absence of an Expires value is 86400 seconds.
A new Event header field parameter 'body' with predefined values ('true'/'false') is registered in the SIP 'Header Field Parameters and Parameter Values' registry, as created by RFC 3968.
A new SIP event package named 'http-monitor' of type 'package' is registered in the IANA 'SIP Events' registry, as created by RFC 3265.
Two new link relation types are registered in the IANA 'Link Relation Types' registry (created by RFC 5988): 'monitor' (refers to a resource for monitoring changes in an HTTP resource) and 'monitor-group' (refers to a resource for monitoring changes in a group of HTTP resources).
Because the Link header field can be tampered with or inserted in transit, clients must consider the impact of a forged set of notifications on their application, particularly when change notifications include entity state ('body=true').
Unless secured via TLS, IPsec, or similar, the Link header field is not secure, private, or integrity-protected. Server implementations must not use the Link header field value as a security token for authentication or authorization.
For resource renaming, the message/http start line contains a 3xx-class HTTP response (e.g., '301 Moved Permanently') and SHOULD contain a Location header with the new resource name. For deletion, the start line contains a 4xx-class response (e.g., '404 Not Found' or '410 Gone').
NOTIFY message bodies use content-type 'message/http' (defined in RFC 2616) and reflect a subset of the HTTP HEAD response for the monitored resource, including status line, ETag, Content-MD5, Last-Modified, Content-Location, and optionally the entity body.