idnits 2.17.1 draft-mierla-simple-xmpp-interworking-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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) == There are 8 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 156 has weird spacing: '...sent in eithe...' == Line 158 has weird spacing: '... both proto...' -- 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 (October 23, 2003) is 7484 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 552 looks like a reference -- Missing reference section? '3' on line 558 looks like a reference -- Missing reference section? '2' on line 555 looks like a reference -- Missing reference section? '9' on line 579 looks like a reference -- Missing reference section? '11' on line 587 looks like a reference -- Missing reference section? '8' on line 576 looks like a reference -- Missing reference section? '10' on line 583 looks like a reference -- Missing reference section? '4' on line 562 looks like a reference -- Missing reference section? '5' on line 566 looks like a reference -- Missing reference section? '6' on line 570 looks like a reference -- Missing reference section? '7' on line 573 looks like a reference Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Mierla 3 Internet-Draft Fraunhofer FOKUS 4 Expires: April 22, 2004 October 23, 2003 6 SIMPLE-XMPP Interworking 7 draft-mierla-simple-xmpp-interworking-01 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 22, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This document describes the behavior for the logical entity named the 38 SIMPLE-XMPP Interworking Function (SIMPLE-XMPP IWF) that allows the 39 interworking between the SIMPLE (Session initiation protocol for 40 Instant Messaging and Presence Leveraging Extensions) and XMPP 41 (eXtensible Messaging and Presence Protocol - also known as Jabber 42 protocol) protocols. It refers to the conversion of the message 43 format from one to the other protocol. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. Conventions Used in this Document . . . . . . . . . . . . . . 3 51 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3.1 IWF (InterWorking Function) . . . . . . . . . . . . . . . . . 3 53 3.2 SIMPLE Server . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3.3 XMPP Server . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3.4 EndPoint . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.5 'Non Signaling' message . . . . . . . . . . . . . . . . . . . 4 57 3.6 'Signaling' message . . . . . . . . . . . . . . . . . . . . . 4 59 4. Functional Requirements and Behaviour of the SIMPLE-XMPP 60 IWF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.1 Basic Configuration . . . . . . . . . . . . . . . . . . . . . 4 62 4.2 Advanced Configuration . . . . . . . . . . . . . . . . . . . . 4 63 4.3 Functionality . . . . . . . . . . . . . . . . . . . . . . . . 4 65 5. General Interworking Requirements . . . . . . . . . . . . . . 5 67 6. Mapping between SIMPLE and XMPP . . . . . . . . . . . . . . . 6 68 6.1 General Procedures . . . . . . . . . . . . . . . . . . . . . . 6 69 6.2 Message Type Conversion . . . . . . . . . . . . . . . . . . . 6 70 6.3 Presence Specific Attributes Conversion . . . . . . . . . . . 7 72 7. Managing the message flow . . . . . . . . . . . . . . . . . . 7 74 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 9. Examples and scenarios . . . . . . . . . . . . . . . . . . . . 8 77 9.1 Basic Instant Messaging sequence . . . . . . . . . . . . . . . 9 78 9.2 Sample message conversion . . . . . . . . . . . . . . . . . . 9 80 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 82 A. Revision History . . . . . . . . . . . . . . . . . . . . . . . 12 83 A.1 Changes from draft-mierla-simple-xmpp-interworking-00 . . . . 12 85 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 87 C. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 Intellectual Property and Copyright Statements . . . . . . . . 14 91 1. Introduction 93 SIMPLE [1] extends the Session Initiation Protocol with Instant 94 Messaging and Presence functionality. The Session Initiation Protocol 95 (SIP) [3] was designed to initiate and manipulate media 'sessions' 96 between communicating parties. 98 XMPP is an XML-based streaming protocol designed for Instant 99 Messaging and Presence [2]. 101 The primary objective of a SIMPLE-XMPP Interworking function (IWF) is 102 to provide protocol conversion between SIMPLE and XMPP protocols. The 103 document describes the requirements and behavior of the SIMPLE-XMPP 104 Interworking function for conversion of the SIMPLE and XMPP 105 protocols. 107 How to use SIP to initiate XMPP chat sessions [9] or how to initiate 108 sessions over XMPP [11] are not the subject of the present document. 110 2. Conventions Used in this Document 112 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 113 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 114 and "OPTIONAL" are to be interpreted as described in RFC 2119 [8] and 115 indicate requirement levels for the protocol. 117 3. Definitions 119 3.1 IWF (InterWorking Function) 121 Performs interworking between SIMPLE and XMPP protocols. 123 3.2 SIMPLE Server 125 This can be either a SIP proxy, redirect or registrar server [3] that 126 supports SIMPLE. 128 3.3 XMPP Server 130 Any entity that acts according to the definition of entity 'Server' 131 for XMPP protocol [2]. 133 3.4 EndPoint 135 An endpoint can send and can receive instant messages. An endpoint is 136 an entity from which the instant message originates or terminates. An 137 endpoint can either be a SIMPLE client or an XMPP client. 139 3.5 'Non Signaling' message 141 Any message which does not change the state of IWF within an Instant 142 Messaging sequence. 144 3.6 'Signaling' message 146 Any message which changes the state of IWF within an Instant 147 Messaging sequence. 149 4. Functional Requirements and Behaviour of the SIMPLE-XMPP IWF 151 SIMPLE-XMPP IWF can be designed in various ways. This may include 152 coexistence of SIMPLE Servers and/or XMPP Servers with IWF. The 153 co-location of the SIMPLE server and/or XMPP server in conjunction 154 with the IWF is a matter of implementation and not a protocol issue. 155 There shall be no assumptions made for the optional elements and 156 components present in either SIMPLE or XMPP networks. The solution 157 provided here shall work for a minimum configuration required for 158 both protocols. There may be recommendations for other 159 configurations, which include optional components. 161 4.1 Basic Configuration 163 SIMPLE EndPoint <---------> IWF <---------> XMPP EndPoint 165 4.2 Advanced Configuration 167 SIMPLE EP <---> SIMPLE Srv <---> IWF <---> XMPP Srv <---> XMPP EP 169 4.3 Functionality 171 Therefore, an IWF must contain the following functions: 173 a) Instant Messaging flow management between SIMPLE and XMPP 174 protocols. The incoming Instant Messaging message from any endpoint 175 must be delivered to the other endpoint after the protocol 176 conversion. 178 b) Address resolution for the two protocols. 180 The IWF should contain the following functions: 182 a) Presence flow management between SIMPLE and XMPP protocols. The 183 incoming presence message from any endpoint must be delivered to the 184 other endpoint after the protocol conversion. 186 The IWF may contain the following functions: 188 a) Interoperability Service reservation and release. The IWF may 189 reserve some messages to act as 'Signaling' messages, but these 190 messages must be known by all parts involved in usage of IWF (e.g., 191 the SIMPLE SUBSCRIBE message intended for a XMPP conference may be 192 interpreted by IWF as 'joining' the conference and act according to). 193 The IWF may release any resource that was not released by any of the 194 parts involved in an IM sequence and is no longer in use (e.g., when 195 an IM sequence is ended and for unknown reasons one part does not 196 close the connection established with the IWF, the IWF may release 197 any resource related to it). 199 b) Ability to provide the state of the Interoperability Service. The 200 IWF may inform the endpoints about the state of IWF, like stop, 201 restart and so on. 203 c) Ability to process the messages for supplementary services (file 204 transfer, ...) if the service is supported by the all parts of the 205 Instant Messaging flow. 207 5. General Interworking Requirements 209 The IWF shall provide the seamless interworking of the two protocols. 210 The functioning of IWF must not involve any modification to the 211 SIMPLE and XMPP protocols, but may involve specific profiles of these 212 protocols. 214 The IWF should: 216 a) Follow the mandatory requirements as defined by SIMPLE protocol 217 and XMPP protocol 219 b) Support all the addressing schemes of both SIMPLE and XMPP 220 protocols. 222 c) Release any related resources on the detection of the end of the 223 Instant Messaging flow between two parts. 225 d) Not make any assumptions about the capabilities of either SIMPLE 226 client or XMPP client. 228 The IWF may: 230 a) Have a look-up table for resolving the addresses. 232 b) Use any type of data storage for keeping address resolution 233 information. 235 c) Use DNS for address resolution 236 d) Define a set of 'Signaling' messages without changing the SIMPLE 237 protocol or XMPP protocol 239 6. Mapping between SIMPLE and XMPP 241 To convert SIP messages to XMPP messages and vice-versa the IWF must 242 follow the general mapping procedures. 244 6.1 General Procedures 246 a) A clear mapping between SIMPLE and XMPP addresses shall be 247 provided to support all the addressing schemes of both SIMPLE and 248 XMPP protocols. 250 b) A clear mapping between SIMPLE and XMPP messages shall be provided 251 to reflect similar meaning in the Instant Messaging sequence. 253 c) For a given message of a given protocol, there may not be a 254 corresponding message of the other protocol that may appear to be 255 equivalent. The IWF needs to create a mapping between the messages or 256 generate error messages based on common understanding of an agreed 257 upon standard. 259 d) A clear mapping between SIMPLE and XMPP message attributes shall 260 be provided to reflect similar meaning in the two protocols. 262 e) All attributes used in each message on one side may not match 263 exactly the corresponding message of the other side. In this 264 situation, some manipulations need to be done by the IWF so that an 265 agreed-upon standard can be created based on common under-standing 266 although all attributes do not exactly match. 268 f) The messages that do not have a match on the other side should be 269 terminated on the IWF, and IWF should take the necessary action on 270 them (e.g, silently discard of any unknown message). 272 g) In case the IWF is required to generate a message on its own in 273 any of the sides, IWF should follow the mandatory requirements as 274 defined by SIMPLE protocol or XMPP protocol. 276 6.2 Message Type Conversion 278 The message types of the two protocols are to be converted as 279 follows: 281 +----------------+--------------+ 282 | SIMPLE Message | XMPP Message | 283 +================+==============+ 284 | MESSAGE | MESSAGE | 285 |----------------|--------------| 286 | SUBSCRIBE | PRESENCE | 287 | NOTIFY | | 288 |----------------|--------------| 289 | REGISTER | IQ | 290 +----------------+--------------+ 292 Figure 1 294 The common attributes of the messages of the two protocols are to be 295 converted as follows 297 +------------------+----------------+ 298 | SIMPLE Attribute | XMPP Attribute | 299 +==================+================+ 300 | From | from | 301 |------------------|----------------| 302 | To | to | 303 |------------------|----------------| 304 | Call-ID | thread | 305 |------------------|----------------| 306 | CSeq | id | 307 |------------------|----------------| 308 | Message body | body | 309 +------------------+----------------+ 311 Figure 2 313 Any other attribute from any of the two protocols may be converted 314 into an attribute of the other protocol if the meaning of the 315 attribute is not changed. Any attribute which does not have a similar 316 meaning attribute in the other protocol must be silently discarded. 318 6.3 Presence Specific Attributes Conversion 320 SIMPLE uses PIDF [10] format to carry the presence information and 321 the XMPP presence attributes must be converted to satisfy the PIDF 322 format and meaning. Other details are subject for further 323 discussions. 325 7. Managing the message flow 327 The management of the messages shall follow the following guidelines: 329 a) Unexpected messages in a particular state of the Instant Messaging 330 sequence shall be treated as 'Error' messages. 332 b) All messages which do not change the state of the Instant 333 Messaging sequence shall be treated as 'Non Signaling' messages. 335 c) All messages which expect a change in state of the Instant 336 Messaging sequence shall be treated as 'Signaling' messages. 338 d) The content of all 'Non Signaling' messages must be delivered with 339 no change to the destination. 341 e) The 'Signaling' messages may end at IWF or may be delivered to the 342 destination in the appropriate meaning form. 344 8. Security Considerations 346 A security scheme should be enabled in the IWF. A simple security 347 scheme may be when the IWF will accept only requests from a 348 pre-configured set of SIMPLE Servers or XMPP server only and it will 349 reject all other requests. 351 All other security requirements are for further discussion. 353 Assumptions for the endpoints: 355 a) All endpoints trying to use IWF are authorized with the respective 356 SIMPLE servers or XMPP servers. 358 Required for the endpoints: 360 a) All endpoints trying to make open an Instant Messaging flow using 361 IWF are respectively permitted to do so from IWF, as long as their 362 messages pass an accepted SIMPLE or XMPP server first. 364 Required for IWF 366 a) Procedures for preventing denial of service security attacks. 368 b) Maintaining persistent data for authorized endpoints for future 369 verifications. 371 9. Examples and scenarios 373 This section describes some examples of Instant Messaging scenarios 374 that will show primarily the input and output messages of the IWF for 375 interworking between SIMPLE and XMPP. 377 9.1 Basic Instant Messaging sequence 379 The 'Signaling' messages (control messages) may be represented by the 380 Presence Messages, if the Presence is supported by the EndPoint. 382 SIMPLE XMPP 383 EP IWF EP 384 | | | 385 | SIMPLE Ctrl Msg | | 386 |------------------>| XMPP Ctrl Msg | 387 | 200 OK |<--------------->| 388 |<------------------| | 389 | | | 390 | ............... | ............. | 391 | | | 392 | SIMPLE IM Msg | XMPP IM Msg | 393 |------------------>|---------------->| 394 | 202 Accepted | | 395 |<------------------| | 396 | | | 397 | ............... | ............. | 398 | | | 399 | SIMPLE IM Msg | XMPP IM Msg | 400 |<------------------|<----------------| 401 | 200 OK | | 402 |------------------>| | 403 | | | 404 | ............... | ............. | 405 | | | 407 Figure 3 409 9.2 Sample message conversion 411 Scenario: 412 - SIP server with SIMPLE support is sipserver.com 413 - XMPP server is xmppserver.com 414 - xmpp.sipserver.com is a DNS alias for SIP server 415 - sip.xmppserver.com is a DNS alias for XMPP server 416 - all SIP messages for xmpp.sipserver.com will be processed by IWF 417 - all XMPP messages for sip.xmppserver.com will be processed by 418 IWF 419 - address mapping between SIMPLE and XMPP 420 The XMPP address 'xuser@xmppserver.com' is mapped by SIMPLE server 421 as 'xuser*xmppserver.com@xmpp.sipserver.com'. 422 The SIP address 'suser@sipserver.com' is mapped by XMPP server as 423 'suser*sipserver.com@sip.xmmpserver.com'. 425 a) Sample Instant Messaging message 427 Example of a SIMPLE message for an XMPP endpoint 429 | MESSAGE sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0 430 | Via: SIP/2.0/UDP xmmp.sipserver.com;branch=as42tbK14rfaFhxzi 431 | From: ;tag=49394 432 | To: 433 | Call-ID: arnskGnska@1.2.3.4 434 | CSeq: 1 MESSAGE 435 | Content-Type: text/plain 436 | Content-Length: 6 437 | 438 | Hello! 440 The appropriate XMPP message generated by IWF 442 | 445 | hello! 446 | 448 Example of an XMPP message for a SIMPLE endpoint 450 | 453 | hi! 454 | 456 The appropriate SIMPLE message generated by IWF 458 | MESSAGE sip:suser@sipserver.com SIP/2.0 459 | Via: SIP/2.0/UDP xmpp.sipserver.com;branch=ld82682JUgskF12ed 460 | From: ;tag=49394 461 | To: 462 | Call-ID: sgRTk893HG@5.6.7.8i 463 | CSeq: 1 MESSAGE 464 | Content-Type: text/plain 465 | Content-Length: 3 466 | 467 | Hi! 469 Figure 4 471 b) Sample Presence messages 473 SIMPLE message 475 | NOTIFY sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0 476 | Via: SIP/2.0/UDP xmpp.sipserver.com;branch=as42tbK14rfaFhxzi 477 | From: ;tag=49394 478 | To: 495 SIMPLE message 497 | SUBSCRIBE sip:xuser*xmppserver.com@xmpp.sipserver.com SIP/2.0 498 | Via: SIP/2.0/UDP xmpp.sipserver.com;branch=as42tbK14rfaFhxzi 499 | From: ;tag=49394 500 | To: 501 | Call-ID: 4tqsdf430@1.2.3.4 502 | CSeq: 1 SUBSCRIBE 503 | Max-Forwards: 20 504 | Event: presence 505 | Accept: application/cpim-pidf+xml 506 | Expires: 1800 507 | Content-Length: 0 509 XMPP message 511 | 515 Figure 5 517 Author's Address 519 Daniel-Constantin Mierla 520 Fraunhofer FOKUS 521 Kaiserin-Augusta-Allee 31 522 Berlin 10589 523 Germany 525 EMail: mierla@fokus.fraunhofer.de 527 Appendix A. Revision History 529 A.1 Changes from draft-mierla-simple-xmpp-interworking-00 531 - Abstract adjusted. 533 - The word Jabber is now refered only in the abstract, otherwise it 534 was replaced with XMPP. 536 - New examples with XMPP to SIMPLE request conversion. 538 - The address translation within IWF is more intuitive in the sample 539 scenario. 541 Appendix B. Acknowledgments 543 I would like to acknowledge to Dorgham Sisalem and Jiri Kuthan from 544 Fraunhofer FOKUS Institute for their support for this work and to 545 Peter Saint-Andre from Jabber Software Foundation for reviewing the 546 document. Also, I would like to thank "Sip Express Router - SER" 547 development team and the Iptel.org for providing support with first 548 implementation of these specifications. 550 Appendix C. References 552 [1] B. Campbell et al. , "Session Initiation Protocol Extension for 553 Instant Messaging", RFC 3428, December 2002. 555 [2] P. Saint-Andre and J. Miller, "XMPP Core", Internet-Draft 556 "draft-ietf-xmpp-core-18", September 2003. 558 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 559 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session 560 Initiation Protocol", RFC 3261, June 2002. 562 [4] J. Rosenberg "A Presence Event Package for the Session 563 Initiation Protocol (SIP)", Internet Draft 564 "draft-ietf-simple-presence-10", 2003. 566 [5] B. Campbell, J. Rosenberg, "CPIM Mapping of SIMPLE Presence and 567 Instant Messaging", Internet Draft 568 "draft-ietf-simple-cpim-mapping-01", June 2002. 570 [6] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging", 571 Internet-Draft "draft-ietf-xmpp-im-09", April 2003. 573 [7] P. Saint-Andre and T. Bamonti, "XMPP CPIM Mapping", 574 Internet-Draft "draft-ietf-xmpp-cpim-02", August 2003. 576 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 577 Levels", BCP 14, RFC 2119, March 1997. 579 [9] R. Sparks, "Establishing Jabber Messaging Sessions with the 580 Session Initiation Protocol", Internet-Draft 581 "draft-sparks-simple-jabber-sessions-00", October 2002. 583 [10] H. Sugano et al., "Common Presence and Instant Messaging (CPIM) 584 Presence Information Data Format", Internet-Draft 585 "draft-ietf-impp-cpim-pidf-07", December 2002. 587 [11] J. Hildebrand, "CTINS: A Transport for Initiating and 588 Negotiating Sessions using SDPng over XMPP", Internet-Draft 589 "draft-hildebrand-xmpp-sdpng-00", February 2003. 591 Intellectual Property Statement 593 The IETF takes no position regarding the validity or scope of any 594 intellectual property or other rights that might be claimed to 595 pertain to the implementation or use of the technology described in 596 this document or the extent to which any license under such rights 597 might or might not be available; neither does it represent that it 598 has made any effort to identify any such rights. Information on the 599 IETF's procedures with respect to rights in standards-track and 600 standards-related documentation can be found in BCP-11. Copies of 601 claims of rights made available for publication and any assurances of 602 licenses to be made available, or the result of an attempt made to 603 obtain a general license or permission for the use of such 604 proprietary rights by implementors or users of this specification can 605 be obtained from the IETF Secretariat. 607 The IETF invites any interested party to bring to its attention any 608 copyrights, patents or patent applications, or other proprietary 609 rights which may cover technology that may be required to practice 610 this standard. Please address the information to the IETF Executive 611 Director. 613 Full Copyright Statement 615 Copyright (C) The Internet Society (2003). All Rights Reserved. 617 This document and translations of it may be copied and furnished to 618 others, and derivative works that comment on or otherwise explain it 619 or assist in its implementation may be prepared, copied, published 620 and distributed, in whole or in part, without restriction of any 621 kind, provided that the above copyright notice and this paragraph are 622 included on all such copies and derivative works. However, this 623 document itself may not be modified in any way, such as by removing 624 the copyright notice or references to the Internet Society or other 625 Internet organizations, except as needed for the purpose of 626 developing Internet standards in which case the procedures for 627 copyrights defined in the Internet Standards process must be 628 followed, or as required to translate it into languages other than 629 English. 631 The limited permissions granted above are perpetual and will not be 632 revoked by the Internet Society or its successors or assignees. 634 This document and the information contained herein is provided on an 635 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 636 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 637 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 638 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 639 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 641 Acknowledgment 643 Funding for the RFC Editor function is currently provided by the 644 Internet Society.