RFC 5989

A SIP Event Package for Subscribing to Changes to an HTTP Resource

📅 published October 2010, from ietf

RFC 5989 🎀 A SIP Event Package for Subscribing to Changes to an HTTP Resource

Okay bestie, this one is RFC 5989 💖. It's a Standards Track doc from October 2010 (ISSN 2070-1721), written by A.B. Roach at Tekelec ✨. The header doesn't list anything it obsoletes or updates, so it's a clean slate 🦋.

Abstract ✨

SIP is basically everywhere now, and it's super tightly coupled with HTTP servers for all kinds of reasons 🌸. A lot of apps would love to find out in near real-time when a specific HTTP resource gets created, changed, or deleted 👀. This doc proposes a way to do exactly that, built on the SIP Event Framework 💅.

Status of This Memo

This is an Internet Standards Track document 🔥.

This doc is a product of the Internet Engineering Task Force (IETF) 🌈. It represents the consensus of the IETF community, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). For more on Internet Standards, check Section 2 of RFC 5741 📚.

For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc5989 🧚.

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) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document 🙈. Code Components pulled out of this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶.

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

1. Introduction 🌷

SIP [3] is increasingly showing up in systems that are tightly coupled with HTTP [2] servers, for a bunch of reasons 💕. In lots of these cases, apps benefit a ton from hearing about changes to specific HTTP resources in near real-time ⚡. Like, user agent terminals might decide to keep their service-related data in an HTTP tree 🌳. When that config info is stored and fetched over HTTP, clients may need to know when it changes, so they can update their local behavior and UI accordingly 🎀.

This doc defines a mechanism, built on the SIP Event Framework [4], for subscribing to changes in a resource that an HTTP server references 🦋. These subscriptions don't have to carry the resource's content 🤷‍♀️. When the content isn't conveyed, HTTP is still the protocol used to transfer the contents of HTTP resources 📦. The doc also defines how to figure out the right SIP and/or Session Initiation Protocol Secure (SIPS) URI to use for these subscriptions, straight 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]. Those are the vibes we're going with 😤.

Heads up, this doc talks about both SIP messages and HTTP messages 📨. SIP's syntax was heavily based on HTTP's, so the components of these messages have similar or identical names 👯‍♀️. When talking about message payloads, HTTP docs have historically preferred the hyphenated message-body, while SIP docs favor the unhyphenated message body 🙃. This doc does both: hyphenated for HTTP, unhyphenated for SIP 💖.

3. Associating Monitoring SIP URIs with HTTP URLs 🔍

One of the key challenges when subscribing to changes of a resource given by an HTTP URL is figuring out which SIP URI matches that specific HTTP URL 🧩. This spec takes the approach of having the HTTP server that's responsible for the URL pick a suitable SIP URI for the matching resource, then return that URI inside an HTTP transaction 🎁.

To be specific, HTTP servers use link relations to pass along the URI or URIs that can be used to discover changes to the resource 🔗. The examples are the HTTP Link header field [10], the HTML <link/> element [11], and the Atom <atom:link/> element [5] 📎. This doc defines two new link relation types for this purpose, "monitor" and "monitor-group", and specifies behavior for SIP and SIPS URIs in link relations of those types 🌈. Handling other URI schemes is out of scope for this doc, though the authors expect future specs to define how to monitor via other protocols 🔮.

Clients using the mechanism in this doc MUST support the HTTP Link header field 🫡. Clients that can process HTML documents SHOULD support the HTML <link/> element, and clients that can process Atom documents SHOULD support Atom <atom:link/> elements 💜. These requirements don't mean other ways of conveying link relations are ruled out 🌸.

A service that gives HTTP access to a resource might also monitor that resource over multiple protocols, so an HTTP response is totally allowed to contain multiple link relationships whose relations allow monitoring of changes (see [10]) 🍓. Implementors are cautioned to process all link relations so they can find the one that matches their preferred change monitoring protocol ⚠️.

These link relations are scoped to a single HTTP entity 🚨. When an HTTP resource is linked to 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 wants to let clients subscribe to changes in a resource's value with 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 that wants to subscribe to the state change of an HTTP resource gets a SIP or SIPS URI by sending a GET or HEAD request to the HTTP URL it wants to monitor 🧚‍♀️. That SIP or SIPS URI then gets used in a SUBSCRIBE request, following the event package defined in Section 4 💖.

3.2. Monitoring Multiple HTTP Resources ✨

okay so if a client wants to watch a whole bunch of HTTP resources at once, it's totally allowed to use the mechanisms in RFC 4662 [6] and/or RFC 5367 [9] 💅 The server doesn't need any special help for this one, bestie. The catch is that those approaches need a Resource List Server (RLS), as defined in RFC 4662, which basically subscribes to the state of resources on behalf of the monitoring user. ngl that's not always the most efficient move when you're watching several resources, especially if they all live on the same HTTP server 🙈

