idnits 2.17.1 draft-moffitt-xmpp-over-websocket-00.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 : ---------------------------------------------------------------------------- ** 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 110: '...hake, the client MUST include the |Sec...' RFC 2119 keyword, line 113: '... MUST also contain |xmpp| in its own...' RFC 2119 keyword, line 121: '...MPP sub-protocol MUST be of the text t...' RFC 2119 keyword, line 131: '...r the handshake is complete MUST be an...' RFC 2119 keyword, line 134: '... The stream tag MUST NOT be closed (i...' (14 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 8, 2010) is 4880 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) == Outdated reference: A later version (-17) exists of draft-ietf-hybi-thewebsocketprotocol-03 -- Obsolete informational reference (is this intentional?): RFC 3920 (Obsoleted by RFC 6120) -- Obsolete informational reference (is this intentional?): RFC 3921 (Obsoleted by RFC 6121) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HyBi Working Group J. Moffitt, Ed. 3 Internet-Draft 4 Intended status: Standards Track E. Cestari 5 Expires: June 11, 2011 ProcessOne 6 December 8, 2010 8 An XMPP Sub-protocol for WebSocket 9 draft-moffitt-xmpp-over-websocket-00 11 Abstract 13 This document defines a binding for the XMPP protocol over a 14 WebSocket transport layer. A WebSocket binding for XMPP provides 15 higher performance than the current HTTP binding for XMPP. 17 Status of this Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on June 11, 2011. 34 Copyright Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. XMPP Sub-Protocol . . . . . . . . . . . . . . . . . . . . . . 5 54 3.1. Handshake . . . . . . . . . . . . . . . . . . . . . . . . 5 55 3.2. Messages . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 3.3. XMPP Stream Setup . . . . . . . . . . . . . . . . . . . . 5 57 3.4. Stream Errors . . . . . . . . . . . . . . . . . . . . . . 5 58 3.5. Closing the Connection . . . . . . . . . . . . . . . . . . 6 59 3.6. Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 3.7. Stream Restarts . . . . . . . . . . . . . . . . . . . . . 6 61 3.8. Pings and Keepalives . . . . . . . . . . . . . . . . . . . 6 62 3.9. TLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 7. Informative References . . . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Applications using XMPP (see [RFC3920] and [RFC3921]) on the Web 72 currently make use of BOSH (see [XEP-0124] and [XEP-0206]), an XMPP 73 binding to HTTP. BOSH is based on the HTTP long polling technique, 74 and it suffers from high transport overhead compared to XMPP's native 75 binding to TCP. 77 It would be much better in most circumstances to avoid tunneling XMPP 78 over HTTP long polled connections and instead use the XMPP protocol 79 directly. However, the APIs and sandbox that browsers have provided 80 do not allow this. The WebSocket protocol 81 [I-D.ietf-hybi-thewebsocketprotocol] now exists to solve these kinds 82 of problems. The WebSocket protocol is a bi-directional protocol 83 that provides a simple message-based framing layer over raw sockets 84 and allows for more robust and efficient communication in web 85 applications. 87 This document defines a binding of the XMPP protocol over the 88 WebSocket protocol transport. It makes using XMPP within web 89 applications simpler and more efficient. 91 2. Terminology 93 The basic unit of framing in the WebSocket protocol is called a 94 message. In XMPP, the basic unit is the stanza, which is a subset of 95 the first-level children of each document in an XMPP stream (see 96 Section 9 of [RFC3920]). XMPP also has a concept of messages, which 97 are stanzas whose top-level element name is message. In this 98 document, the word "message" will mean a WebSocket message, not an 99 XMPP message stanza (see Section 3.2). 101 3. XMPP Sub-Protocol 103 3.1. Handshake 105 The xmpp sub-protocol is used to transport XMPP over a WebSocket 106 connection. The client and server agree to this protocol during the 107 WebSocket handshake (see Section 1.3 of 108 [I-D.ietf-hybi-thewebsocketprotocol]). 110 During the WebSocket handshake, the client MUST include the |Sec- 111 WebSocket-Protocol| header in its handshake, and the value |xmpp| 112 must be included in the list of protocols. The reply from the server 113 MUST also contain |xmpp| in its own |Sec-WebSocket-Protocol| header 114 in order for an XMPP sub-protocol connection to be established. 116 Once the handshake is complete, WebSocket messages sent or received 117 will conform to the protocol defined in the rest of this document. 119 3.2. Messages 121 Data frame messages in the XMPP sub-protocol MUST be of the text type 122 and contain UTF-8 encoded data. The close control frame's contents 123 are specified in Section 3.5. Control frames other than close are 124 not restricted. 126 Unless noted in text, the word "message" will mean a WebSocket 127 message containing a text data frame. 129 3.3. XMPP Stream Setup 131 The first message sent after the handshake is complete MUST be an 132 XMPP opening stream tag as defined in XMPP [RFC3920] or an XML text 133 declaration (see Section 4.3.1 of [W3C.REC-xml-20081126]) followed by 134 an XMPP opening stream tag. The stream tag MUST NOT be closed (i.e. 135 the closing tag should not appear in the message) as 136 it is the start of the client's outgoing XML. The '<' character of 137 the tag or text declaration MUST be the first character of the text 138 payload. 140 The server MUST respond with a message containing an error (see 141 Section 3.4), its own opening stream tag, or an XML text declaration 142 followed by an opening stream tag. 144 3.4. Stream Errors 146 Stream level errors in XMPP are terminal. Should such an error 147 occur, the server MUST send the stream error as a complete element in 148 a message to the client. This message MAY include the closing stream 149 tag if a stream is opened. 151 If the error occurs during the opening of a stream, the stream error 152 message MUST start with an opening stream tag (see Section 4.7.1 of 153 [RFC3920]) and end with a closing stream tag. 155 After the stream error and closing stream tag have been sent, the 156 server MUST close the connection as in Section 3.5. 158 3.5. Closing the Connection 160 Either the server or the client may close the connection at any time. 161 Before closing the connection, the closing party MUST close the XMPP 162 stream if it has been established. To initiate the close, the 163 closing party MUST send a normal WebSocket close message with an 164 empty body. The connection is considered closed when a matching 165 close message is received (see Section 1.4 of 166 [I-D.ietf-hybi-thewebsocketprotocol]). 168 3.6. Stanzas 170 Each XMPP stanza MUST be sent in its own message. A stanza MUST NOT 171 be split over multiple messages. All first level children of the 172 element MUST be treated the same as stanzas (e.g. 173 and ). 175 3.7. Stream Restarts 177 After successful SASL authentication, an XMPP stream must be 178 restarted. In these cases, as soon as the message is sent (or 179 received) containing the success indication, both the server and 180 client streams are implicitly closed, and new streams must be opened. 181 The client MUST open a new stream as in Section 3.3 and MUST NOT send 182 a closing stream tag. 184 3.8. Pings and Keepalives 186 XMPP servers send whitespace pings as keepalives between stanzas, and 187 XMPP clients can do the same thing. These extra whitespace 188 characters are not significant in the protocol. Servers and clients 189 SHOULD use WebSocket ping messages instead for this purpose. 191 The XMPP Ping extension [XEP-0199] allows entities to send and 192 respond to ping requests. A client sending a WebSocket ping is 193 equivalent to pinging the WebSocket server, which may also be the 194 XMPP server. When the XMPP server is not also the WebSocket server, 195 a WebSocket ping may be useful to check the health of the 196 intermediary server. 198 3.9. TLS 200 TLS cannot be used in The XMPP sub-protocol because the sub-protocol 201 does not allow for raw binary data to be sent. A server MUST NOT 202 advertise TLS as a stream feature (see Section 4.6 of [RFC3920]). A 203 client MUST ignore the TLS feature if it is advertised over 204 WebSocket. 206 4. Examples 208 Examples will be added as soon as the WebSocket protocol 209 specification is more stable. 211 5. IANA Considerations 213 If a registry is created for WebSocket sub-protocols, the xmpp sub- 214 protocol will be registered. 216 6. Security Considerations 218 Since application level TLS cannot be used (see Section 3.9), 219 applications which need to protect the privacy of the XMPP traffic 220 need to do so a the WebSocket level or some other higher level. 222 7. Informative References 224 [I-D.ietf-hybi-thewebsocketprotocol] 225 Fette, I., "The WebSocket protocol", 226 draft-ietf-hybi-thewebsocketprotocol-03 (work in 227 progress), October 2010. 229 [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence 230 Protocol (XMPP): Core", RFC 3920, October 2004. 232 [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence 233 Protocol (XMPP): Instant Messaging and Presence", 234 RFC 3921, October 2004. 236 [W3C.REC-xml-20081126] 237 Sperberg-McQueen, C., Yergeau, F., Maler, E., Paoli, J., 238 and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth 239 Edition)", World Wide Web Consortium Recommendation REC- 240 xml-20081126, November 2008, 241 . 243 [XEP-0124] 244 Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt, 245 "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF 246 XEP 0124, July 2010. 248 [XEP-0199] 249 Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009. 251 [XEP-0206] 252 Paterson, I. and P. Saint-Andre, "XMPP Over BOSH", XSF 253 XEP 0206, July 2010. 255 Authors' Addresses 257 Jack Moffitt (editor) 259 Email: jack@metajack.im 261 Eric Cestari 262 ProcessOne 264 Email: ecestari@process-one.com