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