idnits 2.17.1 draft-ietf-sipping-uri-list-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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 326. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 332), 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? ** 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 : ---------------------------------------------------------------------------- ** There are 2 instances 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 == Line 232 has weird spacing: '...ri-list the...' == 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 (June 2004) is 7226 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) == Unused Reference: '2' is defined on line 246, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 249, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 267, but no explicit reference was found in the text ** 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 (-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-simple-xcap-02 Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 8 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: November 30, 2004 A. Roach 4 dynamicsoft 5 June 2004 7 Message-Contained URI-Lists in the Session Initiation Protocol (SIP) 8 draft-ietf-sipping-uri-list-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 3668. 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 November 30, 2004. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document describes how a user agent can provide another user 41 agent with a list of URIs in a SIP message. The way the receiving 42 user agent uses the URIs in the list is method or status code 43 specific. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 3. The uri-list Disposition Type . . . . . . . . . . . . . . . . 3 50 3.1 Default URI List Format . . . . . . . . . . . . . . . . . 4 51 4. Pointing to External URI Lists . . . . . . . . . . . . . . . . 4 52 5. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 54 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 55 8. Acknowledges . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 57 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 6 58 9.2 Informational References . . . . . . . . . . . . . . . . . . 7 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 60 Intellectual Property and Copyright Statements . . . . . . . . 8 62 1. Introduction 64 Some services require a SIP UA (User Agent) to provide another UA 65 (e.g., a SIP URI-list service acting as a UA server) with a set of 66 URIs. For example, a UA creating a conference needs to provide the 67 conference server with the participants. The same way, a UA 68 requesting presence information from a set of users needs to provide 69 the resource list server with the URIs of the users that belong to 70 the list. 72 These lists are typically configured using out-of-band methods. For 73 instance, a UA can use XCAP [8] to create a list of URIs and to 74 associate this list with a SIP URI (e.g., sip:myfriends@example.com). 75 It can, then, send a SIP request (an INVITE or a SUBSCRIBE in our 76 previous examples) to that SIP URI. 78 Still, there is a need to create lists of URIs and send them directly 79 in a SIP message. Transporting the URI list in the SIP message that 80 triggers the service usually helps reduce the service establishment 81 time, and is useful for UAs that do not have access to a server to 82 host their list (and they cannot act as a server themselves). 84 In any case, the way the application server interprets the URI list 85 received in the request is method specific. 87 A UA creating a SIP request or response that needs to carry a URI 88 list places the URI list (e.g., an XCAP resource list [4]) in a body 89 part whose disposition type is "uri-list". The way the receiving UA 90 interprets the URI list received is method specific, or, in the case 91 of a response, status code specific. 93 2. Terminology 95 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 96 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT 97 RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as 98 described in BCP 14, RFC 2119 [1] and indicate requirement levels for 99 compliant implementations. 101 3. The uri-list Disposition Type 103 We define a new disposition type for the Content-Disposition header 104 field: uri-list. Both requests and responses MAY carry uri-list 105 bodies. 107 Bodies whose disposition type is uri-list carry a list of URIs. The 108 way a UA receiving a URI list interprets it is method specific, or, 109 in the case of a response, status code specific. 111 3.1 Default URI List Format 113 The default format for uri-list bodies is the XCAP resource list 114 format defined in [4]. So, SIP entities handling uri-list bodies MUST 115 support this format. 117 Nevertheless, the XCAP resource list format provides features such as 118 hierarchical lists and list's attributes that are not needed by many 119 services, which only need to transfer a flat list of URIs between two 120 UAs. The amount of information that a URI list needs to carry between 121 two UAs is method or status code specific. Additionally, the way a 122 client and a server negotiate the amount of information needed for a 123 particular service is method specific as well. 125 A client invoking a particular service SHOULD NOT include more 126 information in its URI list than the service requires. A server 127 providing a particular service MAY discard any extra information 128 which is received in a URI list from the client. 130 The following is an example of a flat list without attributes. 132 133 134 135 136 137 138 139 141 Figure 1: URI List 143 4. Pointing to External URI Lists 145 UAs that want to use an external URI list, instead of sending it as a 146 body part, SHOULD use the content indirection mechanism defined in 147 [5]. Indirected body parts are equivalent and have the same treatment 148 as in-line body parts. 150 5. Example 152 The following is an example of an INVITE request that carries a URI 153 list in its body. The Request-URI of this INVITE contains a pointer 154 to the body part carrying the list. 156 INVITE sip:conf-fact@example.com SIP/2.0 157 Via: SIP/2.0/TCP client.chicago.example.com 158 ;branch=z9hG4bKhjhs8ass83 159 Max-Forwards: 70 160 To: Conf Factory 161 From: Carol ;tag=32331 162 Call-ID: d432fa84b4c76e66710 163 CSeq: 1 INVITE 164 Contact: 165 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, 166 SUBSCRIBE, NOTIFY 167 Allow-Events: dialog 168 Accept: application/sdp, message/sipfrag, 169 Conten-Type: multipart/mixed;boundary="boundary1" 170 Content-Length: 635 172 --boundary1 173 Content-Type: application/sdp 175 v=0 176 o=carol 2890844526 2890842807 IN IP4 chicago.example.com 177 s=Example Subject 178 c=IN IP4 192.0.2.1 179 t=0 0 180 m=audio 20000 RTP/AVP 0 181 a=rtpmap:0 PCMU/8000 182 m=video 20002 RTP/AVP 31 183 a=rtpmap:31 H261/90000 185 --boundary1 186 Content-Type: application/resource-lists+xml 187 Content-Disposition: uri-list 189 190 191 192 193 194 195 196 197 --boundary1-- 199 Figure 2: INVITE request 201 Refer to (draft-ietf-sipping-uri-list-conferencing-00.txt) for the 202 normative details on how a list can be used with the INVITE method. 204 6. Security Considerations 206 This document discusses how to carry URI lists in SIP messages. 207 Attackers may attempt to modify URI lists sent between two user 208 agents. This would cause a different service behavior than expected 209 by the user agents. To prevent this attack, user agents SHOULD 210 integrity protect URI lists using mechanisms such as S/MIME, which 211 can also provide URI list confidentiality, if needed. 213 Some application servers, on reception of a SIP message with a URI 214 list, send SIP requests to the URIs in the list. These application 215 servers are referred to as SIP URI-list services. The Security 216 Considerations Section of the Requirements and Framework for SIP SIP 217 URI-List Services [6] discusses issues related to SIP URI-list 218 services. Implementations of SIP URI-list services MUST follow the 219 security-related rules in [6]. These rules include mandatory 220 authentication and authorization of clients, and opt-in lists. 222 7. IANA Considerations 224 This document defines a new Content-Disposition header field 225 disposition type (uri-list) in Section 3. This value should be 226 registered in the IANA registry for Content-Dispositions on 228 http://www.iana.org/assignments/mail-cont-disp 230 with the following description: 232 uri-list the body contains a list of URIs 234 8. Acknowledges 236 Alan Johnston, Orit Levin, and Cullen Jennings provided useful 237 comments on this document. 239 9. References 241 9.1 Normative References 243 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 244 Levels", BCP 14, RFC 2119, March 1997. 246 [2] Levinson, E., "Content-ID and Message-ID Uniform Resource 247 Locators", RFC 2392, August 1998. 249 [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 251 [4] Rosenberg, J., "An Extensible Markup Language (XML) 252 Configuration Access Protocol (XCAP) Usage for Presence Lists", 253 draft-ietf-simple-xcap-list-usage-02 (work in progress), 254 February 2004. 256 [5] Olson, S., "A Mechanism for Content Indirection in Session 257 Initiation Protocol (SIP) Messages", 258 draft-ietf-sip-content-indirect-mech-03 (work in progress), June 259 2003. 261 [6] Camarillo, G., "Requirements for Session Initiation Protocol 262 (SIP) Exploder Invocation", draft-camarillo-sipping-exploders-02 263 (work in progress), February 2004. 265 9.2 Informational References 267 [7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 268 Extensions (MIME) Part One: Format of Internet Message Bodies", 269 RFC 2045, November 1996. 271 [8] Rosenberg, J., "The Extensible Markup Language (XML) 272 Configuration Access Protocol (XCAP)", draft-ietf-simple-xcap-02 273 (work in progress), February 2004. 275 Authors' Addresses 277 Gonzalo Camarillo 278 Ericsson 279 Hirsalantie 11 280 Jorvas 02420 281 Finland 283 EMail: Gonzalo.Camarillo@ericsson.com 285 Adam Roach 286 dynamicsoft 287 5100 Tennyson Pkwy 288 Suite 1200 289 Plano, TX 75024 290 US 292 EMail: adam@dynamicsoft.com 294 Intellectual Property Statement 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the IETF's procedures with respect to rights in IETF Documents can 303 be found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Disclaimer of Validity 320 This document and the information contained herein are provided on an 321 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 322 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 323 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 324 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 325 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 326 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 328 Copyright Statement 330 Copyright (C) The Internet Society (2004). This document is subject 331 to the rights, licenses and restrictions contained in BCP 78, and 332 except as set forth therein, the authors retain all their rights. 334 Acknowledgment 336 Funding for the RFC Editor function is currently provided by the 337 Internet Society.