idnits 2.17.1 draft-camarillo-sipping-adhoc-management-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances 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 (February 6, 2004) is 7378 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 (-05) exists of draft-ietf-simple-xcap-list-usage-01 == Outdated reference: A later version (-02) exists of draft-camarillo-sipping-uri-list-00 -- Possible downref: Normative reference to a draft: ref. '3' Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 3 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 6, 2004 February 6, 2004 6 Ad-Hoc URI List Management in the Session Initiation Protocol (SIP) 7 draft-camarillo-sipping-adhoc-management-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on August 6, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This document defines two mechanisms to manage ad-hoc URI lists in 38 SIP. In the first mechanism, the user agent sends an updated version 39 of the entire list to the server. In the second mechanism, the server 40 provides the user agent with a URI (e.g., http) that can be used to 41 manipulate the list using an out-of-band mechanim (e.g., XCAP). We 42 define the Associated-List-Manipulation header field that carries a 43 URI that allows manipulating an ad-hoc list. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. List Substitution . . . . . . . . . . . . . . . . . . . . . . 3 50 4. Out-of-Band Management . . . . . . . . . . . . . . . . . . . . 3 51 5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5.1 List Substitution . . . . . . . . . . . . . . . . . . . . . . 6 53 5.2 Out-of-Band Management . . . . . . . . . . . . . . . . . . . . 7 54 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 55 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 56 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 57 Normative References . . . . . . . . . . . . . . . . . . . . . 8 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 59 Intellectual Property and Copyright Statements . . . . . . . . 9 61 1. Introduction 63 SIP messages can carry URI lists using the "list" SIP and SIPS URI 64 parameter defined in [3]. An application server receiving a SIP 65 request with a URI list creates a so called ad-hoc URI list, which is 66 valid for the duration of the service provided by the server. 68 Once an ad-hoc URI list is created at the server, the user agent may 69 need to manipulate it (e.g., add URIs to the list and remove URIs 70 from the list). Section 3 and Section 4 describe two methods to 71 perform ad-hoc URI list management. 73 2. Terminology 75 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 76 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 77 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 78 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 79 compliant implementations. 81 3. List Substitution 83 A user agent MAY provide an application server with an updated 84 version of the ad-hoc list by sending a request with a "list" 85 parameter [3] in its Request-URI. The "list" parameter MUST contain a 86 pointer to the updated list. (The method of this request depends on 87 the service being delivered.) On reception of such a request, the 88 application server MUST substitute the previous ad-hoc list with the 89 list referenced by the "list" parameter. 91 4. Out-of-Band Management 93 Section 3 describes how to send a complete URI list to an application 94 server that substitutes the previous one. Following this approach, a 95 user agent that wants to modify a single URI in a long URI list needs 96 to resend the whole list. 98 Still, there are URI list management mechanisms, such as the XCAP 99 usage defined in [2], that allow user agents to manipulate URI lists 100 more efficiently. We define a new SIP header field called 101 Associated-List-Manipulation that allows a server to provide a URI to 102 the client to manipulate the ad-hoc list using an out-of-band 103 mechanism. The XCAP Usage for Resource Lists MUST be supported. Other 104 mechanisms MAY be supported. 106 The ABNF of the Associated-List-Manipulation header field is: 108 List-Manipulation = "Associated-List-Manipulation" HCOLON 109 absoluteURI 111 5. Examples 113 This section shows how to use the mechanisms described in Section 3 114 and Section 4 to manipulate the list of participants in an ad-hoc 115 conference. This example illustrates the use of both mechanisms. It 116 does not mandate how ad-hoc conference services have to be 117 implemented. 119 When the ad-hoc conferencing server in this example receives an 120 initial INVITE with a URI list, it sends out an INVITE to each URI in 121 the list and creates an ad-hoc conference with all of them. If, at a 122 later point, a URI is added to the list, the conference server 123 INVITEs the new user. If a URI is removed from the list, the 124 conference server BYEs the user. 126 Carol creates an ad-hoc conference on the server by sending the 127 INVITE request shown in Figure 1. The list parameter in the 128 Request-URI points to a MIME body that carries the list of 129 participants. 131 INVITE sip:ad-hoc@example.com;list=cid:cn35t8jf02@example.com SIP/2.0 132 Via: SIP/2.0/TCP client.chicago.example.com 133 ;branch=z9hG4bKhjhs8ass83 134 Max-Forwards: 70 135 To: "Ad-Hoc Conferences" 136 From: Carol ;tag=32331 137 Call-ID: d432fa84b4c76e66710 138 CSeq: 1 INVITE 139 Contact: 140 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 141 SUBSCRIBE, NOTIFY 142 Allow-Events: dialog 143 Accept: application/sdp, message/sipfrag, 144 application/resource-lists+xml 145 Conten-Type: multipart/mixed;boundary="boundary1" 146 Content-Length: 731 148 --boundary1 149 Content-Type: application/sdp 150 Content-Length: 160 152 v=0 153 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 154 s=Example Subject 155 c=IN IP4 192.0.0.1 156 t=0 0 157 m=audio 20000 RTP/AVP 0 158 m=video 20002 RTP/AVP 31 160 --boundary1 161 Content-Type: application/resource-lists+xml 162 Content-Length: 367 163 Content-ID: 165 166 167 168 169 170 171 172 173 174 --boundary1-- 176 Figure 1: INVITE request 178 SIP/2.0 200 OK 179 Via: SIP/2.0/TCP client.chicago.example.com 180 ;branch=z9hG4bKhjhs8ass83;received=192.0.2.4 181 To: "Ad-Hoc Conferences" ;tag=733413 182 From: Carol ;tag=32331 183 Call-ID: d432fa84b4c76e66710 184 CSeq: 1 INVITE 185 Contact: ;isfocus 186 Associated-List-Manipulation: http://xcap.example.com/lists/yourlist 187 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 188 SUBSCRIBE, NOTIFY 189 Allow-Events: dialog, conference 190 Accept: application/sdp, application/conference-info+xml, 191 application/resource-lists+xml, message/sipfrag 192 Supported: replaces, join 193 Content-Type: application/sdp 194 Content-Length: 312 196 v=0 197 o=focus431 2890844526 2890842807 IN IP4 ms5.conf.example.com 198 s=Example Subject 199 i=Example Conference Hosted by Example.com 200 u=http://conf.example.com/3402934234 201 e=3402934234@conf-help.example.com 202 p=+1-888-555-1212 203 c=IN IP4 ms5.conf.example.com 204 t=0 0 205 m=audio 49170 RTP/AVP 0 206 m=video 51372 RTP/AVP 31 208 Figure 2: 200 (OK) response 210 The conference server responds with the 200 (OK) in Figure 1, which 211 carries the URI for the conference in its Contact header field and a 212 URI for manipulating the URI list in its Associated-List-Manipulation 213 header field. 215 5.1 List Substitution 217 Carol wants to remove Bill and Joe from the conference. She sends the 218 re-INVITE in Figure 3 to the conference server with an updated URI 219 list in a "list" parameter. 221 INVITE sip:34@example.com;isfocus;list=cid:cn35t8j@example.com SIP/2.0 222 Via: SIP/2.0/TCP client.chicago.example.com 223 ;branch=z9hG4bKhjhs8ass83 224 Max-Forwards: 70 225 To: "Ad-Hoc Conferences" 226 From: Carol ;tag=32331 227 Call-ID: d432fa84b4c76e66710 228 CSeq: 2 INVITE 229 Contact: 230 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 231 SUBSCRIBE, NOTIFY 232 Allow-Events: dialog 233 Accept: application/sdp, message/sipfrag, 234 application/resource-lists+xml 235 Conten-Type: multipart/mixed;boundary="boundary1" 236 Content-Length: xxx 238 --boundary1 239 Content-Type: application/sdp 240 Content-Length: 160 242 v=0 243 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 244 s=Example Subject 245 c=IN IP4 192.0.0.1 246 t=0 0 247 m=audio 20000 RTP/AVP 0 248 m=video 20002 RTP/AVP 31 250 --boundary1 251 Content-Type: application/resource-lists+xml 252 Content-Length: xxx 253 Content-ID: 255 256 257 258 259 260 261 262 --boundary1-- 264 Figure 3: Re-INVITE 266 5.2 Out-of-Band Management 268 Now, Carol wants to add Alice to the conference. This time, she uses 269 the http URI received in the Associated-List-Manipulation header 270 field. She uses XCAP to add Alice's URI, so no SIP traffic is 271 exchanged between her and the server. 273 6. Security Considerations 275 TBD. 277 7. IANA Considerations 279 This document registers the Associated-List-Manipulation SIP header 280 field, which is described in Section 4. This header field is to be 281 added to the header field registry under http://www.iana.org/ 282 assignments/sip-parameters. 284 Header Name: Associated-List-Manipulation 286 Compact Form: (none) 288 8. Acknowledgments 290 Adam Roach, Jonathan Rosenberg, and Orit Levin provided useful 291 comments on this document. 293 Normative References 295 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 296 Levels", BCP 14, RFC 2119, March 1997. 298 [2] Rosenberg, J., "An Extensible Markup Language (XML) 299 Configuration Access Protocol (XCAP) Usage for Presence Lists", 300 draft-ietf-simple-xcap-list-usage-01 (work in progress), October 301 2003. 303 [3] Camarillo, G., "Providing a Session Initiation Protocol (SIP) 304 Application Server with a List of URIs", 305 draft-camarillo-sipping-uri-list-00 (work in progress), November 306 2003. 308 Author's Address 310 Gonzalo Camarillo 311 Ericsson 312 Hirsalantie 11 313 Jorvas 02420 314 Finland 316 EMail: Gonzalo.Camarillo@ericsson.com 318 Intellectual Property Statement 320 The IETF takes no position regarding the validity or scope of any 321 intellectual property or other rights that might be claimed to 322 pertain to the implementation or use of the technology described in 323 this document or the extent to which any license under such rights 324 might or might not be available; neither does it represent that it 325 has made any effort to identify any such rights. Information on the 326 IETF's procedures with respect to rights in standards-track and 327 standards-related documentation can be found in BCP-11. Copies of 328 claims of rights made available for publication and any assurances of 329 licenses to be made available, or the result of an attempt made to 330 obtain a general license or permission for the use of such 331 proprietary rights by implementors or users of this specification can 332 be obtained from the IETF Secretariat. 334 The IETF invites any interested party to bring to its attention any 335 copyrights, patents or patent applications, or other proprietary 336 rights which may cover technology that may be required to practice 337 this standard. Please address the information to the IETF Executive 338 Director. 340 Full Copyright Statement 342 Copyright (C) The Internet Society (2004). All Rights Reserved. 344 This document and translations of it may be copied and furnished to 345 others, and derivative works that comment on or otherwise explain it 346 or assist in its implementation may be prepared, copied, published 347 and distributed, in whole or in part, without restriction of any 348 kind, provided that the above copyright notice and this paragraph are 349 included on all such copies and derivative works. However, this 350 document itself may not be modified in any way, such as by removing 351 the copyright notice or references to the Internet Society or other 352 Internet organizations, except as needed for the purpose of 353 developing Internet standards in which case the procedures for 354 copyrights defined in the Internet Standards process must be 355 followed, or as required to translate it into languages other than 356 English. 358 The limited permissions granted above are perpetual and will not be 359 revoked by the Internet Society or its successors or assignees. 361 This document and the information contained herein is provided on an 362 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 363 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 364 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 365 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 366 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 368 Acknowledgment 370 Funding for the RFC Editor function is currently provided by the 371 Internet Society.