Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02

Florian Zeitz <> Wed, 09 April 2014 19:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 956D31A023D for <>; Wed, 9 Apr 2014 12:48:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.878
X-Spam-Status: No, score=0.878 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UliNJ6vgeERs for <>; Wed, 9 Apr 2014 12:48:46 -0700 (PDT)
Received: from ( [IPv6:2a02:d40:3:1:10a1:5eff:fe52:509]) by (Postfix) with ESMTP id F24091A023B for <>; Wed, 9 Apr 2014 12:48:43 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1WXyUG-0002Jl-6g; Wed, 09 Apr 2014 21:48:44 +0200
Message-ID: <>
Date: Wed, 09 Apr 2014 21:48:35 +0200
From: Florian Zeitz <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-websocket-02
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 09 Apr 2014 19:48:51 -0000

I generally consider this draft to be in a decent shape. The wording and
general flow still seem a bit rough to me at times. More detailed
comments below:

= Substantive =
* Having some text explaining the general framing approach upfront
  would be helpful. This should note that an XML Stream is not used as
  described in RFC 6120, but <open/> and <close/> elements are used
  instead. The lack of a surrounding <stream:stream> element should
  be explicitly noted. This could go along with text explaining each
  message is a full XML document without an XML declaration.

3.5 Closing the connection:
 * "To initiate closing the WebSocket connection, the closing party MUST
   send a normal WebSocket close message with an empty body."
   Why? Having no body at all implies that sending a status code
   is not allowed. This seems undesirable to me.

3.5.1 see-other-uri
 * This currently says that the URI may only point to another WebSocket
   endpoint. IIRC the intent was specifically to be able to also move
   from WebSocket to BOSH.

= Editorial =
1. Introduction:
 * "The WebSocket protocol [...]. The WebSocket protocol [...]."

3.3 XMPP Stream Setup
 * It would be helpful to reuse RFC 6120's language here.
   I.e. "The first message sent by the initiating entity [...]"
   "The receiving entity MUST respond [...]"

3.6 Stanzas
 * "directly over the XMPP stream", RFC 6120 calls this a "XML Stream".
 * "XML text declaration" XML 1.0 calls this a "XML declaration",
   the whole sentence could use some rewording, possibly also mentioning
   size overhead.

3.7 Stream Restarts
 * "In these cases", only one case is listed. Possibly reword to say
   something like "Whenever a stream restart is mandated [...]"
   Clarify <open/> is used for stream restarts instead of

3.8 Stanzas
 * "that the XMPP stream is still alive" -> "XML Stream"

Florian Zeitz

On 07.04.2014 23:29, Ben Campbell wrote:
> This is a Working Group Last Call of draft-ietf-xmpp-websocket-02. The draft is available at the following URL:
> The WGLC will conclude on 21 April, 2014. Please send your comments to the authors and the XMPP mailing list.
> Thanks!
> Ben.