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