Subject: [xmpp] Comments on draft-ietf-xmpp-websocket-05

From: Ben Campbell <[email-masked]>
Date: Mon, 21 Apr 2014 16:15:30 -0500

Here's some just under the wire comments on draft-ietf-xmpp-websocket-05. It mostly looks fine, but I have a few comments, mainly about some 2119 language, and about connection managers:

-- 3.1: "During the WebSocket handshake, the client MUST include the Sec-WebSocket-Protocol header in its handshake, and the value |xmpp| MUST be included in the list of protocols. "

Isn't the "MUST include Sec-WebSocket-Protocol" part really a requirement of WebSocket in general? That is, is it in any way specific to XMPP?, if it's simply a repetition of a general WebSocket requirement, we should not state it normatively here. ( In any case, it seems to be implied by the "value MUST include xmpp"  part.)

-- 3.2.2: "...  MUST close the stream with an error, which SHOULD be <invalid-namespace> ..."

Why SHOULD and not MUST? Are there reasonable circumstances to choose something else? Can you offer guidance on why one might choose something else, and what impact that would have?

-- 3.6:

Do we have to worry about half-closes situations where the peer does not respond in a timely manner? How about glare?

How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since that would involve not closing the stream.

-- 3.6.1: Can a server (or connection manager) redirect the client at any time?

-- 3.8:

First paragraph says clients can use extra whitespace, but goes onto say you SHOULD use WebSocket ping control frames. Does that mean we are recommending _against_ using the extra whitespace? If so, I'd avoid language saying you "can" do it in the first place, or add some qualification to make it clear those are "standard" XMPP clients and servers, but _WebSocket_ implementations SHOULD do things differently.

Are the uses of XMPP Ping or Stream Management for this purpose limited to the connection manager case? If not, does the aforementioned SHOULD also recommend against doing these?

Are clients and servers expected to know that a connection manager exists in the first place? Can we have plain-vanilla XMPP servers with a websocket connection manager? If so, how would they know to follow the XMPP/WebSocket recommendations? 

-- 3.9: " ... enabling TLS SHOULD be done at the WebSocket layer ... "

Why not MUST? Can you give guidance about when it might make sense not to do it, and the consequences?

Does the possibility of a connection manager change anything?

---

From: Lance Stout <[email-masked]>
Date: Mon, 21 Apr 2014 15:12:26 -0700

> Isn't the "MUST include Sec-WebSocket-Protocol" part really a requirement of WebSocket in general? That is, is it in any way specific to XMPP?, if it's simply a repetition of a general WebSocket re…

Makes sense. We only need to require here that the header includes 'xmpp' in the list of protocols.

> Why SHOULD and not MUST? Are there reasonable circumstances to choose something else? Can you offer guidance on why one might choose something else, and what impact that would have?

I was mirroring the language in RFC 6120 Section 4.8.1. The SHOULD there seems to come from some server implementations that used <bad-format /> instead.

I'd be fine changing this to a MUST, since we're requiring servers to change the stream start header anyway.

> -- 3.6.1: Can a server (or connection manager) redirect the client at any time?

Yes, just as it can close the stream at any time. I'll make that more explicit.

> First paragraph says clients can use extra whitespace, but goes onto say you SHOULD use WebSocket ping control frames. Does that mean we are recommending _against_ using the extra whitespace? If so…

Right. We're mandating in Section 3.3.3 that every WebSocket message begins with "<", which makes using whitespace pings problematic.

> Are the uses of XMPP Ping or Stream Management for this purpose limited to the connection manager case? If not, does the aforementioned SHOULD also recommend against doing these?

Using Ping or Stream Management is acceptable in any case, if redundant, as it turns out browsers do not explicitly give developers control over WebSocket pings.

My recommendation for preferred order of use of pinging mechanisms is:

1. Use Stream Management acks to ping (they're smaller and give useful info).
2. Use XMPP Ping
3. Use WebSocket ping control frames (mostly useful only if you're using WebSocket outside of a browser, such as on the server side of the connection).

> Does the possibility of a connection manager change anything?

Using MUST here does make more sense. TLS SHOULD be used, and if MUST be enabled at the WebSocket layer.

---

From: Lance Stout <[email-masked]>
Date: Mon, 21 Apr 2014 15:29:40 -0700

I seem to have missed a section.

> Do we have to worry about half-closes situations where the peer does not respond in a timely manner? How about glare?

We're following the same procedure as in RFC 6120 Section 4.4 (with the substitution of <close /> instead of </stream:stream>)

Would referencing that section be sufficient to address this, or do I need to include that language in this document?

> How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since tha…

The closing party ought to do the polite thing and first end the XMPP stream and then the WebSocket connection. In which case, the stream is closed when the other party replies with a close, and the server considers the session ended. The use of XEP-0198 is irrelevant in this case, as the XMPP session is ended regardless.

However, if the WebSocket connection happens to close before the XMPP stream is closed (network loss, etc), then:

    XEP-0198 not enabled: consider the XMPP stream implicitly closed, and end the XMPP session.
    XEP-0198 enabled: keep the XMPP session alive for a configured period of time to allow resumption, as described in XEP-0198

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Apr 2014 15:51:35 -0500

Hi,

Thanks for the response. Comments inline. I removed sections that didn't seem to require further comment.

> On Apr 21, 2014, at 2:15 PM, Ben Campbell <[email-masked]> wrote:

[...]

> I'd be fine changing this to a MUST, since we're requiring servers to change the stream start header anyway.

I'm okay either way, but if we leave it a SHOULD it would be good to add a note about the reasoning.

>> How does the XEP-0198 guidance after the figure interact with the guidance saying the closing party SHOULD close the stream? That would seem to imply one SHOULD NOT keep the stream alive, since th…

(I see you responded to those in a separate email. I will address them there.)

[...]

> 3. Use WebSocket ping control frames (mostly useful only if you're using WebSocket outside of a browser, such as on the server side of the connection).

Sounds good to me, pending clarifying text. (I wonder if others agree with those priorities?)

> Using MUST here does make more sense. TLS SHOULD be used, and if MUST be enabled at the WebSocket layer.

Sounds good. Any thoughts on the connection manager question?

---

From: Ben Campbell <[email-masked]>
Date: Tue, 22 Apr 2014 15:57:35 -0500

> Would referencing that section be sufficient to address this, or do I need to include that language in this document?

That gets down into esoterica about whether you would expect an update to that section of 6120 to impact this draft. But in general I'm okay with either approach as long as it is clear, and we don't end up with dueling 2119 language between here and 6120.

>    XEP-0198 enabled: keep the XMPP session alive for a configured period of time to allow resumption, as described in XEP-0198

Okay, so the use of XEP-0198 does not absolve you from closing the stream. That seems to be the way the text currently rendered, but some notes to that effect might make it easier to understand. OTOH, do I infer correctly that failure to close the stream does no harm under any circumstances? If true, do we really need that SHOULD, rather than just something to the effect of your "... ought to do the polite thing..." comment?

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