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