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).