idnits 2.17.1 draft-camarillo-sipping-uri-list-02.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 405. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 389. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 395. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 411), 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? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-camarillo-uri-list-02', but the file name used is 'draft-camarillo-sipping-uri-list-02' == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 1 character 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). == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (March 27, 2004) is 7328 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) ** Obsolete normative reference: RFC 2822 (ref. '3') (Obsoleted by RFC 5322) == Outdated reference: A later version (-05) exists of draft-ietf-simple-xcap-list-usage-02 == Outdated reference: A later version (-05) exists of draft-ietf-sip-content-indirect-mech-03 == Outdated reference: A later version (-12) exists of draft-ietf-simple-xcap-02 Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 4 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. Roach 4 dynamicsoft 5 March 27, 2004 7 Providing a Session Initiation Protocol (SIP) Application Server with 8 a List of URIs 9 draft-camarillo-uri-list-02.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 3667. 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 September 25, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 This document describes how a user agent can provide an application 42 server with a list of URIs. The way the application server uses the 43 URIs in the list is method specific. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 50 4. Procedures at the User Agent . . . . . . . . . . . . . . . . . 4 51 5. URI List Format . . . . . . . . . . . . . . . . . . . . . . . 4 52 6. The SIP and SIPS URI List Parameter . . . . . . . . . . . . . 5 53 7. The Content-ID SIP Header Field . . . . . . . . . . . . . . . 5 54 8. Pointing to External URI Lists . . . . . . . . . . . . . . . . 6 55 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 12. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 Normative References . . . . . . . . . . . . . . . . . . . . . 8 60 Informational References . . . . . . . . . . . . . . . . . . . 9 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 9 62 Intellectual Property and Copyright Statements . . . . . . . . 10 64 1. Introduction 66 Some services require a SIP UA to provide an application server with 67 a set of URIs. For example, a UA creating a conference needs to 68 provide the conference server with the participants. The same way, a 69 UA requesting presence information from a set of users needs to 70 provide the resource list server with the URIs of the users that 71 belong to the list. 73 These lists are typically configured using out-of-band methods. For 74 instance, a UA can use XCAP [7] to create a list of URIs and to 75 associate this list with a SIP URI (e.g., sip:myfriends@example.com). 76 It can, then, send a SIP request (an INVITE or a SUBSCRIBE in our 77 previous examples) to that SIP URI. 79 Still, there is a need to create lists of URIs in an ad-hoc way and 80 send them directly in a SIP message. Transporting the URI list in the 81 SIP message that triggers the service usually helps reduce the 82 service establishment time, and is useful for UAs that do not have 83 access to a server to host their list (and they cannot act as a 84 server themselves). 86 In any case, the way the application server interprets the URI list 87 received in the request is method specific. 89 A UA creating a SIP request that needs to carry a URI list proceeds 90 this way. It places the URI list (e.g., an XCAP resource list [4]) in 91 a body part, and constructs a pointer to that body part (i.e., a 92 Content-ID URL [2] that points to the body part that carries the URI 93 list). Then, the UA places the pointer in a "list" URI parameter. The 94 way the application server interprets the URI list received in the 95 request is method specific. 97 2. Scope 99 This document specifies how to associate a URI list with a SIP or 100 SIPS URI using the "list" parameter. The base URI identifies, as 101 usual, a resource (generally a service), which is further described 102 by the associated URI list. 104 SIP transport of URI lists that are not associated with a SIP or SIPS 105 URI is outside the scope of this document. Note, in any case, that 106 the syntax of a number of already defined SIP header fields (e.g., 107 Alert-Info, Call-Info, Contact, etc) allows them to carry a set of 108 URIs. 110 3. Terminology 112 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 113 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 114 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 115 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 116 compliant implementations. 118 4. Procedures at the User Agent 120 A UA creating a SIP request that needs to carry a SIP or SIPS URI 121 with an associated URI list MUST place the URI list in a body part, 122 and MUST construct a pointer to that body part (i.e., a Content-ID 123 URL [2] that points to the body part that carries the URI list). 124 Then, the UA MUST place the pointer in a "list" URI parameter (which 125 is defined in Section 6) of the SIP or SIPS URI. 127 The following is an example of a Content-ID URL: 129 cid:cn35t8jf02@example.com 131 The body the previous Content-ID URI points to would be described by, 132 among other header fields, the following Content-ID header field: 134 Content-ID: 136 Further procedures are method specific and are defined in separate 137 documents. For example, the use of lists and the INVITE method is 138 described in (draft-camarillo-sipping-adhoc-conferencing-00.txt), and 139 the use of lists and SUBSCRIBE is defined in 140 (draft-camarillo-sipping-adhoc-simple-00.txt). 142 As for any other SIP request, the size of requests carrying URI lists 143 MUST NOT exceed 1300 bytes, unless the user agent client has positive 144 knowledge that the message will not traverse a congestion-unsafe link 145 at any hop, or that the message size is at least 200 bytes less than 146 the lowest MTU value found en route to the server. 148 5. URI List Format 150 The default URI list format for SIP entities is the XCAP resource 151 list format defined in [4]. So, SIP entities handling URI lists MUST 152 support this format. 154 Nevertheless, the XCAP resource list format provides features such as 155 hierarchical lists and list's attributes that are not needed by many 156 services, which only need to transfer a flat list of URIs from a 157 client to a server. The amount of information that a URI list needs 158 to carry between a client and a server is method specific. 159 Additionally, the way a client and a server negotiate the amount of 160 information needed for a particular service is method specific as 161 well. 163 A client invoking a particular service SHOULD NOT include more 164 information in its URI list than the service requires. A server 165 providing a particular service MAY discard any extra information 166 which is received in a URI list from the client. 168 The following is an example of a flat list without attributes. 170 171 172 173 174 175 176 177 178 180 Figure 1: URI List 182 6. The SIP and SIPS URI List Parameter 184 SIP and SIPS URIs that need to reference a URI list MUST carry a 185 pointer to the URI list, as described in Section 4, in a "list" SIP 186 and SIPS URI parameter. We define the "list" parameter for SIP and 187 SIPS URIs so that it MUST contain a Content-ID URL [2] that points to 188 a URI list. The ABNF of the "list" parameter is: 189 list-param = "list=" absoluteURI 191 The following is an example of a SIP URI with a list parameter 192 pointing to a body part using a Content-ID URL [2]: 194 sip:group@example.com;list=cid:cn35t8jf02@example.com 196 7. The Content-ID SIP Header Field 198 The Content-ID MIME header field is defined in RFC 2045 [6]. We 199 define here the same header field to be used in SIP messages. Without 200 this definition, SIP messages with a single body could not reference 201 it using Content-ID URLs (messages with multiple bodies use the 202 definition RFC 2045 [6]). The ABNF of the SIP Content-ID header field 203 is: 204 Content-ID = "Content-ID" HCOLON msg-id 206 RFC 2822 [3] defines msg-id in Section 3.6.4. 208 The Content-ID value is used to uniquely identify a body. The 209 Content-ID header field MAY appear in any SIP request or response 210 that contains a body. 212 8. Pointing to External URI Lists 214 UAs that want to use an external URI list, instead of sending it as a 215 body part, SHOULD use the content indirection mechanism defined in 216 [5]. Indirected body parts are equivalent and have the same treatment 217 as in-line body parts. 219 The content indirection mechanism has certain security properties, 220 such as allowing the UA to provide a hash of the contents of the 221 external list, that could not be provided if "list" parameters could 222 point directly to external lists (e.g., using an HTTP URI). 224 9. Examples 226 The following is an example of an INVITE request that carries a URI 227 list in its body. The Request-URI of this INVITE contains a pointer 228 to the body part carrying the list. 230 INVITE sip:ad-hoc@example.com;list=cid:cn35t8jf02@example.com SIP/2.0 231 Via: SIP/2.0/TCP client.chicago.example.com 232 ;branch=z9hG4bKhjhs8ass83 233 Max-Forwards: 70 234 To: 235 From: Carol ;tag=32331 236 Call-ID: d432fa84b4c76e66710 237 CSeq: 1 INVITE 238 Contact: 239 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 240 SUBSCRIBE, NOTIFY 241 Allow-Events: dialog 242 Accept: application/sdp, message/sipfrag, 243 application/resource-lists+xml 244 Conten-Type: multipart/mixed;boundary="boundary1" 245 Content-Length: 679 247 --boundary1 248 Content-Type: application/sdp 249 Content-Length: 160 251 v=0 252 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 253 s=Example Subject 254 c=IN IP4 192.0.0.1 255 t=0 0 256 m=audio 20000 RTP/AVP 0 257 m=video 20002 RTP/AVP 31 259 --boundary1 260 Content-Type: application/resource-lists+xml 261 Content-Length: 315 262 Content-ID: 264 265 266 267 268 269 270 271 272 273 --boundary1-- 275 Figure 2: INVITE request 277 Refer to (draft-camarillo-sipping-adhoc-conferencing-00.txt) for the 278 normative details on how a list can be used with the INVITE method. 280 10. Security Considerations 282 This document discusses how to carry URI lists in SIP messages. In 283 some cases, the URIs in the lists may need to be kept private. It is 284 RECOMMENDED that S/MIME is used to prevent a third party from viewing 285 this information. 287 Some application servers, on reception of a SIP message with a URI 288 list, send SIP requests to the URIs in the list. Such an application 289 server may have policies that limit the number of URIs in the list, 290 as a very long list could be used in a denial of service attack to 291 place a large burden on the application server to send a large number 292 of SIP requests. In addition, it is RECOMMENDED that S/MIME is used 293 to integrity protect the list contents to keep attackers from adding 294 URIs to a list. 296 An application server MUST authenticate and authorize any user that 297 requests the application server to send requests to a list of URIs. 298 Otherwise, a malicious client could use the application server to 299 perform a denial of service attack. In any event, this risk also 300 exists when a client sets up a URI list using out-of-band methods 301 (e.g., XCAP) and sends a request to that list. Application servers 302 MUST use authentication and authorization mechanisms with equivalent 303 security properties when sending requests to URI lists created using 304 out-of-band and in-band methods. 306 11. IANA Considerations 308 This document registers the "list" SIP and SIPS URI parameter, which 309 is described in Section 6. This parameter is to be added to the SIP 310 and SIPS URI parameter registry under http://www.iana.org/ TBD. 312 This document registers the Content-ID SIP header field, which is 313 described in Section 7. This header field is to be added to the 314 header field registry under http://www.iana.org/assignments/ 315 sip-parameters. 316 Header Name: Content-ID 317 Compact Form: (none) 319 12. Acknowledges 321 Alan Johnston, Orit Levin, and Cullen Jennings provided useful 322 comments on this document. 324 Normative References 326 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 327 Levels", BCP 14, RFC 2119, March 1997. 329 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 330 Locators", RFC 2392, August 1998. 332 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 334 [4] Rosenberg, J., "An Extensible Markup Language (XML) 335 Configuration Access Protocol (XCAP) Usage for Presence Lists", 336 draft-ietf-simple-xcap-list-usage-02 (work in progress), 337 February 2004. 339 [5] Olson, S., "A Mechanism for Content Indirection in Session 340 Initiation Protocol (SIP) Messages", 341 draft-ietf-sip-content-indirect-mech-03 (work in progress), June 342 2003. 344 Informational References 346 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 347 Extensions (MIME) Part One: Format of Internet Message Bodies", 348 RFC 2045, November 1996. 350 [7] Rosenberg, J., "The Extensible Markup Language (XML) 351 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02 352 (work in progress), February 2004. 354 Authors' Addresses 356 Gonzalo Camarillo 357 Ericsson 358 Hirsalantie 11 359 Jorvas 02420 360 Finland 362 EMail: Gonzalo.Camarillo@ericsson.com 364 Adam Roach 365 dynamicsoft 366 5100 Tennyson Pkwy 367 Suite 1200 368 Plano, TX 75024 369 US 371 EMail: adam@dynamicsoft.com 373 Intellectual Property Statement 375 The IETF takes no position regarding the validity or scope of any 376 Intellectual Property Rights or other rights that might be claimed to 377 pertain to the implementation or use of the technology described in 378 this document or the extent to which any license under such rights 379 might or might not be available; nor does it represent that it has 380 made any independent effort to identify any such rights. Information 381 on the IETF's procedures with respect to rights in IETF Documents can 382 be found in BCP 78 and BCP 79. 384 Copies of IPR disclosures made to the IETF Secretariat and any 385 assurances of licenses to be made available, or the result of an 386 attempt made to obtain a general license or permission for the use of 387 such proprietary rights by implementers or users of this 388 specification can be obtained from the IETF on-line IPR repository at 389 http://www.ietf.org/ipr. 391 The IETF invites any interested party to bring to its attention any 392 copyrights, patents or patent applications, or other proprietary 393 rights that may cover technology that may be required to implement 394 this standard. Please address the information to the IETF at 395 ietf-ipr@ietf.org. 397 Disclaimer of Validity 399 This document and the information contained herein are provided on an 400 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 401 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 402 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 403 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 404 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 405 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 407 Copyright Statement 409 Copyright (C) The Internet Society (2004). This document is subject 410 to the rights, licenses and restrictions contained in BCP 78, and 411 except as set forth therein, the authors retain all their rights. 413 Acknowledgment 415 Funding for the RFC Editor function is currently provided by the 416 Internet Society.