[Standards] stream restarts

Stephen Pendleton stephenpendleton at hotmail.com
Wed Apr 30 14:58:37 UTC 2008

As a mobile client author I would be really in favor of this. It always seemed inelegant to restart streams and requires a parser reset. It also makes the state machine that describes the connection procedure less complicated and we always try to make things simple on the XMPP client side at least.
I would be interested in seeing what the new stanza flow looks like too.

> Date: Tue, 29 Apr 2008 13:56:45 -0600> From: stpeter at stpeter.im> To: standards at xmpp.org> Subject: [Standards] stream restarts> > A few weeks ago I got to talking with Joe Hildebrand and Travis Shirk at> Jabber Inc. about stream restarts. Once upon a time we thought we needed> them (e.g., so that the server would be sure to forget about any data it> received before STARTTLS completed), but now we realize that was a> misunderstanding of the TLS and SASL specs. So it seems that we could> redefine the stream negotiation process to get rid of stream restarts> after STARTTLS and SASL negotiation. The conclusion that Joe and Travis> and I came to is that we could do this by defining new features for> STARTTLS and SASL negotiation. So a server that supports old STARTTLS> and "STARTTLS2" would advertise both features. If you choose STARTTLS2,> you would not restart the stream and the server would not expect you to> do so. But if you support STARTTLS you would use that and both sides> would expect the stream restarts. IMHO the new features would use> namespaces like urn:xmpp:starttls instead of the namespaces in the IETF> tree, but that's a minor detail (the important point is that the xmlns> would be different).> > If there are no objections to this idea, I'll write up a little XEP or> two about this.> > Peter> > -- > Peter Saint-Andre> https://stpeter.im/> 
Make i'm yours.  Create a custom banner to support your cause.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20080430/fd59b34e/attachment.html>

More information about the Standards mailing list