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