idnits 2.17.1 draft-campbell-simple-cpimmsg-sessions-00.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 11 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 152: '...yload. An endpoint MUST be willing to...' RFC 2119 keyword, line 153: '... text/plain, and MAY be willing to rec...' RFC 2119 keyword, line 155: '... list MUST contain an explicit entry...' RFC 2119 keyword, line 164: '... endpoint. Each endpoint MUST include...' RFC 2119 keyword, line 174: '... sessions, it MUST provide different...' (36 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 171 has weird spacing: '...hey are not u...' -- 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 25, 2002) is 7855 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: '7' is defined on line 468, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 477, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-campbell-simple-im-sessions-00 -- Possible downref: Normative reference to a draft: ref. '1' == Outdated reference: A later version (-08) exists of draft-ietf-impp-cpim-msgfmt-06 ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) ** Obsolete normative reference: RFC 1893 (ref. '5') (Obsoleted by RFC 3463) ** Obsolete normative reference: RFC 1894 (ref. '6') (Obsoleted by RFC 3464) == Outdated reference: A later version (-08) exists of draft-ietf-msec-mikey-04 Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Campbell 3 Internet-Draft J. Rosenberg 4 Expires: April 25, 2003 dynamicsoft 5 J. Peterson 6 NueStar 7 October 25, 2002 9 Instant Message Transport Sessions using the CPIM Message Format. 10 draft-campbell-simple-cpimmsg-sessions-00 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2003. 35 Copyright Notice 37 Copyright (C) The Internet Society (2002). All Rights Reserved. 39 Abstract 41 Instant Messaging (IM) refers to the transfer of messages between 42 users in near real-time. These messages are usually, but not 43 required to be, short. IMs are often used in a conversational mode, 44 that is, the transfer of messages back and forth is fast enough for 45 participants to maintain an interactive conversation. Each message 46 can be sent independently using the SIP MESSAGE method, or messages 47 can be associated into sessions that are initiated using SIP. The 48 first approach is often referred to as pager-mode messaging, due to 49 its similarity to the behavior of two way pager devices. The second 50 approach is often called session-mode messaging, or simply message 51 sessions. This document describes a message session mechanism based 52 on the Common Presence and Instant Messaging message format. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. CPIM Transport Sessions . . . . . . . . . . . . . . . . . . 3 58 3. Use of CPIM Message Format . . . . . . . . . . . . . . . . . 3 59 4. Session Creation . . . . . . . . . . . . . . . . . . . . . . 4 60 4.1 M-Line Format List . . . . . . . . . . . . . . . . . . . . . 4 61 4.2 Determining the Local and Remote URIs . . . . . . . . . . . 4 62 4.3 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 5 63 5. Sending Messages . . . . . . . . . . . . . . . . . . . . . . 5 64 6. Receiving Messages . . . . . . . . . . . . . . . . . . . . . 6 65 6.1 Message Framing . . . . . . . . . . . . . . . . . . . . . . 6 66 6.2 Parsing the Received Message . . . . . . . . . . . . . . . . 6 67 6.3 Confirmation of Receipt . . . . . . . . . . . . . . . . . . 6 68 6.3.1 Syntax for message/im-delivery-status . . . . . . . . . . . 7 69 7. Intermediaries . . . . . . . . . . . . . . . . . . . . . . . 8 70 8. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 9 71 9. Security Considerations . . . . . . . . . . . . . . . . . . 9 72 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 9 73 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 9 74 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 10 75 Normative References . . . . . . . . . . . . . . . . . . . . 10 76 Informational References . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 11 78 Full Copyright Statement . . . . . . . . . . . . . . . . . . 12 80 1. Introduction 82 The SIP MESSAGE method specification [8] defines how to send instant 83 messages directly inside SIP [3]. These instant messages follow a 84 model similar to that of a two way pager device, i.e. there is not a 85 protocol relationship between one message and another. An 86 alternative model is the session model [1]. In this model, a SIP 87 invitation is used to establish an instant messaging session. This 88 session can provide context to the messages, for features such as 89 sequencing and session key establishment. 91 The SIMPLE IM Session document [1] describes how to use SIP to 92 establish message sessions in general. That document does not 93 however, specify a message session transport mechanism. 95 This document describes such a mechanism based on the CPIM message 96 format [2]. It uses TCP or TLS as the underlying transport. This 97 document also describes extensions to the CPIM format for purposes of 98 transaction identification. The mechanism described herein allows 99 for sessions to be established directly between endpoints, as well as 100 the use of intermediaries. It provides a mechanism for end-to-end 101 protection of message contents. 103 2. CPIM Transport Sessions 105 A CPIM transport session consists of a series of CPIM message format 106 messages [2] exchanged over TCP or TLS. These sessions may be 107 established using the Session Initiation Protocol as described in [1] 108 . A TCP or TLS connection established to carry a CPIM transport 109 session may be reused for other CPIM transport sessions. In 110 particular, each connection is bi-directional and may carry more than 111 one session at a time. 113 3. Use of CPIM Message Format 115 The CPIM message format [2] uses a MIME based format, with additional 116 meta-data headers. Several meta-data headers are defined in the CPIM 117 message specification. Additionally, the cpim format makes use of an 118 outer MIME envelope, which always has a content-type of "message/ 119 cpim". The payload inside a CPIM message is expressed in MIME as 120 well, with its own MIME headers. 122 When used in an instant message session, the From and To meta-data 123 headers are used to identify the session. There is no expectation 124 that these headers actually identify the participants in the session- 125 -they are used only as tokens to identify the session itself. 126 Effectively, the recipient of the message is not a user, but a 127 session context established by SIP. 129 CPIM transport sessions use an extension header known as MsgID. 130 MsgID serves as a message identifier for purposes of delivery 131 confirmation. MsgID is an integer value unique at the scope of 132 session and direction, i.e. the local MsgID of one endpoint is 133 independent of that of the other. An endpoint increments its by one 134 MsgID for each message sent on in the session. 136 4. Session Creation 138 CPIM transport session parameters are negotiated using SDP offer/ 139 answer exchanges as described in the SIMPLE IM Sessions specification 140 [1]. TCP and TLS connections are also managed in accordance with 141 that specification. Note that a single connection may support more 142 than one session. Every session has one associated connection, but a 143 connection may have zero of more associated sessions. 145 4.1 M-Line Format List 147 The IM Session specification states that the protocol parameter 148 indicates the session mechanism and transport protocol. For CPIM 149 transport sessions, this value must be "cpim/tcp" for TCP, or "cpim/ 150 tls" for TLS. Format list entries are used to designate payload 151 types that the endpoint is willing to accept. These entries take the 152 form of the MIME type of the payload. An endpoint MUST be willing to 153 receive payloads of type text/plain, and MAY be willing to receive 154 other types. Even though text/plain support is required, the format 155 list MUST contain an explicit entry for it. For example, an endpoint 156 is willing to accept HTML in addition to the required plain text 157 might create an m-line like the following: 159 m=message 8937 cpim/tls text/plain text/html 161 4.2 Determining the Local and Remote URIs 163 Each endpoint proposes its local URI, and gets the remote URI from 164 the SDP sent by the opposite endpoint. Each endpoint MUST include 165 its proposed URI in an SDP a-line, with a parameter type of "uri". 166 For example: 168 a=uri:im:e9eu7fe@foo.example.com 170 CPIM transport sessions use the URIs only for session identification. 171 They are not used for determining the address of the opposite 172 endpoint. The URI represents the message transport session context. 173 If an endpoint wishes to participate in multiple simultaneous 174 sessions, it MUST provide different URIs for each session. The URI 175 MUST be globally unique, in order to allow the session relay 176 mechanism described later in this document. 178 4.3 Example SDP Exchange 180 Endpoint A wishes to invite Endpoint B to a CPIM transport session. 181 A offers the following session description containing the following 182 lines: 184 c=IN IP4 alice.example.com 185 m=message 7394 cpim/tcp text/plain 186 a=direction:both 187 a=uri:im:2s93i9@alice.example.com 189 Endpoint B chooses to participate, but prefers to initiate the 190 connection. B answers with a media description including the 191 following lines: 193 c=IN IP4 bob.example.com 194 m=message 8493 cpim/tcp text/plain 195 a=direction:active 196 a=uri:im:849ro3@bob.example.com 198 B then opens a TCP connection to alice.example.com:7394, and can send 199 CPIM transport session messages with a remote URI of 200 im:2s93i9@alice.example.com and a local URI of 201 im:849ro3@bob.example.com. And of course, A can send messages on the 202 same connection with the same URIs, swapping local and remote. 204 5. Sending Messages 206 When an endpoint wishes to send an instant message on a CPIM 207 transport session, it constructs a CPIM message. This message MUST 208 contain a To meta-data header value equal to the remote URI, and a 209 From meta-data header value, which SHOULD be used to identify the 210 sender, but MAY be set to some other value for purposes of anonymity 211 . The endpoint MUST insert a MsgID meta-data header. If this is the 212 first message that the endpoint has sent on this particular session, 213 it MUST initialize the local MsgID the value of 1. Each subsequent 214 message MUST increment the MsgID by one. 216 The message MAY include a DateTime header. This can be used to 217 simply convey the sending time of the message, and can also be used 218 to provide additional uniqueness in the message. 220 Furthermore, a message MAY contain a Subject header. This is 221 distinct from the Subject of the SIP invitation, which contains the 222 purpose of the session. The CPIM Subject header indicates the 223 subject of the specific message, and can provide a form of threading 224 within the session. 226 The endpoint MUST also set the outer MIME envelope. This MUST 227 include exactly two MIME headers. The first MUST be a content-type 228 header with a value of "message/cpim". The second MUST be a content- 229 length header in the outer MIME envelope, which specifies the length 230 of the entire contents of the outer envelope. This is made up of the 231 total length of all meta-data headers, the inner separator line, all 232 inner MIME headers, the inner separator line, and the inner MIME 233 payload. 235 The endpoint then MUST place the message payload into the inner MIME 236 body, with the appropriate MIME headers. These MUST include a 237 Content-Type header, and MAY include other MIME headers. 239 Once the message is constructed, the endpoint MUST send the message 240 on the connection associated with this session. 242 6. Receiving Messages 244 When an endpoint receives data on the connection associated with one 245 or more sessions, it first attempts to frame the message. 247 6.1 Message Framing 249 The receiving endpoint MUST discard any data prior to a first outer 250 MIME header. This will always be a Content-type header with a value 251 of "message/cpim". The second header will be a Content-length 252 header. The receiver determines the length of the message from the 253 outer Content-length header. 255 6.2 Parsing the Received Message 257 Once a message is framed, the receiving endpoint MUST read the To and 258 From meta-data headers. If these do not match an existing session 259 that is associated with the connection, the receiver SHOULD discard 260 the message in its entirety. 262 Once the receiver has determined that the message matches a session, 263 it renders the inner body to the session user, following normal MIME 264 rules. The receiver can group the messages into conversations based 265 on the session identifiers, and can use the MsgID to indicate 266 ordering, if so desired. 268 6.3 Confirmation of Receipt 270 Under normal operation, each message sent from one user to another is 271 unacknowledged beyond any transport layer acknowledgements. However, 272 in the case of intermediaries, transport layer acknowledgements are 273 not sufficient to determine the final status of the delivery of an IM 274 to the recipient. To support such an acknowledgement, this 275 specification provides a delivery status confirmation function. 277 A UA indicates its desire to receive delivery confirmations by 278 including the MIME content type of a confirmation format in its list 279 of supported message types. All UA MUST, at a minimum, support 280 message/im-delivery-status, described below. A UA that wishes to 281 receive delivery confirmations MUST explicitly include message/im- 282 delivery-status in the list of supported message types. It MAY also 283 include other message types. 285 If a UA has requested confirmations by including at least one 286 confirmation format in its list of supported message types, its peer 287 MUST generate a delivery status report for each message received in 288 the session. The format of the delivery status report MUST be one of 289 the formats listed in the supported message types by the opposite UA. 290 The only exception is for message confirmations themselves. That is, 291 a UA MUST NOT send a message confirmation for the receipt of a 292 message confirmation. When a confirmation report is sent, it is sent 293 as would any other message within the session. This means that it is 294 encapsulated in the message/cpim wrapper, it will have a MsgID one 295 higher than the previous message transmitted, and the To and From 296 meta-data fields will be set as described above. 298 The format of the mesage/im-delivery-status borrows from RFC 1894 299 [6], but is simpler in structure because of the differences between 300 session-mode messaging and the pager-like architecture of email. 301 This new syntax is described in Section Section 6.3.1. Each IM 302 delivery status message MUST include an Original-MsgID header field, 303 which contains the MsgID of the message begin acknowledged. The 304 Action and Status fields are optional, and their semantics are 305 defined in RFC 1894 [6] and RFC 1893 [5]. 307 [Open Issue: do we want to reuse these? RFCs 1893/4 really refer to 308 status codes from a relay. Session mode messaging is end-to-end. 309 However, an endpoint can be a relay (such as an SMS gateway) or even 310 an expander (a conference server). Therefore, the semantics of the 311 various values don't quite match our use cases.] 313 [Open Issue: For an IM conference server, do we want to support per- 314 recipient confirmations, or just one confirmation from the server? ] 316 6.3.1 Syntax for message/im-delivery-status 318 A message of type message/im-delivery-status contains a series of 319 name/value pairs separated by CRLF. 321 im-status = *header-field 322 header-field = (original-msgid / action / status / extension-header) CRLF 323 original-msgid = "Original-MsgID" HCOLON *DIGIT 324 action = see RFC 1894 325 Status = see RFC 1894 327 7. Intermediaries 329 The CPIM transport session mechanism can support the use of session 330 aware message relays. While end-to-end sessions are encouraged, 331 there are a number of applications where such relays may be needed. 332 For example, such intermediaries may serve as firewall and NAT 333 traversal points. They may also server as policy enforcement points. 335 +--------+ +--------+ 336 | | SIP | | 337 | P1 +-----------------+ P2 | 338 /| | | |\ 339 / +------+-+ +-+------+ \ SIP 340 SIP / | | \ 341 / |Control | \ 342 / |Interface | \ 343 / | | \ 344 +----/---+ +-+------+ +------+-+ +----\---+ 345 | | | | | | | | 346 | C1 +-------+ R1 +-------+ R2 +------+ C2 | 347 | | CPIM | | CPIM | | CPIM| | 348 +--------+ +--------+ +--------+ +--------+ 350 The above diagram shows an example of message relays controlled by 351 SIP proxy servers. The SIP session setup crosses through proxies P1 352 and P2. Each proxy MAY rewrite the C-line address and the M-line 353 port to refer to its associated relays address and port, and request 354 the associated relay to install the relevant session state. The 355 proxies MAY also re-write the protocol parameter on the M-line. The 356 re-written protocol parameter MUST designate a transport otherwise 357 supported by the CPIM transport session mechanism. If the SDP 358 includes a direction attribute including a source address and port, 359 the proxy MUST also re-write this to the source address and port the 360 relay will use. Proxies MUST NOT change any other field in the SDP. 362 R1 and R2 are likely to be traversed by any number of sessions. For 363 reasons of congestion-safety, it is desirable to share a small number 364 of connections between all such sessions. Therefore message session 365 relays MUST be capable of sharing a connection between multiple 366 sessions. Such relays MUST NOT use the port number to de-multiplex 367 sessions, rather they MUST identify sessions using the normal CPIM 368 transport session identification fields, that is, the From and To 369 meta-data headers. 371 The control interface between the controlling proxies and the message 372 session relays is not in scope for this document. In many cases, the 373 proxy and relay functions will simply be collocated. 375 8. Definitions 377 [To do: We probably need formal definitions for MsgID, and for the 378 URI a-line attributes.] 380 9. Security Considerations 382 All IM session protocols must be compliant with the IM security 383 requirements in RFC2779 [10]. The CPIM message format [2] contains 384 its own security considerations, compliant with RFC2779, for 385 providing end-to-end authentication, confidentiality, and integrity 386 properties for CPIM messages. All implementations of this 387 specification MUST follow the normative security requirements 388 described in that specification. 390 Note that the baseline SIP IM sessions specification [1] contains 391 Security Considerations for the negotiation of session keys via SDP 392 [4]; implementations of this specification MUST be able to derive 393 session keys for the aforementioned security mechanisms from the 394 procedures described in that specification [1]. 396 [Open Issues: We need to reconsile the session key requirement of the 397 IM Sessions draft with the S/MIME usage of message/cpim. Is it 398 feasible to use a session key negotiated in the SDP exchange as 399 either a symmetric KEK or a CEK in S/MIME? Is TLS sufficient if 400 intermediaries are not involved? 402 10. IANA Considerations 404 [To do -- if we define a CPIM name space for MsgID. Also, I am 405 unsure if we need to register the URI a-line attribute] 407 The receipt confirmation message format (message/im-delivery-status) 408 will require IANA registration. 410 11. Open Issues 412 Do we really want to use the RFC 1894 and RFC 1893 meanings for 413 Action and Status field in delivery status report messages?. Also, 414 would a conference server or similar device be expected to pass 415 delivery reports back to the message originator? 417 The intermediary section will change significantly. We do not wish 418 to encourage implementers to allow proxies to modify SDP. Rohan has 419 suggested a mechanism to use something conceptually similar to the 420 SIP Route header. Does that belong in this draft, or in a separate 421 document? 423 The security considrations section needs more work. There are 424 several relevant controversies. First, how do we reconcile the idea 425 of a session key negotiated in the SDP with the S/MIME requirements 426 of the message/cpim format. Second, do we really wish to use MIKEY 427 for session key negotiation, or can we get by with something simpler? 429 The draft needs more examples and formal definitions. 431 12. Contributors 433 The following people contributed substantially to this document: 435 Rohan Mahy 436 Allison Mankin 437 Jon Peterson 438 Brian Rosen 439 Jonathan Rosenberg 440 Robert Sparks 441 Dean Willis 443 Normative References 445 [1] Campbell, B. and J. Rosenberg, "Instant Message Sessions in 446 SIMPLE", draft-campbell-simple-im-sessions-00 (work in 447 progress), October 2002. 449 [2] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging 450 Message Format", draft-ietf-impp-cpim-msgfmt-06 (work in 451 progress), February 2001. 453 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 454 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 455 Session Initiation Protocol", RFC 3261, June 2002. 457 [4] Handley, M. and V. Jacobson, "SDP: Session Description 458 Protocol", RFC 2327, April 1998. 460 [5] Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893, 461 January 1996. 463 [6] Moore, K. and G. Vaudreuil, "An Extensible Message Format for 464 Delivery Status Notifications", RFC 1894, January 1996. 466 Informational References 468 [7] Crocker, D., Diacakis, A., Mazzoldi, F., Huitema, C., Klyne, 469 G., Rose, M., Rosenberg, J., Sparks, R., Sugano, H. and J. 470 Peterson, "A Common Profile for Instant Messaging (CPIM)", 471 draft-ietf-impp-cpim-03 (work in progress), August 2002. 473 [8] Campbell, B. and J. Rosenberg, "Session Initiation Protocol 474 Extension for Instant Messaging", draft-ietf-sip-message-07 475 (work in progress), September 2002. 477 [9] Arkko, J., "MIKEY: Multimedia Internet KEYing", draft-ietf- 478 msec-mikey-04 (work in progress), August 2002. 480 [10] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 481 Presence Protocol Requirements", RFC 2779, February 2000. 483 Authors' Addresses 485 Ben Campbell 486 dynamicsoft 487 5100 Tennyson Parkway 488 Suite 1200 489 Plano, TX 75024 491 EMail: bcampbell@dynamicsoft.com 493 Jonathan Rosenberg 494 dynamicsoft 495 72 Eagle Rock Avenue 496 First Floor 497 East Hanover, NJ 07936 499 EMail: jdrosen@dynamicsoft.com 501 Jon Peterson 502 NueStar 503 1800 Sutter St. 504 Suite 570 505 Concord, CA 94520 507 Full Copyright Statement 509 Copyright (C) The Internet Society (2002). All Rights Reserved. 511 This document and translations of it may be copied and furnished to 512 others, and derivative works that comment on or otherwise explain it 513 or assist in its implementation may be prepared, copied, published 514 and distributed, in whole or in part, without restriction of any 515 kind, provided that the above copyright notice and this paragraph are 516 included on all such copies and derivative works. However, this 517 document itself may not be modified in any way, such as by removing 518 the copyright notice or references to the Internet Society or other 519 Internet organizations, except as needed for the purpose of 520 developing Internet standards in which case the procedures for 521 copyrights defined in the Internet Standards process must be 522 followed, or as required to translate it into languages other than 523 English. 525 The limited permissions granted above are perpetual and will not be 526 revoked by the Internet Society or its successors or assigns. 528 This document and the information contained herein is provided on an 529 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 530 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 531 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 532 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 533 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 535 Acknowledgement 537 Funding for the RFC Editor function is currently provided by the 538 Internet Society.