idnits 2.17.1 draft-rosen-xcon-conf-sidebars-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.a on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 597), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (July 16, 2004) is 7214 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) == Unused Reference: '1' is defined on line 497, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 500, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 504, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 507, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 515, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 519, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 534, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 537, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 540, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (ref. '4') (Obsoleted by RFC 6665) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-conference-package-04 == Outdated reference: A later version (-03) exists of draft-ietf-xcon-cpcp-xcap-00 -- Possible downref: Normative reference to a draft: ref. '8' == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-02 Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 XCON Working Group B. Rosen 2 Internet-Draft Marconi 3 Expires: January 14, 2005 A. Johnston 4 MCI 5 July 16, 2004 7 SIP Conferencing: Sub-conferences and Sidebars 8 draft-rosen-xcon-conf-sidebars-01 10 Status of this Memo 12 This document is an Internet-Draft and is subject to all provisions 13 of section 3 of RFC 3667. By submitting this Internet-Draft, each 14 author represents that any applicable patent or other IPR claims of 15 which he or she is aware have been or will be disclosed, and any of 16 which he or she become aware will be disclosed, in accordance with 17 RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as 22 Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at http:// 30 www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 14, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 This document discusses the creation, management of operation of 44 sub-conferences in a centralized conferencing architecture, also 45 known as "sidebars". This work uses the SIP Conferencing Framework 46 and builds on the descriptions of sub-conferences in that document. 47 Examples of SIP and XCON protocols are given. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Sidebars and Dialogs . . . . . . . . . . . . . . . . . . . . . 3 53 3. Sidebar mechanism requirements . . . . . . . . . . . . . . . . 4 54 4. Creating Sidebars . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Adding Participants to a Sidebar . . . . . . . . . . . . . . . 7 56 6. Terminating a Sidebar . . . . . . . . . . . . . . . . . . . . 10 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 58 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 59 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 60 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 12 61 9.2 Informative References . . . . . . . . . . . . . . . . . . . 13 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . 15 65 1. Introduction 67 This document uses the concepts and definitions from the SIP high 68 level conferencing requirements and the SIP conferencing framework 69 [9] documents. 71 While the SIP conferencing framework document describes both SIP and 72 XCON methods for creating and managing a centralized conference, this 73 document will assume a non-SIP method, as sidebars are an advanced 74 conferencing application. Examples of the non-SIP methods include 75 the XCON protocols (used as examples) an IVR, or a web page. 77 2. Sidebars and Dialogs 79 Conference establishment using SIP dialogs is described in the SIP 80 conferencing framework document. The set of XCON protocols to also 81 establish a conference is currently being developed and designed by 82 the XCON working group. Since the details are TBD, this document 83 will refer to the protocol as CPCP (Conference Policy Control 84 Protocol) [8] and omit the details of the messages until they are 85 developed. 87 In SIP sessions, it is not uncommon to have a single dialog with 88 multiple media sessions. The SIP Conferencing Framework assumes this 89 - that a participant uses the Conference URI to establish an INVITE 90 dialog that results in the establishment of one or more media 91 streams. Media streams established using separate dialogs are 92 usually assumed to be unrelated. For example, a pair of SIP/PSTN 93 gateways may have a number of dialogs established between them, and 94 the resulting media streams represent separate calls or sessions. 96 As a result, the simplest sidebar dialog model is to reuse the 97 existing main conference dialog to establish the sidebar. This has 98 the advantage of allowing even the simplest endpoints which are 99 incapable of any local mixing to participate in a conference with 100 sidebars, provided a non-SIP method of controlling the conference is 101 provided. 103 It is also possible for a sidebar to have a separate dialog. 104 However, the motivation and advantages for this are not obvious. As 105 a result, this document will be restricted to the case of a single 106 dialog and the reuse of that dialog for sidebars. 108 As discussed in the framework, a sub-conference is identified by a 109 URI. This URI is an alias for the main conference - that is, it must 110 resolve to the same focus as the main conference. If an intended 111 sidebar participant is not a participant in the main conference, the 112 intended participant joins the conference using the sidebar URI using 113 normal SIP means and is added into the sidebar only. If that 114 participant wishes to become part of the main conference, either a 115 re-INVITE with the main conference URI in the Contact is used, or an 116 INVITE with Replaces from the main conference is issued. Of course, 117 if the participant wishes to maintain separate dialogs, a simple new 118 INVITE would be sent to/from the main conference URI. 120 3. Sidebar mechanism requirements 122 A properly authorized participant in a conference which allows 123 sidebars must be able to: 125 REQ-1 Create a sidebar conference. 127 REQ-2 Invite participants to join the sidebar, both members of the 128 main conference and outside the conference. 130 REQ-3 Discover the status of the invited participants. 132 REQ-4 Remove participants from a sidebar. 134 REQ-5 Delete the sidebar. 136 In addition, any participant or potential participant in a sidebar 137 must be able to: 139 REQ-6 Discover they have been invited to a sidebar. 141 REQ-7 Accept or deny an invitation to a sidebar. 143 REQ-8 Discover who else is a participant in the sidebar. 145 REQ-9 Switch back and forth between the sidebar and the main 146 conference. 148 REQ-10 Add/delete media streams in the sidebar. 150 REQ-11 Leave the sidebar. 152 CPCP [8] can meet requirements REQ-1, REQ-2, REQ-5, REQ-6, and 153 REQ-10. 155 As the conference package [5] contains sidebar rosters, notifications 156 from the focus can meet requirements REQ-3 and REQ-8. In addition, 157 if a "pending" user status is added to the conference package (or the 158 existing "on-hold" status reused), it can meet requirement REQ-6. 160 The remaining requirements need to be met using controls provided by 161 the template, as discussed in the media policy document. 162 Specifically, REQ-9 is needed if the nature of the media type limits 163 the user to participation in only one stream at a time. For example, 164 a user can effectively only listen to a single audio stream at a 165 time, so they can only participate in either the main audio 166 conference or in an audio sidebar but not both at the same time. On 167 the other hand, a user can easily participate in multiple text 168 sidebars while still participating actively in the main conference. 169 Thus, the need for this requirement is media specific. 171 In the main conference, the equivalent requirements to requirements 172 REQ-7, REQ-9 and REQ-11 are met using the signaling protocol, i.e. 173 an INVITE is accepted or rejected to join the main conference, a 174 re-INVITE places media streams on and off hold, and a BYE is sent to 175 leave the main conference. Since a sidebar shares the main 176 conference dialog, clearly these signaling methods are not 177 applicable, except for a participant who is only in the sidebar and 178 not a participant in the main conference. However, the signaling 179 could still be used as the channel to convey this information. For 180 example, a re-INVITE could be initiated by the participant to accept 181 the sidebar invitation if an SDP attribute were defined to convey 182 this information. A re-INVITE could also be used to switch between 183 participation in the main conference and the sidebar, and to leave 184 the sidebar. 186 Alternatively, a CPCP command could be used meet REQ-7, REQ-9 and 187 REQ-11. 189 Until one approach or the other is chosen for this, the call flows 190 will show CPCP/re-INVITE as the mechanism for accepting or denying a 191 sidebar invitation. switching between participation in the main 192 conference and the sidebar, and leaving a sidebar. 194 4. Creating Sidebars 196 The SIP conferencing architecture supports multiple media types and 197 both centralized and distributed mixing. Sidebars also have this 198 same property. The media type and mixing mode of a sidebar need not 199 be the same as the main conference. 201 In the simplest case, the sidebar has the same media types as the 202 main conference, and is centrally mixed. In this case, the focus 203 changes the mix for the sidebar participants, and no SIP signaling is 204 necessary - the existing main conference mix is replaced with the 205 sidebar mix. 207 On the other hand, if the sidebar has different media types than the 208 main conference, then the focus will need to re-INVITE, adding the 209 new media stream(s). Conference package notifications and SDP 210 information will be used by the User Agent to render the new media 211 stream in the proper context as a sidebar. 213 For fully distributed mixing of single dialog sidebars, the focus may 214 need to re-INVITE to add a media stream if the media stream is not 215 already being sent to the participant. The participant will be 216 notified of the desired mix using a non-SIP protocol which will 217 result in the creation of the sidebar. 219 Figure 1 shows a call flow for the creation of a sidebar conference. 220 In this flow and those that follow, Alice, Bob, and Carol are 221 participants in the main conference while Devon is not. 223 Alice Focus Carol Bob 224 | | | | 225 |<==================>| | | 226 | |<==================>| | 227 | |<=======================================>| 228 | | | | 229 | Alice creates a sidebar using CPCP. | 230 | | | | 231 | CPCP Create Sidebar F1 | | 232 |------------------->| | | 233 | CPCP Acknowledgement F2 | | 234 |<-------------------| | | 235 | | | | 236 | Alice adds herself into the sidebar using CPCP. | 237 | | | | 238 | CPCP Add Alice to sidebar F3 | | 239 |------------------->| | | 240 | CPCP Acknowledgement F4 | | 241 |<-------------------| | | 242 | | | | 243 | Alice is notified that she is invited to the sidebar | 244 | | | | 245 | NOTIFY F5 | | | 246 |<-------------------| | | 247 | 200 OK F6 | | | 248 |------------------->| | | 249 | | | | 250 | Alice joins the sidebar | | 251 | | | | 252 | CPCP/re-INVITE F7 | | | 253 |<------------------>| | | 254 | | | | 255 | Alice is notified that she is a participant in the sidebar | 256 | | | | 257 | NOTIFY F8 | | | 258 |<-------------------| | | 259 | 200 OK F9 | | | 260 |------------------->| | | 261 Figure 1. Creation of a Sidebar. 263 5. Adding Participants to a Sidebar 265 Participants can be added to a sidebar in a number of ways. If the 266 intended sidebar participant is already a participant in the main 267 conference and desires a single dialog, then some non-SIP means will 268 be used to add the participant. 270 On the other hand, if the participant is not in the main conference, 271 a SIP means such as a REFER with the Refer-To URI set to the sidebar 272 URI can be used, or a non-SIP means. Either way, a new dialog will 273 be established with the participant and they will join the sidebar 274 using some non-SIP means. 276 Alice Focus Carol Bob 277 | | | | 278 |<==================>| | | 279 | |<==================>| | 280 | |<=======================================>| 281 | | | | 282 | Alice adds Carol to the sidebar using CPCP | 283 | | | | 284 | CPCP Add Carol to sidebar F1 | | 285 |------------------->| | | 286 | CPCP Acknowledgement F2 | | 287 |<-------------------| | | 288 | | | | 289 | Carol is notified that she has been invited to the sidebar with Alice 290 | | | | 291 | | NOTIFY F3 | | 292 | |------------------->| | 293 | | 200 OK F4 | | 294 | |<-------------------| | 295 | | | | 296 | Carol joins the sidebar | | 297 | | | | 298 | | CPCP/re-INVITE F5 | | 299 | |<------------------>| | 300 | | | | 301 | Alice is notified that Carol has joined the sidebar | 302 | | | | 303 | NOTIFY F6 | | | 304 |<-------------------| | | 305 | 200 OK F7 | | | 306 |------------------->| | | 307 | | | | 308 | Carol is notified that she is now in the sidebar | 309 | | | | 310 | | NOTIFY F8 | | 311 | |------------------->| | 312 | | 200 OK F9 | | 313 | |<-------------------| | 315 Figure 2. Adding a participant to a sidebar. 317 Alice Focus Carol Devon 318 | | | | 319 |<==================>| | | 320 | |<==================>| | 321 | | | 322 | Alice adds Devon who is not in the conference to the sidebar.| 323 | | | 324 | CPCP Add Devon to sidebar F1 | 325 |------------------->| | 326 | CPCP Acknowledgement F2 | 327 |<-------------------| | 328 | | | 329 | Alice sends a REFER to Devon to join to the sidebar | 330 | | | 331 | REFER Refer-To:sip:Sidebar-ID F3 | 332 |------------------------------------------------------------->| 333 | 202 Accepted F4 | 334 |<-------------------------------------------------------------| 335 | | NOTIFY F5 | 336 |<-------------------------------------------------------------| 337 | | 200 OK F6 | 338 |------------------------------------------------------------->| 339 | | INVITE sip:Sidebar-ID F7 | 340 | |<----------------------------------------| 341 | | 180 Ringing F8 | 342 | |---------------------------------------->| 343 | | 200 OK Contact:sip:Sidebar-ID;isfocus F9| 344 | |---------------------------------------->| 345 | | ACK F10 | 346 | |<----------------------------------------| 347 | | RTP | 348 | |<=======================================>| 349 | | SUBSCRIBE sip:Sidebar-ID F11 | 350 | |<----------------------------------------| 351 | | 200 OK F12 | 352 | |---------------------------------------->| 353 | | | 354 | Devon is notified that she has been invited to a sidebar with Alice 355 | | | 356 | | NOTIFY F13 | 357 | |---------------------------------------->| 358 | | 200 OK F14 | 359 | |<----------------------------------------| 360 | | | 361 | | Devon joins the sidebar | 362 | | | 363 | | CPCP/re-INVITE F15 | 364 | |<--------------------------------------->| 365 | | | 366 | Devon is notified that Alice is in the sidebar with her | 367 | | | 368 | | NOTIFY F16 | 369 | |---------------------------------------->| 370 | | 200 OK F17 | 371 | |<----------------------------------------| 372 | | | 373 | Alice is notified that Devon has joined the sidebar | 374 | | | 375 | NOTIFY F18 | | 376 |<-------------------| | 377 | 200 OK F19 | | 378 |------------------->| | 379 | | | | 380 | Carol is notified that Devon has joined the sidebar | 381 | | | | 382 | | NOTIFY F20 | | 383 | |------------------->| | 384 | | 200 OK F21 | | 385 | |<-------------------| | 387 Figure 3. Adding a participant to a sidebar who is not a member of the 388 main conference. 390 6. Terminating a Sidebar 392 Participation in a single dialog sidebar is terminated by non-SIP 393 means. When the last participant leaves it, the sidebar ceases to 394 exist. A multiple dialog sidebar is terminated by a BYE on the 395 dialog for each of the participants. When the last participant 396 leaves it, the sidebar ceases to exist, and the sidebar URI becomes 397 unusable. Note that a single participant sidebar is permissible - 398 another participant may join later. 400 Alice Focus Carol Devon 401 | | | | 402 |<==================>| | | 403 | |<==================>| | 404 | |<=======================================>| 405 | | | | 406 | Carol leaves the sidebar. | 407 | | | | 408 | | CPCP/re-INVITE F1 | | 409 | |<------------------>| | 410 | | | | 411 | Carol is notified that she has left the sidebar | 412 | | | | 413 | | NOTIFY F2 | | 414 | |------------------->| | 415 | | 200 OK F3 | | 416 | |<-------------------| | 417 | | | 418 | Devon is notified that Carol has left the sidebar | 419 | | | 420 | | NOTIFY F4 | 421 | |---------------------------------------->| 422 | | 200 OK F5 | 423 | |<----------------------------------------| 424 | | | 425 | Alice is notified that Carol has left the sidebar | 426 | | | 427 | NOTIFY F6 | | 428 |<-------------------| | 429 | 200 OK F7 | | 430 |------------------->| | 431 | | Devon leaves the sidebar. | 432 | | | 433 | | BYE F8 | 434 | |<----------------------------------------| 435 | | 200 OK F9 | 436 | |---------------------------------------->| 437 | | | 438 | Devon is notified that she has left the sidebar. | 439 | | | 440 | | NOTIFY F10 | 441 | |---------------------------------------->| 442 | | 200 OK F11 | 443 | |<----------------------------------------| 444 | | 445 | Alice is notified that Devon has left the sidebar. 446 | | 447 | NOTIFY F12 | 448 |<-------------------| 449 | 200 OK F13 | 450 |------------------->| 451 | | 452 | Alice leaves the sidebar. 453 | | 454 | CPCP/re-INVITE F14 | 455 |<------------------>| 456 | | 457 | Alice is notified that she has left the sidebar. 458 | | 459 | NOTIFY F15 | 460 |<-------------------| 461 | 200 OK F16 | 462 |------------------->| 464 Figure 4. Terminating a sidebar. 466 7. Security Considerations 468 This document discusses call control for SIP conferencing. Both call 469 control and conferencing have specific security requirements which 470 will be summarized here. Conferences generally have authorization 471 rules about who may or may not join a conference, what type of media 472 may or may not be used, etc. This information is used by the focus 473 to admit or deny participation in a conference. It is recommended 474 that these types of authorization rules be used to provide security 475 for a SIP conference. For this authorization information to be used, 476 the focus needs to be able to authenticate potential participants. 477 Normal SIP identity mechanisms including Digest challenge, 478 certificates, and identity header fields can be used. These 479 conference specific security requirements are discussed further in 480 the requirements and framework documents. 482 For call control security, a user agent must maintain local policy on 483 who is permitted to perform call control operations, initiate REFERs, 484 and replace dialogs. Normal SIP authentication mechanisms are also 485 appropriate here. The specific authentication and authorization 486 schemes are described in the multiparty call control framework 487 document. 489 8. IANA Considerations 491 None. 493 9. References 495 9.1 Normative References 497 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 498 Levels", BCP 14, RFC 2119, March 1997. 500 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 501 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 502 Session Initiation Protocol", RFC 3261, June 2002. 504 [3] Sparks, R., "The Session Initiation Protocol (SIP) Refer 505 Method", RFC 3515, April 2003. 507 [4] Roach, A., "Session Initiation Protocol (SIP)-Specific Event 508 Notification", RFC 3265, June 2002. 510 [5] Rosenberg, J. and H. Schulzrinne, "A Session Initiation Protocol 511 (SIP) Event Package for Conference State", 512 draft-ietf-sipping-conference-package-04 (work in progress), May 513 2004. 515 [6] Mahy, R. and D. Petrie, "The Session Inititation Protocol (SIP) 516 'Join' Header", draft-ietf-sip-join-03 (work in progress), 517 February 2004. 519 [7] Rosenberg, J., "Indicating User Agent Capabilities in the 520 Session Initiation Protocol (SIP)", 521 draft-ietf-sip-callee-caps-03 (work in progress), January 2004. 523 [8] Khartabil, H. and P. Koskelainen, "The Conference Policy Control 524 Protocol (CPCP)", draft-ietf-xcon-cpcp-xcap-00 (work in 525 progress), May 2004. 527 9.2 Informative References 529 [9] Rosenberg, J., "A Framework for Conferencing with the Session 530 Initiation Protocol", 531 draft-ietf-sipping-conferencing-framework-02 (work in 532 progress), June 2004. 534 [10] Campbell, B. and R. Sparks, "Control of Service Context using 535 SIP Request-URI", RFC 3087, April 2001. 537 [11] Sparks, R., "Internet Media Type message/sipfrag", RFC 3420, 538 November 2002. 540 [12] Johnston, A., Donovan, S., Sparks, R., Cunningham, C. and K. 541 Summers, "Session Initiation Protocol (SIP) Basic Call Flow 542 Examples", BCP 75, RFC 3665, December 2003. 544 Authors' Addresses 546 Brian Rosen 547 Marconi 548 1000 FORE Drive 549 Warrendale, PA 15086 551 EMail: brian.rosen@marconi.com 552 Alan Johnston 553 MCI 554 100 South 4th Street 555 St. Louis, MO 63102 557 EMail: alan.johnston@mci.com 559 Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 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 AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2004). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights. 599 Acknowledgment 601 Funding for the RFC Editor function is currently provided by the 602 Internet Society.