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

"Romascanu, Dan (Dan)" <dromasca@avaya.com> Tue, 08 July 2014 09:07 UTC

Return-Path: <dromasca@avaya.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 9D7121B27BE; Tue, 8 Jul 2014 02:07:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.551
X-Spam-Level:
X-Spam-Status: No, score=-7.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651] 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 RgulOSUmvTUu; Tue, 8 Jul 2014 02:07:07 -0700 (PDT)
Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8BDE1B27A3; Tue, 8 Jul 2014 02:07:00 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: An4FAEW0u1OHCzIm/2dsb2JhbABZgmokUlqraAEBAQEBAQaSYxyHRAGBFxZ1hAMBAQEBAwEBAQ8oNAsMBAIBCA0EAwEBAQEKFAkHJwsUCQgCBA4FCAEZiCABDKUNpAYXhXCHMYEwAQEeMQIFBoMngRYFllyFYoVwjFSDQ2yBCzk
X-IronPort-AV: E=Sophos;i="5.01,624,1400040000"; d="scan'208";a="75100424"
Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 08 Jul 2014 05:06:35 -0400
X-OutboundMail_SMTP: 1
Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 08 Jul 2014 05:06:35 -0400
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 8 Jul 2014 11:06:34 +0200
From: "Romascanu, Dan (Dan)" <dromasca@avaya.com>
To: Jari Arkko <jari.arkko@piuha.net>
Thread-Topic: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
Thread-Index: AQHPmmk0VMwaQWD3002cTC8XVq7iEJuV4YTw
Date: Tue, 8 Jul 2014 09:06:34 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C836AB4@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA5C823BB2@AZ-FFEXMB04.global.avaya.com> <7CC08F3C-4747-4B65-9743-A19CDAE9F940@piuha.net>
In-Reply-To: <7CC08F3C-4747-4B65-9743-A19CDAE9F940@piuha.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.64.58.46]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/NHaA8uL-it4wJfCZfYURxw93QrM
X-Mailman-Approved-At: Tue, 08 Jul 2014 07:25:37 -0700
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 09:07:10 -0000

Hi Jari,

The authors actually responded - see http://www.ietf.org/mail-archive/web/gen-art/current/msg10306.html. 

They pushed back on my #1 - I am still not convinced by their argument (as the protocol does change by adding a different mapping) but I would not block the document for this purpose. 
The proposed changes for the rest are fine. 

Regards,

Dan
 

> -----Original Message-----
> From: Jari Arkko [mailto:jari.arkko@piuha.net]
> Sent: Tuesday, July 08, 2014 7:58 AM
> To: Romascanu, Dan (Dan)
> Cc: gen-art@ietf.org; draft-ietf-xmpp-websocket.all@tools.ietf.org;
> xmpp@ietf.org
> Subject: Re: [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07
> 
> 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