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