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.