idnits 2.17.1 draft-ietf-sipping-uri-list-conferencing-04.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 394. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 378. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 384. ** 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 : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (October 21, 2005) is 6752 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-03 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: April 24, 2006 A. Johnston 5 MCI 6 October 21, 2005 8 Conference Establishment Using Request-Contained Lists in the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sipping-uri-list-conferencing-04.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on April 24, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document describes how to create a conference using SIP URI-list 44 services. In particular, it describes a mechanism that allows a 45 client to provide a conference server with the initial list of 46 participants using an INVITE-contained URI-list. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Providing a Conference Server with a URI-List . . . . . . . . 3 53 4. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Conference Server Behavior . . . . . . . . . . . . . . . . . . 4 55 6. Re-INVITEs . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 7. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 11. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 12.2. Informational References . . . . . . . . . . . . . . . . 9 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 65 Intellectual Property and Copyright Statements . . . . . . . . . . 11 67 1. Introduction 69 Section 4.5 of [3] describes how to create a conference using ad-hoc 70 SIP [2] methods. The client sends an INVITE request to a conference 71 factory URI and receives the actual conference URI, which contains 72 the "isfocus" feature tag, in the Contact header field of a response 73 (typically a 200 OK). 75 Once the client obtains the conference URI, it can add participants 76 to the newly created conference in several ways, which are described 77 in [3]. 79 Some environments have tough requirements regarding conference 80 establishment time. They require the client to be able to request 81 the creation of an ad-hoc conference and to provide the server with 82 the initial set of participants in a single operation. This document 83 describes how to meet this requirement using the mechanism to 84 transport URI-lists in SIP messages described in [4]. 86 2. Terminology 88 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 89 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 90 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 91 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 92 compliant implementations. 94 3. Providing a Conference Server with a URI-List 96 A client that wants to include the set of initial participants in its 97 initial INVITE to create an ad-hoc conference, adds a body whose 98 disposition type is recipient-list, as defined in [4], with a URI- 99 list that contains the participants that the client wants the server 100 to INVITE. The client sends this INVITE to the conference factory 101 URI. 103 4. URI-List Format 105 As described in [4], specifications of individual URI-list services, 106 like the conferencing service described here, need to specify a 107 default format for recipient-list bodies used within the particular 108 service. 110 The default format for recipient-list bodies for conferencing UAs 111 (User Agents) and servers is the resource list format defined in [5]. 113 So, conferencing UAs and servers handling recipient-list bodies MUST 114 support this format and MAY support other formats. 116 Nevertheless, the Extensible Markup Language (XML) Configuration 117 Access Protocol (XCAP) resource list document provides features, such 118 as hierarchical lists and the ability to include entries by reference 119 relative to the XCAP root URI, that are not needed by the 120 conferencing service defined in this document, which only needs to 121 transfer a flat list of URIs between a UA and the conference server. 122 Therefore, when using the default resource list document, 123 conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) 124 and SHOULD NOT use elements. 126 A conference factory application receiving a URI-list with more 127 information than what has just been described MAY discard all the 128 extra information. 130 Figure 1 shows an example of a flat list that follows the resource 131 list document. 133 134 136 137 138 139 140 141 143 Figure 1: URI-List 145 5. Conference Server Behavior 147 On reception of an INVITE with a recipient-list body as described in 148 Section 3, a conference server MUST follow the rules described in [3] 149 to create ad-hoc conferences. Once the ad-hoc conference is created, 150 the conference server SHOULD attempt to add the participants in the 151 URI-list to the conference as if their addition had been requested 152 using any of the methods described in [3]. 154 Once the conference server has created the ad-hoc conference and has 155 attempted to add the initial set of participants, the conference 156 server behaves as a regular conference server and MUST follow the 157 rules in [3]. 159 Note that the status code in the response to the INVITE does not 160 provide any information about whether or not the conference server 161 was able to bring the users in the URI-list into the conference. 162 That is, a 200 (OK) means that the conference was created 163 successfully, that the client that generated the INVITE is in the 164 conference, and that the server understood the URI-list. If the 165 client wishes to obtain information about the status of other users 166 in the conference it SHOULD use general conference mechanisms, such 167 as the conference package [6]. 169 6. Re-INVITEs 171 The previous Sections have specified how to include a URI-list in an 172 initial INVITE request to a conference server. Once the INVITE- 173 initiated dialog between the client and the conference server has 174 been established, the client may need to send subsequent INVITE 175 requests (typically referred to as re-INVITEs) to the conference 176 server to, for example, modify the characteristics of the media 177 exchanged with the server. 179 At this point, there are no semantics associated with resource-list 180 bodies in re-INVITEs (although future extensions may define them). 181 Therefore, clients SHOULD NOT include resource-list bodies in re- 182 INVITEs sent to a conference server. 184 A conference server receiving a re-INVITE with a resource-list body, 185 following standard SIP procedures, rejects it with a 415 (Unsupported 186 Media Type) response. 188 Note that a difference between an initial INVITE request and a re- 189 INVITE is that while the initial INVITE is sent to the conference 190 factory URI, the re-INVITE is sent to the URI provided by the 191 server in a Contact header field when the dialog was established. 192 Therefore, from the client's point of view, the resource 193 identified by the former URI supports recipient-list bodies while 194 the resource identified by the latter does not support them. 196 7. Option-tag 198 This document defines the 'recipient-list-invite' option-tag for use 199 in the Require and Supported SIP header fields. 201 User agent clients generating an INVITE with a recipient-list body, 202 as described in previous sections, MUST include this option-tag in a 203 Require header field. User agents that are able to receive and 204 process INVITEs with a recipient-list body, as described in previous 205 sections, SHOULD include this option-tag in a Supported header field 206 when responding to OPTIONS requests. 208 Note that according to Section 6, requests and responses coming 209 from the URI of an ongoing conference would not carry this option- 210 tag in a Supported header field. This is because the resource 211 identified by the conference URI does not actually support this 212 extension. On the other hand, the resource identified by the 213 conference factory URI does support this extension and, 214 consequently, would include this option-tag in, for example, 215 responses to OPTIONS requests. 217 8. Example 219 The following is an example of an INVITE request, which carries a 220 URI-list in a recipient-list body part, sent by a UA to a conference 221 factory application. Note that since the INVITE carries an SDP 222 description as well, it contains a multipart body. 224 INVITE sip:conf-fact@example.com SIP/2.0 225 Via: SIP/2.0/TCP client.chicago.example.com 226 ;branch=z9hG4bKhjhs8ass83 227 Max-Forwards: 70 228 To: Conf Factory 229 From: Carol ;tag=32331 230 Call-ID: d432fa84b4c76e66710 231 CSeq: 1 INVITE 232 Contact: 233 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 234 SUBSCRIBE, NOTIFY 235 Allow-Events: dialog 236 Accept: application/sdp, message/sipfrag 237 Require: recipient-list-invite 238 Conten-Type: multipart/mixed;boundary="boundary1" 239 Content-Length: 690 241 --boundary1 242 Content-Type: application/sdp 244 v=0 245 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 246 s=- 247 c=IN IP4 192.0.2.1 248 t=0 0 249 m=audio 20000 RTP/AVP 0 250 a=rtpmap:0 PCMU/8000 251 m=video 20002 RTP/AVP 31 252 a=rtpmap:31 H261/90000 254 --boundary1 255 Content-Type: application/resource-lists+xml 256 Content-Disposition: recipient-list 258 259 261 262 263 264 265 266 267 --boundary1-- 269 Figure 2: INVITE request 271 9. Security Considerations 273 This document discusses setup of SIP conferences using a request- 274 contained URI-list. Both conferencing and URI-lists services have 275 specific security requirements which will be summarized here. 276 Conferences generally have authorization rules about who may or may 277 not join a conference, what type of media may or may not be used, 278 etc. This information is used by the focus to admit or deny 279 participation in a conference. It is RECOMMENDED that these types of 280 authorization rules be used to provide security for a SIP conference. 282 For this authorization information to be used, the focus needs to be 283 able to authenticate potential participants. Normal SIP mechanisms 284 including Digest authentication and certificates can be used. These 285 conference specific security requirements are discussed further in 286 the requirements and framework documents. 288 For conference creation using a list, there are some additional 289 security considerations. The Framework and Security Considerations 290 for SIP URI-List Services [4] discusses issues related to SIP URI- 291 list services. Given that a conference server sending INVITEs to a 292 set of users acts as an URI-list service, implementations of 293 conference servers that handle lists MUST follow the security-related 294 rules in [4]. These rules include mandatory authentication and 295 authorization of clients, and opt-in lists. 297 10. IANA Considerations 299 This document defines the 'recipient-list-invite' SIP option-tag in 300 Section 7. It should be registered in the Option Tags subregistry 301 under the SIP parameter registry. The following is the description 302 to be used in the registration. 304 This option-tag is used to ensure that a server can process the 305 'recipient-list' body used in an INVITE request. 307 11. Acknowledges 309 Cullen Jennings, Hisham Khartabil, and Jonathan Rosenberg provided 310 useful comments on this document. 312 12. References 313 12.1. Normative References 315 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 316 Levels", BCP 14, RFC 2119, March 1997. 318 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 319 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 320 Session Initiation Protocol", RFC 3261, June 2002. 322 [3] Johnston, A. and O. Levin, "Session Initiation Protocol Call 323 Control - Conferencing for User Agents", 324 draft-ietf-sipping-cc-conferencing-07 (work in progress), 325 June 2005. 327 [4] Camarillo, G. and A. Roach, "Requirements and Framework for 328 Session Initiation Protocol (SIP)Uniform Resource Identifier 329 (URI)-List Services", draft-ietf-sipping-uri-services-03 (work 330 in progress), April 2005. 332 [5] Rosenberg, J., "Extensible Markup Language (XML) Formats for 333 Representing Resource Lists", 334 draft-ietf-simple-xcap-list-usage-05 (work in progress), 335 February 2005. 337 12.2. Informational References 339 [6] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 340 Package for Conference State", 341 draft-ietf-sipping-conference-package-12 (work in progress), 342 July 2005. 344 Authors' Addresses 346 Gonzalo Camarillo 347 Ericsson 348 Hirsalantie 11 349 Jorvas 02420 350 Finland 352 Email: Gonzalo.Camarillo@ericsson.com 354 Alan Johnston 355 MCI 356 100 South 4th Street 357 St. Louis, MO 63102 358 USA 360 Email: alan.johnston@mci.com 362 Intellectual Property Statement 364 The IETF takes no position regarding the validity or scope of any 365 Intellectual Property Rights or other rights that might be claimed to 366 pertain to the implementation or use of the technology described in 367 this document or the extent to which any license under such rights 368 might or might not be available; nor does it represent that it has 369 made any independent effort to identify any such rights. Information 370 on the procedures with respect to rights in RFC documents can be 371 found in BCP 78 and BCP 79. 373 Copies of IPR disclosures made to the IETF Secretariat and any 374 assurances of licenses to be made available, or the result of an 375 attempt made to obtain a general license or permission for the use of 376 such proprietary rights by implementers or users of this 377 specification can be obtained from the IETF on-line IPR repository at 378 http://www.ietf.org/ipr. 380 The IETF invites any interested party to bring to its attention any 381 copyrights, patents or patent applications, or other proprietary 382 rights that may cover technology that may be required to implement 383 this standard. Please address the information to the IETF at 384 ietf-ipr@ietf.org. 386 Disclaimer of Validity 388 This document and the information contained herein are provided on an 389 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 390 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 391 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 392 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 393 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 394 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 396 Copyright Statement 398 Copyright (C) The Internet Society (2005). This document is subject 399 to the rights, licenses and restrictions contained in BCP 78, and 400 except as set forth therein, the authors retain all their rights. 402 Acknowledgment 404 Funding for the RFC Editor function is currently provided by the 405 Internet Society.