Re: [xmpp] [Gen-art] Gen-ART review for draft-ietf-xmpp-websocket-07

[Lance Stout <[e-mail]>]

> I would like to see some thoughts from the editors regarding the two points that you raised.

Hrm, did my earlier response on the 3rd not make it through moderation to the gen-art list?



> 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

This is creating a new binding, separate from the TCP binding defined in RFC6120. While
this document introduces framing (thus deviating from RFC6120) it does not actually
modify anything in 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.

That is the only method, so I agree that can be a SHOULD, and also agree on the
second point.

After proposing changing this to SHOULD to the WG, some members have questioned if 
2119 language is even needed here at all, as there is no alternative way to do this.



— Lance