idnits 2.17.1 draft-mahy-sip-join-and-fork-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 316 has weird spacing: '...r field whe...' -- 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 (June 30, 2002) is 7970 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: '11' is defined on line 521, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. '3') (Obsoleted by RFC 4234) == Outdated reference: A later version (-07) exists of draft-ietf-sip-refer-05 == Outdated reference: A later version (-05) exists of draft-ietf-sip-replaces-02 == Outdated reference: A later version (-01) exists of draft-ietf-sipping-conferencing-models-00 -- Obsolete informational reference (is this intentional?): RFC 2543 (ref. '7') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) == Outdated reference: A later version (-12) exists of draft-ietf-sipping-cc-framework-00 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-dialog-package-00 == Outdated reference: A later version (-06) exists of draft-ietf-sipping-3pcc-02 == Outdated reference: A later version (-15) exists of draft-ietf-sipping-service-examples-01 -- Obsolete informational reference (is this intentional?): RFC 2976 (ref. '15') (Obsoleted by RFC 6086) Summary: 2 errors (**), 0 flaws (~~), 12 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. Mahy 3 Internet-Draft Cisco Systems, Inc. 4 Expires: December 29, 2002 D. Petrie 5 Pingtel 6 June 30, 2002 8 The Session Inititation Protocol (SIP) "Join" Header 9 draft-mahy-sip-join-and-fork-01.txt 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on December 29, 2002. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 This document defines a new header for use with SIP multi-party 41 applications and call control. The Join header is used to logically 42 join an existing SIP dialog with a new SIP dialog. This primitive 43 can be used to enable a variety of features, for example: "Barge-In", 44 answering-machine-style "Message Screening" and "Call Center 45 Monitoring". Note that definition of these example features is non- 46 normative. 48 Table of Contents 50 1. Conventions . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Applicability of RFC2804 ("Raven") . . . . . . . . . . . . . 4 53 4. User Agent Server Behavior: Receiving a Join Header . . . . 5 54 5. User Agent Client Behavior: Sending a Join header . . . . . 7 55 6. Proxy behavior . . . . . . . . . . . . . . . . . . . . . . . 7 56 7. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 7.1 The Join Header . . . . . . . . . . . . . . . . . . . . . . 7 58 7.2 New option tag for Require and Supported headers . . . . . . 8 59 8. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . 9 60 8.1 Join accepted and transitioned to central mixer . . . . . . 9 61 8.2 Join rejected . . . . . . . . . . . . . . . . . . . . . . . 10 62 9. Security Considerations . . . . . . . . . . . . . . . . . . 10 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 10 64 10.1 Registration of "Join" SIP header . . . . . . . . . . . . . 11 65 10.2 Registration of "join" SIP Option-tag . . . . . . . . . . . 11 66 11. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 11.1 Changes Since -00 . . . . . . . . . . . . . . . . . . . . . 11 68 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 11 69 Normative References . . . . . . . . . . . . . . . . . . . . 11 70 Informational References . . . . . . . . . . . . . . . . . . 12 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 72 Full Copyright Statement . . . . . . . . . . . . . . . . . . 14 74 1. Conventions 76 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 77 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 78 document are to be interpreted as described in RFC-2119 [2]. 80 This document refers frequently to the terms "confirmed dialog" and 81 "early dialog". These are defined in Section 12 of SIP [1]. 83 2. Overview 85 This document describes a SIP [1] extension header field as part of 86 the SIP multiparty applications architecture framework [8]. The Join 87 header is used to logically join an existing SIP dialog with a new 88 SIP dialog. This is especially useful in peer-to-peer call control 89 environments. 91 One use of the "Join" header is to insert a new participant into a 92 multimedia conversation (which may a two-party call or a conference). 93 While this functionality is already available using 3rd party call 94 control [12] style call control, the 3pcc model requires a central 95 point of control which may not be desirable in many environments. As 96 such, a method of performing these same call control primitives in a 97 distributed, peer-to-peer fashion is very desirable. 99 Use of an explicit Join header is needed in some cases instead of 100 addressing an INVITE to a conference URI for the following reasons: 102 o A conference may not exist--the new invitation may be trying to 103 join an oridinary two-party call. 105 o The party joining may not know if the dialog it wants to join is 106 part of a conference. 108 o The party joining may not know the conference URI. 110 The Join header enables services such as barge-in, real-time message 111 screening, and call center monitoring in a distributed peer-to-peer 112 way. This list of services is not exhaustive. 114 For example, the Boss has an established 2-party conversation with a 115 Customer, and using some out-of-band mechanism (ex:voice, gestures, 116 and email) asks an Assistant to join the conversation. The Assistant 117 sends an INVITE with a Join header to the Boss with the dialog 118 information for the established dialog. The Assistant obtained this 119 information from some mechanism, for example a web-page, and instant 120 message, or from the SIP dialog package [9]. 122 Assitant Boss Customer 123 | callid: 4@A | callid: 7@c | 124 | | | 125 | |<============>| 126 | | | 127 |INVITE------>| | 128 |Join: 7@c | | 129 | |reINVITE----->| 130 |<----200-----|<----200------| 131 |-----ACK---->|<----ACK------| 132 | | | 133 | .. begins mixing .. | 134 | | | 135 |<===========>|<============>| 136 |<::::::::::::::::::::::::::>| 138 Note that this operation effectively creates a new conference. The 139 Boss needs to start a new conference and create or obtain a new 140 conference URI. In our example, the Boss mixes all media locally, 141 so it needs to generate a new conference URI, return the conference 142 URI as the Contact to the Join INVITE, and reINVITE the Customer with 143 the conference URI as the new Contact. 145 3. Applicability of RFC2804 ("Raven") 147 This primitive can be used to create services which are used for 148 monitoring purposes, however these services do not meet the 149 definition of a wiretap according to RFC2804 [10]. The definition 150 from RFC2804 is included here: 152 Wiretapping is what occurs when information passed across the 153 Internet from one party to one or more other parties is delivered 154 to a third party: 156 1. Without the sending party knowing about the third party 158 2. Without any of the recipient parties knowing about the delivery 159 to the third party 161 3. When the normal expectation of the sender is that the 162 transmitted information will only be seen by the recipient 163 parties or parties obliged to keep the information in 164 confidence 166 4. When the third party acts deliberately to target the 167 transmission of the first party, either because he is of 168 interest, or because the second party's reception is of 169 interest. 171 Specifically, item 2 of this definition does not apply to this 172 extension, as one party is always aware of a Join request and can 173 even decline such requests. In addition, in many applications of 174 this primitive, some or all of the other items may not apply. For 175 example, in many call centers which handle financial transactions, 176 all conversations are recorded with the full knowledge and 177 expectation of all parties involved. 179 4. User Agent Server Behavior: Receiving a Join Header 181 The Join header contains information used to match an existing SIP 182 dialog (call-id, to-tag, and from-tag). Upon receiving an INVITE 183 with a Join header, the UA attempts to match this information with a 184 confirmed or early dialog. The to-tag and from-tag are matched as if 185 they were present in an incoming request. In other words the to-tag 186 is compared to the local tag, and the from-tag is compared to the 187 remote tag. 189 If more than one Join header field is present in an INVITE, or if a 190 Join header field is present in a request other than INVITE, the UAS 191 MUST reject the request with a 400 Bad Request response. 193 The Join header has specific call control semantics. If both a Join 194 header field and another header field with contradictory semantics 195 (for example a Replaces [5] header field) are present in a request, 196 the request MUST be rejected with a 400 "Bad Request" response. 198 If the Join header field matches more than one dialog, the UA MUST 199 act as if no match is found. 201 If no match is found, the UAS rejects the INVITE and returns a 481 202 Call/Transaction Does Not Exist response. Likewise, if the Join 203 header field matches a dialog which was not created with an INVITE, 204 the UAS MUST reject the request with an appropriate response (ex: 205 400, 481, or 501). 207 If the Join header field matches a dialog which has already 208 terminated, the UA SHOULD decline the request with a 603 Declined 209 response. 211 If the Join header field matches a active dialog, the UA SHOULD 212 verify that the initiator of the new INVITE is authorized to join the 213 matched dialog. If the initiator of the new INVITE has authenticated 214 successfully as equivalent to the user who is being joined, then the 215 join is authorized. The UA MAY maintain a list of authorized 216 entities who are allowed to join any dialog with certain 217 characteristics (for example, all dialogs placed in the call center 218 context of the UA). In addition, the UA MAY use other authorization 219 mechanisms defined for this purpose in standards track extensions. 220 For example, an extension could define a mechanism for transitively 221 asserting authorization of a join. 223 If authorization is successful, the UA attempts to accept the new 224 INVITE, and assign any mixing or conferencing resources necessary to 225 complete the join. If the UA cannot accept the new INVITE (for 226 example: it cannot establish required QoS or keying, or it has 227 incompatible media), the UA MUST return an appropriate error response 228 and MUST leave the matched dialog unchanged. 230 A User Agent that accepts a Join header needs to setup dialogs or 231 conferences such that the requesting UAC is logically added to the 232 conversation space associated with the matched dialog. Any dialogs 233 which are already logically associated with the matched dialog in the 234 same conversation space are included as well. All the participants 235 in a conversation space should have access to all the media/content 236 sent in the context of that conversation space. That a participant 237 does not negotiate a specific type of media does not mean that it is 238 not otherwise a full participant. For a detailed description of 239 various conferencing mechanisms that could be used to handle a Join, 240 please consult the SIP conferencing framework [6]. 242 If the UAS has sufficient resources to locally handle the Join 243 request, the UAS SHOULD accept the Join request and perform the 244 appropriate media mixing or combining. The UAS MAY rearrange 245 appropriate dialogs instead as described below, based on some local 246 policy. 248 If the UAS does not have sufficient resources locally to handle the 249 request, or does not wish to use these local resources, but is aware 250 of other resources which could be used to satisfy the request (ex: a 251 centralized mixer), the UA SHOULD create a conference using this 252 resource (ex: INVITE the centralized mixer to obtain a conference 253 URI), redirect the requestor to this resource, and request other 254 participants in the same conversation space to use this resource. 255 The UA MAY use any appropriate mechanism to transition participants 256 to the new resource (ex: 3xx repsonse, 3rd-party call control 257 reinvitiations, REFER requests, or reinvitations to a multicast 258 group). The UA SHOULD only use mechanisms which are expected to be 259 acceptable to the participants. For example, the UA SHOULD NOT 260 attempt to transition the participants to a multicast group unless 261 the UA can reasonably expect that all the particpants can support 262 multicast. 264 If the UAS is incapable of satisfying the Join request, it MUST 265 return a 488 "Not Acceptable Here" response. 267 5. User Agent Client Behavior: Sending a Join header 269 A User Agent that wishes to add a new dialog of its own to a single 270 existing early or confirmed dialog and any associated dialogs or 271 conferences, MAY send the target User Agent an INVITE request 272 containing a Join header field. The UAC places the Call-ID, to-tag, 273 and from-tag information for the target dialog in a single Join 274 header field and sends the new INVITE to the target. 276 Note that use of this mechanism does not provide a way to match 277 multiple dialogs, nor does it provide a way to match an entire call, 278 an entire transaction, or to follow a chain of proxy forking logic. 279 For example, if Alice replaces Cathy in an early dialog with Bob, but 280 he does not answer, Alice's replacement request will not match other 281 dialogs to which Bob's UA redirects, nor other branches to which his 282 proxy forwards. 284 6. Proxy behavior 286 Proxy Servers do not require any new behavior to support this 287 extension. They simply pass the Join header field transparently as 288 described in the SIP specification. 290 Note that it is possible for a proxy (especially when forking based 291 on some application layer logic, such as caller screening or time-of- 292 day routing) to forward an INVITE request containing a Join header 293 field to a completely orthogonal set of Contacts than the original 294 request it was intended to replace. In this case, the INVITE request 295 with the Join header field will fail. 297 7. Syntax 299 7.1 The Join Header 301 The Join header field indicates that a new dialog (created by the 302 INVITE in which the Join header field in contained) should be joined 303 with a dialog identified by the header field, and any associated 304 dialogs or conferences. It is a request header only, and defined 305 only for INVITE requests. The Join header field MAY be encrypted as 306 part of end-to-end encryption. Only a single Join header field value 307 may be present in a SIP request 309 This document adds the following entry to Table 3 of [1]. Additions 310 to this table are also provided for extension methods defined at the 311 time of publication of this document. This is provided as a courtesy 312 to the reader and is not normative in any way. SUBSCRIBE and NOTIFY, 313 REFER, INFO, UPDATE, and PRACK are defined respectively in [14], [4], 314 [15], [16], and [17]. 316 Header field where proxy ACK BYE CAN INV OPT REG 317 ------------ ----- ----- --- --- --- --- --- --- 318 Join R - - - o - - 320 SUB NOT REF INF UPD PRA 321 --- --- --- --- --- --- 322 Join R - - - - - - 324 The following syntax specification uses the augmented Backus-Naur 325 Form (BNF) as described in RFC-2234 [3]. 327 Join = "Join" HCOLON callid *(SEMI join-param) 328 join-param = to-tag / from-tag / generic-param 329 to-tag = "to-tag" EQUAL token 330 from-tag = "from-tag" EQUAL token 332 A Join header MUST contain exactly one to-tag and exactly one from- 333 tag, as they are required for unique dialog matching. For 334 compatibility with dialogs initiated by RFC2543 [7] compliant UAs, a 335 tag of zero matches both tags of zero and null tags. 337 Examples: 339 Join: 98732@sip.billybiggs.com 340 ;from-tag=r33th4x0r 341 ;to-tag=ff87ff 343 Join: 12adf2f34456gs5;to-tag=12345;from-tag=54321 345 Join: 87134@171.161.34.23;to-tag=24796;from-tag=0 347 7.2 New option tag for Require and Supported headers 349 This specification defines a new Require/Supported header option tag 350 "join". UAs which support the Join header MUST include the "join" 351 option tag in a Supported header field. UAs that want explicit 352 failure notification if Join is not supported MAY include the "join" 353 option in a Require header field. 355 Example: 357 Require: join, 100rel 359 8. Usage Examples 361 The following non-normative examples are not intended to enumerate 362 all the possibilities for the usage of this extension, but rather to 363 provide examples or ideas only. For more examples, please see 364 service-examples [13]. 366 8.1 Join accepted and transitioned to central mixer 368 A B C mixer 369 | callid: 4@A | callid: 7@c | | 370 | | | | 371 | |<============>| | 372 | | | | 373 |INVITE------>| | | 374 |Join: 7@c |--INVITE-------------------->| 375 | |<----200---------------------| 376 | |-----ACK-------------------->| 377 |<----300-----| | 378 |INVITE------------------------------------>| 379 |<--200-------------------------------------| 380 |---ACK------------------------------------>| 381 | |--REFER------>| | 382 | |<---200-------|--INVITE----->| 383 | | |<----200------| 384 | |<--NOTIFY-----|-----ACK----->| 385 | |------200---->| | 386 | |---BYE------->| | 387 | |<--200--------| | 388 | | | | 389 |<=========================================>| mixes the 390 | |<===========================>| three sessions 391 | | |<============>| together 393 The conversation space now looks identical to the locally mixed 394 example in the Introduction. Details of how the Join are implemented 395 are transparent to A. B could have used 3rd party call control 396 instead to move the necessary sessions. 398 [ B , C ] --> [ A , B , C ] 400 8.2 Join rejected 402 A B C 403 | callid: 4@A | callid: 7@c | 404 | | | 405 | |<============>| 406 | | | 407 |INVITE------>| | 408 |Join: 7@c | | 409 | | | 410 |<----486-----| | 411 |-----ACK---->| | 412 | | | 414 In this example B is Busy (does not want to be disturbed), and 415 therefore does not wish to add A. B could also decline the request 416 with a 603 response. 418 9. Security Considerations 420 The extension specified in this document significantly changes the 421 relative security of SIP devices. Currently in SIP, even if an 422 eavesdropper learns the Call-ID, To, and From headers of a dialog, 423 they cannot easily modify or destroy that dialog if Digest 424 authentication or end-to-end message integrity are used. 426 This extension can be used to insert or monitor potentially sensitive 427 content in a multimedia conversation. As such, invitations with the 428 Replaces header SHOULD only be accepted if the peer requesting 429 replacement has been properly authenticated using a standard SIP 430 mechanism, and authorized to by joined with the target dialog. 432 Some mechanisms for obtaining the dialog information needed by the 433 Join header (Call-ID, to-tag, and from-tag) include URIs on a web 434 page, subscriptions to an appropriate event package, and notifcations 435 after a REFER request. Use of end-to-end security mechanisms to 436 encrypt this information is also RECOMMENDED. 438 This extension was designed to take advantage of future signature or 439 authorization schemes defined by the SIP Working Group. In general, 440 call control features would benefit considerably from such work. 442 10. IANA Considerations 443 10.1 Registration of "Join" SIP header 445 Name of Header: Join 447 Short form: none 449 Normative description: section 7.1 of this document 451 10.2 Registration of "join" SIP Option-tag 453 Name of option: join 455 Description: Support for the SIP Join header 457 SIP headers defined: Join 459 Normative description: This document 461 11. Changes 463 11.1 Changes Since -00 465 o Realigned the text to mirror the outline of Replaces 467 o Removed the fork header 469 o Added a section to explain how this is not a "Raven" wiretap 470 mechanism 472 o Reorganized motivational overview material 474 o Added authorization language in UAS behavior section 476 o Updated and Added references 478 12. Acknowledgments 480 Thanks to Robert Sparks, Alan Johnston, and Ben Campbell and many 481 other members of the SIP WG for their continued support of the cause 482 of distributed call control in SIP. 484 Normative References 486 [1] Rosenberg, J. and H. Schulzrinne, "SIP: Session Initiation 487 Protocol", draft-ietf-sip-rfc2543bis-09 (work in progress), 488 February 2002. 490 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 491 Levels", BCP 14, RFC 2119, March 1997. 493 [3] Crocker, D. and P. Overell, "Augmented BNF for Syntax 494 Specifications: ABNF", RFC 2234, November 1997. 496 Informational References 498 [4] Sparks, R., "The SIP Refer Method", draft-ietf-sip-refer-05 499 (work in progress), June 2002. 501 [5] Dean, R., Biggs, B. and R. Mahy, "The Session Inititation 502 Protocol (SIP) 'Replaces' Header", draft-ietf-sip-replaces-02 503 (work in progress), May 2002. 505 [6] Rosenberg, J. and H. Schulzrinne, "Models for Multi Party 506 Conferencing in SIP", draft-ietf-sipping-conferencing-models-00 507 (work in progress), November 2001. 509 [7] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, 510 "SIP: Session Initiation Protocol", RFC 2543, March 1999. 512 [8] Mahy, R., "A Multi-party Application Framework for SIP", draft- 513 ietf-sipping-cc-framework-00 (work in progress), March 2002. 515 [9] Rosenberg, J. and H. Schulzrinne, "A Session Initiation 516 Protocol (SIP) Event Package for Dialog State", draft-ietf- 517 sipping-dialog-package-00 (work in progress), June 2002. 519 [10] IESG, IAB,., "IETF Policy on Wiretapping", RFC 2804, May 2000. 521 [11] Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc- 522 transfer-05.txt (work in progress), July 2001. 524 [12] Rosenberg, J., Schulzrinne, H., Camarillo, G. and J. Peterson, 525 "Best Current Practices for Third Party Call Control in the 526 Session Initiation Protocol", draft-ietf-sipping-3pcc-02 (work 527 in progress), June 2002. 529 [13] Johnston, A., "SIP Service Examples", draft-ietf-sipping- 530 service-examples-01 (work in progress), April 2002. 532 [14] Roach, A., "SIP-Specific Event Notification", draft-ietf-sip- 533 events-05 (work in progress), March 2002. 535 [15] Donovan, S., "The SIP INFO Method", RFC 2976, October 2000. 537 [16] Rosenberg, J., "The Session Initiation Protocol UPDATE Method", 538 draft-ietf-sip-update-02 (work in progress), May 2002. 540 [17] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 541 Responses in SIP", draft-ietf-sip-100rel-06 (work in progress), 542 February 2002. 544 Authors' Addresses 546 Rohan Mahy 547 Cisco Systems, Inc. 548 170 West Tasman Drive 549 San Jose, CA 95134 550 USA 552 EMail: rohan@cisco.com 554 Dan Petrie 555 Pingtel 556 400 West Cummings Park, Suite 2200 557 Woburn, MA 01801 558 USA 560 EMail: dpetrie@pingtel.com 562 Full Copyright Statement 564 Copyright (C) The Internet Society (2002). All Rights Reserved. 566 This document and translations of it may be copied and furnished to 567 others, and derivative works that comment on or otherwise explain it 568 or assist in its implementation may be prepared, copied, published 569 and distributed, in whole or in part, without restriction of any 570 kind, provided that the above copyright notice and this paragraph are 571 included on all such copies and derivative works. However, this 572 document itself may not be modified in any way, such as by removing 573 the copyright notice or references to the Internet Society or other 574 Internet organizations, except as needed for the purpose of 575 developing Internet standards in which case the procedures for 576 copyrights defined in the Internet Standards process must be 577 followed, or as required to translate it into languages other than 578 English. 580 The limited permissions granted above are perpetual and will not be 581 revoked by the Internet Society or its successors or assigns. 583 This document and the information contained herein is provided on an 584 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 585 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 586 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 587 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 588 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 590 Acknowledgement 592 Funding for the RFC Editor function is currently provided by the 593 Internet Society.