Re: Comments on draft-ietf-xmpp-websocket-05

I seem to have missed a section.


> -- 3.6:
> 
> 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 that would involve not closing the stream.

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

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