[Standards-JIG] Closing idle streams

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

Dave Cridland wrote:
> On Thu Jun  1 23:50:31 2006, Peter Saint-Andre wrote:
>> 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.
> I agree with your theory, and in practise I don't think it's a 
> significant overhead in most cases. I'd call it a RFC2119-SHOULD. I'm 
> somewhat neutral in whether a JEP is needed here or not, but I do think 
> it belongs in 3920bis.

A sentence or two about it in rfc3920bis seems appropriate. As 
previously mentioned, if we publish a JEP about it, that JEP would 
simply be a placeholder that captures the list consensus until 
rfc3920bis is officially published.

> Now... I said "in most cases", and SHOULD rather than MUST. The cases 
> where I think it's be good to close the stream without a reason are:
> 1) Where there is a significant cost-per-octet. I can't really see this 
> being the case for s2s connections.


> 2) Where there is very low available bandwidth. This could be the case 
> for s2s connections, when they're simply running on a choked link or 
> something, or when they're running in largely isolated networks.

I rather doubt that people on such links will be running servers, but 
it's possible.

> 3) Where the link forces a very small packet size. I can't see this 
> being a real issue.

Me, neither.

> Otherwise, the error and stream closure can both fit in a single packet, 
> and the overhead isn't big in percentage terms.


I don't like implicit protocol behavior, IMHO it's best to be explicit.


Peter Saint-Andre
Jabber Software Foundation

-------------- 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/632aed7d/attachment.bin>

More information about the Standards mailing list