2.1.5 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-05


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
Oct 04  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-acl-10.txt
  • draft-ietf-imapext-annotate-11.txt
  • draft-ietf-imapext-list-extensions-10.txt
  • draft-ietf-imapext-condstore-05.txt
  • draft-ietf-imapext-i18n-04.txt
  • draft-ietf-imapext-2086upd-00.txt

    No Request For Comments

    Current Meeting Report

    IETF-61 meeting


    Discussion of /Placeholder: Philip promised to send a mail about a simplification of /Placeholder. Cyrus and Barry agree that LISTEXT is too complicated and we need to back off that.

    Question about which client people initially asked for features in LISTEXT (prompted by observation that LISTEXT has now become rather complex)? Cyrus, David Cridland, Mark Crispin.. who else?

    Suggestion that the /matchparent stuff may be simplifiable -- get rid of it. Any wildcard query (%) could be seen as a request for matchparent -- otherwise the server must not return it.

    Multiple-mailbox-match in LISTEXT: looks like there's consensus to add it. We will take this to the list to see if there's any objectors on the list.

    We will defer to the mailing list for what to do with /NOSELECT, /NONEXISTENT, /DELETED...

    Cyrus and Philip are on the hook to suggest a simplified model to Alexey and Barry for matchparent... the next version of this may get last-called.


    Discussion on 2086 upd: Looks good, needs to be kept simple and finished soon. Scott and Chris promise to review 2086upd


    Discussion on Annotate: lots of discussion over what rights to use for private and public annotations.

    Proposal: that the ability to read private annotations is controlled by the 'r' ACL bit, and the ability to write private annotations is controlled by the new 'm' ACL bit. This means that 'r' controls readability for both private and shared annotations. There were no sticking objections to this proposal (however Barry and Chris would prefer another proposal.)

    2nd issue with ANNOTATE: Interactions with the CATENATE draft.
    Resolution: Cyrus will add text to deal with this and there will be a new dependency of Annotate on Catenate

    3rd issue: APPEND: a slight interaction here with annotate, which Cyrus will add to the draft.

    We plan to last call the next version of Annotate on the day it comes out.


    Plug for AnnotateMore -- Chris and Philip promised to review, Cyrus will ask LEMONADE list for review.


    None received.