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.ar...@piuha.net] > Sent: Tuesday, July 08, 2014 7:58 AM > To: Romascanu, Dan (Dan) > Cc: gen-art@ietf.org; draft-ietf-xmpp-websocket....@tools.ietf.org; > x...@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) <droma...@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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
