[15:43:27] --- eburger has joined
[15:50:06] --- pguenther has joined
[15:50:22] --- alexeymelnikov has joined
[15:52:03] --- randy has joined
[15:53:24] * alexeymelnikov is going to talk along
[15:53:59] <alexeymelnikov> a/along/a lot
[15:54:52] <randy> *tests this stuff*
[15:55:15] --- cyrus_daboo has joined
[15:55:22] * pguenther mumbles
[15:55:45] <randy> *tests again*
[15:59:54] --- Glenn Parsons has joined
[16:00:09] <Glenn Parsons> Greetings from Geneva...
[16:00:26] <randy> How is Geneva?
[16:00:49] --- cnewman@jabber.org has joined
[16:00:58] <Glenn Parsons> it is starting to cool off, it was 25C last week
[16:01:47] <randy> That seems awfully warm for Geneva
[16:02:32] --- cyrus_daboo has left
[16:02:38] --- kmurchison has joined
[16:03:22] <cnewman@jabber.org> Glenn, are you hearing the audio feed?
[16:03:30] --- Barry Leiba has joined
[16:03:42] * pguenther scribes
[16:03:56] <pguenther> presentations are all uploaded
[16:04:01] --- cyrus_daboo has joined
[16:04:08] --- doug.otis@gmail.com has joined
[16:04:28] <pguenther> note welll....
[16:04:37] <pguenther> agenda bashing
[16:04:42] <pguenther> status
[16:04:50] <pguenther> interop event
[16:04:58] --- arnt has joined
[16:04:58] <pguenther> document discussion
[16:05:01] <pguenther> inter-plenary work
[16:05:08] <pguenther> plan for profile
[16:05:12] <pguenther> milestones
[16:05:13] --- Dave Cridland has joined
[16:05:28] <pguenther> desire to discuss charter...?
[16:05:35] <pguenther> going....
[16:05:37] <pguenther> going...
[16:05:43] <pguenther> gone
[16:05:54] <pguenther> that's the agenda for today
[16:05:59] <pguenther> day 2
[16:06:08] <pguenther> issues from the interop
[16:06:16] <Glenn Parsons> audio is great
[16:06:32] <Dave Cridland> I don't seem to be getting audio. :-(
[16:06:34] --- eburger has left
[16:06:48] <pguenther> document editting for convert, search-within, views/filtering, profilebis
[16:07:07] <Glenn Parsons> http://videolab.uoregon.edu/events/ietf/ietf675.m3u
[16:07:16] <pguenther> comments on the agenda?
[16:07:19] <pguenther> split on the days?
[16:07:22] <pguenther> anything?
[16:08:06] <pguenther> Stephane Maes not here, Ray will be his rep (sorta) here
[16:08:13] <pguenther> moving on
[16:08:20] <pguenther> document status:
[16:08:26] <pguenther> out of our hands:
[16:08:42] <pguenther> published: profile, urlauth, burl catenate, mms ..../
[16:08:51] <pguenther> some stuff approved or in queue
[16:09:02] <pguenther> two docs in last call
[16:09:11] <pguenther> convert and search-within
[16:09:22] <pguenther> annotatemore to be reviewed in imapext
[16:09:27] <pguenther> then IETF LC
[16:09:32] <pguenther> documents to discuss
[16:09:34] <pguenther> views
[16:09:35] <Dave Cridland> Ooooh. Audio! Yay!
[16:09:39] <pguenther> other bis bits
[16:09:40] <pguenther> reocnnect
[16:09:42] <pguenther> notificatgioins
[16:09:46] <pguenther> notifications, even
[16:09:53] <pguenther> streaming media
[16:09:55] <pguenther> profile-bis
[16:10:39] <Glenn Parsons> besides posteriety...
[16:10:55] <Glenn Parsons> ther might be some value in some deployments
[16:11:10] <Glenn Parsons> if we have done the work, it makes sense to publish
[16:12:57] <pguenther> Ray: was there other stuff that would be expensive to resync?
[16:13:01] <Glenn Parsons> i would agree that it makes more sense to keep them separate...
[16:13:08] <pguenther> eric: publish after client-side
[16:13:25] <pguenther> alexey: ..but not as an appendix in client-side
[16:13:31] <Glenn Parsons> and publish after
[16:13:35] <Glenn Parsons> not as appendix
[16:13:42] <Glenn Parsons> as informational
[16:13:43] --- Aaron Stone has joined
[16:14:04] --- resnick has joined
[16:14:22] <pguenther> eric: streaming-media as tar-pit for draft editors
[16:14:39] <pguenther> ------
[16:14:42] <pguenther> interop event
[16:14:49] <pguenther> reasons:
[16:14:59] <pguenther> - marketting (often downplayed or forgotten in IETF)
[16:15:14] <pguenther> - prove viability of I-D for RFC
[16:15:22] <pguenther> - moving to draft standard
[16:15:25] --- tonyhansen has joined
[16:15:27] <pguenther> - compliance
[16:15:34] <pguenther> - input to OMA IOP
[16:16:16] <pguenther> testing in late Oct in London was 'private' testing: NDAs in force
[16:16:46] <pguenther> telecom 2006, dec 4-8: more public
[16:16:58] <pguenther> another later basically fully public, more marketting
[16:17:02] <pguenther> summary:
[16:17:08] <pguenther> 4 test servers
[16:17:18] <pguenther> 6 companies, 3 universities
[16:17:25] <pguenther> testinged RFC 4550 bits
[16:17:46] <pguenther> results: lots worked
[16:17:55] <pguenther> some specs need clarification
[16:18:00] --- cromwellian has joined
[16:18:28] <arnt> there was a problem with BURL - the capability advertised
[16:18:30] <pguenther> note: no particular problems with BURL
[16:18:45] <pguenther> arnt: how so?
[16:18:47] <arnt> imap://some.thi.ng to indicate prearranged trust had a problem
[16:18:54] <arnt> chris knows and will deal with it
[16:19:44] <arnt> ok
[16:19:46] <pguenther> slide 13
[16:19:54] <pguenther> ty arnt
[16:19:59] <pguenther> changes to profilebis
[16:20:06] <pguenther> replaced reconnect with qresync
[16:20:20] --- greg.vaudreuil has joined
[16:20:23] <pguenther> added within and list-extended, move idle to new section
[16:20:33] <pguenther> added format=flowed
[16:20:54] <pguenther> clarified smtp size vs smtp burl
[16:21:10] <pguenther> will be another rev for that last bit
[16:21:27] <pguenther> slide 14
[16:21:32] <pguenther> 2192bis issues
[16:21:56] <pguenther> same slide as in montreal
[16:22:01] <pguenther> :-)
[16:22:05] <pguenther> slide 15
[16:22:09] <pguenther> notifications
[16:22:32] <pguenther> alexey's presentation are on the meeting materials site
[16:22:47] <pguenther> controlling in-band notifications
[16:23:00] <pguenther> problem statement;
[16:23:15] <pguenther> idle implemented, but no way to control which events are returned
[16:23:22] <pguenther> spec allows anything
[16:24:02] <pguenther> not all servers returned flag chnages
[16:24:46] <pguenther> barry: failure to return flag changes may be design problem particular servers and not specific to idle
[16:25:12] <pguenther> alexey: notify extension would let client specify what it wants
[16:25:35] <arnt> love the way he pronounces my name.
[16:25:57] <Dave Cridland> Arnt: It comes across as Uncle Branson, which is slightly curious. :-)
[16:26:16] <pguenther> barry: reason for current idle design is that modal interface was pushed back on at that time
[16:26:47] <resnick> Is there a URL for this draft? I missed it.
[16:27:05] <pguenther> it was on first slide
[16:27:19] <resnick> Can someone paste it here?
[16:27:25] <Dave Cridland> draft-gulbrandsen-imap-notify-01.txt
[16:27:32] <resnick> thx
[16:28:04] <pguenther> open issues with draft:
[16:28:14] <pguenther> not sure if extension to IDLE is worthwhile
[16:28:21] <arnt> pete: this is in a sense the twice-improved version of the nostore thing you may remember
[16:28:23] <pguenther> expressing mailbox rename as delete + create is ugly
[16:28:56] <pguenther> minor issues about access controls
[16:29:13] --- Lisa has joined
[16:30:04] <pguenther> pete: if a client asks for everything, then the server MUST send everything? A: yes
[16:30:58] <Lisa> Hi Arnt! Did you change your IM address? I don't see you online on your old one
[16:31:33] <arnt> Lisa: arnt@oryx.com is so old that while I know I had an older one, I've forgotten what it might have been.
[16:31:40] --- eburger has joined
[16:31:57] <pguenther> pete: this means servers MUST do generation of async njotifications
[16:32:05] <pguenther> chris: worried about shared folders
[16:32:15] <pguenther> clients will not expect to get all the bits they will
[16:32:35] <eburger> Updated Alexey slides on the Meeting Materials Web Site, "Notifications, Named Searches, and URLs". You may need to refresh the page to see the link.
[16:32:59] <pguenther> make it simple to ask for mailbox that are subscribed or owned by the user
[16:33:31] <pguenther> barry: still need to queue EXPUNGES
[16:33:49] <arnt> alexey, I'll add the necessary text PDQ ;)
[16:33:58] <pguenther> cyrus: give servers way to say "no, that's too much, you only get this much"
[16:34:13] <pguenther> randy: expresses support for chris's concerns
[16:34:35] <pguenther> initial version that only works on mailbox you own?
[16:35:29] <pguenther> chris: don't have problem with notifications for shared folders, but only if the client understand what they're getting
[16:35:54] <pguenther> TRUST-ME parameter?
[16:36:32] <pguenther> don't want clients to connect to server, list all folders, then download all messages in all folders
[16:36:55] <Glenn Parsons> audio is cutting in & out...
[16:36:58] <pguenther> randy: solve the immediate problem
[16:37:00] <Glenn Parsons> are we talking about IMAP IDLE?
[16:37:11] <resnick> NOTIFY
[16:37:12] <pguenther> notify draft
[16:37:33] <pguenther> moving on
[16:37:37] <pguenther> named searches
[16:37:42] <Glenn Parsons> OK
[16:37:45] <Glenn Parsons> please post the URL
[16:37:48] <pguenther> new version of alexey's slides has been uploaded
[16:38:28] <pguenther> http://www3.ietf.org/proceedings/06nov/slides/lemonade-1.ppt
[16:38:30] <pguenther> I thin
[16:38:32] <pguenther> ki
[16:38:35] * pguenther gives up
[16:38:41] <pguenther> overview
[16:38:41] <resnick> https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=67 and look for lemonade.
[16:39:00] <pguenther> adds ability to store search filters on server in annotations
[16:39:14] <pguenther> reference saved searches in search command
[16:39:40] <pguenther> ex: tag SEARCH UID 300:900 FILTER on-the-road SINCE " 3-Dec-2002"
[16:40:01] <pguenther> ray: interaction with out-of-band notifications...?
[16:40:57] <pguenther> sync up the named searches for in-band vs out-of-band? carry name of filter in out-of-band notifciations
[16:41:07] <pguenther> imap url update
[16:41:12] <Dave Cridland> What happens when more than one named filter triggers a notification, though?
[16:41:45] <Dave Cridland> For Ray's suggestion of out-of-band stuff, I mean.
[16:42:03] <resnick> (Folks mumble at eachother trying to figure out the answer)
[16:42:35] <Dave Cridland> Nope.
[16:42:45] <pguenther> moving on...
[16:43:02] <pguenther> relative path URLs are underspecificied, or maybe just too weird
[16:43:19] <pguenther> interact poorly with servers that don't use /
[16:44:02] <Dave Cridland> BTW, "relative URLs" are now called "relative references"...
[16:44:14] <Dave Cridland> (It's in RFC3986, now)
[16:44:18] <pguenther> that sounds like a suggested wording change for the document
[16:45:50] <arnt> what's the point of relative URLs for lemonade use anyway?
[16:45:56] <Dave Cridland> A '/' character in a URI path means a heirarchy seperator. So if it's not, you need to encode it.
[16:46:06] <pguenther> they are only allowed by CATENATE
[16:46:12] <Dave Cridland> Arnt: You mean, what's the point of dot-segments.
[16:46:44] <Dave Cridland> Arnt: But yes, they're difficult to generate, and difficult to resolve, but also part of RFC3986, so basically you can't avoid them.
[16:47:08] <pguenther> they're useful there as you can refer to messages in the selected mailbox with just the UID
[16:47:23] <pguenther> continuing slides...
[16:47:44] <pguenther> does does this meaning: foo/;UID=20/..
[16:48:56] <Aaron Stone> (offline question) Is there a document that deprecates the non-"/" separators? The responses to LIST and LSUB tell you the mailbox hierarchy separator for each mailbox.
[16:49:14] <arnt> there is no such document.
[16:49:46] <Dave Cridland> Aaron: No, IMAP servers are still free to use any delimiter, although, erm, RFC2197 (maybe? Implementor's advice one) suggests use of a restricted subset of characters.
[16:50:09] <arnt> 2683 does that.
[16:50:19] <arnt> 3.4.10
[16:50:51] --- jr111 has joined
[16:50:53] <Dave Cridland> Ah, then it has to begin with ./
[16:51:00] <Dave Cridland> So ./;UID=20
[16:51:08] <Aaron Stone> 3501 mandates that it be a single character. So if "." is otherwise legal as a hierarchy delimeter, then how did the WG get to having URL not allow . as a hierarchy delimeter?
[16:51:12] <Dave Cridland> It can't be /;UID=20
[16:51:21] <Aaron Stone> Is there some discussion i can read up on?
[16:51:42] --- cromwellian has left
[16:51:44] <Dave Cridland> Aaron: The URL herirarchy seperator is defined by URI syntax itself, RFC3986
[16:51:57] <Dave Cridland> Aaron: Whereas IMAP's heirarchy is *different*.
[16:52:26] <Glenn Parsons> is someone not using the mike?
[16:52:32] <Aaron Stone> Chris just said that there is a mapping between the URL and the IMAP mailbox.
[16:52:41] <Dave Cridland> Phil: Can you remind the nice people that those funny stick things are called "microphones". :-)
[16:52:57] <Aaron Stone> Does that mean that INBOX.Apple.Green can be represented as imap://.../INBOX/Apple/Green ?
[16:53:02] <arnt> yes
[16:53:11] <Dave Cridland> Aaron: Nope.
[16:53:17] <arnt> why not?
[16:53:45] <pguenther> because there's no delimiter mapping on imap URLS
[16:53:48] <Dave Cridland> Aaron: It means that it's imap://.../INBOX.Apple.Green - but it also means that the URI itself has no heirarchy.
[16:53:53] <pguenther> you must use the delim that the server uses
[16:55:27] <Dave Cridland> Channel this: So: Do we correct that, or else do we learn that we should use ./;UID=20
[16:55:58] <Dave Cridland> (As in, do we correct the missing slash)
[16:56:41] <Lisa> what document do I look at to find out what kind of relative URLs are possible in IMAP URLs?
[16:56:59] <Dave Cridland> The missing slash in CATENATE.
[16:57:00] <cyrus_daboo> rfc2192///
[16:58:33] <pguenther> just because something has a meaning doesn't we're worried about it
[16:58:56] <pguenther> Lisa: relative paths are useful when typing stuff in, dangerous on the wire
[17:00:31] --- cromwellian has joined
[17:00:31] <cromwellian> hmm, i knew I wasn't completely crazy. rfc2396 section3 seems to imply that "://" following the scheme name implies, atleast by tradition, that the scheme-specific-part is hierarchical. :)
[17:01:44] <Dave Cridland> cromwellian: Yes, I agree. The trick is that for IMAP, we may or may not have a heirarchy that fits, so we need to encode slashes accordingly.
[17:02:32] <Dave Cridland> IIRC, from the list archives, the primary reason we did this was to make absolute URLs useful for cross-server copying by using URLAUTH et al.
[17:02:49] <Dave Cridland> In other words, we allowed absolute URLs to always mean "another server".
[17:03:00] <cromwellian> yeah, makes sense
[17:03:40] <Dave Cridland> I think the case of leading-slash needs expressly noting, whatever.
[17:04:02] <pguenther> pete: in catenate, client might not have conveniet access to the absolute URL
[17:05:25] <pguenther> idea: limit URLs in catenate to not include relative-path URLs
[17:05:46] <pguenther> only absolute, full path (no server), or just modifiers
[17:05:56] <pguenther> (I think that was the idea)
[17:06:09] <pguenther> moving on
[17:06:13] <pguenther> profile bis
[17:06:16] <pguenther> suggestions
[17:06:21] <pguenther> IMAP SASL-IR
[17:07:19] <pguenther> mumbling to decide whether to cover this right now
[17:07:29] <pguenther> pause in technical bits to cover admin bits
[17:07:51] <pguenther> time permitting, we'll go back to the profile bitrs
[17:08:11] <pguenther> back to chair slides #17
[17:08:36] <pguenther> face-to-face unneeded? monthly jabber chats to push stuff forwards...
[17:10:18] <pguenther> randy: jabber chat idea interesting. if we were to have an interim, topic should be notifications+vfolders
[17:10:42] <pguenther> ray: agrees, bits tied together
[17:11:16] --- ams has joined
[17:11:40] <pguenther> eric: next meeting this week as interim...
[17:12:01] <pguenther> alexey: hopefully wrapping up bis, 4/5 docs need to last call
[17:12:11] <Glenn Parsons> I agree that we need focus on vfolders....and some more on notifications (though we have done a lot of work thus far)....
[17:12:18] <pguenther> that work should keep up quite busy through march
[17:12:29] <Glenn Parsons> these are the two areas that need the most thought...
[17:13:04] <pguenther> docs on deck for last call:
[17:13:13] <pguenther> 2192bis
[17:13:31] <pguenther> convert (another last call due to substantive changes)
[17:13:36] <pguenther> msgevent
[17:13:38] <pguenther> notifications
[17:13:57] <pguenther> imap-events
[17:14:03] <pguenther> notification-protocol
[17:14:09] <pguenther> imap-sieve
[17:14:24] <pguenther> those last four are perhaps "less baked"
[17:15:06] <pguenther> slide #19
[17:15:09] <pguenther> profiel plans
[17:15:12] <arnt> channel this: compress is nice and ready
[17:15:30] <pguenther> it's in last call already, no?
[17:15:47] <arnt> WGLC or IETFLC? certainly not the latter, and I think the former expired.
[17:15:49] <pguenther> it's ahead of the stuff in the previous slide
[17:15:50] <cromwellian> search-within is also WGLC (not on slide, but announced WGLC on list I think)
[17:16:07] <Dave Cridland> cromwellian: Yes, spotted that today.
[17:16:12] <arnt> ray, I sent you LC comments an hour ago
[17:16:24] <cromwellian> thx, will check
[17:16:31] <pguenther> eric: suggestion: publish profile bis with whatever is ready of notifications, views, streaming
[17:17:01] <pguenther> publish profile ter with rest of feature set *OR* do we wait and do everything at once (in profilebis)
[17:17:14] --- cnewman@jabber.org has left: Replaced by new connection
[17:18:04] <pguenther> opportunistic uptake of last-called bits into profile-bis
[17:18:08] <pguenther> thoughts?
[17:18:20] <pguenther> chairs get to decide, but would LOVE input
[17:18:53] <pguenther> Dimitry: OMA depending on profilebis to include stuff
[17:19:53] <pguenther> would cause confusion; what to do with bis?
[17:20:21] <pguenther> s/Dimitry/Dorothy/
[17:20:26] <pguenther> (sorry!)
[17:20:38] <Dave Cridland> Speaking as "just me", rather than a document editor, I don't have a good feel for Notifications, in particular, being ready for March. I think we'd be rushing to get it done right. The rest - in particular some form of view filter system, which is important, I think we can get done very quickly indeed.
[17:20:40] * pguenther tries to read badges from 3 rows away
[17:22:45] <pguenther> Dorothy: given choice between bis sans notification and delay, would prefer delay
[17:23:20] <Dave Cridland> The thing is, the OMA will get a delay whether we do a profile bis as final, or profile ter as final.
[17:23:31] <pguenther> uh huh
[17:23:49] <Dave Cridland> (And you can channel that should you wish)
[17:24:31] * pguenther defers, given the flow
[17:25:04] <Dave Cridland> That's okay.
[17:25:13] <Glenn Parsons> I think the issue is that if we just delay...that is easy to explain.
[17:25:34] <Glenn Parsons> if we split fuinctionality between a profile bis and ter
[17:25:39] <Glenn Parsons> that is harder to explain
[17:25:55] <Glenn Parsons> :-)
[17:26:32] <pguenther> anyway, back to profilebis
[17:26:37] <pguenther> SASL-IR
[17:26:54] <Glenn Parsons> we are on which slide?
[17:27:07] <Dave Cridland> Glenn: Alexey's 9.
[17:27:18] <pguenther> SMTP compression?
[17:27:46] <Dave Cridland> Have people forgotten the microphones, or is Alexey talking to the voices in his head?
[17:27:59] <pguenther> SMTP checkpoint/restart (to match IMAP quick reconnect)?
[17:28:02] <pguenther> voices in his head
[17:28:08] <Dave Cridland> Ah, okay. :-)
[17:28:22] <Lisa> people saying stupid things quietly (speaking for myself ;)
[17:28:37] <Dave Cridland> Tony Finch has been threatening to publish his REPLAY update to RFC1845
[17:28:50] <Lisa> I asserted away from the mic that Arnt was not the author of the IMAPEXT i18n doc and Chris looked at me strangely :)
[17:28:57] <Dave Cridland> (RFC1845 being CHECKPOINT/RESTART)
[17:29:23] <pguenther> chris: re: checkpoint/restart getting chunking interop appears to be tricky, checkpoint is worse
[17:29:30] <arnt> arnt seems to be the author or editor of every document that's delaying people
[17:29:55] <Dave Cridland> Arnt: And Alexey is the author of all the rest.
[17:30:29] <Lisa> A function of who's willing to take on the most difficult things, at least in part.
[17:30:36] <Dave Cridland> Chris: I have to say, CHUNKING doesn't seem to throw up many problems I've seen - Polymer's done it for a while.
[17:30:44] <pguenther> eric: adding more stuff that isn't _really_ important may just delay interop
[17:32:02] <pguenther> pete: point of IMAP quick reconnect is the IMAP state; there is no real SMTP state to restore
[17:32:03] <cromwellian> A.Gulbrandsen, I sent you a response :)
[17:32:07] <cromwellian> inemail
[17:33:45] <pguenther> randy: dave's #s had seem to indicate that SMTP compression was indeed a win
[17:33:55] <Dave Cridland> Yes, compression on SMTP does give you benefit. Around 50% reduction (as opposed to 75% in IMAP).
[17:33:57] <pguenther> and now that we have IMAP compression, the code isn't that much worse
[17:34:32] <pguenther> ray: could always upload compressed via IMAP and then BURL
[17:34:41] <pguenther> <boos>
[17:34:55] <Dave Cridland> (This Ned? Tony Finch is already doing stuff there)
[17:34:59] <pguenther> Ned: remember that checkpoint was experimental
[17:35:07] <pguenther> alexey relayed that
[17:35:37] <pguenther> alexey: story of how checkpoint is cool
[17:35:51] <cromwellian> anyone did any messages on chatty protocol overhead in a typical SMTP exchange? seems like that would be a big factor in whether compression in SMTP would be a big win
[17:36:09] <cromwellian> s/messages/study/
[17:36:29] <Dave Cridland> cromwellian: SMTP isn't that chatty, so most of the compression is likely to be the data.
[17:36:53] <Dave Cridland> cromwellian: Tony Finch did do a lot of work on round-trip analysis, and decided that was the crucial area.
[17:37:06] <cromwellian> you mean latency
[17:37:15] <Dave Cridland> cromwellian: *nods*
[17:37:50] <Dave Cridland> (Those SMTP compression figures off the top of my head, I did do some tests in February or so)
[17:38:56] <pguenther> eric: big stuff on phone is probably a picture or video
[17:39:04] <pguenther> ...which is already compressed
[17:39:09] <Dave Cridland> diff formats are useless for traditional quoting, though.
[17:39:27] <Lisa> Is chunking useful for traditional chunking?
[17:39:29] <pguenther> this is all about checkpoint
[17:39:48] <Lisa> Brain-o. Is chunking useful for traditional quoting?
[17:39:58] <Dave Cridland> I did do lots of work on looking at using the deflate algorithm's dictionary API, and using dictionaries shared by URLAUTH to gain extra compression, which works very well.
[17:39:58] <pguenther> randy: quick connection restart using QTLS...
[17:40:00] <pguenther> ?
[17:40:08] <pguenther> (ref to Tony's thoughts)
[17:40:09] <arnt> compressing SMTP SUBMIT sits badly with CHUNKING. if you use BDAT/CHUNKING because the connection drops every 60 seconds, you defeat every sensibly simple compression. (channel if it seems sensible.)
[17:40:26] <Dave Cridland> Lisa: Nope. :-) Nor is BURL, although it *is* useful for top-posting.
[17:40:32] <pguenther> argh
[17:40:50] <alexeymelnikov> It sounds like there is consensus to add QTLS to Profile bis
[17:41:03] <cromwellian> dave, I did the same thing. I added every terminal in the RFC3501 BNF, as well as common email header fields, and I seemed to get a 10% improvement with deflate vs with no dictionary customization
[17:41:57] <Dave Cridland> cromwellian: I think we're talking about different stuff. I was using, as dictionary, the result of resolution of a URLAUTH of the message I was replying to. (Which is accessible from both sides).
[17:42:10] <arnt> let's say "no SMTP compression for now" and finish some other stuff.
[17:42:24] <Dave Cridland> cromwellian: As such, all the quoted bits compressed *really* well.
[17:42:49] <Dave Cridland> QTLS is a Tony Finch draft.
[17:42:53] <pguenther> chris: checkpoint doesn't seem to belong in profile, but we're geeks so we like to talk about cool ideas
[17:42:55] <Dave Cridland> Proto draft.
[17:42:57] <cromwellian> yeah, i was seeing if you could improve the compression of imap chatty protocol overhead. Oh i see, you;re talking about priming the dictionary with the attachment.message
[17:43:26] <Dave Cridland> cromwellian: Would work with draft editing in IMAP even better. It's effectively a really good diff format. :-)
[17:43:51] <pguenther> randy: QTLS blows away argument that submission outside of IMAP would be too expensive
[17:44:34] <kmurchison> http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf-smtp-quickstart.txt
[17:45:56] <randy> Not QTLS, but SMTP-QuickStart, as I recall
[17:46:10] <randy> The Tony Finch proto-draft?
[17:46:11] <cromwellian> dave, I find that idea very compelling, I almost wish 'compress' had additional modes to tell it to push the dictionary, load one from a given msg reference, and then pop the old one back later. Kinda like stephane's idea for selectively turning compression on/off, but maybe far more useful.
[17:46:39] <pguenther> pete confirms that catenate to be reved once 2192bis finalized
[17:47:16] <Dave Cridland> cromwellian: It freaked several people out. I'll dig out the figures if you like.
[17:47:17] <arnt> ray, search for a paper by doug jones on compression and encyption, you'll like it. he talks about priming the dictionary to get encryption.
[17:47:44] <cromwellian> stephane will love the idea. :)
[17:48:23] <arnt> I have a strong opinion: let's finish the stuff that ALREADY is in profile-bis, not have another long thread about compression ;)
[17:48:39] <arnt> and yes I know I'd contribute my fair share to that thread
[17:48:43] <Dave Cridland> arnt: I vote for object level ESMTP compression! ;-)
[17:49:20] * resnick coughs up a furrball at the thought of that.
[17:49:45] <arnt> per-recipient dictionaries in ESMTP? oh, fine!
[17:49:47] <cromwellian> no,TLS compression for ESMTP combined with tunneling over MPEG-2 HTTP streams through SOAP PACKETS
[17:50:28] <pguenther> summary: compression is out
[17:50:31] <pguenther> checkpoint is out
[17:50:33] <pguenther> SASL-IR is in
[17:50:35] <Dave Cridland> cromwellian: I don't think we're allowed to use TLS, it might put requirements on the TLS WG, which'd be very unfair.
[17:50:37] <pguenther> notification is in
[17:51:56] <Glenn Parsons> what is wrong with BINARY?
[17:53:27] <pguenther> issue is that it's the hard part of profile and kinda sticks out, because it was only required for one of the protocols
[17:54:24] <pguenther> ned: nervous over interaction of SMTP BINARY and DKIM
[17:54:34] <cromwellian> not having BINARY won't kill CONVERT, but it has huge implications for mobile devices if you don't have it
[17:54:40] <arnt> wait.
[17:54:51] <Glenn Parsons> there is SMTP BINARY & IMAP BINARYMIME. we should have both
[17:54:53] <arnt> BINARY is RFC 3516, right? not SMTP?
[17:55:28] --- Barry Leiba has left
[17:55:28] --- Barry Leiba has joined
[17:55:33] --- kmurchison has left
[17:55:35] <pguenther> glenn: vice versa
[17:55:37] <arnt> FETCH BINARY[2] compresses vastly better than FETCH BODY[2]
[17:55:40] --- Barry Leiba has left: Logging off
[17:55:41] <pguenther> SMTP BINARYMIME IMAP BINARY
[17:55:56] --- alexeymelnikov has left
[17:56:15] <pguenther> adjourne til thursday
[17:56:18] --- eburger has left
[17:56:43] --- arnt has left
[17:56:58] --- randy has left: Logged out
[17:57:03] <cromwellian> yeah, not having binary will kill a mobile device transferring binary attachments. Thats why I thought IMAP BINARY is a MUST, every Lemonade server should be expected to have it
[17:57:07] --- Aaron Stone has left
[17:57:11] --- resnick has left
[17:57:25] --- Lisa has left: Logged out
[17:57:26] --- cyrus_daboo has left
[17:57:38] --- cromwellian has left
[17:57:46] <Dave Cridland> cromwellian: Well, you can recover some of the base64 overhead by compression, but not all, and as Arnt says, for compressible attachments, you compress much better when they're decoded first.
[17:57:47] <Glenn Parsons> I agree binary is key
[18:00:52] --- jr111 has left
[18:01:33] --- doug.otis@gmail.com has left: Logged out
[18:02:42] --- Dave Cridland has left
[18:05:43] --- ams has left
[18:35:23] --- tonyhansen has left
[18:39:11] --- Glenn Parsons has left
[18:45:07] --- pguenther has left