[Standards-JIG] Closing idle streams

Carlo v. Loesch CvL at mail.symlynX.com
Fri Jun 2 07:42:22 UTC 2006

Dave Cridland typeth:
| No, it could be server shutdown, or a policy decision never to talk
| to that server again, or...

No, those are all covered by other conditions in 4.7.3 like
<system-shutdown/>, <policy-violation/> or even <undefined-condition/>

| I don't think there's any benefit in eliding the error, and I don't
| think there's ever a good argument for using implicit errors. If
| you're explicit, then even a bad implementation knows what's going on.

Wanting to close a socket because you need the descriptor is not an error.
What's the error about it!???

| Well, I think it's worth specifying a reason for the stream closure. 

It could be a nice-to-have, although I don't see any reasons and
I don't think a friendly handshake shutdown needs an excuse.

| If you accept that, then you have to consider what mechanism to use 
| to provide that reason, and the only available mechanism - without 
| defining some new stanza - is a stream error.
| The fact that stream errors also happen to mandate subsequent closure 
| of the stream actually works in our favour, because it makes the 
| whole thing nicely backwards compatible. Partly because - in as much 
| as I can tell - it's actually how things work now in many cases.

No it does not work in our favour at all. This is why there has been
packet loss in Jabber S2S communications all along, because closing
the socket unilaterally bears the risk of losing data that is just
being submitted on the other side.

Why do you think I'm submitting a BP if it wasn't a problem?

So a stream-error is clearly NOT the mechanism suited for signaling
a harmless close of an unused connection. There is no other suited
mechanism and there is no need to introduce one, because there is no
other S2S situation where a stream would be closed without a reason.
Server developers correct me please if I am wrong, but at least in
our server implementation there is no such condition.

More information about the Standards mailing list