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

<hat type='shepherd'/>

On 7/8/14, 12:51 AM, Lance Stout wrote:
>> 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.

That seems accurate to me (also with my RFC6120-author hat on).

>> 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.

Right. I might change "the server MAY send a <close/> element and 
set..." to, simply, "the server sends a <close/> element and sets..." 
since, as you say, this is just how it's done. (These conditionally 
normative statements are always a bit confusing - "if X then MUST Y" and 
such.)

Peter