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

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Jun 2014 16:09:56 -0400

I have reviewed this draft in preparation for IETF LC.  Overall, it looks
to be in good shape.  Thanks for a nice document.  I've requested last
call, and there are a few minor comments below to consider along with LC
comments.

Thanks,
--Richard

MINOR

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

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?

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.

---

From: Lance Stout <[email-masked]>
Date: Fri, 20 Jun 2014 14:35:17 -0700

> Should this be "MUST conform"?

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

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

> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Jun 2014 19:42:38 -0400

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

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

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.

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