idnits 2.17.1 draft-camarillo-sipping-multiple-refer-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 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 (February 6, 2004) is 7385 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) == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-01 == Outdated reference: A later version (-03) exists of draft-camarillo-sipping-exploders-01 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group G. Camarillo 3 Internet-Draft Ericsson 4 Expires: August 6, 2004 A. Niemi 5 H. Khartabil 6 M. Isomaki 7 Nokia 8 February 6, 2004 10 Refering to Multiple Resources in the Session Initiation Protocol 11 (SIP) 12 draft-camarillo-sipping-multiple-refer-00.txt 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at http:// 29 www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 6, 2004. 36 Copyright Notice 38 Copyright (C) The Internet Society (2004). All Rights Reserved. 40 Abstract 42 This document defines extensions to the SIP REFER method so that this 43 method can be used to refer to multiple resources. These extensions 44 include the use of pointers to URI-lists in the Refer-To header 45 field, the use of bodies to describe the requests to be sent by the 46 server, and the use of a new event package to report the state of 47 several transactions. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Carrying Multiple Destinations . . . . . . . . . . . . . . . . 3 54 4. The Transaction State Event Package . . . . . . . . . . . . . 4 55 5. The Multiple-Refer SIP Option-Tag . . . . . . . . . . . . . . 5 56 6. The Template Disposition-Type . . . . . . . . . . . . . . . . 6 57 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 Normative References . . . . . . . . . . . . . . . . . . . . . 8 61 Informational References . . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 63 Intellectual Property and Copyright Statements . . . . . . . . 10 65 1. Introduction 67 The need for exploders in SIP [2] is described in [6]. Mechanisms to 68 invoke exploders in SIP need to meet the requirements listed there. 70 The SIP REFER method [4] allows a user agent to request a server to 71 send a request to a third party. Still, a number of applications need 72 to request a server to initiate transactions towards a set of 73 destinations. We define several extensions to REFER so that REFER can 74 be used to refer to multiple destinations (e.g., a user agent 75 requesting a conferencing server to INVITE several new participants). 77 2. Terminology 79 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 80 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 81 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 82 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 83 compliant implementations. 85 We define the following three new terms: 87 REFER-Issuer: the UA issuing the REFER request. 89 REFER-Recipient: the UA receiving the REFER request. 91 REFER-Target: the UA designated in the Refer-To URI. 93 3. Carrying Multiple Destinations 95 We represent the multiple REFER-Targets of a REFER using a URI list. 96 We use the Refer-To header field to carry a pointer to that URI-list. 98 draft-camarillo-sipping-uri-list provides rules to carry a pointer to 99 a URI list in a URI parameter called list. Refer-To header fields 100 carring a pointer to a URI-list follow the same rules. That is, the 101 Refer-To header field of REFER with multiple REFER-Targets MUST 102 contain a URI that points to a URI list. The XCAP resource list 103 format [5] MUST be supported; any other URI list formats MAY be 104 supported. 106 The following is an example of a REFER with a Refer-To header field 107 that points to a URI list which is carried in the message body. The 108 option-tag "multiple-refer" in the Require header, which is defined 109 in Section 5, ensures that the REFER-Recipient understands Refer-To 110 header fields with pointers to URI lists. 112 REFER sip:b@atlanta.example.com SIP/2.0 113 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293 114 To: 115 From: ;tag=193402342 116 Call-ID: 898234234@agenta.atlanta.example.com 117 CSeq: 1 REFER 118 Max-Forwards: 70 119 Require: multiple-refer 120 Refer-To: cid:cn35t8jf02@example.com 121 Contact: sip:a@atlanta.example.com 122 Accept: application/sdp, message/sipfrag, 123 application/transaction-info+xml 124 Content-Type: application/resource-lists+xml 125 Content-Length: xxx 126 Content-ID: 128 129 130 131 132 133 134 135 136 138 Figure 1 140 4. The Transaction State Event Package 142 REFER requests establish an implicit subscription to the "refer" 143 event package, defined in [4]. The data format used in this event 144 package is message/sipfrag, which is defined in [3]. The REFER 145 specification says the following about the NOTIFIES triggered by the 146 REFER's implicit subscription: 148 Each NOTIFY MUST contain an Event header field with a value of 149 refer and possibly an id parameter. 151 Each NOTIFY MUST contain a body of type "message/sipfrag". 153 We keep the first statement, but relax the second statement (about 154 the body format) so that the refer event package is aligned with any 155 other event package. That is, the notifier can choose any format that 156 is applicable to the event package and that appears in the Accept 157 header field of the request that created the subscription (the REFER, 158 in our case). The resulting normative statement is the following: 160 The notifications generated by the server MUST be in one of the 161 formats specified in the Accept header field in the REFER request. 163 The default format, which MUST be supported by all UAs that generate 164 REFERs with the option-tag "multiple-refer" in a Require header 165 field, is "application/transaction-info+xml", as defined in 166 (draft-camarillo-sipping-transac-package). 168 The following is an example of the body of a NOTIFY generated by the 169 REFER-Recipient of the REFER in Figure 1. 171 172 176 177 complete 178 179 180 complete 181 182 183 complete 184 185 186 complete 187 188 190 Figure 2 192 5. The Multiple-Refer SIP Option-Tag 194 We define a new SIP option-tag for the Require and Supported header 195 fields: multiple-refer. 197 A UA including the multiple-refer option-tag in a Supported header 198 understands Refer-To header fields that point to URI lists and 199 understands the "application/transaction-info+xml" body type. 201 A UA generating a REFER with a pointer to a URI-list in its Refer-To 202 header field MUST include the multiple-refer option-tag in the 203 Require header field of the REFER. 205 6. The Template Disposition-Type 207 When using REFER, the new request to be sent is described using URI 208 parameters. For example, the following Refer-To header field contains 209 the values of the Accept-Contact and Call-ID header fields of the new 210 request. 212 Refer-To: 215 REFERs with multiple REFER-Targets usually request that the 216 REFER-Recipient sends a set of similar requests. Describing a set of 217 similar requests by adding the same URI parameters to all the URIs in 218 the definition of the URI list is not an efficient way to encode that 219 information. 221 We define a new disposition-type: template. Bodies of this 222 disposition-type (typically sipfrag bodies as defined in RFC 3420 223 [3]) provide the server with a template for the messages to be sent. 225 The following example shows a body whose disposition-type is 226 template. It indicates that the requests to be sent should be 227 MESSAGEs carrying the text "Hello world." 229 Content-Disposition: template;handling=required 230 Content-type: message/sipfrag 231 Content-Length: xxx 233 MESSAGE sip:whoever.invalid SIP/2.0 234 Content-Type: text/plain 235 Content-Length: 12 237 Hello World. 239 If any of the URIs defining the REFER-Targets has a URI parameter 240 indicating a different value for a header field than the one 241 indicated in the template, the exploder MUST use the value in the URI 242 parameter. 244 Note that in order to include the method in a sipfrag body, it is 245 necessary to include the Request-URI as well (the whole Request-line 246 needs to be included as specified in RFC 3420 [3]. If the REFER 247 request contains a single REFER-Target, the URI of the Request-Target 248 SHOULD be placed in the Request-URI of the template body. Otherwise, 249 it is RECOMMENDED that the Request-URI in the template body is an 250 invalid URI. 252 OPEN ISSUE: we may want to define an option-tag for this 253 disposition-type, or to include support for this disposition type in 254 the multiple-refer option tag. 256 7. Example 258 We need to add the whole call flow. 260 REFER sip:b@atlanta.example.com SIP/2.0 261 Via: SIP/2.0/UDP agenta.atlanta.example.com;branch=z9hG4bK2293 262 To: 263 From: ;tag=193402342 264 Call-ID: 898234234@agenta.atlanta.example.com 265 CSeq: 1 REFER 266 Max-Forwards: 70 267 Require: multiple-refer 268 Refer-To: cid:cn35t8jf02@example.com 269 Contact: sip:a@atlanta.example.com 270 Accept: application/sdp, message/sipfrag, 271 application/transaction-info+xml 272 Conten-Type: multipart/mixed;boundary="boundary1" 273 Content-Length: xxx 275 --boundary1 276 Content-Disposition: template;handing=required 277 Content-type: message/sipfrag 278 Content-Length: xxx 280 MESSAGE sip:whoever.invalid SIP/2.0 281 Content-Type: text/plain 282 Content-Length: 12 284 Hello World. 286 --boundary1 287 Content-Type: application/resource-lists+xml 288 Content-Length: xxx 289 Content-ID: 291 292 293 294 295 296 297 298 300 301 --boundary1-- 303 8. Security Considerations 305 TBD 307 9. IANA Considerations 309 TBD: we need to register the multiple-refer option-tag and the 310 template disposition type. 312 Normative References 314 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 315 Levels", BCP 14, RFC 2119, March 1997. 317 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 318 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 319 Session Initiation Protocol", RFC 3261, June 2002. 321 [3] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 322 November 2002. 324 [4] Sparks, R., "The Session Initiation Protocol (SIP) Refer 325 Method", RFC 3515, April 2003. 327 [5] Rosenberg, J., "An Extensible Markup Language (XML) 328 Configuration Access Protocol (XCAP) Usage for Presence Lists", 329 draft-ietf-simple-xcap-list-usage-01 (work in progress), October 330 2003. 332 Informational References 334 [6] Camarillo, G., "Requirements for Session Initiation Protocol 335 (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-01 336 (work in progress), November 2003. 338 Authors' Addresses 340 Gonzalo Camarillo 341 Ericsson 342 Hirsalantie 11 343 Jorvas 02420 344 Finland 346 EMail: Gonzalo.Camarillo@ericsson.com 348 Aki Niemi 349 Nokia 350 P.O. Box 321 351 NOKIA GROUP, FIN 00045 352 Finland 354 EMail: Aki.Niemi@nokia.com 356 Hisham Khartabil 357 Nokia 358 P.O. Box 321 359 NOKIA GROUP, FIN 00045 360 Finland 362 EMail: Hisham.Khartabil@nokia.com 364 Markus Isomaki 365 Nokia 366 Itamerenkatu 11-13 367 Helsinki 00180 368 Finland 370 EMail: Markus.Isomaki@nokia.com 372 Intellectual Property Statement 374 The IETF takes no position regarding the validity or scope of any 375 intellectual property or other rights that might be claimed to 376 pertain to the implementation or use of the technology described in 377 this document or the extent to which any license under such rights 378 might or might not be available; neither does it represent that it 379 has made any effort to identify any such rights. Information on the 380 IETF's procedures with respect to rights in standards-track and 381 standards-related documentation can be found in BCP-11. Copies of 382 claims of rights made available for publication and any assurances of 383 licenses to be made available, or the result of an attempt made to 384 obtain a general license or permission for the use of such 385 proprietary rights by implementors or users of this specification can 386 be obtained from the IETF Secretariat. 388 The IETF invites any interested party to bring to its attention any 389 copyrights, patents or patent applications, or other proprietary 390 rights which may cover technology that may be required to practice 391 this standard. Please address the information to the IETF Executive 392 Director. 394 Full Copyright Statement 396 Copyright (C) The Internet Society (2004). All Rights Reserved. 398 This document and translations of it may be copied and furnished to 399 others, and derivative works that comment on or otherwise explain it 400 or assist in its implementation may be prepared, copied, published 401 and distributed, in whole or in part, without restriction of any 402 kind, provided that the above copyright notice and this paragraph are 403 included on all such copies and derivative works. However, this 404 document itself may not be modified in any way, such as by removing 405 the copyright notice or references to the Internet Society or other 406 Internet organizations, except as needed for the purpose of 407 developing Internet standards in which case the procedures for 408 copyrights defined in the Internet Standards process must be 409 followed, or as required to translate it into languages other than 410 English. 412 The limited permissions granted above are perpetual and will not be 413 revoked by the Internet Society or its successors or assignees. 415 This document and the information contained herein is provided on an 416 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 417 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 418 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 419 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 420 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 422 Acknowledgment 424 Funding for the RFC Editor function is currently provided by the 425 Internet Society.