2.7.1 Interim Meeting - Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-02-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-12.txt
  • draft-ietf-imapext-list-extensions-11.txt
  • draft-ietf-imapext-condstore-05.txt
  • draft-ietf-imapext-i18n-04.txt
  • draft-ietf-imapext-2086upd-03.txt

    No Request For Comments

    Interim Meeting Report

    Interim Meeting

    Status of i18n: need to submit to IESG
    - no real hurry because blocked behind comparator draft, but why not get off our plate?
    - Deliverable: Lisa to remind Arnt to get it off his plate
    - Still need WG last call so prompt Arnt

    - Need draft with changes from last call
    - Confirm that changes are minor enough
    - Since this draft clarifies what the 'd' and 'c' right do, are we going to have any problems with existing clients? They might as well try and see if it's going to work.
    - Better for servers to make the client think an action might be possible, and the client try it and might fail, then for the server to make the client think the action can never succeed and never try it.
    - This *will* require changes to 2086upd, which we will see on the list and confirm that there is consensus.
    - General principle to pick the variant that's been implemented (e.g. in CMU Cyrus) since none of the options are spectacularly better or worse
    - Same issue with 'd' right and list rights -- because rights can be tied and you need to show this. E.g if a server ties 't' to 's' and 'w', and ties 'e' to 'x'. How do you report that?
    - We've looked to see if there are actual implementations that will have serious problems with this, and had no response. So we believe this to be a theoretical problem, and we can mention that in the draft, but won't hold up the draft as long as we see this as only theoretical, not real.
    - references to Annotate gone?
    - yes
    - Deliverable: Alexey to post all 2086upd changes to list by January 28 barring further hardware problems.
    - Deliverable: Alexey also to publish new draft to send to IESG.

    - http://www.ietf.org/internet-drafts/draft-ietf-imapext-annotate-11.txt
    - Randy, Cyrus authors
    - authors need to follow up with draft to last-call -- due date?
    - Text to describe behavior of unsolicited responses -- that you only get the annotation names and not the values back (unless the client goes to actually get the values)
    - Deliverable: New draft promised for January 31, which we intend to do WG last-call - request for a 3-week last call rather than 2 weeks if there's overlap with Lemonade WG last calls

    - Individual draft
    - plan to do an informal WG last call at the same time as Annotate gets a WG last call

    - ready for next steps?
    - Alexey about to send an updated version

    - Alexey proposed making changes which brings it *out* of the RFC queue
    - remove dependencies on Annotate
    - currently, condstore doesn't update the mod-seek on expunges, but there's a thought that it should have all along -- that expunge should cause mod-seek to increment.
    - We agreed that the dependencies on Annotate are not a good reason to pull out of process, but the other problem might be.
    - How can you work around this if it's a "bug" in the spec? The client can do search...
    - Ted thinks that this issue ought to be considered "substantive". It's not just a typo or think-o, so not only would pulling it out of the RFC queue send it back to the IESG, it would also send it back through IETF last call.
    - What about submitting a draft now to extend CondStore to fix this?
    - Alexey needs to propose what changes to make to this mechanism, as a concrete written proposal to the list. Then we will poll the WG to see if we think this ought to pull CondStore back from RFC or cause us to update it.

    - http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-10.txt
    - Barry, Alexey
    - Philip owes a write-up that describes how to replace /MatchParent /PlaceHolder by Jan 28
    - If you do an LSUB where the last char is %, this affects mailboxes with children... mailboxes that don't match the filter, but which have children which do, show up as /PlaceHolder in the current draft. That allows the client to build a sane hierarchy.
    - Can pipelining two LIST requests be a problem ? The answer might be that the client SHOULD NOT pipeline two LIST requests if it can't combine the responses.

    Renaming LISTEXT stuff

    - We add a RECURSIVEMATCH flag to the LISTEXT command to specify whether or not the client wishes the server to look inside every mailbox recursively to see if any of the children match the criteria, as well as seeing whether every mailbox on this level match the criteria. This means that RECURSIVEMATCH can only be used in the request when there is a filter on the LISTEXT request -- it has no sense if there's no matching algorithm going on. Also note that RECURSIVEMATCH is not valid in the request if there is an '*' in the LISTEXT pattern. When the client isn't supposed to use RECURSIVEMATCH the server must return "bad request". [For those familiar enough with existing proposal notice that RECURSIVEMATCH is a rename of MATCHPARENT with a few restrictions]

    - Along with adding RECURSIVEMATCH, we add HASMATCHINGCHILDREN as a flag that appears in the parens, when the server looked inside the mailbox and found that some internal mailbox matched the LISTEXT criteria. So HASMATCHINGCHILDREN only appears if the client asks for it with RECURSIVEMATCH, and it has a different and clear meaning from HASCHILDREN (nothing is overloaded).

    NOTE THAT Lisa is not sure that she has correctly described this proposal and we need to follow up on the list with more text and examples.


    None received.