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 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:’