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:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
