idnits 2.17.1 draft-moffitt-xmpp-over-websocket-02.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 (February 25, 2013) is 4075 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: August 29, 2013 E. Cestari 6 ProcessOne 7 February 25, 2013 9 An XMPP Sub-protocol for WebSocket 10 draft-moffitt-xmpp-over-websocket-02 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 August 29, 2013. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.3. XMPP Stream Setup . . . . . . . . . . . . . . . . . . . . 3 58 3.4. Stream Errors . . . . . . . . . . . . . . . . . . . . . . 4 59 3.5. Closing the Connection . . . . . . . . . . . . . . . . . 4 60 3.6. Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 4 62 3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . 5 63 3.9. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . 5 64 3.10. Stream Management . . . . . . . . . . . . . . . . . . . . 5 65 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Informative References . . . . . . . . . . . . . . . . . . . 6 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 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 3.2. Messages 130 Data frame messages in the XMPP sub-protocol MUST be of the text type 131 and contain UTF-8 encoded data. The close control frame's contents 132 are specified in Section 3.5. Control frames other than close are 133 not restricted. 135 Unless noted in text, the word "message" will mean a WebSocket 136 message containing a text data frame. 138 3.3. XMPP Stream Setup 140 The first message sent after the handshake is complete MUST be an 141 XMPP opening stream tag as defined in XMPP [RFC6120] or an XML text 142 declaration (see Section 4.3.1 of [W3C.REC-xml-20081126]) followed by 143 an XMPP opening stream tag. The stream tag MUST NOT be closed (i.e. 144 the closing tag should not appear in the message) as 145 it is the start of the client's outgoing XML. The '<' character of 146 the tag or text declaration MUST be the first character of the text 147 payload. 149 The server MUST respond with a message containing an error (see 150 Section 3.4), its own opening stream tag, or an XML text declaration 151 followed by an opening stream tag. 153 Except in the case of certain stream errors (see Section 3.4), the 154 opening stream tag, , MUST appear in a message by 155 itself. 157 3.4. Stream Errors 159 Stream level errors in XMPP are terminal. Should such an error 160 occur, the server MUST send the stream error as a complete element in 161 a message to the client. 163 If the error occurs during the opening of a stream, the stream error 164 message MUST start with an opening stream tag (see Section 4.7.1 of 165 [RFC6120]) and end with a closing stream tag. 167 After the stream error and closing stream tag have been sent, the 168 server MUST close the connection as in Section 3.5. 170 3.5. Closing the Connection 172 Either the server or the client may close the connection at any time. 173 Before closing the connection, the closing party MUST close the XMPP 174 stream if it has been established. To initiate the close, the 175 closing party MUST send a normal WebSocket close message with an 176 empty body. The connection is considered closed when a matching 177 close message is received (see Section 1.4 of [RFC6455]). 179 Except in the case of certain stream errors (see Section 3.4), the 180 closing stream tag, , MUST appear in a message by 181 itself. 183 3.6. Stanzas 185 Each XMPP stanza MUST be sent in its own message. A stanza MUST NOT 186 be split over multiple messages. All first level children of the 187 element MUST be treated the same as stanzas (e.g. 188 and ). 190 3.7. Stream Restarts 191 After successful SASL authentication, an XMPP stream needs to be 192 restarted. In these cases, as soon as the message is sent (or 193 received) containing the success indication, both the server and 194 client streams are implicitly closed, and new streams needs to be 195 opened. The client MUST open a new stream as in Section 3.3 and MUST 196 NOT send a closing stream tag. 198 3.8. Pings and Keepalives 200 XMPP servers send whitespace pings as keepalives between stanzas, and 201 XMPP clients can do the same thing. These extra whitespace 202 characters are not significant in the protocol. Servers and clients 203 SHOULD use WebSocket ping messages instead for this purpose. 205 The XMPP Ping extension [XEP-0199] allows entities to send and 206 respond to ping requests. A client sending a WebSocket ping is 207 equivalent to pinging the WebSocket server, which may also be the 208 XMPP server. When the XMPP server is not also the WebSocket server, 209 a WebSocket ping may be useful to check the health of the 210 intermediary server. 212 3.9. Use of TLS 214 TLS cannot be used at the XMPP sub-protocol layer because the sub- 215 protocol does not allow for raw binary data to be sent. Instead, 216 enabling TLS SHOULD be done at the WebSocket layer using secure 217 WebSocket connections via the |wss| URI scheme. (See Section 10.6 of 218 [RFC6455]). 220 Because TLS is to be provided outside of the XMPP sub-protocol layer, 221 a server MUST NOT advertise TLS as a stream feature (see Section 4.6 222 of [RFC6120]), and a client MUST ignore any advertised TLS stream 223 feature, when using the XMPP sub-protocol. 225 3.10. Stream Management 227 Implications of, and recommendation to use, the XMPP Stream 228 Management extension [XEP-0198] to be added. 230 4. Examples 232 Examples will be added as soon as the WebSocket protocol 233 specification is more stable. 235 5. Security Considerations 236 Since application level TLS cannot be used (see Section 3.9), 237 applications which need to protect the privacy of the XMPP traffic 238 need to do so at the WebSocket or other appropriate layer. 240 The Security Considerations for both WebSocket (See Section 10 of 241 [RFC6455] and XMPP (See Section 13 of [RFC6120]) apply to the 242 WebSocket XMPP sub-protocol. 244 6. IANA Considerations 246 This specification requests IANA to register the WebSocket XMPP sub- 247 protocol under the "WebSocket Subprotocol Name" Registry with the 248 following data: 250 Subprotocol Identifier: xmpp 252 Subprotocol Common Name: WebSocket Transport for the Extensible 253 Messaging and Presence Protocol (XMPP) 255 Subprotocol Definition: RFC XXXX 257 [[NOTE TO RFC EDITOR: Please change XXXX to the number assigned to 258 this document upon publication.]] 260 7. Informative References 262 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 263 Requirement Levels", BCP 14, RFC 2119, March 1997. 265 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 266 Protocol (XMPP): Core", RFC 6120, March 2011. 268 [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence 269 Protocol (XMPP): Instant Messaging and Presence", RFC 270 6121, March 2011. 272 [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, 273 "Known Issues and Best Practices for the Use of Long 274 Polling and Streaming in Bidirectional HTTP", RFC 6202, 275 April 2011. 277 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", RFC 278 6455, December 2011. 280 [W3C.REC-xml-20081126] 281 Sperberg-McQueen, C., Yergeau, F., Paoli, J., Bray, T., 282 and E. Maler, "Extensible Markup Language (XML) 1.0 (Fifth 283 Edition)", World Wide Web Consortium Recommendation REC- 284 xml-20081126, November 2008, 285 . 287 [XEP-0124] 288 Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt, 289 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 290 XEP 0124, July 2010. 292 [XEP-0198] 293 Karneges, J., Saint-Andre, P., Hildebrand, J., Forno, F., 294 Cridland, D., and M. Wild, "Stream Management", XSF XEP 295 0198, June 2011. 297 [XEP-0199] 298 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 300 [XEP-0206] 301 Paterson, I. and P. Saint-Andre, "XMPP Over BOSH", XSF XEP 302 0206, July 2010. 304 Authors' Addresses 306 Lance Stout (editor) 307 &yet 309 Email: lance@andyet.net 311 Jack Moffitt 313 Email: jack@metajack.im 315 Eric Cestari 316 ProcessOne 318 Email: ecestari@process-one.com