[xmpp] Fwd: Reviews of draft-ietf-xmpp-websocket-07

Lance Stout <lance@andyet.net> Fri, 04 July 2014 04:00 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 []) by ietfa.amsl.com (Postfix) with ESMTP id E2D081B27AB for <xmpp@ietfa.amsl.com>; Thu, 3 Jul 2014 21:00:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id CLiotAcnA0sQ for <xmpp@ietfa.amsl.com>; Thu, 3 Jul 2014 21:00:04 -0700 (PDT)
Received: from mail-pd0-f171.google.com (mail-pd0-f171.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E3D81A0522 for <xmpp@ietf.org>; Thu, 3 Jul 2014 21:00:02 -0700 (PDT)
Received: by mail-pd0-f171.google.com with SMTP id fp1so1283897pdb.16 for <xmpp@ietf.org>; Thu, 03 Jul 2014 21:00:02 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:subject:date:references:to :message-id:mime-version; bh=DgLYWWpgD94GAgpDbKUAgEqQ0513rP9IKCe5usW+D0A=; b=SI3t6Z8nk6ffs8W5ddQsXxXwIA/5Kbe9Ozbd6fo3o0J9tWBB5j1DAhomRH0+NZTRwS t6aZ8e4XaNE/IGcimtX+B5Xn5KOjhiPvn09IForJcmthdR+uHx4Z6vg4iCa14P9xUGYC 35pPz6a+X/8ndJeFjOPDVOrrlpOnBGBo411SjkoS8StiLjr8rnIqe4TPVdJuqdJ01HnG +fPoZEz0pw+zhVX3D4C0mZpanaB2dwpPOdNcYeTKeOTaBI6uR9v7p1PySB4qOhhYd3I9 etoOkFu89VsA2M8BOpqeTxVyVusCTxy3beyPwZdb7Y8m6vxVITuByecY8DLfhZPST9/m rZqQ==
X-Gm-Message-State: ALoCoQnJ9QiWGnxl7H+e59RW9dYeSo41C+4miCbwx9dgC8GF/+ANABKadxZQcKJjR3P+DBF2iyX7
X-Received: by with SMTP id ce5mr77294052pbc.93.1404446401898; Thu, 03 Jul 2014 21:00:01 -0700 (PDT)
Received: from [] (68-186-83-170.dhcp.knwc.wa.charter.com. []) by mx.google.com with ESMTPSA id qm11sm6932546pdb.85.2014. for <xmpp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Jul 2014 21:00:01 -0700 (PDT)
From: Lance Stout <lance@andyet.net>
Content-Type: multipart/signed; boundary="Apple-Mail=_B50B9DD5-9A44-45FC-BFDE-FC9E5943ECA1"; protocol="application/pkcs7-signature"; micalg=sha1
Date: Thu, 3 Jul 2014 20:59:59 -0700
References: <46B2A4E0-236E-4B1C-8060-C8641E0CA012@andyet.net>
To: XMPP Working Group <xmpp@ietf.org>
Message-Id: <BB6B8882-538F-46BE-9C73-912563C0EB20@andyet.net>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/7Xf72svadsT2plCxIxxVx8_L3mc
Subject: [xmpp] Fwd: Reviews of draft-ietf-xmpp-websocket-07
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: Fri, 04 Jul 2014 04:00:08 -0000

Closing in on the end of IETF LC for draft-ietf-xmpp-websocket-07, so replying to the
feedback generated so far. We'll publish a -08 draft addressing these issues,
which have all been minor or editorial points.

For the XMPP WG: Two proposed changes in normative requirements:

1. A server SHOULD use <close see-other-uri="..." /> when ending a session & pointing
   the client to a new endpoint. Was previously a MAY, but IETF LC feedback pointed
   out that we don't have any other defined way to do this. 

   I don't feel too strongly on this point, so feedback welcome on if this change is really needed.

2. If the server responds to the WebSocket handshake without including 'xmpp'
   in its Sec-WebSocket-Protocol header, then the client MUST close the connection.
   Handling of this situation was previously undefined, but this feels to be
   what we all expected was already the proper client action.

On Jul 3, 2014, at 9:39 AM, <magnusn@gmail.com> <magnusn@gmail.com> wrote:

> Should “when TLS is used, it MUST be enabled the WebSocket layer ” have read
> “when TLS is used, it MUST be enabled at the WebSocket layer ” ?

Yes, that is the intended wording.

On Jul 2, 2014, at 6:00 AM, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

> 1. In order to accommodate the Websocket binding this document describes several
> deviations from RFC6120. For example, in Section 3.3 it says: The WebSocket
> XMPP sub-protocol deviates from the standard method of constructing and using
> XML streams as defined in [RFC6120] by adopting the message framing provided by
> WebSocket to delineate the stream open and close headers, stanzas, and other
> top-level stream elements. I am wondering whether it would not be appropriate to
> reflect this in the document header by adding Updates RFC6120

This is a separate binding from the TCP binding defined in RFC6120, so I don't
think saying Updates RFC6120 would be accurate. Nothing in RFC6120 is modified
by this document.

> 2. In Section 3.6.1:
>   If the server wishes at any point to instruct the client to move to a
>   different WebSocket endpoint (e.g. for load balancing purposes), the server
>   MAY send a <close/> element and set the "see-other-uri" attribute to the
>   URI of the new connection endpoint (which MAY be for a different transport
>   method, such as BOSH (see [XEP-0124] and [XEP-0206]).
>        I do not understand the usage of MAY in this paragraph. Is there another
> method to move to a different Web socket endpoint that is described here or some
> other place? In not, why is not the first MAY at least a SHOULD? The second
> usage seems to describe a state of facts, so it needs not be capitalized at all.

That is the only method, so I agree that can be a SHOULD, and also agree on the
second point.

> In Section 3.1 I believe that the example should be preceded by some text
> that indicates that this is an example, such as: ‘An example of a successful
> handshake and start of session follows:’

+1, will add that.

On Jun 25, 2014, at 11:55 PM, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.de> wrote:

> - Sec 1: The term 'raw socket' can be potentially mis-understood, perhaps simply
> remove 'over row sockets' completely (I think the message of the sentence
> remains intact without these words).

+1 will change

> - Sec 3.1: The text says that both client and server MUST have |xmpp| in the
> list of protocols for the |Sec-WebSocket-Protocol| header. The text does not
> detail what happens if this is not the case. Is there be a defined behavior if
> this protocol negotiation fails?

Good catch, RFC6455 doesn't describe what to do in that case, so we'll need to
address it.

If the server does not reply with 'xmpp' in the Sec-WebSocket-Protocol handshake
reply, then the client MUST close the connection.

> - Sec 3.6.1: There is a closing parenthesis missing at the end of the first
> paragraph.

Noted, will fix.

- Lance