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 receivinga closing stream tag from the other party (e.g., because of network latency or because the other party has messages queued up fordelivery 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 controllingThe 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
smime.p7s
Description: S/MIME Cryptographic Signature