idnits 2.17.1
draft-ietf-sip-multiple-refer-03.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.1 on line 21.
-- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on
line 612.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 623.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 630.
-- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 636.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
No issues found here.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust Copyright Line does not match the
current year
== Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please
use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
mean).
Found 'SHOULD not' in this paragraph:
The REFER-Recipient SHOULD not create an implicit subscription, and
SHOULD add a Refer-Sub header field set to "false" in the 200 OK response.
-- 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 (December 18, 2007) is 5967 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)
== Missing Reference: 'RFCXXXX' is mentioned on line 491, but not defined
== Outdated reference: A later version (-07) exists of
draft-ietf-sipping-capacity-attribute-05
Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 7 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 SIP Working Group G. Camarillo
3 Internet-Draft Ericsson
4 Intended status: Standards Track A. Niemi
5 Expires: June 20, 2008 M. Isomaki
6 Nokia
7 M. Garcia-Martin
8 Nokia Siemens Networks
9 H. Khartabil
10 Ericsson Australia
11 December 18, 2007
13 Referring to Multiple Resources in the Session Initiation Protocol (SIP)
14 draft-ietf-sip-multiple-refer-03.txt
16 Status of this Memo
18 By submitting this Internet-Draft, each author represents that any
19 applicable patent or other IPR claims of which he or she is aware
20 have been or will be disclosed, and any of which he or she becomes
21 aware will be disclosed, in accordance with Section 6 of BCP 79.
23 Internet-Drafts are working documents of the Internet Engineering
24 Task Force (IETF), its areas, and its working groups. Note that
25 other groups may also distribute working documents as Internet-
26 Drafts.
28 Internet-Drafts are draft documents valid for a maximum of six months
29 and may be updated, replaced, or obsoleted by other documents at any
30 time. It is inappropriate to use Internet-Drafts as reference
31 material or to cite them other than as "work in progress."
33 The list of current Internet-Drafts can be accessed at
34 http://www.ietf.org/ietf/1id-abstracts.txt.
36 The list of Internet-Draft Shadow Directories can be accessed at
37 http://www.ietf.org/shadow.html.
39 This Internet-Draft will expire on June 20, 2008.
41 Copyright Notice
43 Copyright (C) The IETF Trust (2007).
45 Abstract
47 This document defines extensions to the SIP REFER method so that this
48 method can be used to refer to multiple resources in a single
49 request. These extensions include the use of pointers to Uniform
50 Resource Identifier (URI)-lists in the Refer-To header field and the
51 "multiple-refer" SIP option-tag.
53 Table of Contents
55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
57 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4
58 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 5
59 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 5
60 6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 6
61 7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 7
62 8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 8
63 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
67 12.1. Normative References . . . . . . . . . . . . . . . . . . 12
68 12.2. Informative References . . . . . . . . . . . . . . . . . 13
69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
70 Intellectual Property and Copyright Statements . . . . . . . . . . 15
72 1. Introduction
74 RFC 3261 (SIP) [RFC3261] is extended by RFC 3515 [RFC3515] with a
75 REFER method that allows a user agent to request a second user agent
76 to send a SIP request to a third party. Still, a number of
77 applications need to request this second user agent to initiate
78 transactions towards a set of destinations. In one example, the
79 moderator of a conference may want the conference server to send BYE
80 requests to a group of participants. In another example, the same
81 moderator may want the conference server to INVITE a set of new
82 participants.
84 We define an extension to the REFER method so that REFER requests can
85 be used to refer other user agents (such as conference servers) to
86 multiple destinations. In addition, this mechanism uses the
87 suppression of the REFER method implicit subscription specified in
88 RFC 4488 [RFC4488] to suppress REFER's implicit subscription.
90 2. Terminology
92 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
93 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
94 document are to be interpreted as described in BCP 14, RFC 2119
95 [RFC2119] and indicate requirement levels for compliant
96 implementations.
98 This document reuses the following terminology defined in RFC 3261
99 [RFC3261]:
101 o User Agent (UA)
102 o User Agent Client (UAC)
103 o User Agent Server (UAS)
105 This document defines the following new terms:
107 REFER-Issuer: a user agent issuing a REFER request.
108 REFER-Recipient: an entity receiving a REFER request and forwarding
109 a SIP request to a number of REFER-Targets. The REFER-Recipient
110 is typically a network entity, such as a URI-List server, that
111 acts as a UAS for REFER requests and as a UAC for other SIP
112 requests.
113 REFER-Target: a UA of the intended final recipient of a SIP request
114 generated by the REFER-Recipient.
116 3. Overview of operation
118 This document describes an application of URI-List services
119 [I-D.ietf-sipping-uri-services] that allows a URI-List service to
120 receive a SIP REFER request containing a list of targets. The URI-
121 List service invokes the requested SIP method to each of the targets
122 contained in the list. This type of URI-List service is referred to
123 as a REFER-Recipient throughout this document.
125 This document defines an extension to the SIP REFER method specified
126 in RFC 3515 [RFC3515] that allows a SIP UAC to include a URI-list as
127 specified in the XML Format for Representing Resource Lists [RFC4826]
128 of REFER-Targets in a REFER request and send it to a REFER-Recipient.
129 The REFER-Recipient creates a new SIP request for each entry in the
130 URI-list and sends it to each REFER-Recipient.
132 The URI-list that contains the list of targets is used in conjunction
133 with the XML Format Extension for Representing Copy Control
134 Attributes in Resource Lists [I-D.ietf-sipping-capacity-attribute] to
135 allow the sender indicate the role (e.g., 'to', 'cc', or anonymous)
136 in which the REFER-Target is involved in the signalling.
138 We represent multiple targets of a REFER request using a URI-list as
139 specified in the XML Format for Representing Resource Lists
140 [RFC4826]. A REFER-Issuer that wants to refer a REFER-Recipient to a
141 set of destinations creates a SIP REFER request. The Refer-To header
142 contains a pointer to a URI-list, which is included in a body part,
143 and an option-tag in the Require header field: "multiple-refer".
144 This option-tag indicates the requirement to support the
145 functionality described in this specification.
147 When the REFER-Recipient receives such request it creates a new
148 request per REFER-Target and sends them, one to each REFER-Target.
150 This document does not provide any mechanism for REFER-Issuers to
151 find out about the results of a REFER request containing multiple
152 REFER-Targets. Furthermore, it does not provide support for the
153 implicit subscription mechanism that is part of the SIP REFER method.
154 The way REFER-Issuers are kept informed about the results of a REFER
155 is service specific. For example, a REFER-Issuer sending a REFER
156 request to invite a set of participants to a conference can discover
157 which participants were successfully brought into the conference by
158 subscribing to the conference state event package specified in RFC
159 4575 [RFC4575].
161 4. The multiple-refer SIP Option-Tag
163 We define a new SIP option-tag for the Require and Supported header
164 fields: "multiple-refer".
166 A user agent including the "multiple-refer" option-tag in a Supported
167 header field indicates compliance with this specification.
169 A user agent generating a REFER with a pointer to a URI-list in its
170 Refer-To header field MUST include the "multiple-refer" option-tag in
171 the Require header field of the REFER.
173 5. Suppressing REFER's Implicit Subscription
175 REFER requests with a single REFER-Target establish implicitly a
176 subscription to the refer event. The REFER-Issuer is informed about
177 the result of the transaction towards the REFER-Target through this
178 implicit subscription. As described in RFC 3515 [RFC3515], NOTIFY
179 requests sent as a result of an implicit subscription created by a
180 REFER request contain a body of type "message/sipfrag", RFC 3420
181 [RFC3420], that describes the status of the transaction initiated by
182 the REFER-Recipient.
184 In the case of a REFER-Issuer that generates a REFER with multiple
185 REFER-targets, the REFER-Issuer is typically already subscribed to
186 other event package that can provide the information about the result
187 of the transactions towards the REFER-Targets. For example, a
188 moderator instructing a conference server to send a BYE request to a
189 set of participants is usually subscribed to the conference state
190 event package for the conference. Notifications to this event
191 package will keep the moderator and the rest of the subscribers
192 informed of the current list of conference participants.
194 Most of the applications using multiple REFER do not need its
195 implicit subscription. Consequently, a SIP REFER-Issuer generating a
196 REFER request with multiple REFER-Targets SHOULD include the
197 "norefersub" option-tag in a Require header field and SHOULD include
198 a Refer-Sub header field set to "false" to indicate that no
199 notifications about the requests should be sent to the REFER-Issuer.
200 The REFER-Recipient SHOULD honor the suggestion and also include a
201 Refer-Sub header field set to "false" in the 200 (OK) response. The
202 "norefersub" SIP option-tag and the Refer-Sub header field are
203 specified in RFC 4488 [RFC4488].
205 RFC 4488 [RFC4488] indicates that a condition for the REFER-Issuer
206 to include a Refer-Sub header is that the REFER-Issuer is sure
207 that the REFER request will not fork.
209 At the time of writing, there is no extension that allows to report
210 the status of several transactions over the implicit subscription
211 associated with a REFER dialog. That is the motivation for this
212 document to recommend the usage of the "norefersub" option-tag. If
213 in the future such an extension is defined, REFER-Issuers using it
214 could refrain from using the "norefersub" option-tag and use the new
215 extension instead.
217 6. URI-List Format
219 As described in the Framework and Security Considerations for SIP
220 URI-List Services [I-D.ietf-sipping-uri-services], specifications of
221 individual URI-list services need to specify a default format for
222 'recipient-list' bodies used within the particular service.
224 The default format for 'recipient-list' bodies for REFER-Issuers and
225 REFER-Recipients is the XML Formats for Representing Resource Lists
226 [RFC4826] extended with the XML Format Extension for Representing
227 Copy Control Attributes in Resource Lists
228 [I-D.ietf-sipping-capacity-attribute]. REFER-Recipients handling
229 'recipient-list' bodies MUST support both of these formats. Both
230 REFER-Issuers and REFER-Recipients MAY support other formats.
232 As described in the XML Format Extension for Representing Copy
233 Control Attributes in Resource Lists
234 [I-D.ietf-sipping-capacity-attribute], each URI can be tagged with a
235 'copyControl' attribute set to either "to", "cc", or "bcc",
236 indicating the role in which the target will get the referred SIP
237 request. However, depending on the target SIP method, a
238 'copyControl' attribute lacks sense. For example, while a
239 'copyControl' attribute can be applied to INVITE requests, it does
240 not make sense with mid-dialog requests such as BYE requests.
242 In addition to the 'copyControl' attribute, URIs can be tagged with
243 the 'anonymize' attribute, also specified in the XML Format Extension
244 for Representing Copy Control Attributes in Resource Lists
245 [I-D.ietf-sipping-capacity-attribute] to prevent that the REFER-
246 Recipient discloses the target URI in a URI-list.
248 Additionally, the XML Format Extension for Representing Copy Control
249 Attributes in Resource Lists [I-D.ietf-sipping-capacity-attribute]
250 defines a 'recipient-list-history' body that contains the list of
251 targets. The default format for 'recipient-list-history' bodies for
252 conference services is also the XML Formats for Representing Resource
253 Lists [RFC4826] extended with the XML Format Extension for
254 Representing Copy Control Attributes in Resource Lists
255 [I-D.ietf-sipping-capacity-attribute]. REFER-Recipients supporting
256 this specification MUST support both of these formats; REFER-Targets
257 MAY support these formats. Both REFER-Recipients and REFER-Targets
258 MAY support other formats.
260 Nevertheless, the XML Format for Representing Resource Lists
261 [RFC4826] document provides features, such as hierarchical lists and
262 the ability to include entries by reference relative to the XCAP root
263 URI, that are not needed by the multiple REFER service defined in
264 this document.
266 Figure 1 shows an example of a flat list that follows the resource
267 list document.
269
270
273
274
275
276
277
278
280 Figure 1: URI List
282 7. Behavior of SIP REFER-Issuers
284 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that
285 creates a REFER request with multiple REFER-Targets includes a
286 "multiple-refer" and "norefersub" option-tags in the Require header
287 field and, if appropriate, a Refer-Sub header field set to "false".
288 The REFER-Issuer includes the set of REFER-Targets in a recipient-
289 list body whose disposition type is 'recipient-list', as defined in
290 the Framework and Security Considerations for SIP URI-List Services
291 [I-D.ietf-sipping-uri-services]. The URI-list body is further
292 described in Section 6.
294 The Refer-To header field of a REFER request with multiple REFER-
295 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource
296 Locator (URL) as per RFC 2392 [RFC2392]) that points to the body part
297 that carries the URI-list. The REFER-Issuer SHOULD NOT include any
298 particular URI more than once in the URI-list.
300 The XML Format for Representing Resource Lists [RFC4826] document
301 provides features, such as hierarchical lists and the ability to
302 include entries by reference relative to the XCAP root URI. However,
303 these features are not needed by the multiple REFER service defined
304 in this document. Therefore, when using the default resource list
305 document, SIP REFER-Issuers generating REFER requests with multiple
306 REFER-Targets SHOULD use flat lists (i.e., no hierarchical lists) and
307 SHOULD NOT use elements.
309 8. Behavior of REFER-Recipients
311 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515
312 [RFC3515] to determine the status code of the response to the REFER.
314 The REFER-Recipient SHOULD not create an implicit subscription, and
315 SHOULD add a Refer-Sub header field set to "false" in the 200 OK
316 response.
318 The incoming REFER request typically contains a URI-list document or
319 reference with the actual list of targets. If this URI-list includes
320 resources tagged with the 'copyControl' attribute set to a value of
321 "to" or "cc", and if appropriate for the service, e.g., if it is non-
322 mid dialog request, the REFER-Recipient SHOULD include a URI-list in
323 each of the outgoing requests. This list SHOULD be formatted
324 according to the XML Format for Representing Resource Lists [RFC4826]
325 and the XML Format Extension for Representing Copy Control Attributes
326 in Resource Lists [I-D.ietf-sipping-capacity-attribute]. The REFER-
327 Recipient MUST follow the procedures specified in XML Format for
328 Representing Resource Lists [RFC4826] with respect handling of the
329 'anonymize', 'count' and 'copyControl' attributes.
331 Section 4 of the Framework and Security Considerations for SIP URI-
332 List Services [I-D.ietf-sipping-uri-services] discusses cases when
333 duplicated URIs are found in a URI-list. In order to avoid
334 duplicated requests, REFER-Recipients MUST take those actions
335 specified in Framework and Security Considerations for SIP URI-List
336 Services [I-D.ietf-sipping-uri-services] into account to avoid
337 sending duplicated request to the same target.
339 If the REFER-Recipient includes a URI-list in an outgoing request, it
340 MUST include a Content-Disposition header field, specified in RFC
341 2183 [RFC2183], with the value set to 'recipient-list-history' and a
342 'handling' parameter, specified in RFC 3204 [RFC3204], set to
343 "optional".
345 Since the multiple REFER service does not use hierarchical lists nor
346 lists that include entries by reference to the XCAP root URI, a
347 REFER-Recipient receiving a URI-list with more information than what
348 has been described in Section 6 MAY discard all the extra
349 information.
351 The REFER-Recipient follows the rules in RFC 3515 [RFC3515] to
352 generate the necessary requests towards the REFER-Targets, acting as
353 if it had received a regular (no URI-list) REFER per each URI in the
354 URI-list.
356 9. Example
358 Figure 2 shows an example flow where a REFER-Issuer sends a multiple-
359 REFER request to the focus of a conference, which acts as the REFER-
360 Recipient. The REFER-Recipient generates a BYE request per REFER-
361 Target. Details for using REFER request to remove participants from
362 a conference are specified in RFC 4579 [RFC4579].
364 +--------+ +---------+ +--------+ +--------+ +--------+
365 | REFER | | REFER | | REFER | | REFER | | REFER |
366 | issuer | |recipient| |target 1| |target 2| |target 3|
367 | | | | | | | | | |
368 | Carol | | (focus) | | Bill | | Joe | | Ted |
369 +--------+ +---------+ +--------+ +--------+ +--------+
370 | 1. REFER | | | |
371 | ---------------->| | | |
372 | 2. 202 Accepted | | | |
373 |<---------------- | 3. BYE | | |
374 | | ----------->| | |
375 | | 4. BYE | | |
376 | | ----------------------->| |
377 | | 5. BYE | | |
378 | | ----------------------------------->|
379 | | 6. 200 OK | | |
380 | |<----------- | | |
381 | | 7. 200 OK | | |
382 | |<----------------------- | |
383 | | 8. 200 OK | | |
384 | |<----------------------------------- |
385 | | | | |
386 | | | | |
387 | | | | |
389 Figure 2: Example flow of a REFER request containing multiple REFER-
390 Targets
392 The REFER request (1) contains a Refer-To header field that includes
393 a pointer to the message body, which carries a list with the URIs of
394 the REFER-Targets. In this example, the URI-list does not contain
395 the copyControl attribute extension. The REFER's Require header
396 field carries the "multiple-refer" and "norefersub" option-tags. The
397 Request-URI is set to a Globally Routable User Agent URIs (GRUU)
398 [I-D.ietf-sip-gruu] (as a guarantee that the REFER request will not
399 fork). The Refer-Sub header field is set to "false" to request the
400 suppression of the implicit subscription. Figure 3 shows an example
401 of this REFER request. The resource list document contains the list
402 of REFER-Target URIs along with the method of the SIP request that
403 the REFER-Recipient generates.
405 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0
406 Via: SIP/2.0/TCP client.chicago.example.com
407 ;branch=z9hG4bKhjhs8ass83
408 Max-Forwards: 70
409 To: "Conference 123"
410 From: Carol ;tag=32331
411 Call-ID: d432fa84b4c76e66710
412 CSeq: 2 REFER
413 Contact:
414 Refer-To:
415 Refer-Sub: false
416 Require: multiple-refer, norefersub
417 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
418 Allow-Events: dialog
419 Accept: application/sdp, message/sipfrag
420 Content-Type: application/resource-lists+xml
421 Content-Disposition: recipient-list
422 Content-Length: 362
423 Content-ID:
425
426
428
429
430
431
432
433
435 Figure 3: REFER request with multiple REFER-Targets
437 Figure 4 shows an example of the BYE request (3) that the REFER-
438 Recipient sends to the first REFER-Target.
440 BYE sip:bill@example.com SIP/2.0
441 Via: SIP/2.0/TCP conference.example.com
442 ;branch=z9hG4bKhjhs8assmm
443 Max-Forwards: 70
444 From: "Conference 123" ;tag=88734
445 To: ;tag=29872
446 Call-ID: d432fa84b4c34098s812
447 CSeq: 34 BYE
448 Content-Length: 0
450 Figure 4: BYE request
452 10. Security Considerations
454 The Framework and Security Considerations for SIP URI-List Services
455 [I-D.ietf-sipping-uri-services] document discusses issues related to
456 SIP URI-list services. Given that a REFER-Recipient accepting REFER
457 requests with multiple REFER-targets acts as a URI-list service,
458 implementations of this type of server MUST follow the security-
459 related rules in the Framework and Security Considerations for SIP
460 URI-List Services [I-D.ietf-sipping-uri-services]. These rules
461 include mandatory authentication and authorization of clients, and
462 opt-in lists.
464 Additionally, REFER-Recipients SHOULD only accept REFER requests
465 within the context of an application that the REFER-Recipient
466 understands (e.g., a conferencing application). This implies that
467 REFER-Recipients MUST NOT accept REFER requests for methods they do
468 not understand. The idea behind these two rules is that REFER-
469 Recipients are not used as dumb servers whose only function is to
470 fan-out random messages they do not understand.
472 11. IANA Considerations
474 This document defines a new SIP option-tag: "multiple-refer". This
475 option-tag should be registered in the SIP Parameters registry.
477 The following row shall be added to the "Option Tags" section of the
478 SIP Parameter Registry:
480 +-----------------+-------------------------------------+-----------+
481 | Name | Description | Reference |
482 +-----------------+-------------------------------------+-----------+
483 | multiple-refer | This option tag indicates support | [RFCXXXX] |
484 | | for REFER requests that contain a | |
485 | | resource list document describing | |
486 | | multiple REFER targets. | |
487 +-----------------+-------------------------------------+-----------+
489 Table 1: Registration of the 'multiple-refer' Option-Tag in SIP
491 Note to the RFC Editor: Please replace [RFCXXXX] with the RFC number
492 of this specification.
494 12. References
496 12.1. Normative References
498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
499 Requirement Levels", BCP 14, RFC 2119, March 1997.
501 [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating
502 Presentation Information in Internet Messages: The
503 Content-Disposition Header Field", RFC 2183, August 1997.
505 [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
506 Locators", RFC 2392, August 1998.
508 [RFC3204] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet,
509 F., Watson, M., and M. Zonoun, "MIME media types for ISUP
510 and QSIG Objects", RFC 3204, December 2001.
512 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
513 A., Peterson, J., Sparks, R., Handley, M., and E.
514 Schooler, "SIP: Session Initiation Protocol", RFC 3261,
515 June 2002.
517 [RFC3420] Sparks, R., "Internet Media Type message/sipfrag",
518 RFC 3420, November 2002.
520 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
521 Method", RFC 3515, April 2003.
523 [RFC4488] Levin, O., "Suppression of Session Initiation Protocol
524 (SIP) REFER Method Implicit Subscription", RFC 4488,
525 May 2006.
527 [RFC4826] Rosenberg, J., "Extensible Markup Language (XML) Formats
528 for Representing Resource Lists", RFC 4826, May 2007.
530 [I-D.ietf-sipping-uri-services]
531 Camarillo, G. and A. Roach, "Framework and Security
532 Considerations for Session Initiation Protocol (SIP)
533 Uniform Resource Identifier (URI)-List Services",
534 draft-ietf-sipping-uri-services-07 (work in progress),
535 November 2007.
537 [I-D.ietf-sipping-capacity-attribute]
538 Garcia-Martin, M. and G. Camarillo, "Extensible Markup
539 Language (XML) Format Extension for Representing Copy
540 Control Attributes in Resource Lists",
541 draft-ietf-sipping-capacity-attribute-05 (work in
542 progress), November 2007.
544 12.2. Informative References
546 [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
547 Initiation Protocol (SIP) Event Package for Conference
548 State", RFC 4575, August 2006.
550 [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol
551 (SIP) Call Control - Conferencing for User Agents",
552 BCP 119, RFC 4579, August 2006.
554 [I-D.ietf-sip-gruu]
555 Rosenberg, J., "Obtaining and Using Globally Routable User
556 Agent (UA) URIs (GRUU) in the Session Initiation Protocol
557 (SIP)", draft-ietf-sip-gruu-15 (work in progress),
558 October 2007.
560 Authors' Addresses
562 Gonzalo Camarillo
563 Ericsson
564 Hirsalantie 11
565 Jorvas 02420
566 Finland
568 Email: Gonzalo.Camarillo@ericsson.com
569 Aki Niemi
570 Nokia
571 P.O. Box 321
572 NOKIA GROUP, FIN 00045
573 Finland
575 Email: Aki.Niemi@nokia.com
577 Markus Isomaki
578 Nokia
579 P.O. Box 100
580 NOKIA GROUP, FIN 00045
581 Finland
583 Email: markus.isomaki@nokia.com
585 Miguel A. Garcia-Martin
586 Nokia Siemens Networks
587 P.O.Box 6
588 Nokia Siemens Networks, FIN 02022
589 Finland
591 Email: miguel.garcia@nsn.com
593 Hisham Khartabil
594 Ericsson Australia
596 Email: hisham.khartabil@gmail.com
598 Full Copyright Statement
600 Copyright (C) The IETF Trust (2007).
602 This document is subject to the rights, licenses and restrictions
603 contained in BCP 78, and except as set forth therein, the authors
604 retain all their rights.
606 This document and the information contained herein are provided on an
607 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
608 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
609 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
610 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
611 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
612 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
614 Intellectual Property
616 The IETF takes no position regarding the validity or scope of any
617 Intellectual Property Rights or other rights that might be claimed to
618 pertain to the implementation or use of the technology described in
619 this document or the extent to which any license under such rights
620 might or might not be available; nor does it represent that it has
621 made any independent effort to identify any such rights. Information
622 on the procedures with respect to rights in RFC documents can be
623 found in BCP 78 and BCP 79.
625 Copies of IPR disclosures made to the IETF Secretariat and any
626 assurances of licenses to be made available, or the result of an
627 attempt made to obtain a general license or permission for the use of
628 such proprietary rights by implementers or users of this
629 specification can be obtained from the IETF on-line IPR repository at
630 http://www.ietf.org/ipr.
632 The IETF invites any interested party to bring to its attention any
633 copyrights, patents or patent applications, or other proprietary
634 rights that may cover technology that may be required to implement
635 this standard. Please address the information to the IETF at
636 ietf-ipr@ietf.org.
638 Acknowledgment
640 Funding for the RFC Editor function is provided by the IETF
641 Administrative Support Activity (IASA).