2.1.6 Internet Message Access Protocol Extension (imapext)
NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
Last Modified: 2005-10-24
Pete Resnick <email@example.com>
Lisa Dusseault <firstname.lastname@example.org>
Applications Area Director(s):
Ted Hardie <email@example.com>
Scott Hollenbeck <firstname.lastname@example.org>
Applications Area Advisor:
Scott Hollenbeck <email@example.com>
General Discussion: firstname.lastname@example.org
To Subscribe: email@example.com
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 |
|Done|| ||Submit I-D to *update* existing ACL RFC, explaining rights &
listing rights in CAPABILITY response |
|Aug 2005|| ||WG last call for comparator draft |
|Sep 2005|| ||WG last call for i18n draft |
|Sep 2005|| ||WG Last call for annotate draft |
|Sep 2005|| ||Submit to IESG: comparator |
|Oct 2005|| ||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 |
|Oct 2005|| ||Submit to IESG: i18n |
|Oct 2005|| ||Submit to IESG: annotate |
|Nov 2005|| ||New draft of ACL2 proposal which would *obsolete* existing ACL
|Nov 2005|| ||Submit to IESG: List Extensions |
|Feb 2006|| ||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 |
No Request For Comments
Current Meeting Report
This is a high level summary of IMAPEXT discussion Nov 8 2005, mostly focusing
on consensus gathering (subject of course to ratification on this list).
More detailed notes of the meeting can effectively be found in the Jabber
room where we tried to convey what was being said in the room.
In WG last call. Chris Newman, Philip Guenther and Dave Cridland will
review (full or changes)
Our "refactoring" of condstore document is believed to be without effect
on requirements or protocol on the wire, merely a removal of a dependency.
Since CONDSTORE is in RFC queue this still obviously merits careful review
but it is our belief that this does not require pulling from queue. Chairs
will post document changes to list and to ADs for verification before
actually changing condstore.
We noted that if the mirroring of flags<--> annotations is removed
*entirely* from ANNOTATE, then this would have a significant effect on
CONDSTORE. We will attempt to continue to reserve the flags namespace in
annotations to limit the damage to CONDSTORE.
Simplification decided in Paris: make it optional to support private
attributes. This isn't yet in draft but in Cyrus' local copy.
Remove content-type and display-name attributes from the wire protocol.
This means that clients will have to know the content-type and decide on an
appropriate display-name based on reading specs or other out-of-band
mechanisms. This decision does weaken the ability of IMAP clients to browse
unfamiliar attributes and we recognize that. Cyrus will propose text.
SEARCH should only operate on an annotation's value. This is more
obvious anyway with the removal of content-type and display-name. We'll
need some discussion about exact language for the draft so that we
understand exactly how this works. Same thing goes for use of %/* in
attribute names and applies to FETCH too. Cyrus is tasked with coming
up with text.
See decision on not mirroring flags to annotations but continue to
reserve namespace to minimize impact on CONDSTORE. Cyrus will propose text.
The per-body-part annotations could be removed to further simplify
ANNOTATE. Further discussion is needed in Lemonade to determine their
need for this feature. Chairs will follow up with Lemonade.
This is going through last call and people should review.
Philip brought a seemingly minor octet/character issue which turned
out to be a white rabbit hole. Does collator operate on character or on
octet? After 20 minutes discussion we concluded to operate on octet but
explain how this ought to be functionally equivalent for character data.
Agenda and annotation draft topics