idnits 2.17.1 draft-ietf-xcon-floor-control-req-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 21. -- Found old boilerplate from RFC 3978, Section 5.5 on line 564. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 541. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 548. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 554. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 570), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 43. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 19, 2004) is 7219 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 458, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 474, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-ietf-sipping-conferencing-framework-02 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-conferencing-framework (ref. '3') == Outdated reference: A later version (-01) exists of draft-ietf-mmusic-sccp-00 Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Transport Area P. Koskelainen 3 Internet-Draft Nokia 4 Expires: January 17, 2005 J. Ott 5 Uni Bremen TZI 6 H. Schulzrinne 7 X. Wu 8 Columbia University 9 July 19, 2004 11 Requirements for Floor Control Protocol 12 draft-ietf-xcon-floor-control-req-01.txt 14 Status of this Memo 16 This document is an Internet-Draft and is subject to all provisions 17 of section 3 of RFC 3667. By submitting this Internet-Draft, each 18 author represents that any applicable patent or other IPR claims of 19 which he or she is aware have been or will be disclosed, and any of 20 which he or she become aware will be disclosed, in accordance with 21 RFC 3668. 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 26 Internet-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 http:// 34 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 January 17, 2005. 41 Copyright Notice 43 Copyright (C) The Internet Society (2004). All Rights Reserved. 45 Abstract 47 Floor control is a means to manage joint or exclusive access to 48 shared resource in a (multiparty) conferencing environment. Thereby, 49 floor control complements other functions -- such as conference and 50 media session setup, conference policy manipulation, and media 51 control -- that are realized by other protocols. This document 52 defines the requirements for a floor control protocol for multiparty 53 conferences in the context of an existing framework. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 59 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4. Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5. Integration with Conferencing . . . . . . . . . . . . . . . . 7 62 6. Assumptions about a Conference Policy . . . . . . . . . . . . 8 63 7. Floor Control Protocol Requirements . . . . . . . . . . . . . 10 64 7.1 Communication between Participant and Server . . . . . . . 10 65 7.2 Communicaton between Chair and Server . . . . . . . . . . 11 66 7.3 General Protocol Requirements . . . . . . . . . . . . . . 12 67 8. Open Issue . . . . . . . . . . . . . . . . . . . . . . . . . . 13 68 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 69 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 15 71 10.2 Informative References . . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 16 73 Intellectual Property and Copyright Statements . . . . . . . . 17 75 1. Introduction 77 Conference applications often have shared resources such as the right 78 to talk, input access to a limited-bandwidth video channel, or a 79 pointer or input focus in a shared application. 81 In many cases, it is desirable to be able to control who can provide 82 input (send/write/control, depending on the application) to the 83 shared resource. 85 Floor control enables applications or users to gain safe and mutually 86 exclusive or non-exclusive input access to the shared object or 87 resource. The floor is an individual temporary access or 88 manipulation permission for a specific shared resource (or group of 89 resources) [8]. 91 Floor control is an optional feature for conferencing applications. 92 SIP [2] conferencing applications may also decide not to support this 93 feature at all. Two-party applications may use floor control outside 94 conferencing, although the usefulness of this kind of scenario is 95 limited. Floor control may be used together with conference policy 96 control protocol (CPCP) [9], or it may be used as independent 97 standalone protocol, e.g. with SIP but without CPCP. 99 Floor control has been studied extensively over the years, (e.g. 100 [10], [8], [7]) therefore earlier work can be leveraged here. 102 The present document describes the requirements for a floor control 103 protocol. As a requirements specification, the document makes no 104 assumptions about the later implementation of the respective 105 requirements as parts of one or more protocols and about the entities 106 implementing it/them and their roles. 108 This document may be used in conjunction with other documents, such 109 as the Conferencing framework document [3]. In particular, when 110 speaking about a floor control server, this entity may be identical 111 to or co-located with the focus or a conference policy server defined 112 in the framework document, while participants and floor chairs 113 referred to in this specificiation may be regular participants as 114 introduced in the conferencing framework document. The term "floor 115 control protocol" is used in an abstract sense in this specification 116 and may ultimately be mapped to any of the existing conference 117 control or other signaling protocols (including CPCP and SIP). But 118 defining those relationships is left to a concrete floor control 119 protocol specification. 121 2. Conventions Used in This Document 123 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 124 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 125 document are to be interpreted as described in RFC 2119. 127 3. Terminology 129 This document uses the definitions from [3]. 131 The following additional definitions apply: 133 Floor: A permission to temporarily access or manipulate a specific 134 shared resource or set of resources. 136 Conference owner: A privileged user who controls the conference, 137 creates floors and assigns and deassigns floor chairs. The 138 conference owner does not have to be a member in a conference. 140 Floor chair: A user (or an entity) who manages one floor (grants, 141 denies or revokes a floor). The floor chair does not have to be a 142 member in a conference. 144 Floor control: A mechanism that enables applications or users to gain 145 safe and mutually exclusive or non-exclusive input access to the 146 shared object or resource. 148 Floor control server: A logical entity that maintains the state of 149 the floor(s) including which floors exists, who the floor chairs are, 150 who holds a floor, etc. Requests to manipulate a floor are directed 151 at the floor control server. 153 Floor request set: A logical data structure holding all requests for 154 a particular floor at a given point in time. 156 Floor holder set: A logical data structure identifying all 157 participants who currently hold the floor. 159 4. Model 161 The model for floor control comprises three logical entities: a 162 single floor control server, one or more floor chairs (moderators), 163 and any number of regular conference participants. 165 A floor control protocol is used to convey the floor control messages 166 among the floor chairs (moderators) of the conference, the floor 167 control server, and the participants of the conference. A 168 centralized architecture is assumed in which all messages go via one 169 point, the floor control server. Processing (granting or rejecting) 170 floor control requests is done by the one or more floor chairs or by 171 the server itself, depending on the policy. 173 Floor requests from the participants are received by the floor 174 control server and kept in an -- at the level of the floor control 175 protocol -- floor request set (i.e. are not ordered in any 176 particular fashion). The current floor holders are reflected in a 177 current floor holder set. Floor chairs are capable of manipulating 178 both sets to e.g. grant, revoke, reject, and pass the floor. 180 The order in which requests are processed, whether they are granted 181 or rejected, how many participants obtain a floor simultaneously, is 182 determined by a higher layer application operating on these sets and 183 is not confined by the floor control protocol. 185 A floor is associated with one or more media sessions. The 186 centralized conference server manages the floors and thus controls 187 access to the media sessions. There are two aspects to this: 1) The 188 server maintains and distributes consistent state information about 189 who has a certain floor at a certain point in time and does so 190 following some rule set. This provides all participants with the 191 necessary information about who is allowed to e.g. speak, but relies 192 on a cooperative behavior among all participants. 2) In addition, to 193 prevent individuals from ignoring the "hints" given by the floor 194 control server, the latter may -- e.g. in cooperation with other 195 functional entities -- enforce compliance with floor status, e.g. by 196 blocking media streams from participants not entitled to speak. The 197 floor control server controls the floors at least at the signaling 198 level (1); actively controlling also the actual (physical) media 199 resources (2) is highly recommended, but beyond the scope of this 200 document. 202 As noted in the introduction, an actual protocol specification 203 fulfilling the requirements defined in this memo may map the 204 components of the above model onto the conferencing components 205 defined in the conferencing framework document. Some of these 206 aspects are discussed briefly in the next subsection. 208 5. Integration with Conferencing 210 Floor control itself does not support privileges such as creating 211 floors and appointing floor chairs, handing over chair privileges to 212 other users (or taking them away). Instead, some external mechanism, 213 such as conference management (e.g. CPCP or web interface for policy 214 manipulation) is used for that. 216 The conference policy (and thus the conference owner or creator) 217 defines whether floor control is in use or not. Actually enforcing 218 conference media distribution in line with the respective media's 219 floor status (e.g. controlling an audio bridge) is beyond the scope 220 of this document. Floor control itself does not define media 221 enforcement. It is up to the conference and media policies to define 222 which media streams may be used in a conference and which ones are 223 floor controlled. 225 Typically, the conference owner creates the floor(s) using conference 226 policy control protocol (or some other mechanism) and appoints the 227 floor chair. The conference owner can remove the floor anytime (so 228 that a media session is not floor-controlled anymore) or change floor 229 chair or floor parameters. 231 The floor chair just controls the access to the floor(s), according 232 to the conference policy. 234 A floor control server is a separate logical entity, typically 235 co-located with focus and/or conference policy server. Therefore, 236 the floor control server can interact with focus, conference Policy 237 Server and media servers as needed. Communication mechanisms between 238 floor control server and other central conferencing entities are not 239 within the scope of the floor control protocol requirements described 240 in this document. 242 6. Assumptions about a Conference Policy 244 The floor control protocol is supposed to be used to manage access to 245 shared resources in the context of a conference. It is up to this 246 conference -- more precisely: its conference policy [4] -- to define 247 the rules for the operation of the floor control protocol. 248 Furthermore, a conference policy control protocol [4] may define 249 mechanisms to alter those rules during the course of a conference. 250 This section briefly outlines the assumptions made by a floor control 251 protocol about the conference policy and means for its modification. 253 The conference policy is expected to define the rules for floor 254 control -- which particularly implies that it is not the 255 responsibility of the floor control protocol to establish or 256 communicate those rules. 258 In general, it is assumed that the conference policy also defines who 259 is allowed to create, change and remove a floor in a conference. 261 Conference participants and floor chairs should be able to get and 262 set floor-related parameters. The conference policy may restrict who 263 may access or alter which parameters. Note that not all parameters 264 maintained for a floor are also interpreted by the floor control 265 protocol (e.g. floor policy descriptions may be stored associated 266 with a floor but may be interpreted by a higher layer application). 267 Note also that changes to the floor control policy outside the scope 268 of the floor control protocol and e.g. to be carried out by a 269 conference policy control protocol. 271 (For example, it may be useful to see who the floor chair is, what 272 kind of policy is in use, time limits, number of simultanous floor 273 holders and current floor holder.) 275 These following requirements on a conference policy related to floor 276 control are identified in [4]: 278 REQ-F1: It MUST be possible to define whether floor control is in use 279 or not. 281 REQ-F2: It MUST be possible to define the algorithm to be used in 282 granting the floor. (Note: Example algorithms might be e.g. 283 moderator-controlled, FCFS, random.) 285 Note: it must be possible to use an automated floor policy where the 286 floor control server decides autonomously about granting, and 287 rejecting floor requests as well as revoking the floor. It must also 288 be possible to use a chair-controlled floor policy in which the floor 289 control server notifies the floor chair and waits for the chair to 290 make a decision. This enables the chair to fully control who has the 291 floor. The server MAY forward all requests immediately to the floor 292 chair, or it may do filtering and send only occasional notifications 293 to the chair. 295 REQ-F3: It MUST be possible to define how many users can have the 296 floor at the same time. 298 REQ-F4: It MUST be possible to have one floor for one or more media 299 types. 301 REQ-F5: It MUST be possible to have multiple floors in a conference. 303 REQ-F6: It MUST be possible to define whether a floor is 304 moderator-controlled or not. 306 REQ-F7: If the floor is moderator-controlled, it MUST be possible to 307 assign and replace the floor moderator. 309 7. Floor Control Protocol Requirements 311 This section covers the requirements on a floor control protocol. 312 The requirements are grouped as follows: 1) floor control protocol 313 between participant and server; 2) floor control protocol between 314 floor chairs and server; 3) floor control server management, and 4) 315 general protocol requirements. 317 7.1 Communication between Participant and Server 319 REQ-PS-1: Participants MUST be able to request (claim) a floor. 321 REQ-PS-2: It SHOULD be possible for a participant requesting a floor 322 to give additional information about the request, such as the topic 323 of the question for an audio floor. Note: In some scenarios, the 324 floor control server or the floor chair may use this information when 325 granting the floor to the user, or when making manipulation to the 326 floor sets at the server. 328 REQ-PS-3: It MUST be possible for a participant to modify (e.g. 329 cancel) a previously placed floor request. 331 REQ-PS-4: It SHOULD be possible for a participant to initiate a floor 332 control operation (e.g. floor request, release) on behalf of another 333 participant (third-party floor control) provided that he is 334 authorized to do so. 336 REQ-PS-5: A participant MUST be informed that she has been granted 337 the floor. 339 REQ-PS-6: A participant MUST be informed that his floor request has 340 been rejected. 342 REQ-PS-7: A participant MUST be informed that the floor was revoked 343 from her. 345 REQ-PS-8: A participant SHOULD be informed that her floor request is 346 pending and will be processed later. 348 REQ-PS-9: A floor holder MUST be able to release a floor. 350 REQ-PS-10: It MUST be possible to notify conference participants 351 (changes to) the floor holder(s) 353 REQ-PS-11: It MUST be possible to notify conference participants when 354 a new floor request is being made. 356 RRQ-PS-12: It MUST be possible for a floor requester to request 357 privacy for claiming the floor. 359 anonymous: the participants (including the floor chair) cannot see 360 the floor requester's identity. The floor chairs grant the floor 361 based on the claim id and the topic of the claim. 363 known to the floor chair: only the floor chair is able to see the 364 floor requester's identity; all other participants do not obtain this 365 information. 367 public: all the participants can see the floor requester's identity. 369 REQ-PS-13: It MUST be possible for a participant to request privacy 370 for holding the floor along with a floor request. Note that identity 371 information about the particpant may become available to others 372 through different means (e.g. application/media protocols or the 373 mmedia itself such as the voice). 375 7.2 Communicaton between Chair and Server 377 REQ-CS-1: It MUST be possible to inform the floor chairs, if present, 378 about a participant's floor request. 380 It SHOULD be possible to convey additional information the 381 participant may have provided along with her request. 383 It MUST be possible to hide the requesting participant's identity 384 from the chair, i.e. not include this identity information in the 385 floor request. 387 REQ-CS-2: It MUST be possible to grant a floor to a participant. 389 REQ-CS-3: It MUST be possible to reject a participant's floor 390 request. 392 REQ-CS-4: The floor chair MUST be able to revoke a floor from (one 393 of) its current holder(s). Note that the floor chair may also remove 394 pending floor requests from the request set (by rejecting them). 396 REQ-CS-5: It MUST be possible to notify floor chairs about changes to 397 the floor holder(s) 399 REQ-CS-6: There SHOULD be operations to manipulate the request set 400 available for floor chair(s). Such request set SHOULD at least 401 include creating, maintaining, and re-ordering floor requests a queue 402 and clearing the floor control queue. 404 RRQ-CS-7: It MUST be possible to hide the identity of a floor chair 405 from a subset or all participants of a conference. 407 REQ-CS-8: It MUST be possible for a newly assigned floor chair to 408 learn about (e.g. inquire) the existing floor request set. 410 7.3 General Protocol Requirements 412 REQ-GEN-1: Bandwidth and terminal limitations SHOULD be taken into 413 account in order to ensure that floor control can be efficiently used 414 in mobile environments. 416 It should be noted that efficient communication by means of minimal 417 sized messages may contradict the desire to express reasons for 418 requesting a floor along with other information. Therefore, a floor 419 control protocol SHOULD be designed in a way that it allow for 420 expressive as well as minimal messaging, as (negotiable) 421 configuration option and/or selectable on a per-message basis. 423 REQ-GEN-2: The floor control MUST be a reliable client-server 424 protocol. Hence, it MUST provide a positive response indicating that 425 a request has been received or an error response if an error has 426 occurred. 428 REQ-GEN-3: It MUST be possible for the floor control server to 429 authenticate participants and chairs. 431 REQ-GEN-4: It MUST be possible for the participants and chairs to 432 authenticate the server. 434 REQ-GEN-5: It MUST be possible to ensure message integrity between 435 participants and chairs and the floor control server. 437 REQ-GEN-6: It MUST be possible to ensure privacy of messages 438 exchanged between participants and chairs and the floor control 439 server. 441 8. Open Issue 443 Conferences can be cascaded, such that a participant of the 444 conference can be a conference in its own right. What implications 445 (if any) does this have on floor control and the requirements on a 446 floor control protocol? 448 9. Acknowledgements 450 The authors would like to thank IETF conferencing design team and 451 Keith Drage, Marcus Brunner, Sanjoy Sen, Eric Burger, Brian Rosen, 452 and Nermeen Ismail for their feedback. 454 10. References 456 10.1 Normative References 458 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 459 Levels", RFC 2119, BCD 14, March 1997. 461 [2] Rosenberg et al., J., "SIP: Session Initiation Protocol", RFC 462 3261, June 2002. 464 [3] Rosenberg, J., "A Framework for Conferencing with the Session 465 Initiation Protocol", 466 draft-ietf-sipping-conferencing-framework-02.txt (work in 467 progress), June 2004. 469 10.2 Informative References 471 [4] Koskelainen, P. and H. Khartabil, "Additional Requirements to 472 Conferencing", January 2004. 474 [5] Wu, X., Schulzrinne, H. and P. Koskelainen, "Use of SIP and 475 SOAP for conference floor control", January 2003. 477 [6] Camarillo, G., Ott, J. and K. Drage, "", June 2004. 479 [7] Koskelainen, P., Schulzrinne, H. and X. Wu, "A sip-based 480 conference control framework", Nossdav'2002 Miami Beach, May 481 2002. 483 [8] Dommel, H. and J. Garcia-Luna-Aceves, "Floor control for 484 activity coordination in networked multimedia applications", 485 Proc. of 2nd Asian-pacific Conference on Communications APPC, 486 Osaka Japan, June 1995. 488 [9] Koskelainen, P. and H. Khartabil, "An Extensible Markup 489 Language (XML) Configuration Access Protocol (XCAP) Usage for 490 Conference Policy Manipulation", 491 draft-koskelainen-xcon-xcap-cpcp-usage-02.txt (work in 492 progress), February 2004. 494 [10] Borman, C., Kutscher, D., Ott, J. and D. Trossen, "Simple 495 conference control protocol service specification", 496 draft-ietf-mmusic-sccp-00.txt (work in progress), March 2001. 498 Authors' Addresses 500 Petri Koskelainen 501 Nokia 502 P.O. Box 100 (Visiokatu 1) 503 Tampere FIN-33721 504 Finland 506 EMail: petri.koskelainen@nokia.com 508 Joerg Ott 509 Uni Bremen TZI 510 Bibliothekstr. 1 511 Bremen D-28359 512 Germany 514 EMail: jo@tzi.uni-bremen.de 516 Henning Schulzrinne 517 Columbia University 518 1214 Amsterdam Avenue 519 New York 10027 520 USA 522 EMail: hgs@cs.columbia.edu 524 Xiaotao Wu 525 Columbia University 526 1214 Amsterdam Avenue 527 New York 10027 528 USA 530 EMail: xiaotaow@cs.columbia.edu 532 Intellectual Property Statement 534 The IETF takes no position regarding the validity or scope of any 535 Intellectual Property Rights or other rights that might be claimed to 536 pertain to the implementation or use of the technology described in 537 this document or the extent to which any license under such rights 538 might or might not be available; nor does it represent that it has 539 made any independent effort to identify any such rights. Information 540 on the procedures with respect to rights in RFC documents can be 541 found in BCP 78 and BCP 79. 543 Copies of IPR disclosures made to the IETF Secretariat and any 544 assurances of licenses to be made available, or the result of an 545 attempt made to obtain a general license or permission for the use of 546 such proprietary rights by implementers or users of this 547 specification can be obtained from the IETF on-line IPR repository at 548 http://www.ietf.org/ipr. 550 The IETF invites any interested party to bring to its attention any 551 copyrights, patents or patent applications, or other proprietary 552 rights that may cover technology that may be required to implement 553 this standard. Please address the information to the IETF at 554 ietf-ipr@ietf.org. 556 Disclaimer of Validity 558 This document and the information contained herein are provided on an 559 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 560 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 561 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 562 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 563 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 564 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 566 Copyright Statement 568 Copyright (C) The Internet Society (2004). This document is subject 569 to the rights, licenses and restrictions contained in BCP 78, and 570 except as set forth therein, the authors retain all their rights. 572 Acknowledgment 574 Funding for the RFC Editor function is currently provided by the 575 Internet Society.