Current Meeting Report
Slides
Jabber Logs


2.1.7 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 55th IETF Meeting in Altanta, Georgia USA. It may now be out-of-date.

Last Modifield: 11/06/2001

Chair(s):
Pete Resnick <presnick@qualcomm.com>
Applications Area Director(s):
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>
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
Internet-Drafts:
  • - draft-ietf-imapext-sort-10.txt
  • - draft-ietf-imapext-acl-05.txt
  • - draft-ietf-imapext-annotate-04.txt
  • - draft-ietf-imapext-thread-11.txt
  • No Request For Comments

    Current Meeting Report

    Internet Message Access Protocol Extension WG minutes, Thu Nov 21 2002
    reported by Rob Siemborski <rjs3+@andrew.cmu.edu>
    
    Pete Resnick is chairing.
    
    . Chair, introduction and agenda bashing
    
    - This group is being stalled on various issues for too long, we need to 
    decide on what we need to get done and punt on what we can't.
    
    . CONDSTORE - Alexey Melnikov
    draft-melnikov-imap-condstore-08.txt
    
    This draft is pretty much done with only minor open issues.
    
    1. The inclusion of a shared flags response to the SELECT command.  The 
    purpose of the response would be to indicate which flags are shared 
    between users, and would be totally server-defined.
    
    2. What kind of notification sequence should be returned if another 
    session modifies a flag with or without CONDSTORE?
    
    Alexey will make a decision on both of these issues and post a final draft 
    before doing a last call (soon).
    
    . ACL - Alexey Melnikov
    draft-ietf-imapext-acl-06.txt
    
    Minor issues:
    
    1. Missing a section on compatibility with RFC2086.
    
    Alexey has text and will include it in a new version of the draft.
    
    2. Alexey added syntax to apply ACL commands to multiple mailboxes in a 
    single command, with individual failure notifications.
    
    Larry Greenfield felt that this was unnecessary because it could be done 
    with pipelining of commands almost as easily and with no real loss in 
    functionality.  We also do not have a model for partial failures 
    anywhere else in IMAP, and is not sure if we really want to introduce one.
    
    The chair asked Alexey to make a final decision and we'll see if people 
    scream on the list when the new draft is published.
    
    Chris Newman expressed concerns that allowing different ACL models, 
    especially given that WebDAV's recent ACL draft was rejected by the IESG for 
    being too complicated.
    
    Mark Crispin requested that we not put a minimum requirement on the 
    extension that implementors with legacy mail stores cannot meet, and that 
    this might be one of those requirements.
    
    Ned Freed commented that WebDAV's rejection was not specifically for the ACL 
    models, but an overriding level of complexity.  He does not feel that IMAP 
    ACL even comes close.
    
    Larry Greenfield commented that it is OK to have an extension that is not 
    implementable on all servers, and that it is also absolutely necessary for 
    all clients to understand how a server will react to ACL commands from a 
    security standpoint.  Currently we are using an IANA registry for this, but 
    will the clients be able to keep up?
    
    Rough consensus to proceed down the current path, which is not as 
    complicated as webdav, and seek guidence from the security area.
    
    3. The issue of tied rights.  Currently the client must do a 
    LISTRIGHTS before setting an ACL.  The proposal is to just have the 
    client try to set the ACL and return a NO with a LISTRIGHTS response code if 
    rights do happen to be tied and not all of them were specified.
    
    No objections to this change.
    
    - Cyrus commented that it might be nice to have a table in the draft of 
    which rights were required for which commands, even if such a table was 
    large.
    
    . LISTEXT - Barry Leiba
    (Expired Draft)
    
    Issues:
    
    1. Not including all LISTEXT capabilities in the CAPABILITIES 
    response.
    It was generally agreed that this isn't what we want to do.
    
    2. Addition of extensible attribute value pairs at the end of the 
    response.  This was generally agreed to be a good idea.
    
    3. Interaction with ANNOTATEMORE and ACL.  This would create some sort of 
    document dependency (one direction or another).
    
    Mark Crispin prefers that all responses happen through the single LIST 
    interface.  No one saw a problem with this for ACL, and generally agreed 
    that it was a good idea.
    
    Cyrus Daboo commented that we would need GETANNOTATION for /server 
    annotations atleast anyway.  General agreement that we should allow both 
    methods of fetching /mailbox annotations.  The chair suggested that we will 
    decide to deprecate one or the other once LISTEXT is available.
    
    Larry Greenfield noted that if we are going down this path we want to be 
    absolutely certain that LISTEXT is extensible enough that we can get any 
    future per-mailbox information through a LISTEXT extension.
    
    We will decide if ACL and ANNOTATEMORE depend on LISTEXT or the other way 
    around once we can see where LISTEXT is.  General preference appeared to be 
    that ANNOTATEMORE and ACL depend on LISTEXT.
    
    Barry Leiba will have a new draft out next week.
    
    . ANNOTATE[MORE] - Cyrus Daboo
    draft-ietf-imapext-annotate-05.txt
    draft-daboo-imap-annotatemore-01.txt
    
    ANNOTATE Issues:
    
    1. Dealing with system flags ('\' prefix), keywords ('$' prefix), and 
    'vendor flags' (no prefix)
    
    Suggested solution was creating an IANA registry for keywords, and using the 
    ACAP vendor registry for vendor names, and using a hierarchy like:
    
    /message/flag/XXX
    /message/flag/vendor/YYY.ZZZ
    
    Where XXX is a system flag or keyword without the prefix, YYY was a 
    registered vendor name, and ZZZ was the name of the vendor flag.
    
    Mark Crispin noted that the vendor namespace doesn't make sense if a user 
    has their own flags.
    
    Cyrus Daboo suggested creating a new prefix symbol to pull off the vendor 
    namespace, and perhaps adding a new annotation category for user flags.
    
    Randall Gellens suggested the use of a single annotation that was a list of 
    all user flags.
    
    This discussion was punted to the list.
    
    2. Removing dependency on SORT, which will have i18n issues.  SORT would add 
    the ability to sort annotations back in.
    
    3. Switch to using /message/envelope in ANNOTATE instead of 
    /message/smtp-envelope.  Specify that it contains RFC 2821 MAIL FROM And 
    RCPT TO stream data.  This requires attention in the Security 
    Considerations section as well.  We should probably break this out into a 
    separate document.
    
    4. Add sieve-action annotation to ANNOTATE.  This should also probably be a 
    separate document.
    
    The chair suggested removing as many of the annotations as possible and 
    placing them in an IANA registry.  Alexey will come up with a list of 
    which should be removed from the current draft.
    
    Chris Newman wanted to add a caveat that sort on annotations was a 
    capability if both SORT and ANNOTATE was advertised.  Also, it would be 
    nice if SORT on annotations was left in the ANNOTATE document, even if this 
    meant that ANNOTATE was sitting in the IESG queue blocked on SORT.  
    (general agreement)
    
    ANNOTATEMORE Issues:
    
    1. Interaction with LISTEXT.
    
    2. Right now we require an RFC to add an annotation to the IANA 
    registry, we want to change this to just require expert review.
    
    Ned Freed stated that this sounded fine.
    
    3. Barry Leiba expressed concerns about private vs. shared and 
    read-write vs read-only annotations in the /server hierarchy.
    
    Cyrus Daboo commented that it was difficult because we lack ACLs for 
    /server.
    
    Barry suggested that we just make a decision so that the behavior was 
    known.
    
    4. Barry suggested that the ANNOTATION response should have defined 
    semantics as to when it is sent.  The suggestion is to always send 
    /server annotations, but only send /mailbox annotations for the 
    currently selected mailbox.  No objections.
    
    . SORT/THREAD - Mark Crispin
    draft-ietf-imapext-sort-10.txt
    draft-ietf-imapext-thread-12.txt
    
    Issues:
    
    1. These drafts are being held up by the specification of a mandatory to 
    implement i18n solution.  Specifically, collation is problematic.
    
    2. We might look into combining these two documents into a single 
    document, as they share a large amount of text.  This was left up to 
    whatever is easier for Mark.
    
    3. Some have suggested other threading algorithms.  Mark felt that this was a 
    good idea as the threading document is already very complicated and 
    implementations are having trouble complying.  Future algorithms can be 
    provided in separate documents if this is desired.
    
    . New i18n Document - Chris Newman
    
    Randall Gellens and Chris Newman volunteered to create a single 
    document that would be an i18n spec for IMAP that could move 
    everything forward.
    
    Mark Crispin expressed nervousness about making it harder or more 
    confusing for implementations to comply, and that we would see binary 
    compare last much longer than it should.
    
    Larry Greenfield suggested that the place for choosing the collation 
    mechanism is the ACAP comparator registry.  There isn't a good way to 
    allow SORT/THREAD to go forward without a mandatory to implement 
    comparator.
    
    Chris suggested that we keep binary compare as the default, but name a 
    mandatory to implement comparator that is based on stringprep.  For 
    example, binary compare on the output of stringprep.
    
    The chair summarized the situation with the following steps:
      1. Convert to Unicode
      2. Run Stringprep
      3. Run your comparator (this may involve a conversion to UTF-8 if you are 
    doing a binary compare).
    
    . Search Extensions - Barry Leiba
    (No Draft Available)
    
    This is an extension from a while ago that recently some interest has been 
    expressed in again, especially given some discussion at the lemonade BOF.  We 
    would like to be able to ask "for these folders do these searches and give me 
    back just the number of hits." This is related to 
    STATUS-COUNTERS, which would be a fast wrapper around the search 
    extensions.
    
    Mark suggested adding the SCAN extension to the Search Extensions draft.
    
    . General Discussion
    
    Chris Newman reminded everyone of the need review documents for nits 
    before submitting to the IESG.  There is a document at:
        http://www.ietf.org/ID-nits.html
    
    The chair reminded the group that there is IMAP work going on in 
    lemonade that we should watch for.
    
    Lyndon Nerenberg had commented on Jabber during the pre-meeting that he had 
    been having difficulty moving the CHANNEL extension forward, and wanted to 
    discuss it within imapext.
    
    The chair commented that in actuality this draft had been picked up by 
    lemonade, and that was probably a good place for it to thrive.
    

    Slides

    None received.