[Standards] stream restarts
dave at cridland.net
Wed Apr 30 07:50:13 UTC 2008
On Tue Apr 29 21:48:04 2008, Curtis King wrote:
> On 29-Apr-08, at 2:43 PM, Peter Saint-Andre wrote:
>> Curtis King wrote:
>>> I have one question why? I see absolutely no return for this
>>> work, as it
>>> safes what 2 round trips.
>> I think the main driver is simplification of stream handling (we
>> will be
>> living with the core XMPP stream negotiation protocols for a long
>> why force all the newer implementations to jump through the same
>> hoops?), but I'll let folks who are closer to the code speak to
> I found it added no complexity in implementation. Also, since you
> would have to send a new capability list after TLS and SASL
> negotiation anyways I would argue the existing stream restarts is
> simpler than avoiding them ;-)
Indeed - I'm not even sure it saves round-trips, given that it's
This is not terribly valuable work, and I don't see any reason to
devote any effort to it, especially given that we'd be stuck with the
"old style" more or less forever.
One more thing - for many stream restarts, these could have been
stripped in RFC3920 - prior to us deploying. But for some, it's
largely impossible - consider, for example, a switch to EXI. In this
case, you'd need to restart the stream, since you'd need to bootstrap
a new parser. (It'd be possible to spoof the <stream:stream> element
start tag, but, well, hackery-dackery.)
So in summary:
a) Lots of effort for minimal gain, and perpetual legacy support.
b) Gain is mostly æsthetic.
c) Sometimes, that gain is a loss.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the Standards