Skip to main content

Last Call Review of draft-ietf-xmpp-websocket-07

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-08
Requested 2014-07-03
Authors Lance Stout, Jack Moffitt , Eric Cestari
I-D last updated 2014-07-14
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
Completed 2014-07-14

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART,
please see the FAQ at


Please resolve these comments along with any other Last Call comments you may


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:


Minor issues:


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


              I am wondering whether it would not be appropriate to reflect
              this in the document header by adding Updates RFC6120


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


        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

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