idnits 2.17.1 draft-moffitt-xmpp-over-websocket-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2013) is 3902 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HyBi Working Group L. Stout, Ed. 3 Internet-Draft &yet 4 Intended status: Standards Track J. Moffitt 5 Expires: February 20, 2014 E. Cestari 6 cstar industries 7 August 19, 2013 9 An XMPP Sub-protocol for WebSocket 10 draft-moffitt-xmpp-over-websocket-04 12 Abstract 14 This document defines a binding for the XMPP protocol over a 15 WebSocket transport layer. A WebSocket binding for XMPP provides 16 higher performance than the current HTTP binding for XMPP. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 20, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. XMPP Sub-Protocol . . . . . . . . . . . . . . . . . . . . . . 3 55 3.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3.3. XMPP Stream Setup . . . . . . . . . . . . . . . . . . . . 4 58 3.4. Stream Errors . . . . . . . . . . . . . . . . . . . . . . 4 59 3.5. Closing the Connection . . . . . . . . . . . . . . . . . 5 60 3.6. Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 6 62 3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . 6 63 3.9. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . 6 64 3.10. Stream Management . . . . . . . . . . . . . . . . . . . . 7 65 4. Discovering Connection Method . . . . . . . . . . . . . . . . 7 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 68 7. Informative References . . . . . . . . . . . . . . . . . . . 8 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 71 1. Introduction 73 Applications using XMPP (see [RFC6120] and [RFC6121]) on the Web 74 currently make use of BOSH (see [XEP-0124] and [XEP-0206]), an XMPP 75 binding to HTTP. BOSH is based on the HTTP long polling technique, 76 and it suffers from high transport overhead compared to XMPP's native 77 binding to TCP. In addition, there are a number of other known 78 issues with long polling [RFC6202], which have an impact on BOSH- 79 based systems. 81 It would be much better in most circumstances to avoid tunneling XMPP 82 over HTTP long polled connections and instead use the XMPP protocol 83 directly. However, the APIs and sandbox that browsers have provided 84 do not allow this. The WebSocket protocol [RFC6455] now exists to 85 solve these kinds of problems. The WebSocket protocol is a bi- 86 directional protocol that provides a simple message-based framing 87 layer over raw sockets and allows for more robust and efficient 88 communication in web applications. 90 The WebSocket protocol enables two-way communication between a client 91 and a server, effectively emulating TCP at the application layer and 92 therefore overcoming many of the problems with existing long-polling 93 techniques for bidirectional HTTP. This document defines a WebSocket 94 sub-protocol for the Extensible Messaging and Presence Protocol 95 (XMPP). 97 2. Terminology 99 The basic unit of framing in the WebSocket protocol is called a 100 message. In XMPP, the basic unit is the stanza, which is a subset of 101 the first-level children of each document in an XMPP stream (see 102 Section 9 of [RFC6120]). XMPP also has a concept of messages, which 103 are stanzas whose top-level element name is message. In this 104 document, the word "message" will mean a WebSocket message, not an 105 XMPP message stanza (see Section 3.2). 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in [RFC2119]. 111 3. XMPP Sub-Protocol 113 3.1. Handshake 115 The XMPP sub-protocol is used to transport XMPP over a WebSocket 116 connection. The client and server agree to this protocol during the 117 WebSocket handshake (see Section 1.3 of [RFC6455]). 119 During the WebSocket handshake, the client MUST include the |Sec- 120 WebSocket-Protocol| header in its handshake, and the value |xmpp| 121 MUST be included in the list of protocols. The reply from the server 122 MUST also contain |xmpp| in its own |Sec-WebSocket-Protocol| header 123 in order for an XMPP sub-protocol connection to be established. 125 Once the handshake is complete, WebSocket messages sent or received 126 will conform to the protocol defined in the rest of this document. 128 C: GET /xmpp-websocket HTTP/1.1 129 Host: example.com 130 Upgrade: websocket 131 Connection: Upgrade 132 Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 133 Origin: http://example.com 134 ... 135 Sec-WebSocket-Protocol: xmpp 136 Sec-WebSocket-Version: 13 138 S: HTTP/1.1 101 Switching Protocols 139 Upgrade: websocket 140 Connection: Upgrade 141 ... 142 Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 143 Sec-WebSocket-Protocol: xmpp 145 [WebSocket connection established] 147 C: 152 3.2. Messages 154 Data frame messages in the XMPP sub-protocol MUST be of the text type 155 and contain UTF-8 encoded data. The close control frame's contents 156 are specified in Section 3.5. Control frames other than close are 157 not restricted. 159 Unless noted in text, the word "message" will mean a WebSocket 160 message composed of text data frames. 162 3.3. XMPP Stream Setup 164 The first message sent after the handshake is complete MUST be an 165 XMPP opening stream tag as defined in XMPP [RFC6120] or an XML text 166 declaration (see Section 4.3.1 of [W3C.REC-xml-20081126]) followed by 167 an XMPP opening stream tag. The stream tag MUST NOT be closed (i.e. 168 the closing tag should not appear in the message) as 169 it is the start of the client's outgoing XML. The '<' character of 170 the tag or text declaration MUST be the first character of the text 171 payload. 173 The server MUST respond with a message containing an error (see 174 Section 3.4), its own opening stream tag, or an XML text declaration 175 followed by an opening stream tag. 177 Except in the case of certain stream errors (see Section 3.4), the 178 opening stream tag, , MUST appear in a message by 179 itself. 181 3.4. Stream Errors 183 Stream level errors in XMPP are terminal. Should such an error 184 occur, the server MUST send the stream error as a complete element in 185 a message to the client. 187 If the error occurs during the opening of a stream, the stream error 188 message MUST start with an opening stream tag (see Section 4.7.1 of 189 [RFC6120]) and end with a closing stream tag. 191 After the stream error and closing stream tag have been sent, the 192 server MUST close the connection as in Section 3.5. 194 3.5. Closing the Connection 196 Either the server or the client may close the connection at any time. 197 Before closing the connection, the closing party SHOULD close the 198 XMPP stream, if it has been established, by sending a message with 199 the closing tag. The XMPP stream is considered 200 closed when a corresponding tag is received from the 201 other party. 203 If a client closes the WebSocket connection without closing the XMPP 204 stream after having enabled stream management (see Section 3.10), the 205 server SHOULD keep the XMPP session alive for a period of time based 206 on server policy, as specified in [XEP-0198]. 208 To initiate closing the WebSocket connection, the closing party MUST 209 send a normal WebSocket close message with an empty body. The 210 connection is considered closed when a matching close message is 211 received (see Section 1.4 of [RFC6455]). 213 Except in the case of certain stream errors (see Section 3.4), the 214 closing stream tag, , MUST appear in a message by 215 itself. 217 An example of ending an XMPP over WebSocket session by first closing 218 the XMPP stream layer and then the WebSocket connection layer: 220 Client (XMPP WSS) Server 221 | | | | 222 | | | | 223 | |------------------------------------>| | 224 | | | | 225 | |<------------------------------------| | 226 | | | | 227 | | (XMPP Stream Closed) | | 228 | +-------------------------------------+ | 229 | | 230 | WS CLOSE FRAME | 231 |------------------------------------------>| 232 | WS CLOSE FRAME | 233 |<------------------------------------------| 234 | | 235 | (Connection Closed) | 236 +-------------------------------------------+ 238 3.6. Stanzas 240 Each XMPP stanza MUST be sent in its own message. A stanza MUST NOT 241 be split over multiple messages. All first level children of the 242 element MUST be treated the same as stanzas (e.g. 243 and ). 245 3.7. Stream Restarts 247 After successful SASL authentication, an XMPP stream needs to be 248 restarted. In these cases, as soon as the message is sent (or 249 received) containing the success indication, both the server and 250 client streams are implicitly closed, and new streams need to be 251 opened. The client MUST open a new stream as in Section 3.3 and MUST 252 NOT send a closing stream tag. 254 S: 256 [Streams implicitly closed] 258 C: 263 3.8. Pings and Keepalives 265 XMPP servers send whitespace pings as keepalives between stanzas, and 266 XMPP clients can do the same as these extra whitespace characters are 267 not significant in the protocol. Servers and clients SHOULD use 268 WebSocket ping control frames instead for this purpose. 270 In some cases, the WebSocket connection might be served by an 271 intermediary connection manager and not the XMPP server. In these 272 situations, the use of WebSocket ping messages are insufficient to 273 test that the XMPP stream is still alive. Both the XMPP Ping 274 extension [XEP-0199] and the XMPP Stream Management extension 275 [XEP-0198] provide mechanisms to ping the XMPP server, and either 276 extension (or both) MAY be used to determine the state of the 277 connection. 279 3.9. Use of TLS 280 TLS cannot be used at the XMPP sub-protocol layer because the sub- 281 protocol does not allow for raw binary data to be sent. Instead, 282 enabling TLS SHOULD be done at the WebSocket layer using secure 283 WebSocket connections via the |wss| URI scheme. (See Section 10.6 of 284 [RFC6455]). 286 Because TLS is to be provided outside of the XMPP sub-protocol layer, 287 a server MUST NOT advertise TLS as a stream feature (see Section 4.6 288 of [RFC6120]), and a client MUST ignore any advertised TLS stream 289 feature, when using the XMPP sub-protocol. 291 3.10. Stream Management 293 In order to alleviate the problems of temporary disconnections, the 294 XMPP Stream Management extension [XEP-0198] MAY be used to confirm 295 when stanzas have been received by the server. 297 In particular, the use of session resumption in [XEP-0198] MAY be 298 used to allow for recreating the same stream session state after a 299 temporary network unavailability or after navigating to a new URL in 300 a browser. 302 4. Discovering Connection Method 304 The XMPP extension Discovering Alternate XMPP Connection Methods 305 [XEP-0156] provides a mechanism to discover the additional 306 information needed to connect to an XMPP server outside of the 307 procedure defined in in Section 3 of [RFC6120]. 309 For the XMPP over Websocket connection type, the connection method 310 name "_xmpp-client-websocket" is used to specify a URI for the 311 server's WebSocket connection endpoint. 313 An example entry advertising that the URI "wss://example.com/xmpp" is 314 an XMPP over WebSocket endpoint, using a DNS TXT record as specified 315 in [XEP-0156]: 317 _xmppconnect IN TXT "_xmpp-client-websocket=wss://example.com/xmpp" 319 Implementation Note: A server is able to expose both BOSH [XEP-0206] 320 and WebSocket endpoints over the registered port 5280, using the URI 321 path and connection upgrade headers to determine which transport to 322 serve. 324 5. Security Considerations 325 Since application level TLS cannot be used (see Section 3.9), 326 applications which need to protect the privacy of the XMPP traffic 327 need to do so at the WebSocket or other appropriate layer. 329 The Security Considerations for both WebSocket (See Section 10 of 330 [RFC6455] and XMPP (See Section 13 of [RFC6120]) apply to the 331 WebSocket XMPP sub-protocol. 333 6. IANA Considerations 335 This specification requests IANA to register the WebSocket XMPP sub- 336 protocol under the "WebSocket Subprotocol Name" Registry with the 337 following data: 339 Subprotocol Identifier: xmpp 341 Subprotocol Common Name: WebSocket Transport for the Extensible 342 Messaging and Presence Protocol (XMPP) 344 Subprotocol Definition: RFC XXXX 346 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 347 this document upon publication.]] 349 7. Informative References 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", BCP 14, RFC 2119, March 1997. 354 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 355 Protocol (XMPP): Core", RFC 6120, March 2011. 357 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 358 Protocol (XMPP): Instant Messaging and Presence", RFC 359 6121, March 2011. 361 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 362 "Known Issues and Best Practices for the Use of Long 363 Polling and Streaming in Bidirectional HTTP", RFC 6202, 364 April 2011. 366 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 367 6455, December 2011. 369 [W3C.REC-xml-20081126] 370 Sperberg-McQueen, C., Yergeau, F., Paoli, J., Bray, T., 371 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth 372 Edition)", World Wide Web Consortium Recommendation REC- 373 xml-20081126, November 2008, 374 . 376 [XEP-0124] 377 Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt, 378 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 379 XEP 0124, July 2010. 381 [XEP-0156] 382 Hildebrand, J. and P. Saint-Andre, "Discovering 383 Alternative XMPP Connection Methods", XSF XEP 0156, June 384 2007. 386 [XEP-0198] 387 Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., 388 Cridland, D., and M. Wild, "Stream Management", XSF XEP 389 0198, June 2011. 391 [XEP-0199] 392 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 394 [XEP-0206] 395 Paterson, I. and P. Saint-Andre, "XMPP Over BOSH", XSF XEP 396 0206, July 2010. 398 Authors' Addresses 400 Lance Stout (editor) 401 &yet 403 Email: lance@andyet.net 405 Jack Moffitt 407 Email: jack@metajack.im 409 Eric Cestari 410 cstar industries 412 Email: eric@cestari.info