[03:24:09] --- fanf has joined
[03:27:42] --- Hollenbeck has joined
[03:30:24] --- lisa has joined
[03:30:29] <lisa> Bonjour
[03:31:25] --- cnewman has joined
[03:34:47] --- KMK has joined
[03:35:33] --- oern has joined
[03:35:38] --- randhy has joined
[03:35:52] --- tonyhansen has joined
[03:36:02] --- Barry Leiba has joined
[03:36:47] <lisa> Anybody not in the physical meeting room today?
[03:36:57] <lisa> anybody listening to voice multicast?
[03:37:27] <cnewman> Anything to add to the agenda?
[03:37:59] <cnewman> Lisa: puts up really ugly messy dependency graph of IMAP extension specifications.
[03:38:19] --- shmaes has joined
[03:38:59] --- resnick has joined
[03:39:28] <cnewman> Lisa: lots of drafts gated on other drafts
[03:39:49] <lisa> http://rtg.ietf.org/~fenner/ietf/deps/viz/
[03:40:16] <cnewman> Note: a dependency from SORT to IMAP i18n is missing
[03:40:22] --- alexeymelnikov has joined
[03:40:23] --- pguenther has joined
[03:40:44] <cnewman> Topic: LISTEXT
[03:41:01] <cnewman> quick review of LIST-EXTENDED extensibility
[03:41:10] --- jlcjohn has joined
[03:41:13] <cnewman> Barry has the floor
[03:42:46] <cnewman> Barry: Alexey suggested paged list results as a future option. Wants syntax extensible enough so that can be put in the future.
[03:42:53] --- paulmdx has joined
[03:43:17] <cnewman> Q: Is anyone else in favor of this extra extensibility?
[03:43:25] <resnick> Presentation at imapext-ietf63.ppt
[03:43:27] <cnewman> Dave supports this.
[03:43:54] <cnewman> Arnt: against any kind of complexity unless there are two good reasons for it.
[03:44:22] <cnewman> Phil: Minneapolis archives were very useful. Please use microphone.
[03:46:03] <cnewman> Alexey: Worried about dependencies on LISTEXT. There's another document which adds syntax extensibility to all IMAP commands.
[03:46:33] <cnewman> Tony: worried about how many times we've painted ourselves into a corner because we didn't have extensibility built into the grammer.
[03:47:21] --- oern has left
[03:47:32] <cnewman> Alexey: Thinks we're in a bad situation because we didn't pass extensible grammer draft when it was proposed.
[03:48:19] <cnewman> Arnt: Generic complexity done without the guidance of examples turns out to be a solution looking for a problem.
[03:50:01] <cnewman> Me: I think we've messed up FIND *, LIST *, etc too many times in the past so we should err on the side of extensibility.
[03:50:23] <cnewman> Barry: sounds like we're getting rough consensus
[03:50:35] <cnewman> Next issue: REMOTE option
[03:50:53] <cnewman> Alexey: What does it mean to use REMOTE with RECURSIVEMATCH?
[03:51:22] --- randhy has left
[03:51:31] <cnewman> Offline discussion: If server doesn't support REMOTE, then REMOTE is ignored.
[03:51:37] --- randy has joined
[03:52:31] <cnewman> Dave: REMOTE means local and remote. So REMOTE + RECURSIVEMATCH would in theory provide child information for remote.
[03:52:48] <cnewman> Phil: In theory REMOTE + RECURSIVEMATCH is similar to CHILDREN option.
[03:53:35] <cnewman> Alexey: This is not very useful because its just another way of doing the same thing, so we'd need to document that.
[03:53:53] <cnewman> Alexey: alternative would be to change meaning of REMOTE, but probably not good idea at this point.
[03:54:10] <cnewman> Barry: agrees its bad idea to change at this point. Just need to clarify
[03:54:43] <cnewman> Dave: Is CHILDREN optional?
[03:54:54] <cnewman> Phil: No. CHILDREN is mandatory.
[03:55:06] <cnewman> Phil: That text was fixed or supposed to be fixed.
[03:55:11] <cnewman> Barry: agrees.
[03:55:48] <cnewman> *Dave is on the hook to provide text that explains REMOTE + RECURSIVEMATCH
[03:56:48] <cnewman> Barry: one case in text where it said yes instead of no in child info stuff. Wants confirmation that behavior of child info is what client people want.
[03:57:19] <cnewman> Phil: Theory of recursive match is if pattern ends in "%", we return NOSELECT mailbox so we can do a walk of the tree layer by layer.
[03:57:56] <lisa> He wrote "LIST X* (SUB)"
[03:57:59] <cnewman> Phil: with RECURSIVEMATCH, you are hunting for children which match the selection criteria
[03:58:13] <cnewman> Barry: on white board wrote "LIST X* (SUB)"
[03:58:16] --- alexeymelnikov has left
[03:58:44] <cnewman> Barry: change to "LIST X% (SUB REC)" means tell every subscribe mailbox, but only go down one level.
[03:59:11] <cnewman> Phil: return all mailboxes that start with X and is subscribed or has a child that's subscribed.
[04:00:28] <cnewman> Discussion between Phil and Barry about pattern matching.
[04:01:05] <cnewman> Barry will write some text to clarify matching.
[04:01:10] <cnewman> LISTEXT done
[04:01:52] <cnewman> Dave's LISTEXT text will be due Aug 12.
[04:02:06] <cnewman> Barry's update will be due Aug 19.
[04:02:16] <cnewman> One more WG last call after that, then we're done.
[04:02:20] <cnewman> Next topic
[04:02:43] <cnewman> new topic ANNOTATE
[04:02:50] <cnewman> Do we need another last call?
[04:02:59] <cnewman> Rough consensus: no.
[04:03:41] <cnewman> Lisa will work on sheparding WG chair text.
[04:03:47] <cnewman> Next topic: IMAP BNF
[04:03:47] --- alexeymelnikov has joined
[04:04:24] <cnewman> Purpose: use of common syntax for all extension elements (document refactoring)
[04:05:00] <cnewman> Which extended commands should be listed (suggestion to add CREATE and maybe ESEARCH response)
[04:05:33] <cnewman> Alexey: Phil suggested we consider using the same syntax for all extensions.
[04:06:02] <cnewman> Alexey: Has changed document to use consistent extension grammar.
[04:06:33] <cnewman> Alexey: Wants to know if anyone cares if we use consistent extension grammar
[04:07:07] <cnewman> Arnt: Speaks in favor of this change. Thinks we have enough experience with extensions that we can do it.
[04:07:28] <cnewman> Arnt: Thinks now is the time to do this.
[04:07:33] <cnewman> Lisa: Who has read this?
[04:07:47] <cnewman> Phil: Has read it. Likes the change he proposed.
[04:08:23] <cnewman> Lisa: sounds like a great individual submission. But doesn't hear enough that it should be part of the WG.
[04:08:40] <cnewman> Alexey: second point: which command extensions should we include in the document?
[04:10:04] <cnewman> Alexey: any opinions on adding generic extended search to IMAP ABNF draft?
[04:10:14] <cnewman> *silence*
[04:10:25] --- resnick has left: Disconnected
[04:10:57] <cnewman> Alexey: will change MUST to SHOULD for normative restrictions on future documents.
[04:11:19] <cnewman> Alexey: Thinks document will be ready for last call after these three changes.
[04:12:39] <cnewman> Ted: Since catenate has a dependency on this, the lemonade WG needs to be asked to review that draft.
[04:12:48] <cnewman> Ted: note that Alexey's drafts have imap-ext
[04:13:26] --- alexeymelnikov has left
[04:13:59] <cnewman> New topic: i18n and comparator
[04:14:24] <cnewman> Lisa: any objections to having this WG adopt comparator to unblock chartered items?
[04:15:01] <cnewman> Phil: volunteered to review it.
[04:15:07] <cnewman> Dave: has already reviewed it.
[04:15:10] <cnewman> Barry: says sure.
[04:15:19] <cnewman> Tony: did two reviews already
[04:15:35] <cnewman> rough consensus: it's a WG document now.
[04:16:14] <cnewman> Lisa: next version will be an imapext document and will be last called upon publication.
[04:16:37] <cnewman> Arnt is the editor and needs to respond to comments from Dave.
[04:16:56] <cnewman> Document due late August-ish.
[04:19:11] <cnewman> Next topic: ANNOTATE
[04:19:17] <cnewman> Lisa: implementations?
[04:19:30] <cnewman> Several people are looking at annotate implementations
[04:19:40] <cnewman> a few more are looking at ANNOTATEMORE.
[04:19:50] <cnewman> But ANNOTATEMORE is relevant to ANNOTATE.
[04:20:49] <cnewman> Pete: from a client perspective, ANNOTATE is really important, but clients can't start supporting it until servers implement it.
[04:21:08] <cnewman> Lisa: what server implementors plan to do this?
[04:21:21] <cnewman> Arnt raises hand.
[04:26:44] <cnewman> discussion of why servers are relucant to implement ANNOTATE
[04:27:14] <cnewman> Me: private annotations are hard because of backup case, creates relational dependency. Shared only annotations would be much easier.
[04:28:10] <cnewman> Suggestion: make draft allow servers to implement shared only? Do we need a response code or something to indicate shared-only?
[04:30:23] <lisa> CNewman suggests describing a way that servers can implement shared annotations only in a way that doesn't make an impossible situation for clients
[04:30:59] <lisa> Pete said that most serious IMAP server implementors are aware what happens in this room
[04:32:08] <lisa> Greg: If you have two different implementation levels for annotations, it should be clear so that there isn't too much complexity for clients
[04:34:15] <cnewman> GregV: would want two capabilities up front
[04:34:45] <cnewman> Pete: has to make a decision up front what he's going to implement. Doesn't find capability strings useful.
[04:35:52] <cnewman> GregV: wants us to shoot for a common goal so we get parallel implementations like lemonade.
[04:36:08] <cnewman> Pete: lemonade has something general IMAP doesn't.
[04:37:52] <cnewman> Randy: the question about whether we need capabilities comes down to what advice we should give clients. A capability is useful if it avoids clients from trying multiple things. But if we can give advise to clients that doesn't require a new capability, that also works.
[04:38:34] <cnewman> Ted: profiling simplifies things for clients. Discoverability without try & fail is simpler for less capable clients.
[04:39:42] <cnewman> Phil: could add another SELECT response code for annotate to handle this. That might be sufficient instead of capability.
[04:41:40] <cnewman> Dave: if adding SELECT response codes, perhaps we should wait until we see what server implementors will do?
[04:42:27] <lisa> Ted said that the big risk is that servers might not implement annotate at *all* if it isn't clear what subset they can implement usefully for clients.
[04:43:12] <cnewman> Phil: If clients don't have the information, that makes life hard for clients.
[04:44:03] <cnewman> Randy: a summary of this discussion to the mailing list would probably make sense.
[04:45:43] <lisa> Greg asked if IMAP had a concept of private stuff already
[04:46:08] <lisa> Chris: shared folders is somewhat unspecified and whether a particular flag is shared or private is implementation dependent.
[04:47:03] <lisa> Chris: Annotate is a laudable attempt to rationalize this craziness
[04:47:18] <lisa> Phillip: but it does make it hard for servers to implement both the new and the old interface in a way that is sensible to clients
[04:50:04] <randy> Greg V asks if servers fall into two camps regarding shared/private flags etc.
[04:50:36] <randy> Chris says there are more like three camps: those where the back-end varries and hence capabilities vary, those
[04:50:49] <cnewman> Lisa: we want to get document out there.
[04:51:42] <cnewman> Lisa: Option 1: push document as is. Option 2: consider text to advertise server behaviors for private vs. shared.
[04:51:50] <cnewman> discussion of state of exhaustion
[04:52:19] <cnewman> Pete: not sure we have enough information to make a decision.
[04:52:44] <cnewman> Arnt: Suggest we go on with draft as is, but add an example with a read-only response to a private annotation
[04:53:06] <cnewman> Ted: Just add the response code.
[04:53:31] <cnewman> Ted: either put it in this one or write a spec describing it.
[04:53:52] <cnewman> Rough consensus to add a response code
[04:54:55] <cnewman> Phil will write proposal.
[04:55:11] <cnewman> Done by next week.
[04:56:03] <cnewman> Annotate: august is terrible for Randy. September is possible.
[04:56:48] --- Hollenbeck has left
[04:56:51] --- Barry Leiba has left
[04:57:11] --- alexeymelnikov has joined
[04:57:14] --- paulmdx has left
[04:57:27] --- alexeymelnikov has left
[04:57:32] <cnewman> We're done.
[04:57:43] <cnewman> Motion to adjurn?
[04:57:47] <cnewman> All in favor please leave.
[04:57:57] --- cnewman has left
[04:58:54] --- tonyhansen has left
[05:00:06] --- randy has left: Logged out
[05:04:39] --- lisa has left
[05:08:59] --- pguenther has left: Disconnected
[05:15:44] --- fanf has left
[05:16:23] --- shmaes has left: Disconnected
[05:22:53] --- KMK has left: Disconnected
[05:39:17] --- jlcjohn has left
[06:42:27] --- shmaes has joined
[06:54:34] --- shmaes has left
[13:18:09] --- kmurchison has joined
[13:18:24] --- kmurchison has left
[13:19:11] --- kmurchison has joined
[13:24:19] --- kmurchison has left