An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for WebSocket
RFC 7395
Internet Engineering Task Force (IETF) L. Stout, Ed.
Request for Comments: 7395 &yet
Category: Standards Track J. Moffitt
ISSN: 2070-1721 Mozilla
E. Cestari
cstar industries
October 2014
An Extensible Messaging and Presence Protocol (XMPP) Subprotocol for
WebSocket
Abstract
This document defines a binding for the Extensible Messaging and
Presence Protocol (XMPP) over a WebSocket transport layer. A
WebSocket binding for XMPP provides higher performance than the
current HTTP binding for XMPP.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7395.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Stout, et al. Standards Track [Page 1]
RFC 7395 XMPP over WebSocket October 2014
Table of Contents
1. Introduction ....................................................2
2. Terminology .....................................................3
3. XMPP Subprotocol ................................................3
3.1. Handshake ..................................................3
3.2. WebSocket Messages .........................................4
3.3. XMPP Framing ...............................................5
3.3.1. Framed XML Stream ...................................5
3.3.2. Framed Stream Namespace .............................5
3.3.3. Stream Frames .......................................5
3.4. Stream Initiation ..........................................6
3.5. Stream Errors ..............................................7
3.6. Closing the Connection .....................................7
3.6.1. see-other-uri .......................................8
3.7. Stream Restarts ............................................9
3.8. Pings and Keepalives .......................................9
3.9. Use of TLS .................................................9
3.10. Stream Management ........................................10
4. Discovering the WebSocket Connection Method ....................10
5. IANA Considerations ............................................11
5.1. WebSocket Subprotocol Name ................................11
5.2. URN Sub-namespace .........................................11
6. Security Considerations ........................................12
7. References .....................................................14
7.1. Normative References ......................................14
7.2. Informative References ....................................14
Appendix A. XML Schema ............................................16
Acknowledgements ..................................................17
Authors' Addresses ................................................18
1. Introduction
To date, applications using the Extensible Messaging and Presence
Protocol (XMPP) (see [RFC6120] and [RFC6121]) on the Web have made
use of Bidirectional-streams Over Synchronous HTTP (BOSH) (see
[XEP-0124] and [XEP-0206]), an XMPP binding to HTTP. BOSH is based
on the HTTP "long polling" technique, and it suffers from high
transport overhead compared to XMPP's native binding to TCP. In
addition, there are a number of other known issues with long polling
[RFC6202] that have an impact on BOSH-based systems.
In most circumstances, it would be much better to avoid tunneling
XMPP over HTTP long-polled connections and instead use XMPP directly.
Show full document text