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?

-- 
Alban

Reply via email to