rfc7395.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">

<?rfc toc="yes"?>
<?rfc rfcprocack="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc linkmailto="yes"?>
<?rfc strict="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>

<rfc number="7395" category="std" ipr="trust200902" submissionType="IETF"
   consensus="yes">

  <front>
    <title abbrev="XMPP over WebSocket">
      An Extensible Messaging and Presence Protocol (XMPP) Subprotocol
      for WebSocket
    </title>

    <author initials="L." surname="Stout" fullname="Lance Stout"
            role="editor">
      <organization>&amp;yet</organization>
      <address>
        <email>lance@andyet.net</email>
      </address>
    </author>

    <author initials="J." surname="Moffitt" fullname="Jack Moffitt">
      <organization>Mozilla</organization>
      <address>
        <email>jack@metajack.im</email>
      </address>
    </author>

    <author initials="E." surname="Cestari" fullname="Eric Cestari">
      <organization>cstar industries</organization>
      <address>
        <email>eric@cstar.io</email>
      </address>
    </author>

    <date month="October" year="2014"/>

    <keyword>WebSocket</keyword>
    <keyword>XMPP</keyword>

    <abstract>
      <t>
        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.
      </t>
    </abstract>
  </front>

  <middle>
    <section anchor="intro" title="Introduction">
      <t>
        To date, applications using the Extensible Messaging and 
        Presence Protocol (XMPP) (see <xref target="RFC6120"/>
        and <xref target="RFC6121"/>) on the Web have made
        use of Bidirectional-streams Over Synchronous HTTP (BOSH)
        (see <xref target="XEP-0124"/> and <xref target="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 <xref target="RFC6202"/> that have
        an impact on BOSH-based systems.
      </t>
      <t>
        In most circumstances, it would be much better to avoid
        tunneling XMPP over HTTP long-polled connections and instead
        use XMPP directly. However, the APIs and sandbox
        that browsers have provided do not allow this. The WebSocket
        protocol <xref target="RFC6455"/> exists to solve these
        kinds of problems and is a bidirectional
        protocol that provides a simple message-based framing layer, 
        allowing for more robust and efficient
        communication in web applications.
      </t>
      <t>
        The WebSocket protocol enables two-way communication
        between a client and a server, effectively emulating TCP
        at the application layer and, therefore, overcoming many of
        the problems with existing long-polling techniques for
        bidirectional HTTP.  This document defines a WebSocket 
        subprotocol for XMPP.
      </t>
      <t>
        The WebSocket binding for XMPP is designed for use by 
        browser-based applications (e.g., XMPP clients written in 
        JavaScript).  Typically, these applications are used to 
        access the same information and communication opportunities
        (e.g., the same XMPP "roster" of contacts) as clients that
        connect to an XMPP server over the TCP binding 
        defined in <xref target='RFC6120'/>. Although the only 
        essential difference is the underlying transport binding, 
        relevant implications (e.g., framing methods and discovery
        processes) are highlighted in this specification.
      </t>
    </section>

    <section title="Terminology">
      <t>
        The basic unit of framing in the WebSocket protocol is called
        a "message". In XMPP, the basic unit is the stanza, which is a
        subset of the first-level children of each document in an XMPP
        stream (see Section 9 of <xref target="RFC6120"/>). XMPP also
        has a concept of messages, which are stanzas with a top-level
        element of &lt;message/&gt;. In this
        document, the word "message" will mean a WebSocket message,
        not an XMPP message stanza (unless otherwise noted).
      </t>
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
        NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
        "MAY", and "OPTIONAL" in this document are to be interpreted as
        described in <xref target="RFC2119"/>.
      </t>
    </section>

    <section title="XMPP Subprotocol">
      <section title="Handshake">
        <t>
          The XMPP subprotocol is used to transport XMPP over a
          WebSocket connection. The client and server agree to this
          protocol during the WebSocket handshake (see Section 1.3 of
          <xref target="RFC6455"/>).
        </t>
        <t>
          During the WebSocket handshake, the client MUST include the value
          'xmpp' in the list of protocols for the 'Sec-WebSocket-Protocol'
          header. The reply from the server MUST also contain 'xmpp' in
          its own 'Sec-WebSocket-Protocol' header in order for an XMPP
          subprotocol connection to be established.
        </t>
        <t>
          If a client receives a handshake response that does not include
          'xmpp' in the 'Sec-WebSocket-Protocol' header, then an XMPP
          subprotocol WebSocket connection was not established and the
          client MUST close the WebSocket connection.
        </t>
        <t>
          Once the handshake has successfully completed, WebSocket messages sent or
          received MUST conform to the protocol defined in the rest of
          this document.
        </t>
        <t>
          <figure>
            <preamble>
              The following is an example of a WebSocket handshake, followed
              by opening an XMPP stream:
            </preamble>
            <artwork><![CDATA[
C:  GET /xmpp-websocket HTTP/1.1
    Host: example.com
    Upgrade: websocket
    Connection: Upgrade
    Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
    Origin: http://example.com
    ...
    Sec-WebSocket-Protocol: xmpp
    Sec-WebSocket-Version: 13


S:  HTTP/1.1 101 Switching Protocols
    Upgrade: websocket
    Connection: Upgrade
    ...
    Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
    Sec-WebSocket-Protocol: xmpp

[WebSocket connection established]

C:  <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
          to="example.com"
          version="1.0" />

S:  <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
          from="example.com"
          id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
          xml:lang="en"
          version="1.0" />
]]></artwork>
          </figure>
        </t>
      </section>

      <section title="WebSocket Messages" anchor="messages">
        <t>
          Data frame messages in the XMPP subprotocol MUST be of the
          text type and contain UTF-8 encoded data.
        </t>
      </section>

      <section title="XMPP Framing" anchor="sect-xmpp-framing">
          <t>
            The framing method for the binding of XMPP to WebSocket differs from the
            framing method for the TCP binding as defined in <xref target="RFC6120"/>;
            in particular, the WebSocket binding adopts the message framing provided
            by WebSocket to delineate the stream open and close headers, stanzas, and
            other top-level stream elements.
          </t>
          <section title="Framed XML Stream">
            <t>
              The start of a framed XML stream is marked by the use of an opening "stream
              header", which is an &lt;open/&gt; element with the appropriate attributes
              and namespace declarations (see <xref target="framed-stream-namespace"/>). The
              attributes of the &lt;open/&gt; element are the same as those of the &lt;stream/&gt;
              element defined for the 'http://etherx.jabber.org/streams' namespace
              <xref target="RFC6120"/> and with the same semantics and
              restrictions.
            </t>
            <t>
              The end of a framed XML stream is denoted by the closing "stream header",
              which is a &lt;close/&gt; element with its associated attributes and
              namespace declarations (see <xref target="framed-stream-namespace"/>).
            </t>
            <t>
              The introduction of the &lt;open/&gt; and &lt;close/&gt; elements is motivated
              by the parsable XML document framing restriction in <xref target="frames"/>.
              As a consequence, note that a framed XML stream does not
              provide a wrapping &lt;stream:stream/&gt; <xref target="RFC6120"/> element encompassing the entirety
              of the XML stream.
            </t>
          </section>
          <section title="Framed Stream Namespace" anchor="framed-stream-namespace">
            <t>
              The XML stream headers (the &lt;open/&gt; and &lt;close/&gt; elements)
              MUST be qualified by the namespace 'urn:ietf:params:xml:ns:xmpp-framing'
              (the "framed stream namespace"). If this rule is violated, the entity that
              receives the offending stream header MUST close the stream with an error,
              which MUST be &lt;invalid-namespace&gt; (see Section 4.9.3.10 of
              <xref target="RFC6120"/>).
            </t>
          </section>
          <section title="Stream Frames" anchor="frames">
            <t>
              The individual frames of a framed XML stream have a one-to-one correspondence
              with WebSocket messages and MUST be parsable as standalone XML documents,
              complete with all relevant namespace and language declarations. The inclusion
              of XML declarations, however, is NOT RECOMMENDED, as WebSocket messages are already
              mandated to be UTF-8 encoded.
Including declarations in each message would only increase the framing
overhead of each message.
            </t>
            <t>
              The first character of each frame MUST be a '&lt;' character.
            </t>
            <t>
              Every XMPP stanza or other XML element (including the stream open and close headers)
              sent directly over the XML stream MUST be sent in its own frame.
            </t>
            <figure>
              <preamble>
                Example of a WebSocket message that contains an independently
                parsable XML document:
              </preamble>
              <artwork><![CDATA[
<message xmlns="jabber:client" xml:lang="en">
  <body>Every WebSocket message is parsable by itself.</body>
</message>
]]></artwork>
            </figure>

            <figure>
              <preamble>
                Note that for stream features and
                errors, there is no parent context element providing the
                "stream" namespace prefix as in <xref target="RFC6120"/>,
                and thus the stream prefix MUST be declared or use
                an unprefixed form:
              </preamble>
              <artwork><![CDATA[
<stream:features xmlns:stream="http://etherx.jabber.org/streams">
  <bind xmlns="urn:ietf:params:xml:ns:xmpp-bind"/>
</stream:features>

-- OR --

<error xmlns="http://etherx.jabber.org/streams">
  <host-unknown xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</error>
]]></artwork>
            </figure>
          </section>
      </section>

      <section title="Stream Initiation" anchor="setup">
        <t>
          The first message sent after the WebSocket opening handshake MUST be from the initiating entity and
          MUST be an &lt;open/&gt; element qualified by the 'urn:ietf:params:xml:ns:xmpp-framing'
          namespace and with the same attributes mandated for the &lt;stream&gt; opening tag as described
          in Section 4.7 of <xref target="RFC6120"/>.
        </t>
        <t>
          The receiving entity MUST respond with either an &lt;open/&gt; element (whose attributes match
          those described in Section 4.7 of <xref target="RFC6120"/>) or
          a &lt;close/&gt; element (see <xref target="see-other-uri"/>).
        </t>
        <figure>
          <preamble>
            An example of a successful stream initiation exchange:
          </preamble>
          <artwork><![CDATA[
C:  <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
          to="example.com"
          version="1.0" />

S:  <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
          from="example.com"
          id="++TR84Sm6A3hnt3Q065SnAbbk3Y="
          xml:lang="en"
          version="1.0" />
]]></artwork>
        </figure>
        <t>
          Clients MUST NOT multiplex XMPP streams over the same WebSocket.
        </t>
      </section>

      <section title="Stream Errors" anchor="errors">
        <t>
          Stream-level errors in XMPP are fatal. Should such an
          error occur, the server MUST send the stream error as a
          complete element in a message to the client.
        </t>
        <t>
          If the error occurs during the opening of a stream, the
          server MUST send the initial open element response, followed by
          the stream-level error in a second WebSocket message frame. The
          server MUST then close the connection as specified in <xref target="closing"/>.
        </t>
      </section>

      <section title="Closing the Connection" anchor="closing">
        <t>
          The closing process for the XMPP subprotocol mirrors that of
          the XMPP TCP binding as defined in Section 4.4 of <xref target="RFC6120"/>,
          except that a &lt;close/&gt; element is used instead of the
          ending &lt;/stream:stream&gt; tag.
        </t>
        <t>
          Either the server or the client may close the connection at any
          time. Before closing the connection, the closing party is expected
          to first close the XMPP stream (if one has been opened) by sending a
          message with the &lt;close/&gt; element, qualified by
          the "urn:ietf:params:xml:ns:xmpp-framing" namespace. The
          stream is considered closed when a corresponding &lt;close/&gt;
          element is received from the other party, and the XMPP session is ended.
        </t>
        <t>
          To then close the WebSocket connection, the closing
          party MUST initiate the WebSocket closing handshake (see Section 7.1.2 of
          <xref target="RFC6455"/>).
        </t>
        <figure>
          <preamble>
            An example of ending an XMPP-over-WebSocket session by first
            closing the XMPP stream layer and then the WebSocket connection
            layer:
          </preamble>
          <artwork><![CDATA[
Client                         (XMPP WSS)                      Server
|  |                                                             |  |
|  | <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" />       |  |
|  |------------------------------------------------------------>|  |
|  |       <close xmlns="urn:ietf:params:xml:ns:xmpp-framing" /> |  |
|  |<------------------------------------------------------------|  |
|  |                                                             |  |
|  |                      (XMPP Stream Closed)                   |  |
|  +-------------------------------------------------------------+  |
|                                                                   |
| WS CLOSE FRAME                                                    |
|------------------------------------------------------------------>|
|                                                    WS CLOSE FRAME |
|<------------------------------------------------------------------|
|                                                                   |
|                         (Connection Closed)                       |
+-------------------------------------------------------------------+
]]></artwork>
        </figure>
        <t>
          If the WebSocket connection is closed or broken  without the XMPP stream having
          been closed first, then the XMPP stream is considered implicitly closed
          and the XMPP session ended; however, if the use of stream management
          resumption was negotiated (see <xref target="XEP-0198"/>), the server
          SHOULD consider the XMPP session still alive for a period of time based
          on server policy as specified in <xref target="XEP-0198"/>.
        </t>
        <section title="see-other-uri" anchor="see-other-uri">
          <t>
            At any point, if the server wishes to instruct
            the client to move to a different WebSocket endpoint (e.g., for load-balancing
            purposes), then a &lt;close/&gt; element is sent with the
            'see-other-uri' attribute set to the URI of the new connection endpoint (which MAY be
            for a different transport method, such as BOSH (see <xref target="XEP-0124"/> and 
            <xref target="XEP-0206"/>)).
          </t>
          <t>
            Clients MUST NOT accept suggested endpoints with a lower security context (e.g., moving
            from a 'wss://' endpoint to a 'ws://' or <vspace/>'http://' endpoint).
          </t>
          <figure>
            <preamble>
              An example of the server closing a stream and instructing the client
              to connect at a different WebSocket endpoint:
            </preamble>
            <artwork><![CDATA[
S: <close xmlns="urn:ietf:params:xml:ns:xmpp-framing"
          see-other-uri="wss://otherendpoint.example/xmpp-bind" />
]]></artwork>
          </figure>
        </section>
      </section>

      <section title="Stream Restarts">
        <t>
          Whenever a stream restart is mandated (see Section 4.3.3 of
          <xref target="RFC6120"/>), both the server and
          client streams are implicitly closed and new streams MUST
          be opened, using the same process as in <xref target="setup"/>.
        </t>
        <t>
          The client MUST send a new stream &lt;open/&gt; element and MUST
          NOT send a closing &lt;close/&gt; element.
        </t>
        <figure>
          <preamble>
            An example of restarting the stream after successful
            Simple Authentication and Security Layer (SASL) negotiation:
          </preamble>
          <artwork><![CDATA[
S: <success xmlns="urn:ietf:params:xml:ns:xmpp-sasl" />

[Streams implicitly closed]

C: <open xmlns="urn:ietf:params:xml:ns:xmpp-framing"
         to="example.com"
         version="1.0" />
]]></artwork></figure>
      </section>

      <section title="Pings and Keepalives">
        <t>
          Traditionally, XMPP servers and clients often send "whitespace keepalives" (see Section 4.6.1 
          of <xref target='RFC6120'/>) between stanzas to maintain an XML
          stream. However, for the XMPP subprotocol each message is required
          to start with a '&lt;' character, and, as such, whitespace keepalives
          MUST NOT be used.
        </t>
        <t>
          As alternatives, the XMPP Ping extension <xref target="XEP-0199"/> and the XMPP Stream
          Management extension <xref target="XEP-0198"/> provide pinging mechanisms.
          Either of these extensions (or both) MAY be used to determine the state
          of the connection.
        </t>
        <t>
          Clients and servers MAY also use WebSocket ping control frames for this purpose, but
          note that some environments, such as browsers, do not provide access for generating
          or monitoring ping control frames.
        </t>
      </section>

      <section title="Use of TLS" anchor="tls">
        <t>
          Transport Layer Security (TLS) cannot be used at the
          XMPP subprotocol layer because the
          subprotocol does not allow for raw binary data to be sent.
          Instead, when TLS is used, it MUST be enabled at the WebSocket layer
          using secure WebSocket connections via the 'wss' URI scheme.
          (See Section 10.6 of <xref target="RFC6455"/>.)
        </t>
        <t>
          Because TLS is to be provided outside of the XMPP
          subprotocol layer, a server MUST NOT advertise
          TLS as a stream feature (see Section 4.6 of 
          <xref target="RFC6120"/>) when using the XMPP
          subprotocol. Likewise, a client MUST ignore any advertised TLS stream feature when using the XMPP 
          subprotocol.
        </t>
      </section>

      <section title="Stream Management" anchor="sm">
        <t>
          In order to alleviate the problems of temporary disconnections,
          the client MAY use the XMPP Stream Management extension <xref target="XEP-0198"/> 
          to confirm when stanzas have been received by the server.
        </t>
        <t>
          In particular, the client MAY use session resumption as
          described in <xref target="XEP-0198"/> 
          to recreate the same stream session state after a temporary network 
          unavailability or after navigating to a new URL in a browser.
        </t>
      </section>
    </section>

    <section anchor='discovery' title="Discovering the WebSocket Connection Method">
      <t>
        Section 3 of <xref target="RFC6120"/> defines a procedure for
        connecting to an XMPP server, including ways to discover the
        TCP/IP address and port of the server using Domain Name System
        service (DNS SRV) records <xref target="RFC2782"/>.  When using the WebSocket 
        binding as specified in this document (instead of the 
        TCP binding as specified in <xref target="RFC6120"/>), a client
        needs an alternative way to discover information about the 
        server's connection methods, since web browsers and other 
        WebSocket-capable software applications typically cannot obtain 
        such information from the DNS.
      </t>
      <t>
        The alternative lookup process uses Web-host Metadata 
        <xref target='RFC6415'/> and Web Linking <xref target='RFC5988'/>, 
        where the link relation type is
        <vspace/>"urn:xmpp:alt-connections:websocket" 
        as described in "Discovering Alternative XMPP Connection Methods"
        <xref target="XEP-0156"/>.  Conceptually, the host-meta lookup 
        process used for the WebSocket binding is analogous to the DNS SRV 
        lookup process used for the TCP binding.  The process is as follows.
      </t>
      <t>
        <list style='numbers'>
          <t>Send a request over secure HTTP to the path
          <vspace/>"/.well-known/host-meta" at an HTTP origin <xref target='RFC6454'/>
          that matches the XMPP service domain (e.g., a URL of
          "https://im.example.org/.well-known/host-meta" if the XMPP service
          domain is "im.example.org").</t>

          <t>Retrieve a host-meta document specifying a link relation type of "urn:xmpp:alt-connections:websocket", such as:</t>
        </list>
      </t>
      <figure>
        <artwork><![CDATA[
    <XRD xmlns='http://docs.oasis-open.org/ns/xri/xrd-1.0'>
      <Link rel="urn:xmpp:alt-connections:websocket"
            href="wss://im.example.org:443/ws" />
    </XRD>
        ]]></artwork>
      </figure>
      <t>
        Servers MAY expose discovery information using host-meta documents, 
        and clients MAY use such information to determine the WebSocket 
        endpoint for a server.
      </t>
      <t>
        In cases where the XMPP service domain does not match the discovered web
        origin of the WebSocket endpoint, the Web-host Metadata SHOULD be 
        used to establish trust between the XMPP server domain and the 
        WebSocket endpoint as long as the host-meta request and
        response occurred over secure HTTP; this is especially relevant 
        in multi-tenant situations where the same WebSocket endpoint is
        serving multiple XMPP domains (e.g., the XMPP service domains 
        for both "example.com" and "im.example.org" might be serviced 
        by the same WebSocket endpoint at "hosting.example.net").  See
        <xref target='security'/> for related discussion.
      </t>
    </section>

    <section anchor="iana" title="IANA Considerations">
      <section anchor="iana-ws" title="WebSocket Subprotocol Name">
        <t>
          IANA has registered the WebSocket XMPP subprotocol
          in the "WebSocket Subprotocol Name Registry",
          with the following data:
          <list style="hanging">
            <t hangText="Subprotocol Identifier:">
              xmpp
            </t>
            <t hangText="Subprotocol Common Name:">
              WebSocket Transport for the Extensible Messaging and
              Presence Protocol (XMPP)
            </t>
            <t hangText="Subprotocol Definition:">
              this document
            </t>
          </list>
        </t>
      </section>

      <section anchor="iana-ns" title="URN Sub-namespace">
        <t>A URN sub-namespace for framing of Extensible Messaging and Presence Protocol (XMPP) streams is defined as follows.</t>
        <t>
          <list style='hanging'>
            <t hangText='URI:'>urn:ietf:params:xml:ns:xmpp-framing</t>
            <t hangText='Specification:'>this document</t>
            <t hangText='Description:'>This is the XML namespace name for framing of Extensible Messaging and Presence Protocol (XMPP) streams as defined by RFC 7395.</t>
            <t hangText='Registrant Contact:'>IESG &lt;iesg@ietf.org&gt;</t>
          </list>
        </t>
      </section>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>The WebSocket binding for XMPP differs in several respects from the
 TCP binding defined in <xref target="RFC6120"/>:</t>
      <t>
        <list style="numbers">
          <t>
            As described in <xref target="discovery"/> of this document, the method for
            discovering a connection endpoint does not use DNS SRV records as in the TCP
            binding but instead uses Web-host Metadata files retrieved via HTTPS from a URL
            at the XMPP service domain. From a security standpoint, this is functionally
            equivalent to resolution via DNS SRV records (and still relies on the DNS for
            resolution of the XMPP source domain).
          </t>
          <t>
            The method for authenticating a connection endpoint uses TLS
            (typically with PKIX certificates) as in the TCP binding, but the identity
            to be authenticated is the connection endpoint address instead of the XMPP
            service domain; delegation from the XMPP service domain to the connection
            endpoint address (if any) is accomplished via the discovery method described
            in <xref target="discovery"/>. Thus, the connection endpoint is still authenticated, and the
            delegation is secure as long as the Web-host Metadata file is retrieved via
            HTTPS. However, note that, in practice, this option might not be employed when user 
            agents are configured or deployed for a particular delegated domain.
          </t>
          <t>
            The framing method described in <xref target="sect-xmpp-framing"/>
 follows the WebSocket
            pattern by sending one top-level XML element per WebSocket message, instead
            of using streaming XML as in the TCP binding. However, the framing method has
            no impact on the security properties of an XMPP session (e.g., end-to-end
            encryption of XML stanzas can be accomplished just as easily with WebSocket
            framing as with streaming XML).
          </t>
          <t>
            In all other respects (e.g., user authentication via SASL,
            allowable characters in XMPP addresses, and reuse of various technologies such
            as Base 64, SASL mechanisms, UTF-8, and XML), the WebSocket binding does not
            differ from the TCP binding and, thus, does not modify the security properties
            of the protocol. In all these respects, the security considerations of 
            <xref target="RFC6120"/> apply directly to the WebSocket binding.
          </t>
        </list>
      </t>

      <t>
        In order to ensure that communications over the WebSocket binding are as
        secure as communications over the TCP binding, an operator needs to (1) serve
        the Web-host Metadata file for the XMPP service domain over secure HTTP ('https'
        URIs) only, (2) configure the WebSocket connection endpoint to use TLS
        ('wss' URIs) only, and (3) deploy certificates that properly
        identify the XMPP service domain and WebSocket connection endpoint for usages
        (1) and (2), respectively.
      </t>
      <t>
        Since application-level TLS cannot be used (see <xref
        target="tls"/>), applications need to protect the privacy
        of XMPP traffic at the WebSocket or other appropriate layer.
      </t>
      <t>
        Browser-based applications are not able to inspect and verify, 
        at the application layer, the certificate used for the WebSocket 
        connection to ensure that it corresponds to the domain specified 
        as the 'to' address of the XMPP stream. There are two cases:</t>
      <t>
        <list style='numbers'>
          <t>
            If the XMPP service domain matches the origin for the WebSocket 
            connection, the relevant check is already performed by the 
            browser. For example, the XMPP service domain might be 
            "foo.example", and the WebSocket endpoint discovered for the 
            link relation type of "urn:xmpp:alt-connections:websocket" might
            be "wss://foo.example/websocket".  As long as the certificate
            provided over WebSocket or HTTPS is verified according to the
            rules defined for secure HTTP <xref target='RFC2818'/>, then
            the browser will report the successful establishment of a 
            secure connection to the application. (However, as noted, the
            application is still not able to independently inspect and
            verify the certificate, and needs to trust the browser; this
            is a limitation of existing browser technologies and thus 
            cannot be worked around by WebSocket applications.)
          </t>
          <t>
            In situations where the user agent has to deal with delegation
            and the domain of the XMPP server does not 
            match the web origin of the WebSocket endpoint (such as 
            multi-tenant hosting situations), the host-meta process 
            described in <xref target='discovery'/> SHOULD be used to 
            delegate trust from the XMPP server domain to the WebSocket 
            origin, as long as the host-meta request and response 
            occurred over secure HTTP (with appropriate certificate 
            verification as defined in <xref target='RFC2818'/>).
          </t>
        </list>
      </t>
      <t>
        When presented with a new WebSocket endpoint via the 'see-other-uri' attribute
        of a &lt;close/&gt; element, clients MUST NOT accept the suggestion if the security
        context of the new endpoint is lower than the current one in order to prevent downgrade
        attacks from a 'wss://' endpoint to 'ws://'.
      </t>
      <t>
        The security considerations for both WebSocket (see Section
        10 of <xref target="RFC6455"/>) and XMPP (see Section 13 of
        <xref target="RFC6120"/>) apply to the WebSocket XMPP
        subprotocol.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">

<reference anchor='RFC2119' target="http://www.rfc-editor.org/info/rfc2119">
<front>
<title abbrev='RFC Key Words'>Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials='S.' surname='Bradner' fullname='Scott Bradner'>
<organization>Harvard University</organization>
</author>
<date year='1997' month='March' />
</front>
<seriesInfo name='BCP' value='14' />
<seriesInfo name='RFC' value='2119' />
</reference>

<reference anchor='RFC2818' target="http://www.rfc-editor.org/info/rfc2818">
<front>
<title>HTTP Over TLS</title>
<author initials='E.' surname='Rescorla' fullname='E. Rescorla'>
<organization /></author>
<date year='2000' month='May' />
</front>
<seriesInfo name='RFC' value='2818' />
</reference>

<reference anchor='RFC5988' target="http://www.rfc-editor.org/info/rfc5988">
<front>
<title>Web Linking</title>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<date year='2010' month='October' />
</front>
<seriesInfo name='RFC' value='5988' />
</reference>

<reference anchor='RFC6120' target="http://www.rfc-editor.org/info/rfc6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
</front>
<seriesInfo name='RFC' value='6120' />
</reference>

<reference anchor='RFC6415' target="http://www.rfc-editor.org/info/rfc6415">
<front>
<title>Web Host Metadata</title>
<author initials='E.' surname='Hammer-Lahav' fullname='E. Hammer-Lahav'>
<organization /></author>
<author initials='B.' surname='Cook' fullname='B. Cook'>
<organization /></author>
<date year='2011' month='October' />
</front>
<seriesInfo name='RFC' value='6415' />
</reference>

<reference anchor='RFC6455' target="http://www.rfc-editor.org/info/rfc6455">
<front>
<title>The WebSocket Protocol</title>
<author initials='I.' surname='Fette' fullname='I. Fette'>
<organization /></author>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
<organization /></author>
<date year='2011' month='December' />
</front>
<seriesInfo name='RFC' value='6455' />
</reference>

    </references>

    <references title="Informative References">

<reference anchor='RFC2782' target="http://www.rfc-editor.org/info/rfc2782">
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
</author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
</author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
</author>
<date year='2000' month='February' />
</front>
<seriesInfo name='RFC' value='2782' />
</reference>

<reference anchor='RFC6121' target="http://www.rfc-editor.org/info/rfc6121">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
</front>
<seriesInfo name='RFC' value='6121' />
</reference>

<reference anchor='RFC6202' target="http://www.rfc-editor.org/info/rfc6202">
<front>
<title>Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP</title>
<author initials='S.' surname='Loreto' fullname='S. Loreto'>
<organization /></author>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<author initials='S.' surname='Salsano' fullname='S. Salsano'>
<organization /></author>
<author initials='G.' surname='Wilkins' fullname='G. Wilkins'>
<organization /></author>
<date year='2011' month='April' />
</front>
<seriesInfo name='RFC' value='6202' />
</reference>

<reference anchor='RFC6454' target="http://www.rfc-editor.org/info/rfc6454">
<front>
<title>The Web Origin Concept</title>
<author initials='A.' surname='Barth' fullname='A. Barth'>
<organization /></author>
<date year='2011' month='December' />
</front>
<seriesInfo name='RFC' value='6454' />
</reference>

   <?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0124.xml"?>
   <?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0156.xml"?>
   <?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0198.xml"?>
   <?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0199.xml"?>
   <?rfc include="http://xmpp.org/extensions/refs/reference.XSF.XEP-0206.xml"?>

<reference anchor='XML-SCHEMA'
           target='http://www.w3.org/TR/2004/REC-xmlschema-1-20041028'>
<front>
<title>XML Schema Part 1: Structures Second Edition</title>
<author initials='H.' surname='Thompson' fullname='Henry S. Thompson'>
    <organization />
</author>
<author initials='D.' surname='Beech' fullname='David Beech'>
    <organization />
</author>
<author initials='M.' surname='Maloney' fullname='Murray Maloney'>
    <organization />
</author>
<author initials='N.' surname='Mendelsohn' fullname='Noah Mendelsohn'>
    <organization />
</author>
<date month='October' day='28' year='2004' />
</front>
<seriesInfo name='World Wide Web Consortium Recommendation' value='REC-xmlschema-1-20041028' />
<format type='HTML' target='http://www.w3.org/TR/2004/REC-xmlschema-1-20041028' />
</reference>

    </references>

    <section title="XML Schema" anchor="schema">
      <t>The following schema formally defines the
      'urn:ietf:params:xml:ns:xmpp-framing' namespace used in this document,
      in conformance with W3C XML Schema <xref target='XML-SCHEMA'/>.  Because
      validation of XML streams and stanzas is optional, this schema is not
      normative and is provided for descriptive purposes only.</t>

      <figure>
        <artwork><![CDATA[
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
    xmlns:xs='http://www.w3.org/2001/XMLSchema'
    targetNamespace='urn:ietf:params:xml:ns:xmpp-framing'
    xmlns='urn:ietf:params:xml:ns:xmpp-framing'
    elementFormDefault='unqualified'>

  <xs:element name='open'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='from' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='id' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='to' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='version' type='xs:decimal' 
                        use='optional'/>
          <xs:attribute ref='xml:lang' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:element name='close'>
    <xs:complexType>
      <xs:simpleContent>
        <xs:extension base='empty'>
          <xs:attribute name='from' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='id' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='see-other-uri' type='xs:anyURI' 
                        use='optional'/>
          <xs:attribute name='to' type='xs:string' 
                        use='optional'/>
          <xs:attribute name='version' type='xs:decimal' 
                        use='optional'/>
          <xs:attribute ref='xml:lang' 
                        use='optional'/>
        </xs:extension>
      </xs:simpleContent>
    </xs:complexType>
  </xs:element>

  <xs:simpleType name='empty'>
    <xs:restriction base='xs:string'>
      <xs:enumeration value=''/>
    </xs:restriction>
  </xs:simpleType>

</xs:schema>
        ]]></artwork>
      </figure>
    </section>

    <section title="Acknowledgements" anchor="acknowledgements">
      <t>The authors wish to thank the following individuals for their feedback:

          Andreas Guth,
          Bjoern Hoerhmann,
          Dave Cridland,
          Florian Zeitz,
          Kurt Zeilenga,
          Matt Miller,
          Matthew Wild,
          Paul Aurich,
          Sergey Dobrov, and
          Waqas Hussain.
      </t>

      <t>Dan Romascanu reviewed the document on behalf of the General Area Review Team.</t>

      <t>During IESG review, 

          Barry Leiba,
          Benoit Claise,
          Dan Romascanu,
          Jari Arkko,
          Juergen Schoenwaelder,
          Spencer Dawkins,
          Stephen Farrell,
          Ted Lemon,
          Kathleen Moriarty, and
          Pete Resnick

          caught several issues that needed to be addressed.</t>

      <t>The authors gratefully acknowledge the assistance of Peter Saint-Andre as document
         shepherd, Ben Campbell and Joe Hildebrand as the working group chairs, and Richard 
         Barnes as the sponsoring Area Director.</t>
    </section>

  </back>

</rfc>