Re: [Gen-art] Reviews of draft-ietf-xmpp-websocket-07

Lance Stout <lance@andyet.net> Fri, 04 July 2014 02:30 UTC

Content-Type: multipart/signed; boundary="Apple-Mail=_1F4FC48B-2C42-4B9B-A09F-838E4C7BB53A"; protocol="application/pkcs7-signature"; micalg="sha1"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Lance Stout <lance@andyet.net>
In-Reply-To: <53b587f5.09d5440a.44eb.2126@mx.google.com>
Date: Thu, 03 Jul 2014 19:30:43 -0700
Message-Id: <46B2A4E0-236E-4B1C-8060-C8641E0CA012@andyet.net>
References: <CADajj4YJVxE8fh1iuZQ0qTPGrvnF_N_ywYBsouifN2jv-UqJZQ@mail.gmail.com> <53b587f5.09d5440a.44eb.2126@mx.google.com>
To: "iesg@ietf.org" <iesg@ietf.org>
Archived-At: http://mailarchive.ietf.org/arch/msg/gen-art/UFngGEGG5OrVRccvdmYFrhrDklY
Cc: ops-dir@ietf.org, "secdir@ietf.org" <secdir@ietf.org>, ops-ads@tools.ietf.org, "gen-art@ietf.org" <gen-art@ietf.org>, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, magnusn@gmail.com, draft-ietf-xmpp-websocket.all@tools.ietf.org, "draft-ietf-xmpp-websocket@tools.ietf.org" <draft-ietf-xmpp-websocket@tools.ietf.org>
Subject: Re: [Gen-art] Reviews of draft-ietf-xmpp-websocket-07
Precedence: list

Closing in on the end of 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.

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

Attachment: smime.p7s

Re: [Gen-art] Reviews of draft-ietf-xmpp-websocke… Lance Stout

Re: [Gen-art] Reviews of draft-ietf-xmpp-websocket-07

Attachment: smime.p7s