> 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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
