idnits 2.17.1
draft-roach-sip-http-subscribe-07.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document date (February 4, 2010) is 5166 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
** Obsolete normative reference: RFC 2616 (ref. '2') (Obsoleted by RFC
7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665)
== Outdated reference: A later version (-10) exists of
draft-nottingham-http-link-header-06
-- Possible downref: Non-RFC (?) normative reference: ref. '11'
-- Obsolete informational reference (is this intentional?): RFC 2818 (ref.
'12') (Obsoleted by RFC 9110)
-- Obsolete informational reference (is this intentional?): RFC 3851 (ref.
'13') (Obsoleted by RFC 5751)
Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIP WG A. B. Roach
3 Internet-Draft Tekelec
4 Intended status: Standards Track February 4, 2010
5 Expires: August 8, 2010
7 A SIP Event Package for Subscribing to Changes to an HTTP Resource
8 draft-roach-sip-http-subscribe-07
10 Status of this Memo
12 This Internet-Draft is submitted to IETF in full conformance with the
13 provisions of BCP 78 and BCP 79.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on August 8, 2010.
33 Copyright Notice
35 Copyright (c) 2010 IETF Trust and the persons identified as the
36 document authors. All rights reserved.
38 This document is subject to BCP 78 and the IETF Trust's Legal
39 Provisions Relating to IETF Documents
40 (http://trustee.ietf.org/license-info) in effect on the date of
41 publication of this document. Please review these documents
42 carefully, as they describe your rights and restrictions with respect
43 to this document.
45 Abstract
47 The Session Initiation Protocol (SIP) is increasingly being used in
48 systems that are tightly coupled with Hypertext Transport Protocol
49 (HTTP) servers for a variety of reasons. In many of these cases,
50 applications can benefit from being able to discover, in near-real-
51 time, when a specific HTTP resource is created, changed, or deleted.
52 This document proposes a mechanism, based on the SIP events
53 framework, for doing so.
55 Table of Contents
57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
59 3. Associating Monitoring SIP URIs with HTTP URLs . . . . . . . . 3
60 3.1. Monitoring a Single HTTP Resource . . . . . . . . . . . . 4
61 3.2. Monitoring Multiple HTTP Resources . . . . . . . . . . . . 5
62 4. HTTP Change Event Package . . . . . . . . . . . . . . . . . . 6
63 4.1. Event Package Name . . . . . . . . . . . . . . . . . . . . 6
64 4.2. Event Package Parameters . . . . . . . . . . . . . . . . . 6
65 4.3. SUBSCRIBE Bodies . . . . . . . . . . . . . . . . . . . . . 7
66 4.4. Subscription Duration . . . . . . . . . . . . . . . . . . 7
67 4.5. NOTIFY Bodies . . . . . . . . . . . . . . . . . . . . . . 8
68 4.5.1. Use of message/http in HTTP Monitor Event Package . . 8
69 4.6. Notifier processing of SUBSCRIBE requests . . . . . . . . 9
70 4.7. Notifier generation of NOTIFY requests . . . . . . . . . . 9
71 4.8. Subscriber processing of NOTIFY requests . . . . . . . . . 9
72 4.9. Handling of forked requests . . . . . . . . . . . . . . . 10
73 4.10. Rate of notifications . . . . . . . . . . . . . . . . . . 10
74 4.11. State Agents . . . . . . . . . . . . . . . . . . . . . . . 10
75 5. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 10
76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
78 7.1. New Link Relations . . . . . . . . . . . . . . . . . . . . 15
79 7.1.1. New Link Relation: monitor . . . . . . . . . . . . . . 15
80 7.1.2. New Link Relation: monitor-group . . . . . . . . . . . 16
81 7.2. New SIP Event Package: http-monitor . . . . . . . . . . . 16
82 7.3. New Event Header Field Parameter: body . . . . . . . . . . 16
83 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
84 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
85 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
86 9.2. Informative References . . . . . . . . . . . . . . . . . . 17
87 Appendix A. Rationale: Other Approaches Considered . . . . . . . 18
88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
90 1. Introduction
92 The Session Initiation Protocol (SIP) [3] is increasingly being used
93 in systems that are tightly coupled with Hypertext Transport Protocol
94 (HTTP) [2] servers for a variety of reasons. In many of these cases,
95 applications can benefit from learning of changes to specified HTTP
96 resources in near-real-time. For example, user agent terminals may
97 elect to store service-related data in an HTTP tree. When such
98 configuration information is stored and retrieved using HTTP, clients
99 may need to be informed when information changes, so as to make
100 appropriate changes to their local behavior and user interface.
102 This document defines a mechanism, based on the SIP Event Framework
103 [4], for subscribing to changes in the resource referenced by an HTTP
104 server. Such subscriptions do not necessarily carry the content
105 associated with the resource. In the cases that the content is not
106 conveyed, the HTTP protocol is still used to transfer the contents of
107 HTTP resources. This document further defines a mechanism by which
108 the proper SIP and/or SIPS URI to be used for such subscriptions can
109 be determined from the HTTP server.
111 2. Terminology
113 The capitalized terms "MUST," "SHOULD," "MAY," "SHOULD NOT," and
114 "MUST NOT" in this document are to be interpreted as described in RFC
115 2119 [1].
117 Note that this document discusses both SIP messages and HTTP
118 messages. Because SIP's syntax was heavily based on HTTP's, the
119 components of these messages have similar or identical names. When
120 referring to message payloads, HTTP documents have historically
121 preferred the hyphenated form "message-body", while SIP documents
122 favor the unhyphenated form "message body". This document conforms
123 to both conventions, using the hyphenated form for HTTP, and the
124 unhyphenated form for SIP.
126 3. Associating Monitoring SIP URIs with HTTP URLs
128 One of the key challenges in subscribing to the changes of a resource
129 indicated by an HTTP URL is determining which SIP URI corresponds to
130 a specific HTTP URL. This specification takes the approach of having
131 the HTTP server responsible for the URL in question select an
132 appropriate SIP URI for the corresponding resource, and to return
133 that URI within an HTTP transaction.
135 In particular, HTTP servers use link relations -- such as the HTTP
136 Link: header field [10], the HTML element [11], and the Atom
137 element [5] -- to convey the URI or URIs that can be
138 used to discover changes to the resource. This document defines two
139 new link relation types ("monitor" and "monitor-group") for this
140 purpose, and specifies behavior for SIP and SIPS URIs in link
141 relations of these types. Handling for other URI schemes is out of
142 scope for the current document, although we expect future
143 specifications to define procedures for monitoring via other
144 protocols.
146 Clients making use of the mechanism described in this document MUST
147 support the HTTP Link: header field. Those clients that support
148 processing of HTML documents SHOULD support the HTML element;
149 those that support processing of Atom documents SHOULD support Atom
150 elements. These requirements are not intended to
151 preclude the use of any other means of conveying link relations.
153 The service that provides HTTP access to a resource might provide
154 monitoring of that resource using multiple protocols, so it is
155 perfectly legal for an HTTP response to contain multiple link
156 relationships with relations that allow for monitoring of changes
157 (see [10]). Implementors are cautioned to process all link relations
158 to locate a one that corresponds with their preferred change
159 monitoring protocol.
161 These link relations are scoped to a single HTTP entity. When an
162 HTTP resource is associated with multiple entities (for example, to
163 facilitate content negotiation), the "monitor" and "monitor-group"
164 link relations will generally be different for each entity.
166 3.1. Monitoring a Single HTTP Resource
168 If an HTTP server wishes to offer the ability to subscribe to a
169 changes in a resource's value using this event package, it returns a
170 link relation containing a SIP or SIPS URI with a relation type of
171 "monitor" in a successful response to a GET or HEAD request on that
172 resource. If the server supports both SIP and SIPS access, it MAY
173 return link relations for both kinds of access.
175 A client wishing to subscribe to the change state of an HTTP resource
176 obtains a SIP or SIPS URI by sending a GET or HEAD request to the
177 HTTP URL it wishes to monitor. This SIP or SIPS URI is then used in
178 a SUBSCRIBE request, according to the event package defined in
179 Section 4.
181 3.2. Monitoring Multiple HTTP Resources
183 If a client wishes to subscribe to the state of multiple HTTP
184 resources, it is free to make use of the mechanisms defined in RFC
185 4662 [6] and/or RFC 5367 [9]. This requires no special support by
186 the server that provides resource state information. These
187 approaches, however, require the addition of a Resource List Server
188 (RLS) as defined in RFC 4662, which will typically subscribe to the
189 state of resources on behalf of the monitoring user. In many cases,
190 this is not a particularly efficient means of monitoring several
191 resources, particularly when such resources reside on the same HTTP
192 server.
194 As a more efficient alternative, if an HTTP server wishes to offer
195 the ability to subscribe to the state of several HTTP resources in a
196 single SUBSCRIBE request, it returns a link relation containing a SIP
197 or SIPS URI with a relation type of "monitor-group" in a successful
198 response to a GET or HEAD request on any monitorable resource. In
199 general, this monitor-group URI will be the same for all resources on
200 the same HTTP server.
202 The monitor-group URI corresponds to an RLS service associated with
203 the HTTP server. This RLS service MUST support subscriptions to
204 request-contained resource lists, as defined in RFC 5367 [9]. This
205 RLS service MAY, but is not required to, accept URI lists that
206 include monitoring URIs that are not associated with resources served
207 by its related HTTP server. Not requiring such functionality allows
208 the RLS to be implemented without requiring back-end subscriptions.
209 If a server wishes to reject such requests, the "403" (Forbidden)
210 response code is appropriate. Any "403" responses generated for this
211 reason SHOULD contain a message body of type "application/
212 resource-lists+xml"; this message body lists the offending URI or
213 URIs. See RFC 4826 [7] for the definition of the "application/
214 resource-lists+xml" MIME type.
216 The HTTP server MUST also return a SIP and/or SIPS link relation with
217 a relation type of "monitor" whenever it returns a SIP and/or SIPS
218 link relation with a relation type of "monitor-group". The monitor-
219 group URI corresponds only to an RLS, and never an HTTP resource or
220 fixed set of HTTP resources.
222 If a client wishes to subscribe to the state of multiple HTTP
223 resources, and has received monitor-group URIs for each of them, it
224 may use the monitor-group URIs to subscribe to multiple resources in
225 the same subscription. To do so, it starts with the set of HTTP
226 resources it wishes to monitor. It then groups these resources by
227 their respective monitor-group URIs. Finally, for each such group,
228 it initiates a subscription to the group's monitor-group URI; this
229 subscription includes a URI list, as described in RFC 5367. The URI
230 list contains all of the URIs in the group.
232 For example: consider the case in which a client wishes to monitor
233 the resources http://www.example.com/goat,
234 http://www.example.com/sheep, http://www.example.org/llama, and
235 http://www.example.org/alpaca. It would use HTTP to perform HEAD
236 and/or GET operations on these resources. The responses to these
237 operations will contain link relations for both monitor and
238 monitor-type for each of the four resources. Assume the monitor
239 link for http://www.example.com/goat is sip:a94aa000@example.com;
240 for http://www.example.com/sheep, sip:23ec24c5@example.com; for
241 http://www.example.org/llama,
242 sip:yxbO-UHYxyizU2H3dnEerQ@example.org; and for
243 http://www.example.org/alpaca,
244 sip:-J0piC0ihB9hfNaJc7GCBg@example.org. Further, assume the
245 monitor-group link for http://www.example.com/goat and
246 http://www.example.com/sheep are both sip:httpmon@rls.example.com,
247 while the monitor-group link for http://www.example.org/llama and
248 http://www.example.org/alpaca are both sip:rls@example.org.
250 Because they share a common monitor-group link, the client would
251 group together http://www.example.com/goat and
252 http://www.example.com/sheep in a single subscription. It sends
253 this subscription to the monitor-group URI
254 (sip:httpmon@rls.example.com), with a resource-list containing the
255 relevant monitor URIs (sip:a94aa000@example.com and
256 sip:23ec24c5@example.com). It then repeats this process for the
257 remaining two HTTP resources, using their monitor-group and
258 monitor URIs in the same way.
260 4. HTTP Change Event Package
262 4.1. Event Package Name
264 The name of this event package is "http-monitor".
266 4.2. Event Package Parameters
268 This event package defines a single parameter to be used with the
269 "Event" header field. The syntax for this parameter is shown below,
270 using the ABNF format defined in RFC 5234 [8]. The use of the
271 construction "EQUAL" is as defined by RFC 3261 [3].
273 body-event-param = "body" EQUAL ( "true" / "false" )
275 If present and set to "true" in a SUBSCRIBE request, this parameter
276 indicates to the server that the client wishes to receive a message-
277 body component in the message/http message bodies sent in NOTIFY
278 messages.
280 If a server receives a SUBSCRIBE message with a "Event" header field
281 "body" parameter set to "true", it MAY choose to include a message-
282 body component in the message/http message bodies that it sends in
283 NOTIFY messages. Alternatively, it MAY decline to send such message-
284 bodies, even when this parameter is present, based on local policy.
285 In particular, it would be quite reasonable for servers to have a
286 policy of not including HTTP message-bodies larger than a relatively
287 small number of bytes.
289 When absent, the value of this parameter is assumed to be "false".
291 Note that this parameter refers to the message-body component of
292 the HTTP message, not the message body component of the SIP
293 message.
295 4.3. SUBSCRIBE Bodies
297 This event package defines no message bodies to be used in the
298 SUBSCRIBE message.
300 4.4. Subscription Duration
302 Reasonable values for the duration of subscriptions to the http-
303 monitor event package vary widely with the nature of the HTTP
304 resource being monitored. Some HTTP resources change infrequently
305 (if ever), while others can change comparatively rapidly. For
306 rapidly changing documents, the ability to recover more rapidly from
307 a subscription failure is relatively important, so implementations
308 will be well served by selecting smaller durations for their
309 subscriptions, on the order of 1800 to 3600 seconds (30 minutes to an
310 hour).
312 Subscriptions to slower-changing resources lack this property, and
313 the need to periodically refresh subscriptions render short
314 subscriptions wasteful. For these type of subscriptions, expirations
315 as long as 604800 (one week) or even longer may well make sense.
317 The subscriber is responsible for selecting an expiration time that
318 is appropriate for its purposes, taking the foregoing considerations
319 into account. Keep in mind that the goal behind selecting
320 subscription durations is to balance server load against time to
321 recover in the case of a failure. In particular, short subscription
322 expiration times guard against the loss of subscription server state,
323 albeit at the expense of additional load on the server.
325 In the absence of an expires value in a subscription, the notifier
326 can assume a default expiration period according to local policy.
327 This local policy might choose to take various aspects of the
328 monitored resource into account, such as its age and presumed period
329 of validity. Absent any other information, it would not be
330 unreasonable for a server to assume a default expiration value of
331 86400 (one day) when the client fails to provide one.
333 4.5. NOTIFY Bodies
335 By default, the message bodies of NOTIFY messages for the http-
336 monitor event package will be of content-type "message/http," as
337 defined in RFC 2616 [2].
339 4.5.1. Use of message/http in HTTP Monitor Event Package
341 The message/http NOTIFY message bodies used in the HTTP monitor event
342 package reflect a subset of the response that would be returned if
343 the client performed an HTTP HEAD operation on the HTTP resource.
345 An example of a message/http message body as used in this event
346 package is shown below.
348 HTTP/1.1 200 OK
349 Date: Sat, 13 Nov 2010 17:18:52 GMT
350 ETag: 38fe6-58b-1840e7d0
351 Content-MD5: 4e3b50421829c7c379a5c6154e560449
352 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT
353 Accept-Ranges: bytes
354 Content-Location: http://www.example.com/pet-profiles/alpacas/
355 Content-Length: 12511
356 Content-Type: text/html
358 When used in the HTTP monitor event package defined in this document,
359 the message/http SHOULD contain at least one of an ETag or Content-
360 MD5 header field, unless returning a null state as described in
361 Section 4.7. Inclusion of a Last-Modified header field is also
362 RECOMMENDED. Additionally, the message/http message body MUST
363 contain a Content-Location field that identifies the resource being
364 monitored. Note that this is not necessarily the same URL from which
365 the link association was originally obtained; see RFC 2616 [2] for
366 details.
368 Except for the foregoing normative requirements, The decision
369 regarding which HTTP header fields to include is at the discretion of
370 the notifier.
372 When used in the HTTP monitor event package, the message/http MUST
373 NOT contain a message-body component, unless the corresponding
374 subscription has explicitly indicated the desire to receive such
375 bodies as described in Section 4.2.
377 If the change to the resource being communicated represents a
378 renaming of the HTTP resource, the message/http start line will
379 contain the same 3xx-class HTTP response that would be returned if a
380 user agent attempted to access the relocated HTTP resource with a
381 HEAD request (e.g., "301 Moved Permanently"). The message/http also
382 SHOULD contain a Location: header field that communicates the new
383 name of the resource.
385 If the change to the resource being communicated represents a
386 deletion of the HTTP resource, the start line will contain the same
387 4xx-class HTTP response that would be returned if a user agent
388 attempted to access the missing HTTP resource with a HEAD request
389 (e.g., "404 Not Found" or "410 Gone").
391 4.6. Notifier processing of SUBSCRIBE requests
393 Upon receipt of a SUBSCRIBE request, the notifier applies
394 authorization according to local policy. Typically, this policy will
395 be aligned with the HTTP server authorization policies regarding
396 access to the resource whose change state is being requested.
398 4.7. Notifier generation of NOTIFY requests
400 NOTIFY messages are generated whenever the underlying resource
401 indicated by the corresponding HTTP URL has been modified.
403 In the case that the notifier has insufficient information to return
404 any useful information about the underlying HTTP resource, it MUST
405 return a message body that is zero bytes long (subject to any
406 mechanisms that would suppress sending of a NOTIFY message).
408 4.8. Subscriber processing of NOTIFY requests
410 Upon receipt of a NOTIFY message, the subscriber applies any
411 information in the message/http to update its view of the underlying
412 HTTP resource. In most cases, this results in an invalidation of its
413 view of the HTTP resource. It is up to the subscriber implementation
414 to decide whether it is appropriate to fetch a new copy of the HTTP
415 resource as a reaction to a NOTIFY message.
417 4.9. Handling of forked requests
419 Multiple notifiers for a single HTTP resource is semantically
420 nonsensical. In the aberrant circumstance that a SUBSCRIBE request
421 is forked, the subscriber SHOULD terminate all but one subscription,
422 as described in section 4.4.9 of RFC 3265 [4].
424 4.10. Rate of notifications
426 Because the data stored in HTTP for the purpose of SIP services may
427 change rapidly due to user input, and because it may potentially be
428 rendered to users and/or used to impact call routing, a high degree
429 of responsiveness is appropriate. However, for the protection of the
430 network, notifiers for the http-monitor event package SHOULD NOT send
431 notifications more frequently than once every second.
433 4.11. State Agents
435 Decomposition of the authority for the HTTP resource into an HTTP
436 Server and a SIP Events Server is likely to be useful, due to the
437 potentially different scaling properties associated with serving HTTP
438 resources and managing subscriptions. In the case of such
439 decomposition, implementors are encouraged to familiarize themselves
440 with the PUBLISH mechanism described in RFC 3903 [14].
442 5. Example Message Flow
444 The following is a simple example message flow, to aid in
445 understanding how this event package can be used. It is included for
446 illustrative purposes only, and does not form any portion of the
447 specification of the mechanisms defined in this document.
449 Client HTTP Server SIP Events Server
450 | | |
451 | | |
452 |(1) HTTP GET | |
453 |------------------>| |
454 |(2) HTTP 200 OK | |
455 |<------------------| |
456 |(3) SIP SUBSCRIBE | |
457 |-------------------------------------->|
458 |(4) SIP 200 OK | |
459 |<--------------------------------------|
460 |(5) SIP NOTIFY | |
461 |<--------------------------------------|
462 |(6) SIP 200 OK | |
463 |-------------------------------------->|
464 | | |
465 | | |
466 | [HTTP document changes] |
467 | | |
468 | | |
469 | |(7) SIP PUBLISH |
470 | |------------------>|
471 | |(8) SIP 200 OK |
472 | |<------------------|
473 |(9) SIP NOTIFY | |
474 |<--------------------------------------|
475 |(10) SIP 200 | |
476 |-------------------------------------->|
477 | | |
478 | | |
480 The following messages illustrate only the portions of the messages
481 that are relevant to the example. They intentionally elide fields
482 that, while typical or mandatory, are not key to understanding the
483 foregoing message flow.
485 1. The client issues a GET request to retrieve the document
486 identified by the URL
487 "http://www.example.com/pet-profiles/alpacas/".
489 GET /pet-profiles/alpacas/ HTTP/1.1
490 Host: www.example.com
492 2. The HTTP server responds with the document, and several relevant
493 pieces of meta-data. Of key interest for this example is the
494 "Link" header field with a "rel" parameter of "monitor". This
495 is the SIP URL that the client will use to monitor changes to
496 the state of the HTTP resource. Note that, since the message-
497 body is an HTML document, the "monitor" link relation could
498 alternately be indicated in the HTML document itself, through
499 the use of a element.
501 Note also the presence of the "ETag", "Content-MD5", and "Last-
502 Modified" header fields. These can be used by the client to
503 identify the version of the entity returned by the HTTP server.
505 HTTP/1.1 200 OK
506 ETag: 38fe6-58b-1840e7d0
507 Content-MD5: 4e3b50421829c7c379a5c6154e560449
508 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT
509 Content-Location: http://www.example.com/pet-profiles/alpacas/
510 Link: ; rel="monitor"
511 Link: ; rel="monitor-group"
512 Content-Length: 12511
513 Content-Type: text/html
515 [HTML message-body]
517 3. The client sends a SUBSCRIBE request to the SIP URI indicated in
518 the "monitor" link relation, indicating an event type of "http-
519 monitor".
521 SUBSCRIBE sip:23ec24c5@example.com SIP/2.0
522 To:
523 From: ;tag=57dac993-0b5b-4f04
524 Event: http-monitor
525 Contact:
527 4. The SIP Events server acknowledges receipt of the subscription
528 request, and establishes a dialog for the resulting
529 subscription.
531 SIP/2.0 200 OK
532 To: ;tag=907A953576E6
533 From: ;tag=57dac993-0b5b-4f04
534 Contact:
536 5. The SIP Events server sends a NOTIFY message containing the
537 current state of the HTTP resource. The client can compare the
538 contents of the ETag, Content-MD5, or Last-Modified header
539 fields against those received in the HTTP "200" response to
540 verify that it has the most recent version of the entity.
542 NOTIFY sip:adam@198.51.100.17:2487 SIP/2.0
543 To: ;tag=57dac993-0b5b-4f04
544 From: ;tag=907A953576E6
545 Contact:
546 Event: http-monitor
547 Subscription-State: active
548 Content-Type: message/http
550 HTTP/1.1 200 OK
551 ETag: 38fe6-58b-1840e7d0
552 Content-MD5: 4e3b50421829c7c379a5c6154e560449
553 Last-Modified: Sat, 13 Nov 2010 03:29:00 GMT
554 Content-Location: http://www.example.com/pet-profiles/alpacas/
555 Content-Length: 12511
556 Content-Type: text/html
558 6. The client acknowledges receipt of the NOTIFY message.
560 SIP/2.0 200 OK
561 To: ;tag=57dac993-0b5b-4f04
562 From: ;tag=907A953576E6
563 Contact:
565 7. At some point after the subscription has been established, the
566 entity hosted by the HTTP server changes. It can convey this
567 information to a SIP Events server using a SIP PUBLISH request.
568 The PUBLISH message body contains information regarding the
569 state of the entity.
571 Note that SIP PUBLISH is one of many ways such information could
572 be conveyed -- any other means of communicating this information
573 would also be valid.
575 PUBLISH sip:23ec24c5@example.com SIP/2.0
576 To:
577 From: ;tag=03-5gbK652_jNMr-b8-11Z_G-NsLR
578 Contact:
579 Event: http-monitor
580 Content-Type: message/http
582 HTTP/1.1 200 OK
583 ETag: 3238e-1a3-b83be580
584 Content-MD5: 10a1ef5b223577059fafba867829abf8
585 Last-Modified: Sat, 17 Nov 2010 08:17:39 GMT
586 Content-Location: http://www.example.com/pet-profiles/alpacas/
587 Content-Length: 17481
588 Content-Type: text/html
590 8. The SIP Events server acknowledges the changed entity state.
591 Note that the value of the "SIP-ETag" header field is not
592 related to the "ETag" header field associated with the HTTP
593 entity.
595 SIP/2.0 200 OK
596 To:
597 From: ;tag=03-5gbK652_jNMr-b8-11Z_G-NsLR
598 SIP-ETag: 3psbqi1o5633
600 9. The SIP events server informs the client of the change in state
601 for the subscribed resource using a NOTIFY message.
603 NOTIFY sip:adam@198.51.100.17:2487 SIP/2.0
604 To: ;tag=57dac993-0b5b-4f04
605 From: ;tag=907A953576E6
606 Contact:
607 Event: http-monitor
608 Subscription-State: active
609 Content-Type: message/http
611 HTTP/1.1 200 OK
612 ETag: 3238e-1a3-b83be580
613 Content-MD5: 10a1ef5b223577059fafba867829abf8
614 Last-Modified: Sat, 17 Nov 2010 08:17:39 GMT
615 Content-Location: http://www.example.com/pet-profiles/alpacas/
616 Content-Length: 17481
617 Content-Type: text/html
619 10. The client acknowledges receipt of the changed state. At this
620 point, the client may choose to retrieve a fresh copy of the
621 document so that it can act on the new content. Alternately, it
622 may simply mark the previously retrieved document as out of date
623 or discard it, choosing to retrieve a new copy at a later point
624 in time.
626 SIP/2.0 200 OK
627 To: ;tag=57dac993-0b5b-4f04
628 From: ;tag=907A953576E6
629 Contact:
631 6. Security Considerations
633 Unless secured using TLS, IPSEC, or a similar technology, the content
634 of the Link header field is not secure, private or integrity-
635 guaranteed.
637 Because an unencrypted Link header field can be intercepted, server
638 implementations are cautioned not to use the value sent in the "Link"
639 header field as a security token that authenticates a subscriber, or
640 that demonstrates authorization to subscribe to a particular
641 resource.
643 Because an unsecured Link header field can be tampered with -- or
644 inserted -- in transit, client implementations need to consider the
645 interaction between their application and a forged set of
646 notifications. This issue becomes particularly problematic when the
647 change notifications include entity state (using "body=true").
649 This mechanism introduces the means to learn information about the
650 state of an HTTP resource using an alternate protocol, and
651 potentially a different server. If the HTTP resource is restricted
652 using some form of access control, special care MUST be taken to
653 ensure that the SIP means of subscribing to the resource state is
654 also restricted in the same way. Otherwise, unauthorized users may
655 learn information that was intended to be confidential (including the
656 actual resource value, in some cases).
658 Similarly, if the HTTP resource is encrypted or integrity protected
659 in transit -- for example, by using HTTP over TLS [12] -- then the
660 SIP means of subscribing to the HTTP resource MUST also have
661 appropriate encryption or integrity protection applied. Examples of
662 mechanisms for providing such protection include the use of the SIPS
663 URI scheme [17], and the use of S/MIME bodies [13].
665 7. IANA Considerations
667 7.1. New Link Relations
669 The following entries are to be added to the "Link Relation Type
670 Registry," as created by the "Web Linking" specification [10].
672 Note: In the case that the final, published version of "Web
673 Linking" [10] does not deprecate the registry defined in RFC4287
674 [5], this section will be changed to add the link relations to the
675 registry defined by RFC 4287. [This note to be removed prior to
676 publication as an RFC]
678 7.1.1. New Link Relation: monitor
680 o Relation Name: monitor
681 o Description: Refers to a resource that can be used to monitor
682 changes in an HTTP resource.
684 o Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC
685 number for this specification]]
687 7.1.2. New Link Relation: monitor-group
689 o Relation Name: monitor-group
690 o Description: Refers to a resource that can be used to monitor
691 changes in a specified group of HTTP resources.
692 o Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC
693 number for this specification]]
695 7.2. New SIP Event Package: http-monitor
697 The following entry is to be added to the "SIP Events" registry, as
698 created by the SIP Event Framework [4].
700 Package Name: http-monitor
701 Type: package
702 Contact: Adam Roach, adam@nostrum.com
703 Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC
704 number for this specification]]
706 7.3. New Event Header Field Parameter: body
708 The following entry is to be added to the SIP "Header Field
709 Parameters and Parameter Values" registry, as created by the SIP
710 Change Framework [15].
712 Header Field: Event
713 Parameter Name: body
714 Predefined Values: yes
715 Reference: RFC XXXX [[Note to RFC Editor: replace with the RFC
716 number for this specification]]
718 8. Acknowledgements
720 Thanks to Lisa Dusseault and Mark Nottingham for significant input on
721 the mechanisms to bind an HTTP URL to a SIP URI. Thanks also to Mark
722 Nottingham and Theo Zourzouvillys for thorough feedback on early
723 versions of this document. Thanks to Martin Thompson, Shida
724 Schubert, John Elwell, and Scott Lawrence for their careful reviews
725 and feedback.
727 9. References
728 9.1. Normative References
730 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
731 Levels", BCP 14, RFC 2119, March 1997.
733 [2] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
734 Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
735 HTTP/1.1", RFC 2616, June 1999.
737 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
738 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
739 Session Initiation Protocol", RFC 3261, June 2002.
741 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event
742 Notification", RFC 3265, June 2002.
744 [5] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication
745 Format", RFC 4287, December 2005.
747 [6] Roach, A., Campbell, B., and J. Rosenberg, "A Session
748 Initiation Protocol (SIP) Event Notification Extension for
749 Resource Lists", RFC 4662, August 2006.
751 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for
752 Representing Resource Lists", RFC 4826, May 2007.
754 [8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
755 Specifications: ABNF", STD 68, RFC 5234, January 2008.
757 [9] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to
758 Request-Contained Resource Lists in the Session Initiation
759 Protocol (SIP)", RFC 5367, October 2008.
761 [10] Nottingham, M., "Web Linking",
762 draft-nottingham-http-link-header-06 (work in progress),
763 July 2009.
765 [11] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01
766 Specification", World Wide Web Consortium Recommendation REC-
767 html401-19991224, December 1999,
768 .
770 9.2. Informative References
772 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
774 [13] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
775 (S/MIME) Version 3.1 Message Specification", RFC 3851,
776 July 2004.
778 [14] Niemi, A., "Session Initiation Protocol (SIP) Extension for
779 Event State Publication", RFC 3903, October 2004.
781 [15] Camarillo, G., "The Internet Assigned Number Authority (IANA)
782 Header Field Parameter Registry for the Session Initiation
783 Protocol (SIP)", BCP 98, RFC 3968, December 2004.
785 [16] Dusseault, L., "HTTP Extensions for Web Distributed Authoring
786 and Versioning (WebDAV)", RFC 4918, June 2007.
788 [17] Audet, F., "The Use of the SIPS URI Scheme in the Session
789 Initiation Protocol (SIP)", RFC 5630, October 2009.
791 [18] Wachob, G., Reed, D., Chasen, L., Tan, W., and S. Churchill,
792 "Extensible Resource Identifier (XRI) Resolution V2.0",
793 February 2008, .
796 Appendix A. Rationale: Other Approaches Considered
798 Several potential mechanisms for retrieving the SIP URI from the HTTP
799 server were evaluated. Of them, link relations were determined to
800 have the most favorable set of properties. Two key candidates that
801 were considered but rejected in favor of link relations are discussed
802 below.
804 The HTTP PROPFIND method ([16], section 9.1) can be used to retrieve
805 the value of a specific property associated with an HTTP URL.
806 However, this cannot be done in conjunction with retrieval of the
807 document itself, which is usually desirable. If a PROPFIND approach
808 is employed, clients will typically perform both a GET and a PROPFIND
809 on resources of interest. Additionally, the use of PROPFIND requires
810 support of the PROPFIND method in HTTP User Agents -- which, although
811 fairly well implemented, still lacks the penetration of GET
812 implementations.
814 Similar to PROPFIND, XRDS [18] can be used to retrieve properties
815 associated with an HTTP URL. It has the advantage of using GET
816 instead of PROPFIND; however, it suffers from both the two-round-trip
817 issue discussed above, as well as an unfortunately large number of
818 options in specifying how to retrieve the properties.
820 Author's Address
822 Adam Roach
823 Tekelec
824 17210 Campbell Rd.
825 Suite 250
826 Dallas, TX 75252
827 US
829 Email: adam@nostrum.com