idnits 2.17.1 draft-ietf-sip-uri-list-conferencing-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 534. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 547. ** 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 (September 18, 2006) is 6428 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 445 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-05 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-01 Summary: 3 errors (**), 0 flaws (~~), 5 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: March 22, 2007 A. Johnston 4 Avaya 5 September 18, 2006 7 Conference Establishment Using Request-Contained Lists in the Session 8 Initiation Protocol (SIP) 9 draft-ietf-sip-uri-list-conferencing-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 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 29 http://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 March 22, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document describes how to create a conference using SIP URI-list 43 services. In particular, it describes a mechanism that allows a 44 client to provide a conference server with the initial list of 45 participants using an INVITE-contained URI-list. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 3. Providing a Conference Server with a URI-List . . . . . . . . 3 52 4. URI-List Document . . . . . . . . . . . . . . . . . . . . . . 3 53 5. Conference Server Behavior . . . . . . . . . . . . . . . . . . 5 54 6. Re-INVITEs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 7. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 58 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 59 11. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 62 12.2. Informative References . . . . . . . . . . . . . . . . . 13 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Intellectual Property and Copyright Statements . . . . . . . . . . 15 66 1. Introduction 68 Section 5.4 of [5] describes how to create a conference using ad-hoc 69 SIP [4] methods. The client sends an INVITE request to a conference 70 factory URI and receives the actual conference URI, which contains 71 the "isfocus" feature tag, in the Contact header field of a response 72 (typically a 200 OK). 74 Once the client obtains the conference URI, it can add participants 75 to the newly created conference in several ways, which are described 76 in [5]. 78 Some environments have tough requirements regarding conference 79 establishment time. They require the client to be able to request 80 the creation of an ad-hoc conference and to provide the server with 81 the initial set of participants in a single operation. This document 82 describes how to meet this requirement using the mechanism to 83 transport URI-lists in SIP messages described in [6]. 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 3. Providing a Conference Server with a URI-List 95 A client that wants to include the set of initial participants in its 96 initial INVITE to create an ad-hoc conference, adds a body whose 97 disposition type is 'recipient-list', as defined in [6], with a URI- 98 list that contains the participants that the client wants the server 99 to INVITE. The client sends this INVITE to the conference factory 100 URI. 102 4. URI-List Document 104 As described in [6], specifications of individual URI-list services, 105 like the conferencing service described here, need to specify a 106 default format for 'recipient-list' bodies used within the particular 107 service. 109 The default format for 'recipient-list' bodies for conferencing UAs 110 (User Agents) and servers is the XML resource list format [7] 111 extended with the XML Format Extension for Representing Copy Control 112 Attributes in Resource Lists [8]. So, conferencing UACs and servers 113 handling 'recipient-list' bodies MUST support both of these formats 114 and MAY support other formats. 116 As described in the XML Format Extension for Representing Copy 117 Control Attributes in Resource Lists [8], each URI can be tagged with 118 a 'copyControl' attribute set to either "to", "cc", or "bcc", 119 indicating the role in which the recipient will get the INVITE 120 request. Additionally, URIs can be tagged with the 'anonymize' 121 attribute to prevent that the conference server discloses the target 122 URI in a URI-list. 124 Additionally, the XML Format Extension for Representing Copy Control 125 Attributes in Resource Lists [8] defines a 'recipient-list-history' 126 body that contains the list of recipients. The default format for 127 'recipient-list-history' bodies for conference services is also the 128 XML resource list document format [7] extended with the XML Format 129 Extension for Representing Copy Control Attributes in Resource Lists 130 [8]. Conferencing servers MUST support both of these formats; UASes 131 MAY support these formats. Both conferencing servers and UASes MAY 132 support other formats. 134 Nevertheless, the XML resource list document [7] provides features, 135 such as hierarchical lists and the ability to include entries by 136 reference relative to the XCAP root URI, that are not needed by the 137 conferencing service defined in this document, which only needs to 138 transfer a flat list of URIs between a UA and the conference server. 139 Therefore, when using the default resource list document, 140 conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) 141 and SHOULD NOT use elements. 143 A conference factory application receiving a URI-list with more 144 information than what has just been described MAY discard all the 145 extra information. 147 Figure 1 shows an example of a flat list that follows the XML 148 resource list document [7] extended with the XML Format Extension for 149 Representing Copy Control Attributes in Resource Lists [8]. 151 152 154 155 156 157 158 159 161 Figure 1: URI-List 163 5. Conference Server Behavior 165 On reception of an INVITE request containing a 'recipient-list' body 166 as described in Section 3, a conference server MUST follow the rules 167 described in [5] to create ad-hoc conferences. Once the ad-hoc 168 conference is created, the conference server SHOULD attempt to add 169 the participants in the URI-list to the conference as if their 170 addition had been requested using any of the methods described in 171 [5]. 173 Once the conference server has created the ad-hoc conference and has 174 attempted to add the initial set of participants, the conference 175 server behaves as a regular conference server and MUST follow the 176 rules in [5]. 178 Note that the status code in the response to the INVITE does not 179 provide any information about whether or not the conference server 180 was able to bring the users in the URI-list into the conference. 181 That is, a 200 (OK) means that the conference was created 182 successfully, that the client that generated the INVITE is in the 183 conference, and that the server understood the URI-list. If the 184 client wishes to obtain information about the status of other users 185 in the conference it SHOULD use general conference mechanisms, such 186 as the conference package [9]. 188 The incoming INVITE request typically contains a URI-list body or 189 reference [6] with the actual list of recipients. If this URI-list 190 includes resources tagged with the 'copyControl' attribute set to a 191 value of "to" or "cc", the conference server SHOULD include a URI- 192 list in each of the outgoing INVITE requests. This list SHOULD be 193 formatted according to the XML format for representing resource lists 194 [7] and the copyControl extension specified in [8]. The URI-list 195 service MUST follow the procedures specified in XML format for 196 representing resource lists [8] with respect to the handling of the 197 'anonymize', 'count' and 'copyControl' attributes. 199 If the conference server includes a URI-list in an outgoing INVITE 200 request, it MUST include a Content-Disposition header field [2] with 201 the value set to 'recipient-list-history' and a 'handling' parameter 202 [3] set to "optional". 204 6. Re-INVITEs 206 The previous sections have specified how to include a URI-list in an 207 initial INVITE request to a conference server. Once the INVITE- 208 initiated dialog between the client and the conference server has 209 been established, the client may need to send subsequent INVITE 210 requests (typically referred to as re-INVITEs) to the conference 211 server to, for example, modify the characteristics of the media 212 exchanged with the server. 214 At this point, there are no semantics associated with resource-list 215 bodies in re-INVITEs (although future extensions may define them). 216 Therefore, clients SHOULD NOT include resource-list bodies in re- 217 INVITEs sent to a conference server. 219 A conference server receiving a re-INVITE with a resource-list body, 220 following standard SIP procedures, rejects it with a 415 (Unsupported 221 Media Type) response. 223 Note that a difference between an initial INVITE request and a re- 224 INVITE is that while the initial INVITE is sent to the conference 225 factory URI, the re-INVITE is sent to the URI provided by the 226 server in a Contact header field when the dialog was established. 227 Therefore, from the client's point of view, the resource 228 identified by the former URI supports 'recipient-list' bodies 229 while the resource identified by the latter does not support them. 231 7. Option-tag 233 This document defines the 'recipient-list-invite' option-tag for use 234 in the Require and Supported SIP header fields. 236 This option-tag is used to ensure that a server can process the 237 'recipient-list' body used in an INVITE request. It also provides 238 a mechanism to discover the capability of the server in responses 239 to OPTIONS requests. 241 User agent clients generating an INVITE request containing a 242 'recipient-list' body, as described in previous sections, MUST 243 include this option-tag in a Require header field. User agents that 244 are able to receive and process INVITEs with a 'recipient-list' body, 245 as described in previous sections, SHOULD include this option-tag in 246 a Supported header field when responding to OPTIONS requests. 248 Note that according to Section 6, requests and responses coming 249 from the URI of an ongoing conference would not carry this option- 250 tag in a Supported header field. This is because the resource 251 identified by the conference URI does not actually support this 252 extension. On the other hand, the resource identified by the 253 conference factory URI does support this extension and, 254 consequently, would include this option-tag in, for example, 255 responses to OPTIONS requests. 257 8. Example 259 Figure 2 shows an example of operation. A UAC sends an INVITE 260 request (F1) that contains an SDP body and a URI-list to the 261 conference server. The conference server answers with a 200 (OK) 262 response and generates an INVITE request to each of the URIs included 263 in the URI-list. The conference server includes SDP and a 264 manipulated URI-list in each of the outgoing INVITE requests. 266 +--------+ +---------+ +--------+ +--------+ +--------+ 267 |SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS | 268 | | | server | | 1 | | 2 | | n | 269 +--------+ +---------+ +--------+ +--------+ +--------+ 270 | | | | | 271 | F1. INVITE | | | | 272 | ---------------->| | | | 273 | F2. 200 OK | | | | 274 |<---------------- | F3. INVITE | | | 275 | | ------------->| | | 276 | | F4. INVITE | | | 277 | | ------------------------>| | 278 | | F5. INVITE | | | 279 | | ----------------------------------->| 280 | | F6. 200 OK | | | 281 | |<------------- | | | 282 | | F7. 200 OK | | | 283 | |<------------------------ | | 284 | | F8. 200 OK | | | 285 | |<----------------------------------- | 286 | | | | | 287 | | | | | 288 | | | | | 290 Figure 2: Example of operation 291 Figure 3 shows an example of the INVITE request F1, which carries a 292 multipart/mixed body composed of two other bodies: an application/sdp 293 body that describes the session and an application/resource-lists+xml 294 body that contains the list of target URIs. 296 INVITE sip:conf-fact@example.com SIP/2.0 297 Via: SIP/2.0/TCP atlanta.example.com 298 ;branch=z9hG4bKhjhs8ass83 299 Max-Forwards: 70 300 To: "Conf Factory" 301 From: Alice ;tag=32331 302 Call-ID: d432fa84b4c76e66710 303 CSeq: 1 INVITE 304 Contact: 305 Allow: INVITE, ACK, CANCEL, BYE, REFER 306 Allow-Events: dialog 307 Accept: application/sdp, message/sipfrag 308 Require: recipient-list-invite 309 Content-Type: multipart/mixed;boundary="boundary1" 310 Content-Length: 690 312 --boundary1 313 Content-Type: application/sdp 315 v=0 316 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 317 s=- 318 c=IN IP4 192.0.2.1 319 t=0 0 320 m=audio 20000 RTP/AVP 0 321 a=rtpmap:0 PCMU/8000 322 m=video 20002 RTP/AVP 31 323 a=rtpmap:31 H261/90000 325 --boundary1 326 Content-Type: application/resource-lists+xml 327 Content-Disposition: recipient-list 329 330 332 333 334 336 338 339 341 342 343 344 345 --boundary1-- 347 Figure 3: INVITE request received at the conference server 349 The INVITE requests F3, F4, and F5 are similar in nature. All those 350 INVITE requests contain a multipart/mixed body which is composed of 351 two other bodies: an application/sdp body describing the session and 352 an application/resource-lists+xml containing the list of recipients. 353 The application/resource-lists+xml bodies are not equal to the 354 application/resource-lists+xml included in the received INVITE 355 request F1, because the conference server has anonymized those URIs 356 tagged with the 'anonymize' attribute and has removed those URIs 357 tagged with a "bcc" 'copyControl' attribute. Figure 4 shows an 358 example of the message F3. 360 INVITE sip:bill@example.com SIP/2.0 361 Via: SIP/2.0/TCP conference.example.com 362 ;branch=z9hG4bKhjhs8as454 363 Max-Forwards: 70 364 To: 365 From: Conference Server ;tag=234332 366 Call-ID: 389sn189dasdf 367 CSeq: 1 INVITE 368 Contact: ;isfocus 369 Allow: INVITE, ACK, CANCEL, BYE, REFER 370 Allow-Events: dialog, conference 371 Accept: application/sdp, message/sipfrag 372 Require: recipient-list-invite 373 Conten-Type: multipart/mixed;boundary="boundary1" 374 Content-Length: 690 376 --boundary1 377 Content-Type: application/sdp 379 v=0 380 o=conf 2890844343 2890844343 IN IP4 conference.example.com 381 s=- 382 c=IN IP4 192.0.2.5 383 t=0 0 384 m=audio 40000 RTP/AVP 0 385 a=rtpmap:0 PCMU/8000 386 m=video 40002 RTP/AVP 31 387 a=rtpmap:31 H261/90000 389 --boundary1 390 Content-Type: application/resource-lists+xml 391 Content-Disposition: recipient-list-history; handling=optional 393 394 396 397 398 400 401 403 404 405 --boundary1-- 407 Figure 4: INVITE request sent by the conference server 409 9. Security Considerations 411 This document discusses setup of SIP conferences using a request- 412 contained URI-list. Both conferencing and URI-lists services have 413 specific security requirements which will be summarized here. 414 Conferences generally have authorization rules about who may or may 415 not join a conference, what type of media may or may not be used, 416 etc. This information is used by the focus to admit or deny 417 participation in a conference. It is RECOMMENDED that these types of 418 authorization rules be used to provide security for a SIP conference. 420 For this authorization information to be used, the focus needs to be 421 able to authenticate potential participants. Normal SIP mechanisms 422 including Digest authentication and certificates can be used. These 423 conference specific security requirements are discussed further in 424 the requirements and framework documents. 426 For conference creation using a list, there are some additional 427 security considerations. The Framework and Security Considerations 428 for SIP URI-List Services [6] discusses issues related to SIP URI- 429 list services. Given that a conference server sending INVITEs to a 430 set of users acts as an URI-list service, implementations of 431 conference servers that handle lists MUST follow the security-related 432 rules in [6]. These rules include mandatory authentication and 433 authorization of clients, and opt-in lists. 435 10. IANA Considerations 437 This document defines the 'recipient-list-invite' SIP option-tag in 438 Section 7. It should be registered in the Option Tags subregistry 439 under the SIP parameter registry. The following is the description 440 to be used in the registration. 442 +------------------------+------------------------------+-----------+ 443 | Name | Description | Reference | 444 +------------------------+------------------------------+-----------+ 445 | recipient-list-invite | The body contains a list of | [RFCXXXX] | 446 | | URIs that indicates the | | 447 | | recipients of the SIP INVITE | | 448 | | request | | 449 +------------------------+------------------------------+-----------+ 451 Table 1: Registration of the 'recipient-list-invite' Option-Tag in 452 SIP 454 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 455 number of this specification. 457 11. Acknowledges 459 Cullen Jennings, Hisham Khartabil, and Jonathan Rosenberg provided 460 useful comments on this document. Miguel Garcia-Martin assembled the 461 dependencies to the 'copyControl' attribute extension. 463 12. References 465 12.1. Normative References 467 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 468 Levels", BCP 14, RFC 2119, March 1997. 470 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 471 Presentation Information in Internet Messages: The Content- 472 Disposition Header Field", RFC 2183, August 1997. 474 [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 475 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 476 Objects", RFC 3204, December 2001. 478 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 479 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 480 Session Initiation Protocol", RFC 3261, June 2002. 482 [5] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 483 Call Control - Conferencing for User Agents", BCP 119, RFC 4579, 484 August 2006. 486 [6] Camarillo, G. and A. Roach, "Framework and Security 487 Considerations for Session Initiation Protocol (SIP) Uniform 488 Resource Identifier (URI)-List Services", 489 draft-ietf-sipping-uri-services-05 (work in progress), 490 January 2006. 492 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 493 Representing Resource Lists", 494 draft-ietf-simple-xcap-list-usage-05 (work in progress), 495 February 2005. 497 [8] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 498 (XML) Format Extension for Representing Capacity Attributes in 499 Resource Lists", draft-ietf-sipping-capacity-attribute-01 (work 500 in progress), September 2006. 502 12.2. Informative References 504 [9] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 505 Initiation Protocol (SIP) Event Package for Conference State", 506 RFC 4575, August 2006. 508 Authors' Addresses 510 Gonzalo Camarillo 511 Ericsson 512 Hirsalantie 11 513 Jorvas 02420 514 Finland 516 Email: Gonzalo.Camarillo@ericsson.com 518 Alan Johnston 519 Avaya 520 St. Louis, MO 63124 521 USA 523 Email: alan@sipstation.com 525 Intellectual Property Statement 527 The IETF takes no position regarding the validity or scope of any 528 Intellectual Property Rights or other rights that might be claimed to 529 pertain to the implementation or use of the technology described in 530 this document or the extent to which any license under such rights 531 might or might not be available; nor does it represent that it has 532 made any independent effort to identify any such rights. Information 533 on the procedures with respect to rights in RFC documents can be 534 found in BCP 78 and BCP 79. 536 Copies of IPR disclosures made to the IETF Secretariat and any 537 assurances of licenses to be made available, or the result of an 538 attempt made to obtain a general license or permission for the use of 539 such proprietary rights by implementers or users of this 540 specification can be obtained from the IETF on-line IPR repository at 541 http://www.ietf.org/ipr. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights that may cover technology that may be required to implement 546 this standard. Please address the information to the IETF at 547 ietf-ipr@ietf.org. 549 Disclaimer of Validity 551 This document and the information contained herein are provided on an 552 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 553 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 554 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 555 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 556 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 557 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Copyright Statement 561 Copyright (C) The Internet Society (2006). This document is subject 562 to the rights, licenses and restrictions contained in BCP 78, and 563 except as set forth therein, the authors retain all their rights. 565 Acknowledgment 567 Funding for the RFC Editor function is currently provided by the 568 Internet Society.