idnits 2.17.1 draft-ietf-sipping-multiple-refer-05.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 472. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 449. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 456. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 462. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- No issues found here. 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 (May 11, 2006) is 6558 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 (-07) exists of draft-ietf-sipping-uri-services-05 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING Working Group G. Camarillo 2 Internet-Draft Ericsson 3 Expires: November 12, 2006 A. Niemi 4 M. Isomaki 5 M. Garcia-Martin 6 Nokia 7 H. Khartabil 8 Telio 9 May 11, 2006 11 Refering to Multiple Resources in the Session Initiation Protocol (SIP) 12 draft-ietf-sipping-multiple-refer-05.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on November 12, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 This document defines extensions to the SIP REFER method so that this 46 method can be used to refer servers to multiple resources. These 47 extensions include the use of pointers to Uniform Resource Identifier 48 (URI)-lists in the Refer-To header field and the "multiple-refer" SIP 49 option-tag. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3 56 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4 57 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4 58 6. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 5 59 7. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 5 60 8. Default URI-List Format . . . . . . . . . . . . . . . . . . . 5 61 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 66 12.2. Informational References . . . . . . . . . . . . . . . . 10 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 68 Intellectual Property and Copyright Statements . . . . . . . . . . 12 70 1. Introduction 72 The SIP [3] REFER method [5] allows a user agent to request a server 73 to send a request to a third party. Still, a number of applications 74 need to request a server to initiate transactions towards a set of 75 destinations. In one example, the moderator of a conference may want 76 the conference server to send BYE requests to a group of 77 participants. In another example, the same moderator may want the 78 conference server to INVITE a set of new participants. 80 We define an extension to REFER so that REFER can be used to refer 81 servers to multiple destinations. In addition, we use the REFER 82 extension defined in [7] which suppresses REFER's implicit 83 subscription. 85 2. Terminology 87 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 88 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 89 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 90 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 91 compliant implementations. 93 We define the following three new terms: 95 REFER-Issuer: the user agent issuing the REFER request. 96 REFER-Recipient: the user agent receiving the REFER request. 97 REFER-Target: the intended final recipient of the request to be 98 generated by the REFER-Recipient. 100 3. Overview of operation 102 This document defines an extension to the SIP REFER method [5] that 103 allows a SIP User Agent Client (UAC) to include a list of REFER- 104 Targets in a REFER request and send it to a server. The server will 105 create a new request for each entry in the list of REFER-Target URIs. 107 We represent the multiple REFER-Targets of a REFER using a URI-list. 108 A UAC (User Agent Client) that wants to refer a server to a set of 109 destinations creates a SIP REFER request. The Refer-To header 110 contains a pointer to a URI-list, which is included in a body part, 111 and an option-tag in the Required header field: "multiple-refer". 112 This option-tag indicates the requirement to support the 113 functionality described in this specification. 115 When the server receives such request it creates a new request per 116 destination and sends them. 118 This document does not provide any mechanism for UACs to find out 119 about the results of a REFER with multiple REFER-Targets. 120 Furthermore, it does not provide support for the implicit 121 subscription mechanism that is part of the SIP REFER method. The way 122 UACs are kept informed about the results of a REFER is service 123 specific. For example, a UAC sending a REFER to INVITE a set of 124 participants to a conference may discover which participants were 125 successfully brought into the conference by subscribing to the 126 conference state event [9]. 128 4. The multiple-refer SIP Option-Tag 130 We define a new SIP option-tag for the Require and Supported header 131 fields: "multiple-refer". 133 A user agent including the "multiple-refer" option-tag in a Supported 134 header indicates compliance with this specification. 136 A user agent generating a REFER with a pointer to a URI-list in its 137 Refer-To header field MUST include the "multiple-refer" option-tag in 138 the Require header field of the REFER. 140 5. Suppressing REFER's Implicit Subscription 142 REFER requests with a single REFER-Target establish implicitly a 143 subscription to the refer event. The REFER-Issuer is informed about 144 the result of the transaction towards the REFER-Target through this 145 implicit subscription. As described in RFC 3515 [5], NOTIFY requests 146 sent as a result of an implicit subscription created by a REFER 147 request contain a body of type "message/sipfrag" [4] that describes 148 the status of the transaction initiated by the REFER-Recipient. 150 In the case of a REFER-Issuer that generates a REFER with multiple 151 REFER-targets, the REFER-Issuer is typically already subscribed to 152 other event package that can provide the information about the result 153 of the transactions towards the REFER-Targets. For example, a 154 moderator instructing a conference server to send a BYE request to a 155 set of participants is usually subscribed to the conference state 156 event package for the conference. Notifications to this event 157 package will keep the moderator and the rest of the subscribers 158 informed of the current list of conference participants. 160 Most of the applications using multiple REFER do not need its 161 implicit subscription. Consequently, a SIP REFER-Issuer generating a 162 REFER request with multiple REFER-Targets SHOULD include the 163 "norefersub" option-tag in a Require header field to indicate that no 164 notifications about the requests should be sent to the REFER-Issuer. 165 The "norefersub" SIP option-tag is defined in [7] and suppresses the 166 REFER's implicit subscription. 168 At the time of writing, there is no extension that allows to report 169 the status of several transactions over a REFER's implicit 170 subscription. That is the motivation for this document to recommend 171 the usage of the "norefersub" option-tag. If in the future such an 172 extension is defined, REFER-Issuers using it could refrain from using 173 the "norefersub" option-tag and use the new extension instead. 175 6. Behavior of SIP REFER-Issuers 177 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that 178 creates a REFER request with multiple REFER-Targets includes a 179 "multiple-refer" and a "norefersub" option-tags in the Require header 180 field. 182 The Refer-To header field of a REFER request with multiple REFER- 183 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 184 Locator (URL) [2]) that points to the body part that carries the URI- 185 list. The REFER-Issuer SHOULD NOT include any particular URI more 186 than once in the URI-list. 188 7. Behavior of REFER-Recipients 190 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 191 [5] to determine the status code of the response to the REFER. 193 If the URI-list contains a URI more than once, the REFER-Recipient 194 MUST behave as if that URI appeared in the URI-list only once. The 195 REFER-Recipient uses the comparison rules specific to the URI scheme 196 of each of the URIs in the URI-list to determine if there is any URI 197 which appears more than once. 199 The REFER-Recipient follows the rules in RFC 3515 [5] to generate the 200 necessary requests towards the REFER-Targets, acting as if it had 201 received a regular (no URI-list) REFER per each URI in the URI-list. 203 8. Default URI-List Format 205 The default format for URI-list bodies used in a multiple REFER 206 request is the resource list document specified in [6]. User agents 207 able to generate or receive REFERs with multiple REFER-Targets MUST 208 support this format as specified in [6] and MAY support other 209 formats. 211 Nevertheless, the Extensible Markup Language (XML) Configuration 212 Access Protocol (XCAP) resource list document provides features, such 213 as hierarchical lists and the ability to include entries by reference 214 relative to the XCAP root URI, that are not needed by the multiplet 215 REFER service defined in this document. Therefore, when using the 216 default resource list document, SIP REFER-Issuers generating REFERs 217 with multiple REFER-Targets SHOULD use flat lists (i.e., no 218 hierarchical lists) and SHOULD NOT use elements. 220 A REFER-Recipient receiving a URI-list with more information than 221 what has just been described MAY discard all the extra information. 223 Figure 1 shows an example of a flat list that follows the resource 224 list document. 226 227 229 230 231 232 233 234 236 Figure 1: URI List 238 9. Example 240 Figure 2 shows an example flow where a REFER-Issuer sends a multiple- 241 REFER request to the focus of a conference, which acts as the REFER- 242 Recipient. The REFER-Recipient generates a BYE request per REFER- 243 Target. (How to use REFER to remove participants from a conference 244 is specified in [10].) 245 +--------+ +---------+ +--------+ +--------+ +--------+ 246 | REFER | | REFER | | REFER | | REFER | | REFER | 247 | issuer | |recipient| |target 1| |target 2| |target 3| 248 +--------+ +---------+ +--------+ +--------+ +--------+ 249 | 1. REFER | | | | 250 | ---------------->| | | | 251 | 2. 202 Accepted | | | | 252 |<---------------- | 3. BYE | | | 253 | | ----------->| | | 254 | | 4. BYE | | | 255 | | ----------------------->| | 256 | | 5. BYE | | | 257 | | ----------------------------------->| 258 | | 6. 200 OK | | | 259 | |<----------- | | | 260 | | 7. 200 OK | | | 261 | |<----------------------- | | 262 | | 8. 200K OK| | | 263 | |<----------------------------------- | 264 | | | | | 265 | | | | | 266 | | | | | 268 Figure 2: Example flow or a REFER request containin multiple REFER- 269 Targets 271 The REFER request (1) contains a Refer-To header field that includes 272 a pointer to the message body, which carries a list with the URIs of 273 the REFER-Targets. The REFER's Require header field carries both the 274 "multiple-refer" and the "norefersub" option-tags. Figure 3 shows an 275 example of this REFER request. The resource list document contains 276 the list of REFER-Target URIs along with the method of the SIP 277 request that the REFER-Recipient generates. 279 REFER sip:conf-123@example.com SIP/2.0 280 Via: SIP/2.0/TCP client.chicago.example.com 281 ;branch=z9hG4bKhjhs8ass83 282 Max-Forwards: 70 283 To: "Conference 123" 284 From: Carol ;tag=32331 285 Call-ID: d432fa84b4c76e66710 286 CSeq: 2 REFER 287 Contact: 288 Refer-To: 289 Require: multiple-refer, norefersub 290 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 291 Allow-Events: dialog 292 Accept: application/sdp, message/sipfrag 293 Content-Type: application/resource-lists+xml 294 Content-Disposition: uri-list 295 Content-Length: 307 296 Content-ID: 298 299 301 302 303 304 305 306 308 Figure 3: REFER request with multiple REFER-Targets 310 Figure 4 shows an example of the BYE request (3) that the REFER- 311 Recipient sends to the first REFER-Target. 313 BYE sip:bill@example.com SIP/2.0 314 Via: SIP/2.0/TCP conference.example.com 315 ;branch=z9hG4bKhjhs8assmm 316 Max-Forwards: 70 317 From: "Conference 123" ;tag=88734 318 To: ;tag=29872 319 Call-ID: d432fa84b4c34098s812 320 CSeq: 34 BYE 321 Content-Length: 0 323 Figure 4: BYE request 325 10. Security Considerations 327 The Framework and Security Considerations for SIP URI-List Services 328 [8] discusses issues related to SIP URI-list services. Given that a 329 server accepting REFERs with multiple REFER-targets acts as an URI- 330 list service, implementations of this type of server MUST follow the 331 security-related rules in [8]. These rules include mandatory 332 authentication and authorization of clients, and opt-in lists. 334 Additionally, servers SHOULD only accept REFER requests within the 335 context of an application the server understands (e.g., a 336 conferencing application). This implies that servers MUST NOT accept 337 REFERs for methods they do not understand. The idea behind these two 338 rules is that servers are not used as dumb servers whose only 339 function is to fan-out random messages they do not understand. 341 11. IANA Considerations 343 This document defines a new SIP option-tag: "multiple-refer". This 344 option-tag should be registered in the SIP Parameters registry. 346 SIP user agents that place the "multiple-refer" option-tag in a 347 Supported header field understand REFER requests that contain 348 resource list document describing multiple REFER-Targets. 350 12. References 352 12.1. Normative References 354 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 355 Levels", BCP 14, RFC 2119, March 1997. 357 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 358 Locators", RFC 2392, August 1998. 360 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 361 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 362 Session Initiation Protocol", RFC 3261, June 2002. 364 [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 365 November 2002. 367 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 368 Method", RFC 3515, April 2003. 370 [6] Rosenberg, J., "Extensible Markup Language (XML) Formats for 371 Representing Resource Lists", 372 draft-ietf-simple-xcap-list-usage-05 (work in progress), 373 February 2005. 375 [7] Levin, O., "Suppression of Session Initiation Protocol REFER 376 Method Implicit Subscription", 377 draft-ietf-sip-refer-with-norefersub-04 (work in progress), 378 January 2006. 380 [8] Camarillo, G. and A. Roach, "Framework and Security 381 Considerations for Session Initiation Protocol (SIP) Uniform 382 Resource Identifier (URI)-List Services", 383 draft-ietf-sipping-uri-services-05 (work in progress), 384 January 2006. 386 12.2. Informational References 388 [9] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 389 Package for Conference State", 390 draft-ietf-sipping-conference-package-12 (work in progress), 391 July 2005. 393 [10] Levin, O., "Session Initiation Protocol Call Control - 394 Conferencing for User Agents", 395 draft-ietf-sipping-cc-conferencing-07 (work in progress), 396 June 2005. 398 Authors' Addresses 400 Gonzalo Camarillo 401 Ericsson 402 Hirsalantie 11 403 Jorvas 02420 404 Finland 406 Email: Gonzalo.Camarillo@ericsson.com 408 Aki Niemi 409 Nokia 410 P.O. Box 321 411 NOKIA GROUP, FIN 00045 412 Finland 414 Email: Aki.Niemi@nokia.com 416 Markus Isomaki 417 Nokia 418 Itamerenkatu 11-13 419 Helsinki 00180 420 Finland 422 Email: Markus.Isomaki@nokia.com 424 Miguel A. Garcia-Martin 425 Nokia 426 P.O.Box 407 427 NOKIA GROUP, FIN 00045 428 Finland 430 Email: miguel.an.garcia@nokia.com 432 Hisham Khartabil 433 Telio 434 P.O. Box 1203 435 Oslo 0110 436 Norway 438 Email: Hisham.Khartabil@telio.no 440 Intellectual Property Statement 442 The IETF takes no position regarding the validity or scope of any 443 Intellectual Property Rights or other rights that might be claimed to 444 pertain to the implementation or use of the technology described in 445 this document or the extent to which any license under such rights 446 might or might not be available; nor does it represent that it has 447 made any independent effort to identify any such rights. Information 448 on the procedures with respect to rights in RFC documents can be 449 found in BCP 78 and BCP 79. 451 Copies of IPR disclosures made to the IETF Secretariat and any 452 assurances of licenses to be made available, or the result of an 453 attempt made to obtain a general license or permission for the use of 454 such proprietary rights by implementers or users of this 455 specification can be obtained from the IETF on-line IPR repository at 456 http://www.ietf.org/ipr. 458 The IETF invites any interested party to bring to its attention any 459 copyrights, patents or patent applications, or other proprietary 460 rights that may cover technology that may be required to implement 461 this standard. Please address the information to the IETF at 462 ietf-ipr@ietf.org. 464 Disclaimer of Validity 466 This document and the information contained herein are provided on an 467 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 468 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 469 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 470 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 471 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 472 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 474 Copyright Statement 476 Copyright (C) The Internet Society (2006). This document is subject 477 to the rights, licenses and restrictions contained in BCP 78, and 478 except as set forth therein, the authors retain all their rights. 480 Acknowledgment 482 Funding for the RFC Editor function is currently provided by the 483 Internet Society.