Re: [Standards] XEP-0174: Serverless Messaging: Ending a Messaging Session

[Peter Saint-Andre]

Alban Crequy wrote:

Hi,

In a link-local conversation with XEP-0174, a client A sends the
ending stanza to the other end's client B: "</stream:stream>"

http://www.xmpp.org/extensions/xep-0174.html#end

After that, B continues to send message stanzas to A but never sends

the ending stanza. The ending stanza from A is ignored by B.

Why?

The
XEP-0174 seems to say B has to close the stream but there is no "MUST"
or "SHOULD".

I think that's supposed to be a MUST. The text "the other party then closes the stream in the other direction as well" is not good specification language.

When the user of A wants to send a message, A can't send it using the
current connection because the ending stanza has already been sent on
this connection and sending stanzas after the ending stanza is
obviously not correct. The client A cannot closes the TCP connection
while it did not receive the ending stanza from B because it may miss a
message.

I think that A can indeed close the TCP connection, but will miss some messages. Indeed, we might want to say that A sends </stream:stream> and closes the TCP connection immediately.

The XEP does not say whether A should open a second stream or should
wait the first stream to be closed by the remote end. The second option

seems better to me,

Agreed.

but in this case B MUST closes the stream at some
point when A sends the ending stanza (otherwise, A's messages will
never be sent).

Also agreed.

It seems that iChat behaves like the client B in my scenario, i.e. it
does not close the stream when it receives the ending stanza. This
causes problems when the client A waits the connection to be closed in
order to open a new one.

Peter

I think we hadn't considered the complexities here when we first documented serverless messaging. The fact that clients can get in this state is a problem -- i.e., the state where A won't send stanza to B and does not expect stanzas from B, but B ignores A's stream close and continues to send stanzas to A. I consider this a bug in B, and I think we need to clarify the spec so that B sends a stream close as soon as it receives a stream close from A. We probably also need to define how a client needs to handle stanzas it receives after it sends the closing stream tag (ignore them? show them to the user?).

smime.p7s
Description: S/MIME Cryptographic Signature