Here's the lowkey iconic alternative 🦋 If an HTTP server wants to let you subscribe to several HTTP resources in one single SUBSCRIBE request, it returns a link relation with a SIP or SIPS URI and the relation type monitor-group in a successful response to a GET or HEAD request on any monitorable resource. Generally, the 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]. It MAY, but is not required to, accept URI lists that include monitoring URIs that aren't associated with resources served by its related HTTP server. Not requiring that functionality lets the RLS be implemented without needing back-end subscriptions 🌸 If a server wants to reject those requests, the "403" (Forbidden) response code is the right move. Any "403" responses generated for this reason SHOULD contain a message body of type application/resource-lists+xml, and that body lists the offending URI or URIs. See RFC 4826 [7] for the definition of that 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 to an HTTP resource or a fixed set of HTTP resources. That's the whole vibe 💜

If a client wants to subscribe to the state of multiple HTTP resources and has received monitor-group URIs for each of them, it may use those monitor-group URIs to subscribe to multiple resources in the same subscription. Here's how it goes: start with the set of HTTP resources you want to monitor, then group them by their respective monitor-group URIs. Finally, for each group, initiate a subscription to that group's monitor-group URI. That subscription includes a URI list, as described in RFC 5367, and 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" )

If the parameter is present and set to "true" in a SUBSCRIBE request, it tells the server that the client wants 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 those message bodies, even when the parameter is present, based on local policy. 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 the parameter is absent, its value 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 durations for subscriptions to the http-monitor event package vary wildly depending on the HTTP resource being monitored. Some resources change infrequently (if ever), while others can change comparatively rapidly 🍓 For rapidly changing documents, being able to recover quickly from a subscription failure matters a lot, so implementations will be well served by picking smaller durations, on the order of 1800 to 3600 seconds (30 minutes to an hour).

Subscriptions to slower-changing resources don't have that issue, and needing to refresh them periodically makes short subscriptions wasteful. For these, expirations as long as 604800 seconds (one week) or even longer may well make sense 💜

The subscriber is responsible for choosing an expiration time that fits its purposes, taking all of that into account. Keep in mind that the whole goal of picking a subscription duration is to balance server load against time to recover after a failure. In particular, short subscription expiration times guard against the loss of subscription server state, albeit at the expense of extra load on the server 💅

If a subscription has no expires value, the notifier can assume a default expiration period according to local policy. That local policy might consider various aspects of the monitored resource, 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 doesn't 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.

Here's an example of a message/http message body as used in this event package:

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 it's returning a null state as described in Section 4.7. Including a Last-Modified header field is also RECOMMENDED. On top of that, the message/http message body MUST contain a Content-Location field that identifies the resource being monitored. Note that this isn't necessarily the same URL the link association was originally obtained from, so see RFC 2616 [2] for details 🙈

Except for those normative requirements, the decision about 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 a desire to receive those bodies, as described in Section 4.2.

If the change being communicated is 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 tried 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 being communicated is 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 tried 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 line up with the HTTP server's authorization policies for 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 🌈

If the notifier doesn't have enough information to return anything useful 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's up to the subscriber implementation to decide whether it's appropriate to fetch a new copy of the HTTP resource in reaction to a NOTIFY message 💖

4.9. Handling of Forked Requests ✨

Okay so having multiple notifiers for one HTTP resource is semantically nonsensical 💀 like, it just doesn't make sense. In the weird edge case where a SUBSCRIBE request gets forked, the subscriber SHOULD terminate all but one subscription, as described in Section 4.4.9 of RFC 3265 [4]. Tidy and iconic 💅

4.10. Rate of Notifications 🌸

The data stored in HTTP for SIP services can change super fast because users keep typing stuff in, and it might get rendered for people to see or used to affect call routing. So a high degree of responsiveness is totally appropriate 🦋 BUT, to protect the network, notifiers for the http-monitor event package SHOULD NOT send notifications more often than once every second. Slow and steady keeps the network happy 🫶

4.11. State Agents 🧚

Splitting the authority for the HTTP resource into an HTTP server and a SIP Events server is likely to be useful, because serving HTTP resources and managing subscriptions can scale in really different ways 📈 If you do that split, implementors are encouraged to get familiar with the PUBLISH mechanism described in RFC 3903 [14]. Homework, but make it cute 🎀

5. Example Message Flow 🎬

Here's a simple example message flow so you can see how this event package actually gets used 👀 It's included for illustrative purposes only, and it does not form any part of the specification of the mechanisms defined in this document. Just vibes, not rules 💜

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

These messages only show the bits that matter for the example 🙈 They intentionally skip fields that are typical or mandatory but aren't key to following the flow.

  1. The client sends a GET request to grab the document at "http://www.example.com/pet-profiles/alpacas/". Literally the first step, no notes 🍓
GET /pet-profiles/alpacas/ HTTP/1.1
Host: www.example.com
  1. The HTTP server sends back the document along with some useful metadata 🧾 The main thing to look at is the Link header field with a "rel" parameter of "monitor". That's the SIP URL the client uses to watch for changes to the HTTP resource. Also, since the message-body is an HTML document, the "monitor" link relation could instead be indicated inside the HTML itself, using a <link/> element. Options are good 💖

