Current Meeting Report
Slides


2.1.4 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It may now be out-of-date. Last Modified: 06-Nov-01
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:
No Request For Comments

Current Meeting Report

IMAP Extensions WG 2001-12-13 Salt Lake City IETF
9:00 - 11:30
Minutes as taken by Chris Newman.

ANNOTATE

three outstanding issues

1. Mirroring IMAP flags in annotations

If we do it we need to distinguish shared/private flags. Some discussion of the issue. If ANNOTATE gets widely deployed, the shared/private model is more useful. But clients will have to implement support for old flags model in addition to ANNOTATE flags model. People are willing to implement ANNOTATE flags and opposition is mostly in the "not worth it" camp. Rough concensus based on hum at meeting to go ahead and add flags.

Shared vs. private flags. Could advertise SHAREFLAGS and PRIVATEFLAGS, but is it worth it? What happens if client stores shared deleted when server implements client deleted? Needs to be documented clearly.

2. When should server issue unsolicited ANNOTATE responses?

Implicit after use of annotations, or explicit tag on SELECT/EXAMINE.

No strong feelings in either direction. So let the author make the choice.

3. How to tie ACL rights to ANNOTATIONS?

If you have READ-ONLY access to a mailbox you can only change private annotations. READ-WRITE means you can change both private and shared.

Discussion: are we requiring servers to implement both private and shared annotations? Yes.

ACL: write access lets you set shared, read access lets you set private.

Also need to explicitly say that annotations must persist across sessions, exception for flags mapped to annotations which are listed in FLAGS but not in PERMANANTFLAGS.

We will do a WG last call on the next revision due Jan 15.

------
CONDITIONAL STORE

Major change: replaced MODTIME with MODSEQ.

Open Issues:
Need to synchronize with annotate document. Do we need SORT for MODSEQ? People like to sort directories by date, so it would be useful.

If you do conditional store for a message set it's currently atomic, all stores succeed or fail. No rough consensus either way for conditional store on message set. Weak consensus to leave it atomic and get implementation experience.

Randy has volunteered to help with language in the draft. We will do a WG last call on the next revision due Jan 15.
-----
ACLs

Proposal: "d" is a macro for two new rights: one for set deleted flag, one for delete folder.

Proposal: "anyone" and "$" prefix are non-users. "-" is negative rights. All other identifiers are presumed to be users. Could use "$$" prefix for user name beginning "$".

We must have a new capability. It is desirable for the new ACL to have a superset of the syntax of the old ACL. This way server implemented to new ACL should work with both old and new ACL clients. Rough consensus.

Proposal: An additional capability to advertise semantics of ACLs if different from the union model. Need to take this to the list.

We will solicit input on proposal. Target is Feb 1st for ACL extension draft.
-----
LISTEXT

Issues with LISTEXT: doesn't do enough.

Needs more discussion on the list.

There is a proposal to add attribute-value pairs.
-----
Pete Action item: ask Mark to add i18n to SORT/THREAD

SORT on arbitrary headers is desirable. Cyrus will post to list to add arbitrary headers.
-----
Pete Action item: ask Mark to last call the imapv draft.
-----
SNAP

Request to get review of SNAP (notifications) draft by IMAP community.

Slides

None received.