[Standards] stream restarts

Dave Cridland dave at cridland.net
Wed May 7 08:31:11 UTC 2008


On Tue May  6 20:37:16 2008, Alexander Gnauck wrote:
> * this saves us some round trips

If you're particularly aggressive about RTT saving, both with and  
without restarts, then I think there's one RTT saved by not having  
the restarts. I admit this is only off the top of my head, but I  
think it's the stream restart after SASL where we save one, as the  
server could then merely reissue the new stream features immediately  
with the success marker.


> * gets us closer to "real xml"

I think Justin's got a point - it makes us appear, in some respects,  
to be more like classical XML, but also makes us less so in other  
ways. The most "XML-like" we could be would be closing the stream  
prior to stack insertions.


> * makes the specs much cleaner because on some stream features we  
> restart the stream (tls, sasl, compression), with otehrs we don't  
> (bind, session).

Now here I disagree on several counts.

Firstly, it ought to be obvious when we restart - we do so  
specifically when a stack insertion may have occured.  (I say "may",  
because in the case of SASL it's optional and rare).

Secondly, I'd dispute any lack of clarity caused by them anyway.  If  
you're going down this road, I'd like to see evidence of actual  
interoperability problems caused by this alledged issue.

Thirdly, it won't make the specs any cleaner - instead, it will  
simply cause confusion, as both restarting and non-restarting  
implementations - both clients and servers - will exist for many  
years to come, and both methods will have to be supported in all  
implementations in order to interoperate.

So on balance, I'd say that this wasn't worthwhile.

1) For TLS, I'm not convinced it makes any technical difference.  
(Sure, it looks nicer, and ugly isn't good, but ugly is not a reason  
in itself for change). I think the net result of such a change would  
be confusion.

2) For XEP-0138, I would argue that XEP-0138 is largely legacy  
anyway. TLS compression is the way forward for most cases - those  
cases which are specific to XML might benefit from XEP-0138, but  
then, things like EXI will almost certainly require a stream restart  
anyway.

3) For SASL, you could get away without a stream restart in the case  
where no security layer is negotiated quite easily - this being the  
typical case. Moreover, this benefits. So, I'd be open to adding an  
additional attribute to <auth/> which indicates that the initiating  
entity wishes to avoid a stream restart if no security layer is  
negotiated.

If the initiating entity does so, then the receiving entity MUST send  
a <features/> element, which MAY be empty, after the <success/>  
element, when ordinarily both sides would engage any security layer  
and restart the stream.

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



More information about the Standards mailing list