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

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