Alban Crequy wrote:
Le Thu, 14 Aug 2008 11:16:00 -0600,
Peter Saint-Andre <[EMAIL PROTECTED]> a écrit :

Peter Saint-Andre wrote:

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

***

9. Ending a Messaging Session

To end the chat, either party closes the XML stream:

Example 6. Ending the Chat

</stream:stream>


The other party MUST then also close the stream in the other
direction:

Example 7. Closing the Stream

</stream:stream>


The closing party (i.e., the party that sent the first closing stream tag) then MUST close the TCP connection between them.

Note: The closing party might receive additional stanzas from the
other party after sending its closing stream tag and before receiving
a closing stream tag from the other party (e.g., because of network latency or because the other party has messages queued up for
delivery when it receives the closing party's closing stream tag).
Therefore, the closing party needs to be prepared to handle such
messages, which it SHOULD do by presenting them to the controlling

The revised text sounds good.

user (if any) or processing them for presentation when a new stream
is established.

I don't understand what you mean with "when a new stream is
established". Why would a client wait to have a new stream before
presenting the messages from the previous stream?

Well it might present them but not enable the user to reply until the new stream is established, grey the messages out, etc.

I think I will remove that last clause and just leave it as "SHOULD do by presenting them to the controlling user".

Peter




Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to