idnits 2.17.1 draft-camarillo-sipping-adhoc-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.5 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 299. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 315), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** 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? 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 seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (March 27, 2004) is 7335 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-cc-conferencing-03 == Outdated reference: A later version (-02) exists of draft-camarillo-sipping-uri-list-01 -- Possible downref: Normative reference to a draft: ref. '4' == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-03 Summary: 8 errors (**), 0 flaws (~~), 8 warnings (==), 6 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: September 25, 2004 A. Johnston 4 MCI 5 March 27, 2004 7 Ad-Hoc Conferencing in the Session Initiation Protocol (SIP) 8 draft-camarillo-sipping-adhoc-conferencing-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance with 15 RFC 3667. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 25, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes how to create a conference using SIP ad-hoc 41 methods and a URI list. In particular, we describe a mechanism that 42 allows a client to provide a conference server with the initial list 43 of participants for an ad-hoc conference. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Providing a Conference Server with a URI List . . . . . . . . . 3 50 4. URI List Format . . . . . . . . . . . . . . . . . . . . . . . . 3 51 5. Conference Server Behavior . . . . . . . . . . . . . . . . . . . 4 52 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 54 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 Normative References . . . . . . . . . . . . . . . . . . . . . . 6 56 Informational References . . . . . . . . . . . . . . . . . . . . 7 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 58 Intellectual Property and Copyright Statements . . . . . . . . . 8 60 1. Introduction 62 Section 4.5 of [3] describes how to create a conference using ad-hoc 63 SIP [2] methods. The client sends an INVITE request to a conference 64 factory URI, and receives the actual conference URI, which contains 65 the "IsFocus" feature tag, in the Contact header field of a response 66 (typically a 200 OK). 68 Once the client obtains the conference URI, it can add participants 69 to the newly created conference in several ways, which are described 70 in [3]. 72 Some environments have tough requirements regarding conference 73 establishment time. So, they require the client to be able to request 74 the creation of an ad-hoc conference and to provide the server with 75 the initial set of participants in a single operation. This document 76 describes how to meet this requirement using the mechanism to 77 transport URI lists in SIP messages described in [4]. 79 2. Terminology 81 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 82 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 83 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 84 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 85 compliant implementations. 87 3. Providing a Conference Server with a URI List 89 A client that wants to include the set of initial participants in its 90 initial INVITE to create an ad-hoc conference MAY add a "list" 91 parameter (defined in [4]) to the conference factory URI and MUST 92 place the resulting URI in the Request-URI. The "list" parameter MUST 93 contain a pointer to a URI list that contains the participants that 94 the client wants the server to INVITE. The following is an example of 95 a Request-URI with a "list" parameter. 97 sip:conf-factory@example.com;list="cid:cn35t8jf02@example.com" 99 4. URI List Format 101 As described in [4], the default format for URI lists in SIP is the 102 XCAP resource list format [5]. Still, specific services need to 103 describe which information clients should include in their URI lists, 104 as described in [4]. 106 Conferencing UAs SHOULD use flat lists (i.e., no hierarchical lists), 107 SHOULD NOT use any entry's attributes but "uri", and SHOULD NOT 108 include any elements inside entries but "display-name" elements. 110 A conference factory application receiving a URI list with more 111 information than what we have just described SHOULD discard all the 112 extra information. 114 5. Conference Server Behavior 116 On reception of an INVITE with a URI list as described in Section 3, 117 a conference server MUST follow the rules described in [3] to create 118 ad-hoc conferences. Once the ad-hoc conference is created, the 119 conference server SHOULD attempt to add the participants in the URI 120 list to the conference as if their addition had been requested using 121 any of the methods described in [3] (e.g., using CPCP [6]). 123 Once the conference server has created the ad-hoc conference and has 124 attempted to add the initial set of participants, the conference 125 server behaves as a regular conference server and MUST follow the 126 rules in [3]. 128 Note that the status code in the response to the INVITE does not 129 provide any information about whether or not the conference server 130 was able to bring the users in the URI list into the conference. That 131 is, a 200 (OK) means that the conference was created successfully, 132 that the client that generated the INVITE is in the conference, and 133 that the server understood the URI list. If the client wishes to 134 obtain information about the status of other users in the conference 135 it SHOULD use general conference mechanisms, such as the conference 136 package [7]. 138 6. Example 140 The following is an example of an INVITE request, which carries a URI 141 list in its body, sent by a UA to a conference factory application. 143 INVITE sip:conf-fact@example.com;list=cid:cn35t8jf02@example.com SIP/2.0 144 Via: SIP/2.0/TCP client.chicago.example.com 145 ;branch=z9hG4bKhjhs8ass83 146 Max-Forwards: 70 147 To: Conf Factory 148 From: Carol ;tag=32331 149 Call-ID: d432fa84b4c76e66710 150 CSeq: 1 INVITE 151 Contact: 152 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 153 SUBSCRIBE, NOTIFY 154 Allow-Events: dialog 155 Accept: application/sdp, message/sipfrag, 156 application/resource-lists+xml 157 Conten-Type: multipart/mixed;boundary="boundary1" 158 Content-Length: xxx 160 --boundary1 161 Content-Type: application/sdp 162 Content-Length: xxx 164 v=0 165 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 166 s=Example Subject 167 c=IN IP4 192.0.0.1 168 t=0 0 169 m=audio 20000 RTP/AVP 0 170 a=rtpmap:0 PCMU/8000 171 m=video 20002 RTP/AVP 31 172 a=rtpmap:31 H261/90000 174 --boundary1 175 Content-Type: application/resource-lists+xml 176 Content-Length: 315 177 Content-ID: 179 180 181 182 183 184 185 186 187 188 --boundary1-- 190 Figure 1: INVITE request 192 7. Security Considerations 194 This document discusses ad-hoc setup of SIP conferences using a list. 195 Both conferencing and lists have specific security requirements which 196 will be summarized here. Conferences generally have authorization 197 rules about who may or may not join a conference, what type of media 198 may or may not be used, etc. This information is used by the focus to 199 admit or deny participation in a conference. It is recommended that 200 these types of authorization rules be used to provide security for a 201 SIP conference. 203 For this authorization information to be used, the focus needs to be 204 able to authenticate potential participants. Normal SIP mechanisms 205 including Digest authentication and certificates can be used. These 206 conference specific security requirements are discussed further in 207 the requirements and framework documents. 209 For conference creation using a list, there are some additional 210 security considerations. In some cases, the list of potential 211 participants may need to be kept private. The use of TLS transport 212 or S/MIME can be used to prevent a third party from viewing this 213 information. In addition, a focus may have policies that limit the 214 number of participants in the list, as a very long list could be used 215 in a denial of service attack to place a large burden on the focus to 216 send a large number of INVITEs. Other list related security 217 considerations are discussed in the list framework document. 219 8. Acknowledges 221 Cullen Jennings provided useful comments on this document. 223 Normative References 225 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 226 Levels", BCP 14, RFC 2119, March 1997. 228 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 229 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 230 Session Initiation Protocol", RFC 3261, June 2002. 232 [3] Johnston, A. and O. Levin, "Session Initiation Protocol Call 233 Control - Conferencing for User Agents", 234 draft-ietf-sipping-cc-conferencing-03 (work in progress), 235 February 2004. 237 [4] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 238 Application Server with a List of URIs", 239 draft-camarillo-sipping-uri-list-01 (work in progress), February 240 2004. 242 [5] Rosenberg, J., "An Extensible Markup Language (XML) 243 Configuration Access Protocol (XCAP) Usage for Presence Lists", 244 draft-ietf-simple-xcap-list-usage-02 (work in progress), 245 February 2004. 247 Informational References 249 [6] Koskelainen, P. and H. Khartabil, "An Extensible Markup Language 250 (XML) Configuration Access Protocol (XCAP) Usage for Conference 251 Policy Manipulation", draft-koskelainen-xcon-xcap-cpcp-usage-02 252 (work in progress), February 2004. 254 [7] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol 255 (SIP) Event Package for Conference State", 256 draft-ietf-sipping-conference-package-03 (work in progress), 257 February 2004. 259 Authors' Addresses 261 Gonzalo Camarillo 262 Ericsson 263 Hirsalantie 11 264 Jorvas 02420 265 Finland 267 EMail: Gonzalo.Camarillo@ericsson.com 269 Alan Johnston 270 MCI 271 100 South 4th Street 272 St. Louis, MO 63102 273 USA 275 EMail: alan.johnston@mci.com 277 Intellectual Property Statement 279 The IETF takes no position regarding the validity or scope of any 280 Intellectual Property Rights or other rights that might be claimed to 281 pertain to the implementation or use of the technology described in 282 this document or the extent to which any license under such rights 283 might or might not be available; nor does it represent that it has 284 made any independent effort to identify any such rights. Information 285 on the IETF's procedures with respect to rights in IETF Documents can 286 be found in BCP 78 and BCP 79. 288 Copies of IPR disclosures made to the IETF Secretariat and any 289 assurances of licenses to be made available, or the result of an 290 attempt made to obtain a general license or permission for the use of 291 such proprietary rights by implementers or users of this 292 specification can be obtained from the IETF on-line IPR repository at 293 http://www.ietf.org/ipr. 295 The IETF invites any interested party to bring to its attention any 296 copyrights, patents or patent applications, or other proprietary 297 rights that may cover technology that may be required to implement 298 this standard. Please address the information to the IETF at 299 ietf-ipr@ietf.org. 301 Disclaimer of Validity 303 This document and the information contained herein are provided on an 304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 311 Copyright Statement 313 Copyright (C) The Internet Society (2004). This document is subject 314 to the rights, licenses and restrictions contained in BCP 78, and 315 except as set forth therein, the authors retain all their rights. 317 Acknowledgment 319 Funding for the RFC Editor function is currently provided by the 320 Internet Society.