Last Call Review of draft-ietf-xmpp-websocket-07
review-ietf-xmpp-websocket-07-genart-lc-romascanu-2014-07-02-00

Request Review of draft-ietf-xmpp-websocket
Requested rev. no specific revision (document currently at 10)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2014-07-04
Requested 2014-06-26
Draft last updated 2014-07-02
Completed reviews Genart Last Call review of -07 by Dan Romascanu (diff)
Genart Last Call review of -07 by Dan Romascanu (diff)
Secdir Last Call review of -07 by Magnus Nystrom (diff)
Opsdir Last Call review of -07 by Jürgen Schönwälder (diff)
Assignment Reviewer Dan Romascanu
State Completed
Review review-ietf-xmpp-websocket-07-genart-lc-romascanu-2014-07-02
Reviewed rev. 07 (document currently at 10)
Review result Ready with Issues
Review completed: 2014-07-02

Review
review-ietf-xmpp-websocket-07-genart-lc-romascanu-2014-07-02






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