[16:35:43] --- avel has joined
[16:36:06] --- avel has left
[17:51:05] --- randy has joined
[17:51:22] --- arnt has joined
[17:51:59] <arnt> what does that mean - "this room is not anonymous"?
[17:52:06] <arnt> randy, do you know?
[17:56:42] <arnt> I found it.
[18:07:04] --- kmurchison has joined
[18:17:39] --- Barry Leiba has joined
[18:17:39] --- eburger has joined
[18:17:41] --- cyrus_daboo has joined
[18:17:42] --- resnick has joined
[18:17:46] --- cnewman@jabber.org has joined
[18:18:06] <arnt> yes
[18:18:08] --- alexeymelnikov has joined
[18:18:20] <eburger> Eric Burger, Jabber Scribe
[18:18:23] --- aaronstone has joined
[18:18:27] --- pguenther has joined
[18:18:29] --- tonyhansen has joined
[18:18:58] <eburger> Chair's Slides http://www3.ietf.org/proceedings/06nov/slides/imapext-0.ppt
[18:19:10] <eburger> Agenda Slide
[18:19:18] <eburger> Anything for the agenda?
[18:19:28] <eburger> Cyrus to discuss documents
[18:20:26] <eburger> ANNOTATE: draft went through IETF LC for Experimental. That goes to IESG; Pete did PROTO writeup. Arnt asked Cyrus if Experimental is right level. Arnt felt that the protocol is baked.
[18:20:42] <arnt> I feel more comfortable with _this_year's_ draft than I did with _last_ year's.
[18:20:42] <eburger> Pete: Chair said, "It's done, so let's go with it; can go PS later."
[18:21:04] <eburger> Why go to PS? Give more comfort to people to implement.
[18:21:27] <eburger> Pete feels that most implementors are already here, so not important.
[18:21:34] <eburger> Any normative dependencies?
[18:21:35] <eburger> No.
[18:22:16] <arnt> I don't want to push hard. let's say I want to undo my push from last year.
[18:22:47] --- Lisa has joined
[18:23:05] <eburger> Decision from Chair: Leave as Exp for time being.
[18:23:21] <eburger> I18N Status
[18:24:04] <arnt> the draft is split in three. two of them are just fine (the two extenions).
[18:24:06] <eburger> Lisa: who has read I18N draft since COMPARATOR has been.
[18:24:13] <eburger> 2 people
[18:24:22] <eburger> Who has read SORT since COMPARATOR has been done.
[18:24:25] <arnt> the third is miscellaneous IMAP changes. we decided that was fine, but I suspect people may not think so any more.
[18:24:33] <eburger> 1.5 people
[18:24:37] <arnt> I've read SORT since COMPARATOR was done.
[18:25:02] <eburger> Who will do review: Phil, Tony, Cyrus, Barry, Ken
[18:25:31] <eburger> Send comments before U.S. Thanksgiving (22 November 2006)
[18:26:11] <aaronstone> http://tools.ietf.org/wg/imapext/draft-ietf-imapext-i18n/draft-ietf-imapext-i18n-06.txt
[18:26:53] <eburger> Cyrus wants an ibasic comparator done first. Could be done here or in SIEVE.
[18:27:22] <eburger> Volunteers for ibasic: Arnt?
[18:27:26] <arnt> I have a draft for i;basic (basically split off from the document, same text)
[18:27:33] <arnt> I submitted it too late.
[18:27:34] <eburger> Right answer :)
[18:27:50] <tonyhansen> for completeness, comparator is draft-newman-i18n-comparator-14.txt and sort is draft-ietf-imapext-sort-17.txt, right?
[18:28:58] <eburger> history: old IESG required i;basic. Is this still the case?
[18:29:24] <arnt> (who's speaking?)
[18:29:26] <eburger> Cyrus: calDAV progressed without i;basic. That said, you need it for a real-world deployment, anyway
[18:29:34] <arnt> (oh, cyrus)
[18:29:34] <eburger> Cyrus was speaking; female voice is Lisa
[18:29:55] <resnick> I'll be sure to make people introduce (or introduce them)
[18:30:30] <arnt> I know most people's voices anyway, is anyone else listening? ;)
[18:30:41] <arnt> arhive is
[18:30:44] <eburger> Easy to search on metadata without i;basic, but very hard to search on free-form, user-entered data.
[18:31:18] <eburger> Lisa: are the fields we're looking at enumerated, like calDAV? Answer: no.
[18:31:25] <arnt> gnashing of teeeth, but yes
[18:31:45] <arnt> I *know* I'll get impossible reviews from that.
[18:32:08] <eburger> Now, on to...
[18:32:13] <eburger> ANNOATATEMORE
[18:32:29] <Lisa> Let us know how we can help Arnt -- do you anticipate certain reviews which we can address ahead of time, or is this "expecting something random" here?
[18:32:54] <eburger> Cyrus needs more review. Volunteers for review: Ken, (Alexey already did review), ...
[18:33:30] <eburger> Comments from Alexey: Lack of exact match operator; expected to see multi-variable attributes (like ACAP)
[18:33:52] <eburger> Cyrus on Search: relies on IMAP SEARCH, which doesn't do exact match.
[18:34:47] <eburger> Phillip: Use match type modifier a la sieve?
[18:35:05] <eburger> Pete: Let's take this to the IMAPEXT list.
[18:35:17] <eburger> Get comments in by 22 November 2006
[18:35:28] <eburger> Alexey volunteers text...
[18:35:59] <eburger> Phil offers exact match should be stand-alone extension for everything.
[18:36:28] <eburger> Cyrus agrees
[18:36:29] <arnt> I have people asking for exact address searches as well.
[18:36:36] * pguenther smells a regexp extension
[18:36:43] <arnt> people want to search for fred@blah.com and not match alfred@blah.com.au
[18:37:58] <eburger> On Multi-valued attributes: Cyrus says "NO"
[18:38:14] <eburger> Cyrus offers to use a string list instead
[18:38:31] <eburger> Cyrus threatens a two-week delay
[18:39:26] <eburger> Alexey: all you have is substring values. You end up looking for "foo" and "foo," and ",foo" and ",foo,"
[18:40:05] --- healthyao has joined
[18:40:16] <eburger> Cyrus will do steal cage match over a brownie with Alexey to work this out.
[18:40:25] <eburger> EXPUNGED (Alexey)
[18:41:05] <eburger> Open issues: server that supports EXPUNGED causes spurious sync for CONDSTORE-only clients
[18:41:23] <eburger> Problem if client does CONDSTORE and not EXPUNGED
[18:41:58] <eburger> Options: since CONDSTORE is not widely deployed, require or strongly suggest if do CONDSTORE, have to do EXPUNGED
[18:42:14] <eburger> Option 2: hav separate per-mailbox MODSEQUENCE
[18:42:21] <eburger> s/hav/have
[18:44:14] <eburger> CONDSTORE requires EXPUNGED
[18:44:46] <eburger> For dual update, don't need both, but this has morphed into sync, where you do.
[18:46:01] <eburger> Don't want separate notificationsequence for EXPUNGED. Client that only implment CONDSTORE may get spurious resyncs.
[18:48:30] <eburger> Eric agrees to take CONDSTORE, EXPUNGED, and QRESYNC into lemonade as a SINGLE document
[18:49:23] <eburger> Will be called quick resync document
[18:49:57] <eburger> Since CONDSTORE is published, extensions to CONDSTORE will be in quick resync document. Will update CONDSTORE RFC
[18:50:18] <eburger> Issue 2: Handling of MODSEQUENCEs which are too old
[18:50:41] <eburger> Option 1: ignore MODSEQUENCE and return all expunged messages
[18:50:46] <eburger> Option 2: server says NO
[18:51:11] <eburger> Option 3 (Dave and Randy) Optimize Option 1
[18:51:28] <eburger> Cyrus: option 2, because no matter what one has to have code to fall back on
[18:52:29] <eburger> option 1 advantage: client doesn't have to have additional code to fall back on
[18:52:37] <eburger> client already knows how to deal with response
[18:53:23] <eburger> Barry: is there any other recovery other than getting option 1 result?
[18:54:26] --- ams has joined
[18:54:29] <eburger> Pete thinks there is a situation, but not clear to me.... 8-)
[18:54:47] <randy> 'situation'?
[18:54:58] <eburger> situation = use case
[18:55:06] <randy> thx
[18:55:15] <eburger> Cyrus: client might have to do a * FETCH ALL FLAGS
[18:55:45] <eburger> Alexey: not the issue; server has to remember MODSEQUENCE for FLAGS, just allowed to forget for EXPUNGED
[18:56:09] <eburger> Is there consensus in room?
[18:56:33] <eburger> Pete likes NO, because it has semantic meaning
[18:57:06] <eburger> Phil - but server does what client expects, anyway
[18:57:38] <eburger> Cyrus: could go with Option 1, but with untagged response saying MODSEQUENCE is out of date, or response code, that would work
[18:59:15] <eburger> Issue 3: REPORTEXPUNGES FETCH, should it be VANISHED?
[18:59:42] <eburger> REPORTVANISHED, FETCHVANISHED, or VANISHED?
[19:00:26] <eburger> Choice is VANISHED, VANISHED, and VANISHED
[19:00:31] <eburger> IMAP QUOTA
[19:01:02] <eburger> Alexey asks if anyone interested. Everyone says no. Alexey tells us anyway...
[19:01:49] <Lisa> aww, to be fair, only Phillip said no and I think he just needs a cookie.
[19:02:06] <resnick> :)
[19:02:06] <eburger> :-P
[19:02:26] <arnt> arnt would have said no, but tried to ignore the whole thing.
[19:02:40] <resnick> Arnt: You just want to sleep.
[19:02:45] <resnick> ;)
[19:03:22] <eburger> Issue (Chris): two round-trips to get quota
[19:03:28] <arnt> not just that. fewer new draft-melnikov-arntmustimplement is also on my list of desirable things.
[19:03:53] <eburger> Philip: GETQUOTAROOT returns quota, so don't have to ask again (GETQUOTA)
[19:05:30] <eburger> Is there a use case other than "free space available"?
[19:05:46] <eburger> Chris: need it for UM: Voice versus e-mail quotas
[19:06:11] <eburger> You get multiple quota-root responses, so OK
[19:06:29] <eburger> OK with this going forward, individually?
[19:06:58] <eburger> Yes. Alexey needs reviews
[19:07:43] <eburger> Philip: any priority queue for Alexey? :-)
[19:09:31] <eburger> How many clients use RFC 2087? Surprisingly large number
[19:10:08] <eburger> That is all folks!
[19:10:23] <alexeymelnikov> Bye
[19:10:27] --- alexeymelnikov has left
[19:10:36] --- kmurchison has left
[19:10:45] --- cyrus_daboo has left
[19:10:50] <eburger> COOKIE TIME!!!
[19:10:54] --- randy has left: Logged out
[19:10:54] --- Barry Leiba has left
[19:10:54] --- Barry Leiba has joined
[19:10:57] --- Barry Leiba has left: Logging off
[19:11:01] --- aaronstone has left
[19:11:02] --- eburger has left
[19:11:15] <arnt> I just got two cookines and a cup of hot cholcolate from my wife ;) good night
[19:11:17] --- arnt has left
[19:11:26] --- Lisa has left: Logged out
[19:12:07] --- resnick has left
[19:17:55] --- cnewman@jabber.org has left: Logged out
[19:35:40] --- healthyao has left
[19:46:09] --- tonyhansen has left
[20:01:09] --- healthyao has joined
[20:16:16] --- pguenther has left
[21:49:23] --- healthyao has left