[Standards] stream restarts

[Dave Cridland]

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   
>> time,
>> why force all the newer implementations to jump through the same  
>> old
>> hoops?), but I'll let folks who are closer to the code speak to  
>> that.
> 
> 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  
client-speak-first.

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.
-- 
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at jabber.org
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade