Last Modified: 2005-06-02
| Done | Submit revised Sorting/Threading/Viewing spec(s) to IESG | |
| Done | Submit draft on conditional storage to help multiple clients use a single mailbox to IESG | |
| Aug 04 | WG last call for i18n draft | |
| Aug 04 | WG Last call for annotate draft | |
| Aug 04 | WG last call for LIST extensions draft, defining syntax allowing much better extensibility in the frequently-extended LIST command, and supporting other drafts in this WG | |
| Sep 04 | Submit to IESG, Internationalization draft | |
| Sep 04 | Submit to IESG, revised annotate draft | |
| Oct 04 | Submit to IESG, revised List Extensions draft | |
| Done | Submit I-D to *update* existing ACL RFC, explaining rights & listing rights in CAPABILITY response | |
| Oct 04 | New draft of ACL2 proposal which would *obsolete* existing ACL RFC | |
| Feb 05 | ACL2 to WG Last Call -- note that if this milestone is not met we agreed to close the WG and defer ACL2 to another WG |
|
Discussion of which extensions depend on which; a fairly dense graph. Lisa wants to show that practically everything ultimately depends on newmap-i18n-comparator. (Barry did not gloat over listext's independence.)
Listext: On-screen: - quick review - interaction of remote with recursivematch - are there any other issues that need to be addressed? There's a suggestion to extend the grammar such that we can later include "max 100" blah, but the change makes the grammar much more complex. Dave as client developer was in favour, Arnt was against until there are two good reasons. Alexey mentioned IMAPABNF, I didn't really get the point. Food for thought, he said. Tony Hansen cautioned against painting ourselves into a corner. Barry doesn't feel that he has guidance yet, just incidental opinions. Arnt emphasizes that give two good reasons, etc. Chris proposes erring on the side of complexity, since we've had to many too-limited list extensions in the past. Interaction of REMOTE and RECURSIVEMATCH. Alexey: Would it be reasonable to return all mailboxes that might have remote children? Tricky discussion ensues - is it a no-op or not? Scribe is not alone being puzzled. Document needs clarification. Dave will provide some text. Currently, the CHILDINFO works like this: If the parent matches the pattern and the child the other requirement, the parent with CHILDINFO is returned. Is that what clients need? Phillip explains RECURSIVEMATCH: Clients want to find something, and doesn't want to use LIST *. Barry shows parent-child relationships on a way he eventually explains. Revision will ensue, and will be reviewed by people who don't get it. New revision Aug 19, then probably WGLC. ANNOTATE: Brief agreement that we don't need another WGLC. We'll push it on. IMAP ABNF: - purpose: use of common syntax for all extension elements (refactoring) - which extended commands should be listed (suggestion to add CREATE and maybe ESEARCH response) - discussion about wording requirements on future documents Alexey has noted similar but different ABNF in several extensions, and wants that to be the same. Much silence in room. Arnt spoke in favour, saying we now have the experience to write such a document. Lisa suggests it's suitable individual submission and can be discussed on the list. Alexey suggests adding ESEARCH to IMAP ABNF. Noone seems to understand the implications. Hairsplitting over draft names. It's good to name things clearly enough that grep can find it. It's also good to mention thing on lemonade, since a small group of people are paying attention there. COMPARATOR and stuff: comparator is lost, can WG adopt? (Script edits that now.) Adoption carries. Phillip, Barry will review. Tony too. No rename is required. Arnt will submit with the right bullet, including Dave's comments. Tony likes comparator, thinks it's close. Lisa asks about who implements Annotate. Arnt, Dave, who else? Annotatemore and annotate: Depend on each other? Dave says amore has been deployed, annotate not. Someone (Randy) says annotate is attractive once it's there. Eudora and OSAF want it, but not until there's a server. Arnt is alone as server. Lisa asks what's stopping servers from doing it. Chris complains that private annotations requires a relational database. Pete opines that clients really want private annotations. Randy: Most of the time, there's only one annotation, and it can't be reliably identified as either private or shared. Lisa points out that WebDAV effectively has only shared annotations (properties) and no functionality equivalent to that of private annotations. Question: Can we drop one, should it be a separate capability or a quality of implementation? Lisa asks for the good, not the best. Pete suggests going ahead, and dropping one as we go to draft if it's not implemented. Dave notes that a server can legally weasel out of offering private annotations? Chris comments that private should not be removed. If two servers do it, that may jump-start customer demand. Pete once paid someone to implement some extension, but won't do it now. Chris wants to make sure that a shared-only annotation won't trip up clients. Discussion of whether all real server vendors are aware of this room, and will go along with a potential change. Greg Vaudreil doesn't like the diversity - some servers doing this, some that, and the client having to deal with both. Greg wants to make a decision, not a hedge. Like Lemonade. Pete says they have a gorilla, which we don't. Randy suggests that servers should advise clients on what's supported: what's RO, what's RW? Discovering it too late is bad. (Scribe agrees, as a former GUI developer.) Agreement. Philip suggests a per-mailbox response saying that's permitted. We consider but reject defining it in a later draft. Randy suggest summing this up to the mailng list. (This being annonate group/private.) Greg asks whether any part of IMAP supports the private/public split. Chris says no for the base, NAMESPACE informs, and flags are this way or that and there's no way to make. ANNOTATE tries to clarify flags. Greg asks whether there's a bifurcated market, Chris says no, not really, all support private mailboxes, some also public, more or less, but there's no clear split. Followup discussion says \seen is often private, other flags often public. Courier is off by itself behaving differently from everyone else. Lisa asks: go ahead with the draft now, or add capabilities/responses and then WGLC again? Arnt will suggest going ahead with one extra example on the list. Room hums for adding a response code. Pete suggests asking again on the list to make sure the consensus stays. Meeting ends early. There are remarks that the imapext and sieve WGs seem to work much better and feel more productive than most others. |