Dave Cridland wrote: > On Thu Feb 14 22:49:20 2008, Peter Saint-Andre wrote: >> On Thu, Feb 14, 2008 at 08:39:29PM +0000, Dave Cridland wrote: >> > Lots of work from mobile email (ie, Lemonade) is transferrable >> here. > It'd be really nice if Tony Finch was coming, since he could >> talk us > through QTLS and QUICKSTART - they're SMTP fast startup >> work he did a > while back. Very interesting, but didn't make it into >> the Lemonade > Profile itself. >> >> Do you have references? At least we could read up on it so we can >> discuss it intelligently at the devcon, then pester Tony with questions >> afterward. >> >> > You don't need to read them, just say "Ah, yes, QTLS, hmmm", then nod > sagely. > > Or you could look at: > > QTLS/QUICKSTART: > > Two flavours; simple and full: > http://tools.ietf.org/html/draft-fanf-smtp-quickstart-a-00 > http://tools.ietf.org/html/draft-fanf-smtp-quickstart-b-00 > > Both are really scary. I've always been a big fan of the detailed > round-trip analysis at the end. I'm hoping Tony will notice this thread > and do something similar for XMPP.
I haven't read those yet, because you scared me off. :P > Then there's this evil trick of mine, which you can use in concert with > Tony's insane hackery: > http://tools.ietf.org/html/draft-cridland-sasl-tls-sessions-00 That's interesting. The reuse (overloading?) of SASL EXTERNAL is creative. :) I tend to agree with your speculation that we might want to define a family of EXTERNAL-like mechanisms, rather than forcing a wide variety of credential types (X.509 certs, IPSec, reauth) into the one EXTERNAL mechanism. > Otherwise, the remaining tricks we can use are fast resynchronization > from a known state point, and fast reconnection. > > Fast reconnection is essentially the case where there is a short time > period between the end of the last connection and the beginning of the > next, such that both ends can maintain full state. XEP-0198 is basically > fully addressing this - it allows for the somewhat curious case of a > client noticing it's offline and reconnecting before the server has a > chance to notice what's happening. Yes, I need to update that spec real soon now (to incorporate some feedback that Justin hasn't had time to work in). > Fast resynchronization is somewhat more complex - roster optimizations > is one area we need, and I think I see a clear way of doing this. > Whether it's implementable by everyone I don't know. Essentially, it > would be a monotonically increasing modification sequence on the roster, > and whenever a roster entry is changed, increasing the sequence and > stamping the roster entry with the current value. Rosters are so core to how both clients and servers work that I somewhat doubt if changes thereto will see wide implementation or deployment anytime soon. > It's more efficient > than ETags on the entire roster, and would then give clients a simple > "tell me stuff that's changed" operation. Roster removals would still be > painful, but those are rather rarer than changes and additions, I think. Agreed. > This is basically lifting RFC 4551's conditional fetch and reapplying it > to rosters. Yay, another RFC to read. :) > Presence and PubSub resynchronization I think would need addressing for > this, too, but I don't have a clear idea of what can be done there. > > One thing we can do is buffer... If you can get all the initial presence > splurge into a single buffer before you compress/encrypt/send, you'll > get much better compression. > > >> >> 5. Advisability of presence-only connections (no roster-get, just send >> >> presence and whatever you receive is nice). >> >> >> > If you can optimize the roster fetch sufficiently, this really >> isn't > required. >> >> Probably not. >> >> > Oh, definitely not - the only excess would be the first roster fetch - > subsequent ones will yield no data in normal cases. Obviously we still > need to discuss not fetching the roster carefully, since it'll be a > useful tactic until we get an optimized roster thing widely deployed. More to talk about at the devcon... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
