idnits 2.17.1 draft-roach-sip-list-subscribe-bodies-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 459. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 436. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 449. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 392 has weird spacing: '... Change in XM...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 1, 2008) is 5777 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) -- Looks like a reference, but probably isn't: 'TBD' on line 286 == Outdated reference: A later version (-14) exists of draft-ietf-simple-xcap-diff-09 ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 Expires: January 2, 2009 July 1, 2008 6 Application of Event Package Bodies to Subscriptions to Lists of 7 Resources in the Session Initiation Protocol (SIP) 8 draft-roach-sip-list-subscribe-bodies-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 2, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document specifies a mechanism by which subscriptions to the 42 state of request-contained ("ad-hoc") lists of resources can have 43 event-package-defined bodies applied to each of the contained 44 resources. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. List Subscription Bodies . . . . . . . . . . . . . . . . . . . 3 50 2.1. Negotitaion of Support . . . . . . . . . . . . . . . . . . 4 51 2.2. Extension to the Resource Lists Data Format . . . . . . . 4 52 2.3. Application of multipart/related MIME Type . . . . . . . . 4 53 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Subscription to Presence Event Package with Filters . . . 5 55 3.2. Subscription to XCAP Diff Event Package . . . . . . . . . 7 56 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5.1. XML Namespace Registration . . . . . . . . . . . . . . . . 8 59 5.2. XML Schema Registration . . . . . . . . . . . . . . . . . 9 60 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 Intellectual Property and Copyright Statements . . . . . . . . . . 12 64 1. Introduction 66 The SIP-specific event notification protocol extension speficied by 67 RFC 3265 [4] provides the ability for event packages to define bodies 68 for use in SUBSCRIBE messages. These bodies generally provide 69 information that modifies the behavior of the subscription, such as 70 filtering or throttling the information that arrives in subsequent 71 NOTIFY messages. 73 The extension for susbcriptions to predefined lists of resoueces [7] 74 defines a mechanism by which a single SUBSCRIBE message can be used 75 to retrieve the state of multiple resources. This is achieved by 76 defining, via some non-SIP mechanism, a list of resources and 77 associtating these resources with a SIP URI. Subscribers can then 78 subscribe to this single SIP URI and receive state information for 79 each resource in the associated list. 81 The extension for subscriptions to request-contatined ("ad-hoc") 82 lists of resources [1] specifies a mechanism for subscribing to a 83 list of resources in SIP, while defining the list of resources at the 84 time the subscription is created. This is performed by including the 85 list of the URIs to which a list subscription is desired in the body 86 of the SUBSCRIBE message. 88 The current set of mechanisms for subscribing to a list of several 89 resources does not currently provide the means for specification of 90 the body or bodies that are to apply to each of the subscriptions. 91 For certain types of subscriptions, such as presence subscriptions, 92 this creates an inconvenience, as filters cannot be adequately 93 conveyed on a per-resource basis. For other event packages, such as 94 XCAP diff [2], this provides a complete barrier to operation, as XCAP 95 diff subscriptions require the presence of SUBSCRIBE bodies to 96 function at all. 98 This document proposes a solution to this situation by the optional 99 application of a multipart/related [3] body in ad-hoc list 100 subscriptions. In this multipart/related document, the root document 101 contains the ad-hoc list of resources to which the subscription is 102 being established, while the additional body parts contain 103 information relevant to the event-package being invoked. 105 2. List Subscription Bodies 107 Subscribers making use of ad-hoc list subscriptions can indicate 108 bodies to be applied to one or more of the resources on the list by 109 using a multipart/related body, as described in the following 110 sections. 112 2.1. Negotitaion of Support 114 [Open Issue: should we simply rely on the normal SIP content-type 115 negotiate here? Or do we need to add yet another option tag to 116 explicitly signal support for this behavior?] 118 2.2. Extension to the Resource Lists Data Format 120 This document defines an extension to the XML resource list data 121 format [8] that allows binding of resource list elements to body 122 parts in a multipart MIME body. To acheive this, this document adds 123 a new "cid" attribute to the element of the resource list 124 document format. This "cid" attribute binds the resource to a body 125 part contained within the same multipart MIME document as the 126 resource list itself appears. For resource lists appearing outside 127 of the context of a multipart MIME body, the "cid" attribute has no 128 meaning, and can safely be ignored. 130 The schema for the new "cid" attribute is as follows: 132 133 140 143 144 146 [TODO: I'm not completely certain that this schema is 100% correct -- 147 how do we indicate that is specific to the element?] 149 2.3. Application of multipart/related MIME Type 151 To apply event-package-defined bodies to a resource in an ad-hoc list 152 subscription, subscribers compose a SUBSCRIBE message with a top- 153 level MIME body type of "multipart/related." The root of this 154 document will be the resource list (of content type "application/ 155 resource-lists+xml") that defines the list of resources to which the 156 request pertains. The remaing sections in the multipart/related 157 document will contain bodies that are to be interpreted according to 158 the event package indicated in the SUBSCRIBE message "Event" header 159 field. 161 Within the resource list document, any to which an event- 162 package-defined body is to be applied will also contain a "cid" 163 attribute. This "cid" attribute identifies a section within the 164 multipart/related document; this section contains an event-package- 165 specific document that is to be applied to the corresponding 166 resource, according to the rules of the event package. 168 In many cases, such as when the event-package-specific bodies are 169 filtering the state that is to be sent for a resouce, the body to be 170 applied may be common for several resources. To allow for efficient 171 encoding of these cases, multiple elements may refer to the 172 same cid. The section indicated by the cid is appplies to every 173 that references it. 175 Implementors of the mechanism defined in this document are cautioned 176 to take particular care that Content-Disposition headers are 177 associated with the proper MIME body. For example, the top-level 178 MIME body, of type "multipart/related", will not contain a "Content- 179 Disposition" of "recipient-list"; however, its root document, of type 180 "aapplication/resource-lists+xml", will. 182 3. Examples 184 3.1. Subscription to Presence Event Package with Filters 186 This example shows the SUBSCRIBE message for a subscription to an ad- 187 hoc list of presence information [2], with the application of a 188 single notification filter [6] to all of the indicated resources. 190 SUBSCRIBE sip:rls@example.com SIP/2.0 191 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKDlg07GFl 192 Max-Forwards: 70 193 To: RLS 194 From: ;tag=sg83ltmq 195 Call-ID: srag0983kgo@terminal.example.com 196 CSeq: 1 SUBSCRIBE 197 Contact: 198 Event: xcap-diff; diff-processing=agregate 199 Expires: 7200 200 Require: recipient-list-subscribe 201 Supported: eventlist 202 Accept: application/pidf+xml 203 Accept: application/rlmi+xml 204 Accept: multipart/related 205 Accept: multipart/signed 206 Accept: multipart/encrypted 207 Content-Type: multipart/related; 208 type="application/resource-lists+xml"; 209 start=""; 210 boundary="05HOsJ2YFPIYgttHCr0m" 211 Content-Length: [TBD] 213 --05HOsJ2YFPIYgttHCr0m 214 Content-ID: 215 Content-Type: application/resource-lists+xml;charset="UTF-8" 216 Content-Disposition: recipient-list 218 219 222 223 225 227 228 230 --05HOsJ2YFPIYgttHCr0m 231 Content-ID: 232 Content-Type: application/simple-filter+xml;charset="UTF-8" 234 235 236 237 238 239 240 241 242 urn:ietf:params:xml:ns:pidf 243 244 //pidf:tuple/pidf:note 245 246 247 248 249 250 //pidf:tuple/pidf:status/pidf:basic 251 252 254 256 --05HOsJ2YFPIYgttHCr0m-- 258 3.2. Subscription to XCAP Diff Event Package 260 This example shows the SUBSCRIBE message for a subscription to an ad- 261 hoc list of XCAP-diff [2] resources. This would be applicable, for 262 example, if a client wants to monitor resources on multiple XCAP 263 servers through a single subscription. 265 SUBSCRIBE sip:rls@example.com SIP/2.0 266 Via: SIP/2.0/TCP terminal.example.com;branch=z9hG4bKwYb6QREiCL 267 Max-Forwards: 70 268 To: RLS 269 From: ;tag=ie4hbb8t 270 Call-ID: cdB34qLToC@terminal.example.com 271 CSeq: 1 SUBSCRIBE 272 Contact: 273 Event: xcap-diff; diff-processing=agregate 274 Expires: 7200 275 Require: recipient-list-subscribe 276 Supported: eventlist 277 Accept: application/xcap-diff+xml 278 Accept: application/rlmi+xml 279 Accept: multipart/related 280 Accept: multipart/signed 281 Accept: multipart/encrypted 282 Content-Type: multipart/related; 283 type="application/resource-lists+xml"; 284 start=""; 285 boundary="50UBfW7LSCVLtggUPe5z" 286 Content-Length: [TBD] 288 --50UBfW7LSCVLtggUPe5z 289 Content-ID: 290 Content-Type: application/resource-lists+xml;charset="UTF-8" 291 Content-Disposition: recipient-list 293 294 297 298 300 302 303 305 --50UBfW7LSCVLtggUPe5z 306 Content-ID: 307 Content-Type: application/resource-lists+xml;charset="UTF-8" 308 Content-Disposition: [!!! XCAP Event still needs to define one !!!] 310 311 312 313 314 315 316 318 --50UBfW7LSCVLtggUPe5z 319 Content-ID: 320 Content-Type: application/resource-lists+xml;charset="UTF-8" 321 Content-Disposition: [!!! XCAP Event still needs to define one !!!] 323 324 325 326 327 328 329 331 --50UBfW7LSCVLtggUPe5z-- 333 4. Security Considerations 335 The security considerations that apply to SIP list subscriptions also 336 apply to this work, as do the considerations surrounding the use of 337 filters for state subscriptions. The author of this document has not 338 identified any unique security considerations that arise from the 339 combination of these two protocol extensions. 341 5. IANA Considerations 343 5.1. XML Namespace Registration 345 This section registers a new XML namespace in the IANA XML registry, 346 as described in RFC 3688 [5]. 348 URI: urn:ietf:params:xml:ns:rl-cid 350 Registrant Contact: IETF, SIP working group 352 XML: 354 BEGIN 355 356 358 359 360 362 Resource List CID Attribute 363 364 365

Namespace for a CID attribute in Resource Lists

366

urn:ietf:params:xml:ns:rl-cid

367

See RFCXXXX 368 [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with 369 the RFC number of this specification.].

370 371 372 END 374 5.2. XML Schema Registration 376 This section registers a new XML Schema in the IANA XML registry, as 377 described in RFC 3688 [5]. 378 URI: urn:ietf:params:xml:ns:rl-cid 380 Registrant Contact: IETF, SIP working group 382 The schema for this registration can be found in Section 2.2. 384 6. References 386 [1] Camarillo, G., Roach, A., and O. Levin, "Subscriptions to 387 Request-Contained Resource Lists in the Session Initiation 388 Protocol (SIP)", draft-ietf-sip-uri-list-subscribe-02 (work in 389 progress), November 2007. 391 [2] Rosenberg, J. and J. Urpalainen, "An Extensible Markup Language 392 (XML) Document Format for Indicating A Change in XML 393 Configuration Access Protocol (XCAP) Resources", 394 draft-ietf-simple-xcap-diff-09 (work in progress), May 2008. 396 [3] Levinson, E., "The MIME Multipart/Related Content-type", 397 RFC 2387, August 1998. 399 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 400 Notification", RFC 3265, June 2002. 402 [5] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 403 January 2004. 405 [6] Khartabil, H., Leppanen, E., Lonnfors, M., and J. Costa-Requena, 406 "Functional Description of Event Notification Filtering", 407 RFC 4660, September 2006. 409 [7] Roach, A., Campbell, B., and J. Rosenberg, "A Session Initiation 410 Protocol (SIP) Event Notification Extension for Resource Lists", 411 RFC 4662, August 2006. 413 [8] Rosenberg, J., "Extensible Markup Language (XML) Formats for 414 Representing Resource Lists", RFC 4826, May 2007. 416 Author's Address 418 Adam Roach 419 Tekelec 420 17210 Campbell Rd. 421 Suite 250 422 Dallas, TX 75252 423 US 425 Email: adam@nostrum.com 427 Intellectual Property Statement 429 The IETF takes no position regarding the validity or scope of any 430 Intellectual Property Rights or other rights that might be claimed to 431 pertain to the implementation or use of the technology described in 432 this document or the extent to which any license under such rights 433 might or might not be available; nor does it represent that it has 434 made any independent effort to identify any such rights. Information 435 on the procedures with respect to rights in RFC documents can be 436 found in BCP 78 and BCP 79. 438 Copies of IPR disclosures made to the IETF Secretariat and any 439 assurances of licenses to be made available, or the result of an 440 attempt made to obtain a general license or permission for the use of 441 such proprietary rights by implementers or users of this 442 specification can be obtained from the IETF on-line IPR repository at 443 http://www.ietf.org/ipr. 445 The IETF invites any interested party to bring to its attention any 446 copyrights, patents or patent applications, or other proprietary 447 rights that may cover technology that may be required to implement 448 this standard. Please address the information to the IETF at 449 ietf-ipr@ietf.org. 451 Disclaimer of Validity 453 This document and the information contained herein are provided on an 454 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 455 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 456 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 457 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 458 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 459 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 461 Copyright Statement 463 Copyright (C) The IETF Trust (2008). This document is subject to the 464 rights, licenses and restrictions contained in BCP 78, and except as 465 set forth therein, the authors retain all their rights. 467 Acknowledgment 469 Funding for the RFC Editor function is currently provided by the 470 Internet Society.