[Standards-JIG] Closing idle streams

Peter Saint-Andre stpeter at jabber.org
Fri Jun 2 15:52:11 UTC 2006


Jacek Konieczny wrote:

> Regular stream errors mean conditions when the stream is invalid. Eg.
> XML not well formed. All the server can do with the data received after
> detecting such error is ignore it. Much better is to close the connetion
> at once in this case, than waiting for anythig. 
> 
> In case of closing idle connection server has nothing to send, but
> should accept and proccess anything other side sends (that could, of
> course, cause a new outgoing connection being opened). 
> 
> IMHO S2S connections are _temporary_ channels for exchanging stanza
> when neccessary. Closing them is as normal thing as disconnecting 
> a client when the user decides to stop using it. It should not be
> treated as error. IMO closing stream with </stream:stream> and letting
> the other side do the same is the most elegant solution possible with
> current protocol. Anything more that could be invented would be
> something like <presence type="unavailable"/> used in C2S connections.
> But that is not necessary.

IMHO this is a kind of grey area in which reasonable people can disagree 
(do we include an error or just close the stream, is there really an 
error here or just a normal condition of disuse?). Which to me indicates 
that it's not really important enough for us to spend lots of time and 
effort on this through lengthy list discussions. :-)

I keep waffling on this -- back and forth between including a stream 
error or not. Really I don't think there *is* an error, just a normal 
condition that the stream isn't being used. So I lean toward just 
closing the stream.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060602/9073876b/attachment.bin>


More information about the Standards mailing list