2.1.5 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-06-15

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 functions:

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

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

Goals and Milestones:
May 00  Submit an Internet-Draft enumerating known problems to avoid in the base specification
Aug 00  Submit revised Sorting/Threading/Viewing spec(s) to IESG
Nov 00  Submit annotation spec to IESG
Mar 01  Submit revised ACL spec to IESG
  • - draft-ietf-imapext-sort-17.txt
  • - draft-ietf-imapext-acl-10.txt
  • - draft-ietf-imapext-annotate-10.txt
  • - draft-ietf-imapext-list-extensions-07.txt
  • - draft-ietf-imapext-condstore-05.txt
  • - draft-ietf-imapext-i18n-03.txt
  • No Request For Comments

    Current Meeting Report


    TOPIC: Status of i18n and sort drafts

    Summary: These are blocked on the comparator draft, which needs IANA review and buyin. Chris Newman reports that he has had a meeting with Michelle Cotton (IANA) and progress was made

    TOPIC: List extensions

    Issue: What to do about \Placeholder (Mark Crispin has asked if we can get rid of it). We need comments from mail client writers on how useful different flags and options are - Mark thinks it is overengineered. After discussion, we asked client people to post to the list asking if they would use \Placeholder. Alexey Melnikov will formulate the question and post it to the list and Cyrus Daboo to try to answer.

    Issue: Currently filter/select concepts are combined. Propose: Two parts, one to match mailboxes, other to control info returned.
    e.g. LIST <match-options> mailbox-spec RETURN <return-options>
    Some argument that all options need to be returned. Cyrus argues that this is good for use with ANNOTATEMORE. Lisa proposed that we could change only the name to be clearer, e.g. changing <return-options> to <also-return>. In this proposal, any responses that are implied by what you're asking for will be provided automatically. E.g. if you say "no standard flags" you'll still get subscribed if you're querying on that. A Proposal will be sent to the list.

    TOPIC: Annotate draft

    ACL issues: Cyrus says he tried to keep ACL as informative. Noted that ACL can be referenced because it is already an RFC; ACL2 is not done yet. All the bits needed are in ACL but some of the explanation of what the bits mean appears to be missing, specifically what the old [READ-ONLY] and [READ-WRITE] mean and whether ACL should imply one or the other. Pete Resnick is concerned about how mailbox access rights tie into annotations. ACL2 apparently resolves this but is not ready to reference. Shared annotations only interact with read-only/read-write -- private annotations are where the problem is.
    Pete argues for clearly separating these things. One option is to base it on ACL2 and add another bit controlling the ability to write private annotations.

    Proposal for ACL issue: could solve this with a new bit added to _old_ ACL. Chris Newman, channeling Mark Crispin, says adding stuff to ACL is bad because there are implementation that do not/cannot support old ACL.

    Need to warn that clients should not copy ACL bits they do not recognize -- they may inadvertently set or clear the bit. If they delete the flag they will remove rights. We need to add this text to security considerations of annotate. This also needs to be added to ACL2.

    Issue: Shared v private annotations. We need text in draft of the meaning or private annotations; make it clear that this is per-user (not access restricted). Cyrus suggests changing name from .prv to .user. This issue is left to document editor.

    Issue: Security considerations may be weak. Lisa asks for addiitional review of this section.

    Issue: Can set \deleted flag with D right, can set it with annotations with different rights. Put another way: What is "allowed to set annotation is on" but "allowed to set \deleted flag" is off?

    Issue: What happens if you set the shared and private versions of the annotation flags to different values? Answer: This is server-dependent. Then how does the client learn where
    to go to set them?

    Proposal 1: Don't use the suffix on flags in annotate, at least for special-cases \seen and \deleted. These two would not use suffix (or either suffix would be identical). Focusing on \seen for the moment:
    for \seen, FETCH implicitly updates something (per-user or shared, depending on server)

    Proposal 2: Don't map flags to annotate. Problem with this is that old clients will use flags. new ones use annotations, don't interop...

    Resolution: Need a history review of why the tie was done in the first place.) Punting to the list.


    This draft waits for LISTEXT - depends on LISTEXT syntax.

    Proposal: Publish separately an update to existing IMAP ACL doc, containing the complete list of rights linked to the appropriate operations. This would also clarify when to return read-only/read-write.

    Proposal (for update to existing ACL doc): RIGHTS=rightlist capability. Some skepticism that "this will just be a little tweak to ACL" is what led to the present ACL2 delay.

    TOPIC Charter bashing.

    See revised charter (already posted).


    None received.