[Standards-JIG] Closing idle streams

Peter Saint-Andre stpeter at jabber.org
Thu Jun 1 22:50:31 UTC 2006

Hash: SHA1

Dave Cridland wrote:
> On Thu Jun  1 20:48:03 2006, Peter Saint-Andre wrote:
>> Matthew A. Miller wrote:
>> > However, I can also see (in the idle connection case) that the
>> stream is
>> > merely ended, without any error.  To me, this does not really seem
>> to be
>> > an error condition, per se, but the matching of some policy condition
>> > (note I did not say "policy violation").  In which case, you should be
>> > waiting for the other </stream:stream>.
>> > Aha, that reasoning makes sense to me -- in a sense, there is no active
>> error condition, just a kind of passive reason to drop the stream.
> Well, I think it's worth specifying a reason for the stream closure. 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.

Currently, when a client desires to end its session, it simply sends
</stream:stream> and that is the end of the conversation. It doesn't
specify a stream error because there is no error condition. By contrast,
when a server ends a client-to-server stream, it does send a stream
error because we tend to assume that a server can't end a client's
session on a whim, it needs a good reason to do so.

The question is: can a server end its session with another server on a
whim, or does it always need a reason? Theoretically I tend to feel that
it would always be friendly to specify a reason, but I'm not convinced
that in practice that's really necessary.


- --
Peter Saint-Andre
Jabber Software Foundation

Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

-------------- 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/20060601/2ea684fa/attachment.bin>

More information about the Standards mailing list