The ETag, Content-MD5, and Last-Modified header fields are also there. The client can use these to figure out which version of the entity it got back from 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]
  1. The client sends a SUBSCRIBE request to the SIP URI from the "monitor" link relation, with 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>
  1. The SIP Events server acks the subscription request and sets up a dialog for it 🤝
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>
  1. The SIP Events server sends a NOTIFY with the current state of the HTTP resource. The client can compare the ETag, Content-MD5, or Last-Modified header fields against the ones from the HTTP "200" response to confirm it has the latest version of the entity ✅
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
  1. The client acknowledges the NOTIFY 👋
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>
  1. At some point after the subscription is set up, the entity on the HTTP server changes 🔄 The server can tell a SIP Events server about this using a SIP PUBLISH request, and the PUBLISH message body carries info about the entity's state. SIP PUBLISH is just one of many ways to share this, so any other method would work too 🌈
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
  1. The SIP Events server acks the changed entity state. Heads up: the SIP-ETag header field value has nothing to do with the ETag header field on the HTTP entity, so don't mix them up 🙅‍♀️
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
  1. The SIP Events server tells the client about the state change with a NOTIFY 📣
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
  1. The client acks the changed state 🎉 At this point the client can choose to fetch a fresh copy of the document so it can act on the new content. Or it can just mark the old copy as out of date or toss it, and grab a new one whenever it likes later.
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 🔐

Okay this section is SERIOUS, bestie, don't skip it 😭

Unless it's secured using Transport Layer Security (TLS), IPsec, or something similar, the content of the Link header field is not secure, private, or integrity-protected. Totally exposed 🫣

Since 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 means don't use it to authenticate a subscriber, and don't use it to prove someone's allowed to subscribe to a particular resource 🚫

Since an unsecured Link header field can be tampered with (or have stuff inserted into it) in transit, client implementations need to think about how their app handles a forged set of notifications. This gets especially messy when the change notifications include entity state (using "body=true") 😱

This mechanism lets you learn about the state of an HTTP resource over a different protocol, and maybe from a different server. If the HTTP resource is restricted by some kind of access control, special care MUST be taken to make sure the SIP way of subscribing to the resource state is restricted in the same way too. Otherwise, unauthorized users could learn stuff that was meant to stay confidential, including the actual resource value in some cases 🙀

Same energy for encryption: if the HTTP resource is encrypted or integrity-protected in transit (for example, by using HTTP over TLS [12]), then the SIP way of subscribing to the HTTP resource MUST also have appropriate encryption or integrity protection applied. Examples of ways to provide that protection include the SIPS URI scheme [17] and S/MIME bodies [13] 🔒

7. IANA Considerations 📋

The following entries have been added to the "Link Relation Types" registry, which was created by the "Web Linking" specification [10].

  • Relation Name: monitor
  • Description: Refers to a resource that can be used to monitor changes in an HTTP resource.
  • Reference: RFC 5989
  • Relation Name: monitor-group
  • Description: Refers to a resource that can be used to monitor changes in a specified group of HTTP resources.
  • Reference: RFC 5989

7.2. New SIP Event Package: http-monitor 🦋

The following entry is to be added to the "SIP Events" registry, which was 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 🎀

okay so we're adding a new entry to the SIP "Header Field Parameters and Parameter Values" registry, the one set up by the SIP Change Framework [15] 📋 here's the whole entry:

Header Field:  Event

Parameter Name:  body

Predefined Values:  yes

Reference:  RFC 5989

8. Acknowledgements 🫶

huge thanks to Lisa Dusseault and Mark Nottingham for their really significant input on the ways to bind an HTTP URL to a SIP URI 💖 Mark Nottingham and Theo Zourzouvillys also gave super thorough feedback on the early versions of this document, which was so helpful 🌸 and big shoutouts to Martin Thompson, Shida Schubert, John Elwell, and Scott Lawrence for their careful reviews and feedback ✨

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

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

Appendix A. Rationale: Other Approaches Considered 🧠

okay so several different ways to get the SIP URI back from the HTTP server were looked at 👀 link relations came out on top with the most favorable set of properties, so that's the one that won 💅 two big candidates got considered but rejected in favor of link relations, and here's the tea on them 🫖

the HTTP PROPFIND method ([16], Section 9.1) can grab the value of a specific property tied to an HTTP URL 🔍 but the catch is it can't be done together with fetching the document itself, which is usually what you actually want 😭 so with a PROPFIND approach, clients end up doing both a GET and a PROPFIND on the resources they care about. on top of that, PROPFIND needs HTTP user agents to support it, and even though it's fairly well implemented, it still doesn't have the penetration GET implementations have 🥲

XRDS (Extensible Resource Descriptor Sequence) [18] is kind of like PROPFIND in that it can retrieve properties tied to an HTTP URL 🧚 the glow-up is that it uses GET instead of PROPFIND ✨ but it still has the two-round-trip issue we talked about above, plus an unfortunately large number of options for how to retrieve the properties 💀

Author's Address 📮

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

   EMail: adam@nostrum.com
📦 where this page comes from