Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

Jari Arkko <jari.arkko@piuha.net> Tue, 08 July 2014 04:58 UTC

Return-Path: <jari.arkko@piuha.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 087F81B2A25; Mon, 7 Jul 2014 21:58:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.955
X-Spam-Level:
X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.793] autolearn=no
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 bV-6nPrZIp9G; Mon, 7 Jul 2014 21:58:05 -0700 (PDT)
Received: from p130.piuha.net (unknown [IPv6:2001:14b8:400::130]) by ietfa.amsl.com (Postfix) with ESMTP id A7EAC1A0ADC; Mon, 7 Jul 2014 21:58:04 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5D5792CCF9; Tue, 8 Jul 2014 07:58:02 +0300 (EEST)
X-Virus-Scanned: amavisd-new at piuha.net
Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8_JEy_-6UUJ; Tue, 8 Jul 2014 07:57:58 +0300 (EEST)
Received: from [127.0.0.1] (p130.piuha.net [IPv6:2a00:1d50:2::130]) by p130.piuha.net (Postfix) with ESMTP id BE3F52CC48; Tue, 8 Jul 2014 07:57:57 +0300 (EEST)
Content-Type: multipart/signed; boundary="Apple-Mail=_478E5806-7C00-4BA7-A1B6-F59063F83D34"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Jari Arkko <jari.arkko@piuha.net>
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C823BB2@AZ-FFEXMB04.global.avaya.com>
Date: Tue, 8 Jul 2014 00:57:55 -0400
Message-Id: <7CC08F3C-4747-4B65-9743-A19CDAE9F940@piuha.net>
References: <9904FB1B0159DA42B0B887B7FA8119CA5C823BB2@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
X-Mailer: Apple Mail (2.1878.2)
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/oCfZYqDkzkyPs5fj2OaBnlTSNMQ
Cc: "draft-ietf-xmpp-websocket.all@tools.ietf.org" <draft-ietf-xmpp-websocket.all@tools.ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "xmpp@ietf.org" <xmpp@ietf.org>
Subject: Re: [xmpp] [Gen-art] Gen-ART review for 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: Tue, 08 Jul 2014 04:58:07 -0000

Thanks for the review, Dan.

I would like to see some thoughts from the editors regarding the two points that you raised.

Jari

On 02 Jul 2014, at 09:00, Romascanu, Dan (Dan) <dromasca@avaya.com> wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at
>  
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>  
> Please resolve these comments along with any other Last Call comments you may receive.
>  
> Document: https://datatracker.ietf.org/doc/draft-ietf-xmpp-websocket/
> Reviewer: Dan Romascanu
> Review Date: 7/2/2014
> IETF LC End Date: 7/4/2014
> IESG Telechat date: 7/10/2014
>  
> Summary: ready with minor issues
>  
> Major issues:
>  
> None
>  
> Minor issues:
>  
> 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
>  
> 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.
>  
>  
> Nits/editorial comments:
>  
> 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:’
>  
>  
> _______________________________________________
> Gen-art mailing list
> Gen-art@ietf.org
> https://www.ietf.org/mailman/listinfo/gen-art