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