Closing in on the end of LC for draft-ietf-xmpp-websocket-07, so replying to the feedback generated so far. We'll publish a -08 draft addressing these issues, which have all been minor or editorial points.
On Jul 3, 2014, at 9:39 AM, <[email protected]> <[email protected]> wrote: > Should “when TLS is used, it MUST be enabled the WebSocket layer ” have read > “when TLS is used, it MUST be enabled at the WebSocket layer ” ? Yes, that is the intended wording. On Jul 2, 2014, at 6:00 AM, Romascanu, Dan (Dan) <[email protected]> wrote: > 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 a separate binding from the TCP binding defined in RFC6120, so I don't think saying Updates RFC6120 would be accurate. Nothing in RFC6120 is modified by this document. > 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. > 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:’ +1, will add that. On Jun 25, 2014, at 11:55 PM, Juergen Schoenwaelder <[email protected]> wrote: > - Sec 1: The term 'raw socket' can be potentially mis-understood, perhaps > simply > remove 'over row sockets' completely (I think the message of the sentence > remains intact without these words). +1 will change > - Sec 3.1: The text says that both client and server MUST have |xmpp| in the > list of protocols for the |Sec-WebSocket-Protocol| header. The text does not > detail what happens if this is not the case. Is there be a defined behavior if > this protocol negotiation fails? Good catch, RFC6455 doesn't describe what to do in that case, so we'll need to address it. If the server does not reply with 'xmpp' in the Sec-WebSocket-Protocol handshake reply, then the client MUST close the connection. > - Sec 3.6.1: There is a closing parenthesis missing at the end of the first > paragraph. Noted, will fix. - Lance
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
