[xmpp] Comments on draft-ietf-xmpp-websocket-05

Ben Campbell <ben@nostrum.com> Mon, 21 April 2014 21:15 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E37D41A0296 for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 14:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.172
X-Spam-Level:
X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Qq5Ba_WR1IM for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 14:15:36 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDC01A0292 for <xmpp@ietf.org>; Mon, 21 Apr 2014 14:15:36 -0700 (PDT)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3LLFTGl003516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 Apr 2014 16:15:31 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29]
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 419807730.730685-480cc92c088fd0f7102141a803f70cdb
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
Message-Id: <2C46C537-4E3F-4C29-BD2C-AFA1A5D52717@nostrum.com>
Date: Mon, 21 Apr 2014 16:15:30 -0500
To: draft-ietf-xmpp-websocket.all@tools.ietf.org, XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/umDCHM-PSaq4QvhB8WYumZGGRnM
Subject: [xmpp] Comments on draft-ietf-xmpp-websocket-05
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Apr 2014 21:15:39 -0000

Here's some just under the wire comments on draft-ietf-xmpp-websocket-05. It mostly looks fine, but I have a few comments, mainly about some 2119 language, and about connection managers:


-- 3.1: "During the WebSocket handshake, the client MUST include the Sec-WebSocket-Protocol header in its handshake, and the value |xmpp| MUST be included in the list of protocols. "

Isn't the "MUST include Sec-WebSocket-Protocol" part really a requirement of WebSocket in general? That is, is it in any way specific to XMPP?, if it's simply a repetition of a general WebSocket requirement, we should not state it normatively here. ( In any case, it seems to be implied by the "value MUST include xmpp"  part.)

-- 3.2.2: "...  MUST close the stream with an error, which SHOULD be <invalid-namespace> ..."

Why SHOULD and not MUST? Are there reasonable circumstances to choose something else? Can you offer guidance on why one might choose something else, and what impact that would have?

-- 3.6:

Do we have to worry about half-closes situations where the peer does not respond in a timely manner? How about glare?

How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since that would involve not closing the stream.

-- 3.6.1: Can a server (or connection manager) redirect the client at any time?

-- 3.8:

First paragraph says clients can use extra whitespace, but goes onto say you SHOULD use WebSocket ping control frames. Does that mean we are recommending _against_ using the extra whitespace? If so, I'd avoid language saying you "can" do it in the first place, or add some qualification to make it clear those are "standard" XMPP clients and servers, but _WebSocket_ implementations SHOULD do things differently.

Are the uses of XMPP Ping or Stream Management for this purpose limited to the connection manager case? If not, does the aforementioned SHOULD also recommend against doing these?

Are clients and servers expected to know that a connection manager exists in the first place? Can we have plain-vanilla XMPP servers with a websocket connection manager? If so, how would they know to follow the XMPP/WebSocket recommendations? 

-- 3.9: " ... enabling TLS SHOULD be done at the WebSocket layer ... "

Why not MUST? Can you give guidance about when it might make sense not to do it, and the consequences?

Does the possibility of a connection manager change anything?