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 revision | 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 | |
Authors | Lance Stout, Jack Moffitt , Eric Cestari | |
I-D 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 Nyström (diff) Opsdir Last Call review of -07 by Jürgen Schönwälder (diff) |
|
Assignment | Reviewer | Dan Romascanu |
State | Completed | |
Request | Last Call review on draft-ietf-xmpp-websocket by General Area Review Team (Gen-ART) Assigned | |
Reviewed revision | 07 (document currently at 10) | |
Result | Ready w/issues | |
Completed | 2014-07-02 |
review-ietf-xmpp-websocket-07-genart-lc-romascanu-2014-07-02-00
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:’