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

[Peter Saint-Andre]

Alban Crequy wrote:

Le Wed, 13 Aug 2008 12:58:10 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :

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 closing stream tag is ignored just for the purpose of
my scenario ;-) But I agree this is a bug in the client B (and in the
XEP because there should have been a "MUST").

I've made this change in my working copy.

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.

I agree.

I've made this change in my working copy.

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.

I would prefer the XEP to say that the client A MUST wait the closing
stream tag from B before closing the TCP connection and MUST handle
message stanzas from B correctly, so no message will be lost. It is
possible (with network latency) that theses message stanzas are sent by

B before B is notified that A want to close the stream.

I agree, that seems reasonable.

I even propose
that, when B receives the ending stanza from A, B can still send the
remaining messages it may have to send from its queue and sends the
closing stream tag after, as soon as it has nothing to send.

Sounds good.

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.

If we want the XEP to say there can be only one stream between two
clients, we should define the correct behaviour when two clients
initiate a TCP connection to each other at the same time. Do we want one
connection to win and the second to be closed?

I don't think we need to restrict clients to one stream at a time.

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.

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

If a client receives stanzas after it has received the closing stream
tag, that's a bug in the remote client because it is not allowed to
send something after closing the stream.

But a client receives stanzas after it sends the closing stream tag,
the client must show them to the user because the remote client has no
way to know that the client sent the closing stream tag (with some
network latency).

Peter

Yes, that seems good. I will update the spec along these lines and post a temporary link to the provisional version.

smime.p7s
Description: S/MIME Cryptographic Signature