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

Lance Stout <lance@andyet.net> Mon, 21 April 2014 22:12 UTC

Return-Path: <lance@andyet.net>
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 977841A02D1 for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 15:12:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 AGh88rPiPPHq for <xmpp@ietfa.amsl.com>; Mon, 21 Apr 2014 15:12:35 -0700 (PDT)
Received: from mail-pb0-f50.google.com (mail-pb0-f50.google.com [209.85.160.50]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD281A0039 for <xmpp@ietf.org>; Mon, 21 Apr 2014 15:12:35 -0700 (PDT)
Received: by mail-pb0-f50.google.com with SMTP id md12so4183433pbc.37 for <xmpp@ietf.org>; Mon, 21 Apr 2014 15:12:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=KrWTQHNVvlIWy33AaszV/hMwzHj8vGulnX2vTc6mL7Y=; b=Q2Rg/OzhrGUvgYXZCdeMUO6mvr1vPaED5dwwdm86jKzAyKDuf1HhWugUc5L5eEcED+ oJ7KV3i1hlY5pRdmszOOENLW4+LW6WIBpEZtOlLnpyb6FezkEfhEbDkaHLeNvtQmcMbn qc9ZJFfbyuKhDe1xbkTPSUU0uPzwBNUXAhkhsQJ9M2ak03jgzQ5Hg8/siRpU/ksi+NEQ 7S64IdDnktq+9eQHVaACVhXsFNf+afyKCnESRT5nAbBkRqQzAkoBbLdIjaqX5tJ6sYVt 2X+iXMiFfl3RAvI5pyc7RPgIYQgvplwpoqaD03wKdCPSvAx/mBZQ7zgXEhcXFJj9/1xw uR5A==
X-Gm-Message-State: ALoCoQk7dycPHx5LQ+TSSIsWtAgPwyhgVxEtzYpxVxqk/5ydAiXw7UsWUeggw7WxVsLHqtJ6HIsr
X-Received: by 10.67.5.7 with SMTP id ci7mr40181174pad.99.1398118350149; Mon, 21 Apr 2014 15:12:30 -0700 (PDT)
Received: from [10.0.1.172] (96-41-205-84.dhcp.elbg.wa.charter.com. [96.41.205.84]) by mx.google.com with ESMTPSA id xg8sm149450567pac.26.2014.04.21.15.12.28 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Apr 2014 15:12:28 -0700 (PDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_37AB04C4-E2F1-4E9B-8804-360DA364E5E5"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Lance Stout <lance@andyet.net>
In-Reply-To: <2C46C537-4E3F-4C29-BD2C-AFA1A5D52717@nostrum.com>
Date: Mon, 21 Apr 2014 15:12:26 -0700
Message-Id: <60E5F9D6-0ED8-4801-838D-B669BEDA1DAE@andyet.net>
References: <2C46C537-4E3F-4C29-BD2C-AFA1A5D52717@nostrum.com>
To: XMPP Working Group <xmpp@ietf.org>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/P5BIbLxja_dziseH1_qFftqgMYw
Cc: Ben Campbell <ben@nostrum.com>
Subject: Re: [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 22:12:39 -0000

On Apr 21, 2014, at 2:15 PM, Ben Campbell <ben@nostrum.com> wrote:

> 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.)

Makes sense. We only need to require here that the header includes 'xmpp' in the list of protocols.


> -- 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?

I was mirroring the language in RFC 6120 Section 4.8.1. The SHOULD there seems to come from some server implementations that used <bad-format /> instead.

I'd be fine changing this to a MUST, since we're requiring servers to change the stream start header anyway.


> -- 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?

Yes, just as it can close the stream at any time. I'll make that more explicit.

> -- 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.

Right. We're mandating in Section 3.3.3 that every WebSocket message begins with "<", which makes using whitespace pings problematic.

> 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?

Using Ping or Stream Management is acceptable in any case, if redundant, as it turns out browsers do not explicitly give developers control over WebSocket pings.


My recommendation for preferred order of use of pinging mechanisms is:

1. Use Stream Management acks to ping (they're smaller and give useful info).
2. Use XMPP Ping
3. Use WebSocket ping control frames (mostly useful only if you're using WebSocket outside of a browser, such as on the server side of the connection).


> -- 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?


Using MUST here does make more sense. TLS SHOULD be used, and if MUST be enabled at the WebSocket layer.