[Standards-JIG] stream restarts

Peter Saint-Andre stpeter at jabber.org
Thu Sep 14 20:33:36 UTC 2006

A while back, Matthias Wimmer proposed that we define an option for not
doing stream restarts in rfc3920bis:


I took it as an action item to investigate why the stream restarts were
there in the first place and whether we really need them:


I've done the research and I don't think we need to do the stream
restarts, at least not in order to comply with the TLS spec, since
Section 7.1.2 of RFC 4346 says:

   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended.  If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation MAY choose to close the
   transport without waiting for the responding close_notify.  No part
   of this standard should be taken to dictate the manner in which a
   usage profile for TLS manages its data transport, including when
   connections are opened or closed.

There's nothing in RFC 4422 (SASL) that would influence whether we have
restarts, either.

So, as far as I can see, we don't absolutely need the stream restarts.

Therefore, I don't have any objections to defining an OPTIONAL method
that the initating entity and receiving entity can agree on so that they
won't do stream restarts during a given session. Presumably we'll do
that with a new stream feature. I'll post again soon with some thoughts
about how we might do that.


Peter Saint-Andre
Jabber Software Foundation

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

More information about the Standards mailing list