idnits 2.17.1 draft-ietf-sipping-multiple-refer-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 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 387. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 377. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 393), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 is 1 instance 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 (July 7, 2004) is 7232 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) == Unused Reference: '3' is defined on line 274, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 278, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 309, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-02) exists of draft-olson-sipping-refer-extensions-01 -- Possible downref: Normative reference to a draft: ref. '7' == Outdated reference: A later version (-02) exists of draft-camarillo-sipping-uri-list-01 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-03) exists of draft-camarillo-sipping-exploders-02 -- Possible downref: Normative reference to a draft: ref. '9' == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-03 Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 9 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: January 5, 2005 A. Niemi 4 H. Khartabil 5 M. Isomaki 6 M. Garcia-Martin 7 Nokia 8 July 7, 2004 10 Refering to Multiple Resources in the Session Initiation Protocol 11 (SIP) 12 draft-ietf-sipping-multiple-refer-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at http:// 31 www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 5, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). All Rights Reserved. 42 Abstract 44 This document defines extensions to the SIP REFER method so that this 45 method can be used to refer servers to multiple resources. These 46 extensions include the use of pointers to URI-lists in the Refer-To 47 header field and the multiple-refer SIP option-tag. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3 54 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4 55 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4 56 6. Behavior of SIP User Agents . . . . . . . . . . . . . . . . . 5 57 6.1 Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . 5 58 6.2 Behavior of REFER-Recipients . . . . . . . . . . . . . . . 5 59 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 7 64 10.2 Informational References . . . . . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 8 66 Intellectual Property and Copyright Statements . . . . . . . . 10 68 1. Introduction 70 The SIP REFER method [5] 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. In one example, the moderator of a conference may want 74 the conference server to send BYE requests to a group of 75 participants. In another example, the same moderator may want the 76 conference server to INVITE a set of new participants. 78 We define an extension to REFER so that REFER can be used to refer 79 servers to multiple destinations. In addition, we use the REFER 80 extension defined in [7] which suppresses REFER's implicit 81 subscription. 83 2. Terminology 85 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 86 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 87 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 88 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 89 compliant implementations. 91 We define the following three new terms: 93 REFER-Issuer: the user agent issuing the REFER request. 94 REFER-Recipient: the user agent receiving the REFER request. 95 REFER-Target: the user agent designated in the Refer-To URI. 97 3. Overview of operation 99 This document defines an extension to the SIP REFER method [5] that 100 allows a SIP UAC to include a list of REFER-Targets in a REFER 101 request and send it to a server. The server will create a new request 102 for each entry in the list of REFER-Target URIs. 104 We represent the multiple REFER-Targets of a REFER using the URI-list 105 format specified in [8]. A UAC (User Agent Client) that wants to 106 refer a server to a set of destinations creates a SIP REFER request. 107 The Refer-To header contains a pointer to a URI-list, which is 108 included in a body part, and two option-tags in the Required header 109 field: "multiple-refer" and "norefersub". The former indicates the 110 requirement to support the functionality described in this 111 specification and the latter removes the implicit subscription 112 associated to REFER requests by default. 114 When the server receives such request it creates a new request per 115 destination and sends them. 117 This document does not provide any mechanism for UACs to find out 118 about the results of a REFER with multiple REFER-Targets. 119 Furthermore, we do not provide support for the implicit subscription 120 mechanism that is part of the SIP REFER method. The way UACs are kept 121 informed about the results of a REFER is service specific. For 122 example, a UAC sending a REFER to INVITE a set of participants to a 123 conference may discover which participants were successfully brought 124 in into the conference by using the conference package [10] 126 4. The multiple-refer SIP Option-Tag 128 We define a new SIP option-tag for the Require and Supported header 129 fields: "multiple-refer". 131 A user agent including the "multiple-refer" option-tag in a Supported 132 header indicates compliance with this specification. 134 A user agent generating a REFER with a pointer to a URI-list in its 135 Refer-To header field MUST include the "multiple-refer" option-tag in 136 the Require header field of the REFER. 138 5. Suppressing REFER's Implicit Subscription 140 REFER requests with a single REFER-Target establish a subscription 141 implicitly. The REFER-Issuer is informed about the result of the 142 transaction towards the REFER-Target through this implicit 143 subscription. 145 In the case of a REFER-Issuer that generates a REFER with multiple 146 REFER-targets, the REFER-Issuer is typically already subscribed to 147 other event package that can provide the information about the result 148 of the transactions towards the REFER-Targets. For example, a 149 moderator instructing a conference server to send a BYE request to a 150 set of participants is usually subscribed to the conference state 151 event package for the conference. Notifications to this event package 152 will keep the moderator and the rest of the subscribers informed of 153 the current list of conference participant. 155 Consequently, we have decided to remove the implicit subscription 156 from a multiple REFER request. So, a SIP REFER-Issuer generating a 157 REFER request with multiple REFER-Targets MUST include the 158 'norefersub' option-tag in a Require header field to indicate that no 159 notifications about the requests should be sent to the REFER-Issue. 160 The 'norefersub' SIP option-tag is defined in [7] and suppresses the 161 REFER's implicit subscription. 163 6. Behavior of SIP User Agents 165 Implementations of this specification MUST suppot the transfer 166 mechanism for URI-lists defined in [8]. 168 6.1 Behavior of SIP REFER-Issuers 170 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that 171 creates a REFER request with multiple REFER-Targets includes a 172 "multiple-refer" and a "norefersub" option-tags in the Require header 173 field. 175 The Refer-To header field of a REFER request with multiple 176 REFER-Targets MUST contain a pointer (i.e., a Content-ID URL [2]) 177 that points to the body part (whose disposition type is "uri-list") 178 that carries the URI-list. 180 As described in [8], the default format for URI-lists in SIP is the 181 XCAP resource list format [6]. Still, specific services need to 182 describe which information clients should include in their URI lists, 183 as described in [8]. 185 SIP REFER-Issuers generating REFERs with multiple REFER-Targets 186 SHOULD use flat lists (i.e., no hierarchical lists), SHOULD NOT use 187 any entry's attributes but "uri", and SHOULD NOT include any elements 188 inside entries but "display-name" elements. 190 6.2 Behavior of REFER-Recipients 192 A REFER-Recipient receiving a URI-list with more information than 193 what we have described in Section 6.1 SHOULD discard all the extra 194 information. 196 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 197 [5] to determine the status code of the response to the REFER. 199 7. Example 201 The following is an example of a REFER request with multiple 202 REFER-Targets. The REFER's Refer-To header field carries a pointer to 203 the message body, which carries a list with the URIs of the 204 REFER-Targets. The REFER's Require header field carries both the 205 "multiple-refer" and the "norefersub" option-tags. 207 REFER sip:conf-123@example.com 208 SIP/2.0 Via: SIP/2.0/TCP client.chicago.example.com 209 ;branch=z9hG4bKhjhs8ass83 210 Max-Forwards: 70 211 To: Conference 123 212 From: Carol ;tag=32331 213 Call-ID: d432fa84b4c76e66710 214 CSeq: 2 REFER 215 Contact: 216 Refer-To: 217 Require: multiple-refer, norefersub 218 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 219 Allow-Events: dialog 220 Accept: application/sdp, message/sipfrag 221 Content-Type: application/resource-lists+xml 222 Content-Disposition: uri-list 223 Content-Length: 307 224 Content-ID: 226 227 228 229 230 231 232 233 235 Figure 1: REFER request with multiple REFER-Targets 237 8. Security Considerations 239 The Security Considerations Section of the Requirements and Framework 240 for SIP URI-List Services [9] discusses issues related to SIP 241 URI-list services. Given that a server accepting REFERs with multiple 242 REFER-targets acts as an URI-list service, implementations of this 243 type of server MUST follow the security-related rules in [9]. These 244 rules include mandatory authentication and authorization of clients, 245 and opt-in lists. 247 Additionally, servers SHOULD only accept REFER requests within the 248 context of an application the server understands (e.g., a 249 conferencing application). This implies that servers MUST NOT accept 250 REFERs for methods they do not understand. The idea behind these two 251 rules is that servers are not used as dumb servers whose only 252 function is to fan-out random messages they do not understand. 254 9. IANA Considerations 256 This document defines a SIP option-tag (multiple-refer) in Section 4. 257 This option-tag should be registered in the SIP parameter registry 258 (http://www.iana.org/assignments/sip-parameters). 260 SIP user agents that place the multiple-refer option-tag in a 261 Supported header field understand REFER requests with multiple 262 REFER-Targets. 264 10. References 266 10.1 Normative References 268 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 269 Levels", BCP 14, RFC 2119, March 1997. 271 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 272 Locators", RFC 2392, August 1998. 274 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 275 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 276 Session Initiation Protocol", RFC 3261, June 2002. 278 [4] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 279 November 2002. 281 [5] Sparks, R., "The Session Initiation Protocol (SIP) Refer 282 Method", RFC 3515, April 2003. 284 [6] Rosenberg, J., "An Extensible Markup Language (XML) 285 Configuration Access Protocol (XCAP) Usage for Presence Lists", 286 draft-ietf-simple-xcap-list-usage-02 (work in progress), 287 February 2004. 289 [7] Olson, S., "Extended-REFER framework and other REFER 290 extensions", draft-olson-sipping-refer-extensions-01 (work in 291 progress), February 2004. 293 [8] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 294 Application Server with a List of URIs", 295 draft-camarillo-sipping-uri-list-01 (work in progress), February 296 2004. 298 [9] Camarillo, G., "Requirements for Session Initiation Protocol 299 (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02 300 (work in progress), February 2004. 302 10.2 Informational References 304 [10] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 305 Protocol (SIP) Event Package for Conference State", 306 draft-ietf-sipping-conference-package-03 (work in progress), 307 February 2004. 309 [11] Camarillo, G., "A Transaction Event Package for the Session 310 Initiation Protocol (SIP)", 311 draft-camarillo-sipping-transac-package-00 (work in progress), 312 February 2004. 314 Authors' Addresses 316 Gonzalo Camarillo 317 Ericsson 318 Hirsalantie 11 319 Jorvas 02420 320 Finland 322 EMail: Gonzalo.Camarillo@ericsson.com 324 Aki Niemi 325 Nokia 326 P.O. Box 321 327 NOKIA GROUP, FIN 00045 328 Finland 330 EMail: Aki.Niemi@nokia.com 332 Hisham Khartabil 333 Nokia 334 P.O. Box 321 335 NOKIA GROUP, FIN 00045 336 Finland 338 EMail: Hisham.Khartabil@nokia.com 339 Markus Isomaki 340 Nokia 341 Itamerenkatu 11-13 342 Helsinki 00180 343 Finland 345 EMail: Markus.Isomaki@nokia.com 347 Miguel A. Garcia-Martin 348 Nokia 349 P.O.Box 407 350 NOKIA GROUP, FIN 00045 351 Finland 353 EMail: miguel.an.garcia@nokia.com 355 Intellectual Property Statement 357 The IETF takes no position regarding the validity or scope of any 358 Intellectual Property Rights or other rights that might be claimed to 359 pertain to the implementation or use of the technology described in 360 this document or the extent to which any license under such rights 361 might or might not be available; nor does it represent that it has 362 made any independent effort to identify any such rights. Information 363 on the IETF's procedures with respect to rights in IETF Documents can 364 be found in BCP 78 and BCP 79. 366 Copies of IPR disclosures made to the IETF Secretariat and any 367 assurances of licenses to be made available, or the result of an 368 attempt made to obtain a general license or permission for the use of 369 such proprietary rights by implementers or users of this 370 specification can be obtained from the IETF on-line IPR repository at 371 http://www.ietf.org/ipr. 373 The IETF invites any interested party to bring to its attention any 374 copyrights, patents or patent applications, or other proprietary 375 rights that may cover technology that may be required to implement 376 this standard. Please address the information to the IETF at 377 ietf-ipr@ietf.org. 379 Disclaimer of Validity 381 This document and the information contained herein are provided on an 382 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 383 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 384 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 385 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 386 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 387 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 389 Copyright Statement 391 Copyright (C) The Internet Society (2004). This document is subject 392 to the rights, licenses and restrictions contained in BCP 78, and 393 except as set forth therein, the authors retain all their rights. 395 Acknowledgment 397 Funding for the RFC Editor function is currently provided by the 398 Internet Society.