Hey Peter, When I implemented "stream restarts" I was really following the spec without seeing the reason for the restarts. I was not sure if I was missing the point about something or not. In our case, the server was not keeping any information about the session so we really were not forgetting anything with the stream restart. Maybe I'm still missing the point here. :)
Anyway, I'm all good with avoiding the stream restart and just use one stream header where TLS, SASL, etc. are negotiated. BTW, what's the reason for doing this change now? Is it to reduce the amount of traffic and make it more appealing to mobile clients? Regards, -- Gato -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Saint-Andre Sent: Tuesday, April 29, 2008 12:57 PM To: XMPP Extension Discussion List 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/
