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

[Richard Barnes <[e-mail]>]

On Fri, Jun 20, 2014 at 5:35 PM, Lance Stout <[e-mail]> wrote:

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


If it wouldn't be too disruptive to change the syntax, you could just do
the same thing as XEP-0156 and specify the protocol explicitly.  Otherwise,
perhaps some text of the form:

"Since BOSH is the only HTTP-based transport for XMPP, an HTTP URI in the
"see-other-uri" attribute indicates that the client should connect using
BOSH.  Likewise, a WebSocket URI indicates that the client should use the
transport defined in this document."

There's some risk that a persnickety AD will ask for a registry (scheme to
protocol mapping), but I think we can push back on that.


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