idnits 2.17.1 draft-ietf-sipping-uri-list-conferencing-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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 544. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 555. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 568. ** 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 (February 22, 2006) is 6636 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 447 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-uri-services-04 == Outdated reference: A later version (-07) exists of draft-ietf-sipping-capacity-attribute-00 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: August 26, 2006 A. Johnston 5 MCI 6 February 22, 2006 8 Conference Establishment Using Request-Contained Lists in the Session 9 Initiation Protocol (SIP) 10 draft-ietf-sipping-uri-list-conferencing-05.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 August 26, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 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 Document . . . . . . . . . . . . . . . . . . . . . . 3 54 5. Conference Server Behavior . . . . . . . . . . . . . . . . . . 5 55 6. Re-INVITEs . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 7. Option-tag . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 59 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 60 11. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 62 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 63 12.2. Informational References . . . . . . . . . . . . . . . . 13 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 65 Intellectual Property and Copyright Statements . . . . . . . . . . 13 67 1. Introduction 69 Section 4.5 of [5] describes how to create a conference using ad-hoc 70 SIP [4] 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 [5]. 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 [6]. 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 [6], 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 Document 105 As described in [6], 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 XML resource list format [7] 112 extended with the XML Format Extension for Representing Capacity 113 Attributes in Resource Lists [8]. So, conferencing UACs and servers 114 handling 'recipient-list' bodies MUST support both of these formats 115 and MAY support other formats. 117 As described in the XML Format Extension for Representing Capacity 118 Attributes in Resource Lists [8], each URI can be tagged with a 119 'capacity' attribute set to either "to", "cc", or "bcc", indicating 120 the capacity or role in which the recipient will get the INVITE 121 request. Additionally, URIs can be tagged with the 'anonymize' 122 attribute to prevent that the conference server discloses the target 123 URI in a URI-list. 125 Additionally, the XML Format Extension for Representing Capacity 126 Attributes in Resource Lists [8] defines a 'recipient-list-history' 127 body that contains the list of recipients. The default format for 128 'recipient-list-history' bodies for conference services is also the 129 XML resource list document format [7] extended with the XML Format 130 Extension for Representing Capacity Attributes in Resource Lists [8]. 131 Conferencing servers MUST support both of these formats; UASes MAY 132 support these formats. Both conferencing servers and UASes MAY 133 support other formats. 135 Nevertheless, the XML resource list document [7] provides features, 136 such as hierarchical lists and the ability to include entries by 137 reference relative to the XCAP root URI, that are not needed by the 138 conferencing service defined in this document, which only needs to 139 transfer a flat list of URIs between a UA and the conference server. 140 Therefore, when using the default resource list document, 141 conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists) 142 and SHOULD NOT use elements. 144 A conference factory application receiving a URI-list with more 145 information than what has just been described MAY discard all the 146 extra information. 148 Figure 1 shows an example of a flat list that follows the XML 149 resource list document [7] extended with the XML Format Extension for 150 Representing Capacity Attributes in Resource Lists [8]. 152 153 155 156 157 158 159 160 162 Figure 1: URI-List 164 5. Conference Server Behavior 166 On reception of an INVITE request containing a 'recipient-list' body 167 as described in Section 3, a conference server MUST follow the rules 168 described in [5] to create ad-hoc conferences. Once the ad-hoc 169 conference is created, the conference server SHOULD attempt to add 170 the participants in the URI-list to the conference as if their 171 addition had been requested using any of the methods described in 172 [5]. 174 Once the conference server has created the ad-hoc conference and has 175 attempted to add the initial set of participants, the conference 176 server behaves as a regular conference server and MUST follow the 177 rules in [5]. 179 Note that the status code in the response to the INVITE does not 180 provide any information about whether or not the conference server 181 was able to bring the users in the URI-list into the conference. 182 That is, a 200 (OK) means that the conference was created 183 successfully, that the client that generated the INVITE is in the 184 conference, and that the server understood the URI-list. If the 185 client wishes to obtain information about the status of other users 186 in the conference it SHOULD use general conference mechanisms, such 187 as the conference package [9]. 189 The incoming INVITE request typically contains a URI-list body or 190 reference [6] with the actual list of recipients. If this URI-list 191 includes resources tagged with the 'capacity' attribute set to a 192 value of "to" or "cc", the conference server SHOULD include a URI- 193 list in each of the outgoing INVITE requests. This list SHOULD be 194 formatted according to the XML format for representing resource lists 195 [7] and the capacity extension specified in [8]. The URI-list 196 service MUST follow the procedures specified in XML format for 197 representing resource lists [8] with respect handling of the 198 'anonymize', 'count' and 'capacity' attributes. 200 If the conference server includes a URI-list in an outgoing INVITE 201 request, it MUST include a Content-Disposition header field [2] with 202 the value set to 'recipient-list-history' and a 'handling' parameter 203 [3] set to "optional". 205 6. Re-INVITEs 207 The previous sections have specified how to include a URI-list in an 208 initial INVITE request to a conference server. Once the INVITE- 209 initiated dialog between the client and the conference server has 210 been established, the client may need to send subsequent INVITE 211 requests (typically referred to as re-INVITEs) to the conference 212 server to, for example, modify the characteristics of the media 213 exchanged with the server. 215 At this point, there are no semantics associated with resource-list 216 bodies in re-INVITEs (although future extensions may define them). 217 Therefore, clients SHOULD NOT include resource-list bodies in re- 218 INVITEs sent to a conference server. 220 A conference server receiving a re-INVITE with a resource-list body, 221 following standard SIP procedures, rejects it with a 415 (Unsupported 222 Media Type) response. 224 Note that a difference between an initial INVITE request and a re- 225 INVITE is that while the initial INVITE is sent to the conference 226 factory URI, the re-INVITE is sent to the URI provided by the 227 server in a Contact header field when the dialog was established. 228 Therefore, from the client's point of view, the resource 229 identified by the former URI supports 'recipient-list' bodies 230 while the resource identified by the latter does not support them. 232 7. Option-tag 234 This document defines the 'recipient-list-invite' option-tag for use 235 in the Require and Supported SIP header fields. 237 This option-tag is used to ensure that a server can process the 238 'recipient-list' body used in an INVITE request. It also provides 239 a mechanism to discover the capability of the server in responses 240 to OPTIONS requests. 242 User agent clients generating an INVITE request containing a 243 'recipient-list' body, as described in previous sections, MUST 244 include this option-tag in a Require header field. User agents that 245 are able to receive and process INVITEs with a 'recipient-list' body, 246 as described in previous sections, SHOULD include this option-tag in 247 a Supported header field when responding to OPTIONS requests. 249 Note that according to Section 6, requests and responses coming 250 from the URI of an ongoing conference would not carry this option- 251 tag in a Supported header field. This is because the resource 252 identified by the conference URI does not actually support this 253 extension. On the other hand, the resource identified by the 254 conference factory URI does support this extension and, 255 consequently, would include this option-tag in, for example, 256 responses to OPTIONS requests. 258 8. Example 260 Figure 2 shows an example of operation. A UAC sends an INVITE 261 request (F1) that contains an SDP body and a URI-list to the 262 conference server. The conference server answers with a 200 (OK) 263 response and generates an INVITE request to each of the URIs included 264 in the URI-list. The conference server includes SDP and a 265 manipulated URI-list in each of the outgoing INVITE requests. 267 +--------+ +---------+ +--------+ +--------+ +--------+ 268 |SIP UAC | | confer. | |SIP UAS | |SIP UAS | |SIP UAS | 269 | | | server | | 1 | | 2 | | n | 270 +--------+ +---------+ +--------+ +--------+ +--------+ 271 | | | | | 272 | F1. INVITE | | | | 273 | ---------------->| | | | 274 | F2. 200 OK | | | | 275 |<---------------- | F3. INVITE | | | 276 | | ------------->| | | 277 | | F4. INVITE | | | 278 | | ------------------------>| | 279 | | F5. INVITE | | | 280 | | ----------------------------------->| 281 | | F6. 200 OK | | | 282 | |<------------- | | | 283 | | F7. 200 OK | | | 284 | |<------------------------ | | 285 | | F8. 200 OK | | | 286 | |<----------------------------------- | 287 | | | | | 288 | | | | | 289 | | | | | 291 Figure 2: Example of operation 293 Figure 3 shows an example of the INVITE request F1, which carries a 294 multipart/mixed body composed of two other bodies: an application/sdp 295 body that describes the session and an application/resource-lists+xml 296 body that contains the list of target URIs. 298 INVITE sip:conf-fact@example.com SIP/2.0 299 Via: SIP/2.0/TCP atlanta.example.com 300 ;branch=z9hG4bKhjhs8ass83 301 Max-Forwards: 70 302 To: "Conf Factory" 303 From: Alice ;tag=32331 304 Call-ID: d432fa84b4c76e66710 305 CSeq: 1 INVITE 306 Contact: 307 Allow: INVITE, ACK, CANCEL, BYE, REFER 308 Allow-Events: dialog 309 Accept: application/sdp, message/sipfrag 310 Require: recipient-list-invite 311 Content-Type: multipart/mixed;boundary="boundary1" 312 Content-Length: 690 314 --boundary1 315 Content-Type: application/sdp 317 v=0 318 o=alice 2890844526 2890842807 IN IP4 atlanta.example.com 319 s=- 320 c=IN IP4 192.0.2.1 321 t=0 0 322 m=audio 20000 RTP/AVP 0 323 a=rtpmap:0 PCMU/8000 324 m=video 20002 RTP/AVP 31 325 a=rtpmap:31 H261/90000 327 --boundary1 328 Content-Type: application/resource-lists+xml 329 Content-Disposition: recipient-list 331 332 334 335 336 338 340 341 343 344 345 346 347 --boundary1-- 349 Figure 3: INVITE request received at the conference server 351 The INVITE requests F3, F4, and F5 are similar in nature. All those 352 INVITE requests contain a multipart/mixed body which is composed of 353 two other bodies: an application/sdp body describing the session and 354 an application/resource-lists+xml containing the list of recipients. 355 The application/resource-lists+xml bodies are not equal to the 356 application/resource-lists+xml included in the received INVITE 357 request F1, because the conference server has anonymized those URIs 358 tagged with the 'anonymize' attribute and has removed those URIs 359 tagged with a "bcc" 'capacity' attribute. Figure 4 shows an example 360 of the message F3. 362 INVITE sip:bill@example.com SIP/2.0 363 Via: SIP/2.0/TCP conference.example.com 364 ;branch=z9hG4bKhjhs8as454 365 Max-Forwards: 70 366 To: 367 From: Conference Server ;tag=234332 368 Call-ID: 389sn189dasdf 369 CSeq: 1 INVITE 370 Contact: ;isfocus 371 Allow: INVITE, ACK, CANCEL, BYE, REFER 372 Allow-Events: dialog, conference 373 Accept: application/sdp, message/sipfrag 374 Require: recipient-list-invite 375 Conten-Type: multipart/mixed;boundary="boundary1" 376 Content-Length: 690 378 --boundary1 379 Content-Type: application/sdp 381 v=0 382 o=conf 2890844343 2890844343 IN IP4 conference.example.com 383 s=- 384 c=IN IP4 192.0.2.5 385 t=0 0 386 m=audio 40000 RTP/AVP 0 387 a=rtpmap:0 PCMU/8000 388 m=video 40002 RTP/AVP 31 389 a=rtpmap:31 H261/90000 391 --boundary1 392 Content-Type: application/resource-lists+xml 393 Content-Disposition: recipient-list-history; handling=optional 395 396 398 399 400 402 403 405 406 407 --boundary1-- 409 Figure 4: INVITE request sent by the conference server 411 9. Security Considerations 413 This document discusses setup of SIP conferences using a request- 414 contained URI-list. Both conferencing and URI-lists services have 415 specific security requirements which will be summarized here. 416 Conferences generally have authorization rules about who may or may 417 not join a conference, what type of media may or may not be used, 418 etc. This information is used by the focus to admit or deny 419 participation in a conference. It is RECOMMENDED that these types of 420 authorization rules be used to provide security for a SIP conference. 422 For this authorization information to be used, the focus needs to be 423 able to authenticate potential participants. Normal SIP mechanisms 424 including Digest authentication and certificates can be used. These 425 conference specific security requirements are discussed further in 426 the requirements and framework documents. 428 For conference creation using a list, there are some additional 429 security considerations. The Framework and Security Considerations 430 for SIP URI-List Services [6] discusses issues related to SIP URI- 431 list services. Given that a conference server sending INVITEs to a 432 set of users acts as an URI-list service, implementations of 433 conference servers that handle lists MUST follow the security-related 434 rules in [6]. These rules include mandatory authentication and 435 authorization of clients, and opt-in lists. 437 10. IANA Considerations 439 This document defines the 'recipient-list-invite' SIP option-tag in 440 Section 7. It should be registered in the Option Tags subregistry 441 under the SIP parameter registry. The following is the description 442 to be used in the registration. 444 +------------------------+------------------------------+-----------+ 445 | Name | Description | Reference | 446 +------------------------+------------------------------+-----------+ 447 | recipient-list-invite | The body contains a list of | [RFCXXXX] | 448 | | URIs that indicates the | | 449 | | recipients of the SIP INVITE | | 450 | | request | | 451 +------------------------+------------------------------+-----------+ 453 Table 1: Registration of the 'recipient-list-invite' Option-Tag in 454 SIP 456 Note to IANA and the RFC editor: replace RFCXXXX above with the RFC 457 number of this specification. 459 11. Acknowledges 461 Cullen Jennings, Hisham Khartabil, and Jonathan Rosenberg provided 462 useful comments on this document. Miguel Garcia-Martin assembled the 463 dependencies to the 'capacity' attribute extension. 465 12. References 467 12.1. Normative References 469 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 470 Levels", BCP 14, RFC 2119, March 1997. 472 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 473 Presentation Information in Internet Messages: The Content- 474 Disposition Header Field", RFC 2183, August 1997. 476 [3] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 477 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 478 Objects", RFC 3204, December 2001. 480 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 481 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 482 Session Initiation Protocol", RFC 3261, June 2002. 484 [5] Levin, O., "Session Initiation Protocol Call Control - 485 Conferencing for User Agents", 486 draft-ietf-sipping-cc-conferencing-07 (work in progress), 487 June 2005. 489 [6] Camarillo, G. and A. Roach, "Framework and Security 490 Considerations for Session Initiation Protocol (SIP) Uniform 491 Resource Identifier (URI)-List Services", 492 draft-ietf-sipping-uri-services-04 (work in progress), 493 October 2005. 495 [7] Rosenberg, J., "Extensible Markup Language (XML) Formats for 496 Representing Resource Lists", 497 draft-ietf-simple-xcap-list-usage-05 (work in progress), 498 February 2005. 500 [8] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 501 (XML) Format Extension for Representing Capacity Attributes in 502 Resource Lists", draft-ietf-sipping-capacity-attribute-00 (work 503 in progress), February 2006. 505 12.2. Informational References 507 [9] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 508 Package for Conference State", 509 draft-ietf-sipping-conference-package-12 (work in progress), 510 July 2005. 512 Authors' Addresses 514 Gonzalo Camarillo 515 Ericsson 516 Hirsalantie 11 517 Jorvas 02420 518 Finland 520 Email: Gonzalo.Camarillo@ericsson.com 522 Alan Johnston 523 MCI 524 100 South 4th Street 525 St. Louis, MO 63102 526 USA 528 Email: alan.johnston@mci.com 530 Full Copyright Statement 532 Copyright (C) The Internet Society (2006). 534 This document is subject to the rights, licenses and restrictions 535 contained in BCP 78, and except as set forth therein, the authors 536 retain all their rights. 538 This document and the information contained herein are provided on an 539 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 540 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 541 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 542 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 543 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Intellectual Property 548 The IETF takes no position regarding the validity or scope of any 549 Intellectual Property Rights or other rights that might be claimed to 550 pertain to the implementation or use of the technology described in 551 this document or the extent to which any license under such rights 552 might or might not be available; nor does it represent that it has 553 made any independent effort to identify any such rights. Information 554 on the procedures with respect to rights in RFC documents can be 555 found in BCP 78 and BCP 79. 557 Copies of IPR disclosures made to the IETF Secretariat and any 558 assurances of licenses to be made available, or the result of an 559 attempt made to obtain a general license or permission for the use of 560 such proprietary rights by implementers or users of this 561 specification can be obtained from the IETF on-line IPR repository at 562 http://www.ietf.org/ipr. 564 The IETF invites any interested party to bring to its attention any 565 copyrights, patents or patent applications, or other proprietary 566 rights that may cover technology that may be required to implement 567 this standard. Please address the information to the IETF at 568 ietf-ipr@ietf.org. 570 Acknowledgment 572 Funding for the RFC Editor function is currently provided by the 573 Internet Society.