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