2.1.5 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. It may now be out-of-date.

Last Modified: 2005-06-02


Pete Resnick <presnick@qualcomm.com>
Lisa Dusseault <lisa@osafoundation.org>

Applications Area Director(s):

Ted Hardie <hardie@qualcomm.com>
Scott Hollenbeck <sah@428cobrajet.net>

Applications Area Advisor:

Scott Hollenbeck <sah@428cobrajet.net>

Mailing Lists:

General Discussion: ietf-imapext@imc.org
To Subscribe: ietf-imapext-request@imc.org
Archive: http://www.imc.org/ietf-imapext/

Description of Working Group:

The IETF IMAP extensions Working Group shall revise and publish
standards-track extensions to IMAP4 for performing the following

1. Sorting, threading, and viewing (to be dealt with by one or more

2. Access Control Lists

3. Message-level annotations

Revising the base IMAP4rev1 specification is out of the scope of this
WG. However, this WG will ensure that whatever extensions it does
propose do not worsen any existing problems in the base specification
of IMAP, nor do they make any such problems harder to address in the

Goals and Milestones:

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


  • draft-ietf-imapext-sort-17.txt
  • draft-ietf-imapext-annotate-13.txt
  • draft-ietf-imapext-list-extensions-13.txt
  • draft-ietf-imapext-condstore-05.txt
  • draft-ietf-imapext-i18n-05.txt
  • draft-ietf-imapext-2086upd-08.txt

    No Request For Comments

    Current Meeting Report

    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.)



    - 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.


    - 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.