Re: AD review of draft-ietf-xmpp-websocket

> MINOR
> 
> S3.1. "WebSocket messages sent or received will conform"
> Should this be "MUST conform"?

Makes sense to me to make that MUST, since that's the entire point of this document.


> S3.6.1. "a different transport, such as BOSH"
> How is the recipient of one of these messages supposed to tell what transport?  Does the use of an http- or https-schemed URI imply BOSH?

I would assume that's implied, as BOSH is the only defined transport for the http/https scheme, and I don't expect for us to define another given the existing deployment base.

However, I can see where this could get fuzzy. Any suggestions on a solution?


> S3.7. "[Streams implicitly closed]"
> Does this usage map cleanly to the TCP case?  That is, would a </stream> element be sent in this closure case?  I'm just imagining that if you have, say, a relatively naïve gateway that translates <stream> to <open> and </stream> to <close>, this could cause problems.

Yes, this intentionally mirrors the process used in the TCP binding. The Prosody implementation of this spec actually does exactly that 'naïve gateway' approach internally to convert the framed stream to the TCP C2S stream format to reuse its existing code paths.



- Lance

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp