idnits 2.17.1 draft-ietf-sip-multiple-refer-01.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 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 588. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 595. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 601. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages 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 (January 8, 2007) is 6312 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) -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 458 == 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-03 == Outdated reference: A later version (-15) exists of draft-ietf-sip-gruu-11 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 8 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: July 12, 2007 M. Isomaki 6 M. Garcia-Martin 7 Nokia 8 H. Khartabil 9 Khartabil Internet Telephony 10 Consulting 11 January 8, 2007 13 Referring to Multiple Resources in the Session Initiation Protocol (SIP) 14 draft-ietf-sip-multiple-refer-01.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 July 12, 2007. 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 servers to multiple resources. These 49 extensions include the use of pointers to Uniform Resource Identifier 50 (URI)-lists in the Refer-To header field and the "multiple-refer" SIP 51 option-tag. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 3 58 4. The multiple-refer SIP Option-Tag . . . . . . . . . . . . . . 4 59 5. Suppressing REFER's Implicit Subscription . . . . . . . . . . 4 60 6. URI-List Format . . . . . . . . . . . . . . . . . . . . . . . 5 61 7. Behavior of SIP REFER-Issuers . . . . . . . . . . . . . . . . 7 62 8. Behavior of REFER-Recipients . . . . . . . . . . . . . . . . . 7 63 9. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 66 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 68 12.2. Informative References . . . . . . . . . . . . . . . . . 12 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 70 Intellectual Property and Copyright Statements . . . . . . . . . . 15 72 1. Introduction 74 RFC 3261 (SIP) [5] is extended by RFC 3515 [7] with a REFER method 75 that allows a user agent to request a server to send a request to a 76 third party. Still, a number of applications need to request a 77 server to initiate transactions towards a set of destinations. In 78 one example, the moderator of a conference may want the conference 79 server to send BYE requests to a group of participants. In another 80 example, the same moderator may want the conference server to INVITE 81 a set of new participants. 83 We define an extension to the REFER method so that REFER request can 84 be used to refer servers to multiple destinations. In addition, this 85 mechanism uses the suppression of the REFER method implicit 86 subscription specified in RFC 4488 [8] to suppress REFER's implicit 87 subscription. 89 2. Terminology 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in BCP 14, RFC 2119 [1] 94 and indicate requirement levels for compliant 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 [7] that allows a SIP User Agent Client (UAC) to include 109 a URI-list as specified in the XML Format for Representing Resource 110 Lists [9] of REFER-Targets in a REFER request and send it to a 111 server. The server will create a new request for each entry in the 112 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 [11] to allow the sender indicate the role (e.g., 'to', 'cc', 117 or anonymous) in which the REFER-Target is involved in the 118 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 [9]. 122 A UAC (User Agent Client) that wants to refer a server to a set of 123 destinations creates a SIP REFER request. The Refer-To header 124 contains a pointer to a URI-list, which is included in a body part, 125 and an option-tag in the Require header field: "multiple-refer". 126 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) [12]. 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 [7], NOTIFY requests 160 sent as a result of an implicit subscription created by a REFER 161 request contain a body of type "message/sipfrag", RFC 3420 [6], that 162 describes the status of the transaction initiated by the REFER- 163 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 [8]. 186 RFC 4488 [8] indicates that a condition for the REFER-Issuer to 187 include a Refer-Sub header is that the REFER-Issuer is sure that 188 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 [10], specifications of individual URI-list 202 services, need to specify a default format for 'recipient-list' 203 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 [9] extended with the XML Format Extension for 208 Representing Copy Control Attributes in Resource Lists [11]. REFER- 209 Recipients handling 'recipient-list' bodies MUST support both of 210 these formats and MAY support other formats. 212 As described in the XML Format Extension for Representing Copy 213 Control Attributes in Resource Lists [11], each URI can be tagged 214 with a 'copyControl' attribute set to either "to", "cc", or "bcc", 215 indicating the role in which the recipient will get the referred SIP 216 request. However, depending on the target SIP method, a 217 'copyControl' attribute lacks sense. For example, while a 218 'copyControl' attribute can be applied to INVITE requests, it does 219 not make sense with mid-dialog requests such as BYE requests. 221 In addition to the 'copyControl' attribute, URIs can be tagged with 222 the 'anonymize' attribute, also specified in the XML Format Extension 223 for Representing Copy Control Attributes in Resource Lists [11] to 224 prevent that the server discloses the target URI in a URI-list. 226 Additionally, the XML Format Extension for Representing Copy Control 227 Attributes in Resource Lists [11] defines a 'recipient-list-history' 228 body that contains the list of recipients. The default format for 229 'recipient-list-history' bodies for conference services is also the 230 XML Formats for Representing Resource Lists [9] extended with the XML 231 Format Extension for Representing Copy Control Attributes in Resource 232 Lists [11]. Conferencing servers supporting this specification MUST 233 support both of these formats; UASes MAY support these formats. Both 234 conferencing servers and UASes MAY support other formats. 236 Nevertheless, the XML Format for Representing Resource Lists [9] 237 document provides features, such as hierarchical lists and the 238 ability to include entries by reference relative to the XCAP root 239 URI, that are not needed by the multiple REFER service defined in 240 this document. 242 Figure 1 shows an example of a flat list that follows the resource 243 list document. 245 246 249 250 251 252 253 254 256 Figure 1: URI List 258 7. Behavior of SIP REFER-Issuers 260 As indicated in Section 4 and Section 5 a SIP REFER-Issuer that 261 creates a REFER request with multiple REFER-Targets includes a 262 "multiple-refer" and "norefersub" option-tags in the Require header 263 field and, if appropriate, a Refer-Sub header field set to "false". 264 The REFER-Issuer includes the set of REFER-Targets in a recipient- 265 list body whose disposition type is 'recipient-list', as defined in 266 the Framework and Security Considerations for SIP URI-List Services 267 [10]. The URI-list body is further described in Section 6. 269 The Refer-To header field of a REFER request with multiple REFER- 270 Targets MUST contain a pointer (i.e., a Content-ID Uniform Resource 271 Locator (URL) as per RFC 2392 [3]) that points to the body part that 272 carries the URI-list. The REFER-Issuer SHOULD NOT include any 273 particular URI more than once in the URI-list. 275 The XML Format for Representing Resource Lists [9] document provides 276 features, such as hierarchical lists and the ability to include 277 entries by reference relative to the XCAP root URI. However, these 278 features are not needed by the multiple REFER service defined in this 279 document. Therefore, when using the default resource list document, 280 SIP REFER-Issuers generating REFER requests with multiple REFER- 281 Targets SHOULD use flat lists (i.e., no hierarchical lists) and 282 SHOULD NOT use elements. 284 8. Behavior of REFER-Recipients 286 The REFER-Recipient follows the rules in Section 2.4.2 of RFC 3515 287 [7] to determine the status code of the response to the REFER. 289 The REFER-Recipient SHOULD not create an implicit subscription, and 290 SHOULD add a Refer-Sub header field set to "false" in the 200 OK 291 response. 293 If the URI-list of the REFER request contains a repeated URI, the 294 REFER-Recipient MUST behave as if that URI appeared in the URI-list 295 only once. The REFER-Recipient uses the comparison rules specific to 296 the URI scheme of each of the URIs in the URI-list to determine if 297 there is any URI which appears more than once. 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 [9] and the XML Format Extension for Representing Copy Control 307 Attributes in Resource Lists [11]. The URI-list server MUST follow 308 the procedures specified in XML Format for Representing Resource 309 Lists [9] with respect handling of the 'anonymize', 'count' and 310 'copyControl' attributes. 312 If the server includes a URI-list in an outgoing request, it MUST 313 include a Content-Disposition header field, specified in RFC 2183 314 [2], with the value set to 'recipient-list-history' and a 'handling' 315 parameter, specified in RFC 3204 [4], set to "optional". 317 Since the multiple REFER service does not use hierarchical lists nor 318 lists that include entries by reference to the XCAP root URI, a 319 REFER-Recipient receiving a URI-list with more information than what 320 has been described in Section 6 MAY discard all the extra 321 information. 323 The REFER-Recipient follows the rules in RFC 3515 [7] to generate the 324 necessary requests towards the REFER-Targets, acting as if it had 325 received a regular (no URI-list) REFER per each URI in the URI-list. 327 9. Example 329 Figure 2 shows an example flow where a REFER-Issuer sends a multiple- 330 REFER request to the focus of a conference, which acts as the REFER- 331 Recipient. The REFER-Recipient generates a BYE request per REFER- 332 Target. Details for using REFER request to remove participants from 333 a conference are specified in RFC 4579 [13]. 335 +--------+ +---------+ +--------+ +--------+ +--------+ 336 | REFER | | REFER | | REFER | | REFER | | REFER | 337 | issuer | |recipient| |target 1| |target 2| |target 3| 338 +--------+ +---------+ +--------+ +--------+ +--------+ 339 | 1. REFER | | | | 340 | ---------------->| | | | 341 | 2. 202 Accepted | | | | 342 |<---------------- | 3. BYE | | | 343 | | ----------->| | | 344 | | 4. BYE | | | 345 | | ----------------------->| | 346 | | 5. BYE | | | 347 | | ----------------------------------->| 348 | | 6. 200 OK | | | 349 | |<----------- | | | 350 | | 7. 200 OK | | | 351 | |<----------------------- | | 352 | | 8. 200K OK| | | 353 | |<----------------------------------- | 354 | | | | | 355 | | | | | 356 | | | | | 358 Figure 2: Example flow or a REFER request containin multiple REFER- 359 Targets 361 The REFER request (1) contains a Refer-To header field that includes 362 a pointer to the message body, which carries a list with the URIs of 363 the REFER-Targets. In this example, the URI-list does not contain 364 the copyControl attribute extension. The REFER's Require header 365 field carries the "multiple-refer" and "norefersub" option-tags. The 366 Request-URI is set to a Globally Routable User Agent URIs (GRUU) [14] 367 (as a guarantee that the REFER request will not fork). The Refer-Sub 368 header field is set to "false" to request the suppression of the 369 implicit subscription. Figure 3 shows an example of this REFER 370 request. The resource list document contains the list of REFER- 371 Target URIs along with the method of the SIP request that the REFER- 372 Recipient generates. 374 REFER sip:conf-123@example.com;gruu;opaque=hha9s8d-999a SIP/2.0 375 Via: SIP/2.0/TCP client.chicago.example.com 376 ;branch=z9hG4bKhjhs8ass83 377 Max-Forwards: 70 378 To: "Conference 123" 379 From: Carol ;tag=32331 380 Call-ID: d432fa84b4c76e66710 381 CSeq: 2 REFER 382 Contact: 383 Refer-To: 384 Refer-Sub: false 385 Require: multiple-refer, norefersub 386 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY 387 Allow-Events: dialog 388 Accept: application/sdp, message/sipfrag 389 Content-Type: application/resource-lists+xml 390 Content-Disposition: recipient-list 391 Content-Length: 362 392 Content-ID: 394 395 397 398 399 400 401 402 404 Figure 3: REFER request with multiple REFER-Targets 406 Figure 4 shows an example of the BYE request (3) that the REFER- 407 Recipient sends to the first REFER-Target. 409 BYE sip:bill@example.com SIP/2.0 410 Via: SIP/2.0/TCP conference.example.com 411 ;branch=z9hG4bKhjhs8assmm 412 Max-Forwards: 70 413 From: "Conference 123" ;tag=88734 414 To: ;tag=29872 415 Call-ID: d432fa84b4c34098s812 416 CSeq: 34 BYE 417 Content-Length: 0 419 Figure 4: BYE request 421 10. Security Considerations 423 The Framework and Security Considerations for SIP URI-List Services 424 [10] discusses issues related to SIP URI-list services. Given that a 425 REFER-Recipient accepting REFER requests with multiple REFER-targets 426 acts as an URI-list service, implementations of this type of server 427 MUST follow the security-related rules in the Framework and Security 428 Considerations for SIP URI-List Services [10]. These rules include 429 mandatory authentication and authorization of clients, and opt-in 430 lists. 432 Additionally, REFER-Recipients SHOULD only accept REFER requests 433 within the context of an application the server understands (e.g., a 434 conferencing application). This implies that servers MUST NOT accept 435 REFER requests for methods they do not understand. The idea behind 436 these two rules is that servers are not used as dumb servers whose 437 only function is to fan-out random messages they do not understand. 439 11. IANA Considerations 441 This document defines a new SIP option-tag: "multiple-refer". This 442 option-tag should be registered in the SIP Parameters registry. 444 The following row shall be added to the "Option Tags" section of the 445 SIP Parameter Registry: 447 +-----------------+-------------------------------------+-----------+ 448 | Name | Description | Reference | 449 +-----------------+-------------------------------------+-----------+ 450 | multiple-refer | This option tag indicates support | [RFCXXXX] | 451 | | for REFER requests that contain a | | 452 | | resource list document describing | | 453 | | multiple REFER targets. | | 454 +-----------------+-------------------------------------+-----------+ 456 Table 1: Registration of the 'multiple-refer' Option-Tag in SIP 458 Note to the RFC Editor: Please replace [RFCXXXX] with the RFC number 459 of this specification. 461 12. References 463 12.1. Normative References 465 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 466 Levels", BCP 14, RFC 2119, March 1997. 468 [2] Troost, R., Dorner, S., and K. Moore, "Communicating 469 Presentation Information in Internet Messages: The Content- 470 Disposition Header Field", RFC 2183, August 1997. 472 [3] Levinson, E., "Content-ID and Message-ID Uniform Resource 473 Locators", RFC 2392, August 1998. 475 [4] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., 476 Watson, M., and M. Zonoun, "MIME media types for ISUP and QSIG 477 Objects", RFC 3204, December 2001. 479 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 480 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 481 Session Initiation Protocol", RFC 3261, June 2002. 483 [6] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 484 November 2002. 486 [7] Sparks, R., "The Session Initiation Protocol (SIP) Refer 487 Method", RFC 3515, April 2003. 489 [8] Levin, O., "Suppression of Session Initiation Protocol (SIP) 490 REFER Method Implicit Subscription", RFC 4488, May 2006. 492 [9] Rosenberg, J., "Extensible Markup Language (XML) Formats for 493 Representing Resource Lists", 494 draft-ietf-simple-xcap-list-usage-05 (work in progress), 495 February 2005. 497 [10] Camarillo, G. and A. Roach, "Framework and Security 498 Considerations for Session Initiation Protocol (SIP) Uniform 499 Resource Identifier (URI)-List Services", 500 draft-ietf-sipping-uri-services-06 (work in progress), 501 September 2006. 503 [11] Garcia-Martin, M. and G. Camarillo, "Extensible Markup Language 504 (XML) Format Extension for Representing Copy Control 505 Attributes in Resource Lists", 506 draft-ietf-sipping-capacity-attribute-03 (work in progress), 507 December 2006. 509 12.2. Informative References 511 [12] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session 512 Initiation Protocol (SIP) Event Package for Conference State", 513 RFC 4575, August 2006. 515 [13] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) 516 Call Control - Conferencing for User Agents", BCP 119, 517 RFC 4579, August 2006. 519 [14] Rosenberg, J., "Obtaining and Using Globally Routable User 520 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 521 (SIP)", draft-ietf-sip-gruu-11 (work in progress), 522 October 2006. 524 Authors' Addresses 526 Gonzalo Camarillo 527 Ericsson 528 Hirsalantie 11 529 Jorvas 02420 530 Finland 532 Email: Gonzalo.Camarillo@ericsson.com 534 Aki Niemi 535 Nokia 536 P.O. Box 321 537 NOKIA GROUP, FIN 00045 538 Finland 540 Email: Aki.Niemi@nokia.com 542 Markus Isomaki 543 Nokia 544 Itamerenkatu 11-13 545 Helsinki 00180 546 Finland 548 Email: Markus.Isomaki@nokia.com 550 Miguel A. Garcia-Martin 551 Nokia 552 P.O.Box 407 553 NOKIA GROUP, FIN 00045 554 Finland 556 Email: miguel.an.garcia@nokia.com 557 Hisham Khartabil 558 Khartabil Internet Telephony Consulting 560 Phone: +61 416 108 890 561 Email: hisham.khartabil@gmail.com 563 Full Copyright Statement 565 Copyright (C) The IETF Trust (2007). 567 This document is subject to the rights, licenses and restrictions 568 contained in BCP 78, and except as set forth therein, the authors 569 retain all their rights. 571 This document and the information contained herein are provided on an 572 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 573 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 574 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 575 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 576 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 577 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 Intellectual Property 581 The IETF takes no position regarding the validity or scope of any 582 Intellectual Property Rights or other rights that might be claimed to 583 pertain to the implementation or use of the technology described in 584 this document or the extent to which any license under such rights 585 might or might not be available; nor does it represent that it has 586 made any independent effort to identify any such rights. Information 587 on the procedures with respect to rights in RFC documents can be 588 found in BCP 78 and BCP 79. 590 Copies of IPR disclosures made to the IETF Secretariat and any 591 assurances of licenses to be made available, or the result of an 592 attempt made to obtain a general license or permission for the use of 593 such proprietary rights by implementers or users of this 594 specification can be obtained from the IETF on-line IPR repository at 595 http://www.ietf.org/ipr. 597 The IETF invites any interested party to bring to its attention any 598 copyrights, patents or patent applications, or other proprietary 599 rights that may cover technology that may be required to implement 600 this standard. Please address the information to the IETF at 601 ietf-ipr@ietf.org. 603 Acknowledgment 605 Funding for the RFC Editor function is provided by the IETF 606 Administrative Support Activity (IASA).