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