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: [EMAIL PROTECTED]> To: > [email protected]> 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. http://im.live.com/Messenger/IM/Contribute/Default.aspx?source=TXT_TAGHM_MSN_Make_IM_Yours
