2.1.5 Internet Message Access Protocol Extension (imapext)

NOTE: This charter is a snapshot of the 49th IETF Meeting in San Diego, California. It may now be out-of-date. Last Modified: 01-Nov-00


Pete Resnick <presnick@qualcomm.com>

Applications Area Director(s):

Ned Freed <ned.freed@innosoft.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


No Request For Comments

Current Meeting Report

IMAPEXT minutes
Thursday, Dec 14 2000, 1PM
chair: Pete Resnick
notetaker: Tim Showalter


- ACL?
- Binary
- Annotate/etc.


We haven't seen an ACL draft in some time. Steve Hole noted that ACL was divided up into issues, and that killed the conversation. The biggest issue is whether or not one ACL spec will cover everything.

The chair lined up a design team among the usual suspects and planned to move the milestone out.

It was noted that the group syntax still needs to be fixed.

Steve: I really want the group syntax fixed.


Chair: Is someone here to talk about binary?
Lyndon: What went out as the last draft, everyone seems to be happy with it. We've decided to allow binary append as well (~{99} will imply binary, server can reject it if it can't support it)

There will be a way to fetch the binary structure (BINARYSTRUCTURE), analogous to FETCH BODYSTRUCTURE, specifically the binary size of an object after CTEs have been removed.

Floor: the obvious way is to get this as a FETCH item syntax.
Lyndon: We've replaced FETCH BODY[XXX] with FETCH BINARY[XXX].

Floor: I thought we wanted to drop the ~ syntax.
Steve, Lyndon: Some people feel this isn't such a good idea. Consensus was this isn't a big deal, but that we'll discuss it more.

Chair: Is this being rolled in as a work group item?
Steve: VPIM wants this, and VPIM wants stuff through an external channel [via a CHANNEL command]. The channel one is going to be discussed at VPIM tomorrow. We could make the binary thing a VPIM item instead.
Ned: I'd prefer to have it in here.
Barry: (same)
Chair: It's far along, no screaming, so I'm inclined to put it on our charter. [No objections.]

What about CHANNEL? We want to add to the charter both the ability to get binary data both in-band and out-of-band.

The proposal was to try and get both VPIM and IMAP to work with CHANNEL, beginning with an initial draft that will be discussed by both groups. Depending on the issues after that draft appears, it will be handled either by IMAP, VPIM, or both. Consensus of the room was to avoid taking on CHANNEL if it would flood the group. It was noted that CHANNEL presents some unpleasant security issues.

Annotate, etc. (Conditional Store, Modtime)

Chair: Randy, want to talk about the state of Annotate?

Randy: I have design team notes from Annotate from Pittsburgh, and I need to do another draft. I have notes on regexp, too, and need to do another draft.

Alexi: IMAP Conditional Store (aka MODTIME)
We want to have modtimes not just for annotations but for flags as well.

The intent of a conditional store is to tell the server to modify the following flags/annotations if they didn't change since some time.

This proposal
- extends syntax of the STORE command for allowing to specify STORE modifiers
- adds MODIFIED response code that should be used with NO response to store
- adds a new MODTIME message data item for use in the FETCH command
- adds a new MODTIME message data item for use in the SEARCH command

Randy: I want to give background, since a lot of people don't seem to be familiar with this. Annotations had this split off, and there was interest in making MODTIME more general.

There was some discussion on the timestamp offered with MODTIME.
Since the semantics are similar to those used for conditional store in ACAP, it might be a timestamp.

Is the the timestamp is opaque and/or monotonically increasing? If it's increasing, the client only needs to keep one number, which simplifies client implementations.

The modtimes will probably be per-message, since that's considered to be enough granularity.

Alexi: To do list
(1) sync with annotate
(2) potentially add support for SORT

Open issues
- How specify different UNCHANGEDSINCE for different flags in the same store? Do we want such granularity?
- The document asumes that eachflag has a corresponding ANNOTATE attribute. Need to come up with a unified syntax for flags and annotations (attr-name in ABNF).
- What MODTIME has a system flag that was never set?
- Untagged modtime responses used with FETCH/STORE a la ACAP?
- How to deal with partial failure? Is CONDSTORE atomic across message set, or is it good enough to be atomic with any message?

Floor: possible to split this into two parts: one those you do as a part of a single session, and those you do as a part of a disconnected sync. You don't need per-flag stuff in disconnected mode, you just need a way of playing back.

Issues of increasing modtime vs opaque modtime will be posted to the list.

Chris Newman offered the following counterproposal.

Instead of using timestamps, you have explicit markers for a set of mailbox state. Then, you can say it's persistant or not. Then you can do a conditional store against a marker. If it works it updates the marker state, if not it doesn't.

The nice thing about this is it takes the timestamps out of the protocol and it leaves a lot of the issues up to the server. You probably need global state internally, but for per-user state you can probably save a lot of state.

Floor: Marker is for an entire mailbox?
Chris: Marker is updated on a conditional store, but not on a regular store.

Floor: I like the idea of using this for disconnected updates.
Chair: Why don't you post the strawman to the list, and we'll go from there?


Chair: Barry, you want to talk about LIST extension?

LISTX Command Requirements
- Standardize the seperator character
- Consider I18N for mailbox names
- Better filtering
- Allow selection of returned data
- Provide framework for annotations and other extensions

Proposed syntax
- List of mailbox names
Multiple patterns
Each may contain wildcard characters
- List of selection attributes
All applicable attributes must match (implicit AND)
Indifivual attribute may be negated (eg !unseen)
- List of response attributes
- Mailbox names use URLs
Handles standardized hierarchy
Handles I18N
?: Must use relative URLs when possible? SHOULD?

Some Selection Attributes
- depth(n)
controls hierarchy level for traversal
?: should default depth be infinite, or should we force a finite
default? default=1?
- referrals
include referals in list
otherwise, only local mailboxes match
- subscribed
- only matches subscribed mailboxes
lsub still used to get simple subscribed list
- hasunseen, hasdeleted, hasmessages
- others?

Some Response Attributes
- mailbox name is always returned, as a URL
- \noselect is always returned if it applies
- children
returns \haschildren, \hasnochildren, \noinferiours flag
- subscribed
returns \subscribed flag
- unseen, recent, messages, uidnext, uidvalidity
returns what status would return
- others?

- LISTX ("/" "/inbox/*") (depth(1) refferals) (children unseen)
- LISTX ("/inbox") flags(\haschildren) unseen(2)
- LISTX ("/OS%212") flags(\haschildren) unseen(0)
- LISTX (imap://otherserver/remote%20mailboxes" flags(\haschildren)
[others omitted]

Other Extensions
- Now have syntax syntax for list of mailbox names
- Extend all commands that take mailbox names to accept the new URL syntax
- What about APPEND and COPY?

- modtime

- Mailbox annotations


Q: This new list command allows slashes even on servers that don't allow them. How does that interact with clients using legacy LIST?
A: Either legacy clients can't see those mailboxes, or don't allow those mailboxes to be created.

Q: What were the objections to the original extension (just children)?
A: it wasn't enough, we wanted more flexibility.
A: Cross-product of extensions, we wanted a generally flexible LIST command.

Floor: I am personally interested in seeing what was in the original draft proceed. I'm worried that this goes down the ISO thing with everything that everyone thinks is useful.
Barry: I'm willing to carry both drafts forward if there's interest.
Floor: The first draft would be easy. It's much easier to just do that than to do all of this.

Floor: I think we should go with different syntax for cruft removal.
Two things in the command are cruft: mutf-7 and hierarchy delimiters and we should take pain to get rid of the cruft.
Barry: URLs take care of that.
Floor: Also if we want to put mailbox annotations in there the syntax should be extensible to that.
Floor: if we're getting rid of MUTF-7, should that be under LISTX or a general "server supports UTF-8"? mUTF-7 was used in the first place is that there are ISO-8859-1 and shift-jis and EUC mailboxes advertised by IMAP servers out there. If you just expect UTF-8 we're going to have a problem. But we could have

Floor: Was there a feeling that people wanted a 3rd argument or a 3rd and 4th argument?
Floor (several): yes, split 'em


Chair: Last thing, view/sort/thread stuff. Need to describe the problem. We are going to get whacked sumarily on the head if we submit 2 drafts to anything other than informational/experimental and adding extensions to make IMAP even bigger are going to get kicked back very quickly. (Klensin comments Pete on his perception)

Client: With regard to the sort/thread/view issue, this means that coming up with a seperate view draft might not be a good idea, and if possible, we want to merge in with sort/thread. It is also clear to me that client vendors have some issues in what is in the current sort/thread stuff, that they want additional things. Cyrus has been looking for some ways to add stuff that will solve those issues.


Chair: We'd like to avoid VIEW because we believe that the IESG will reject VIEW as a duplication of functionality already available within IMAP. We need to reconcile the functionality. However, it's important that we act with foresight and not screw it up, either.

It was noted that people have concentrated on VIEW for maintaining server-side views of sort/thread state, not for limiting the current window of messages. The reason for maintaining the sorting information on the server is to minimize bandwitdh usage and to avoid having to repeat the sort.

Q: Why hasn't there been a big change to fix SEARCH? SEARCH has been around for 15 years...
A: The amount of data managed in folders has grown very recently.

Floor: Windowing on threading is hard; maybe we shouldn't do it.
Floor: Since threading is what most client users say that they want... People switch from clients that don't thread to clients that do. Chris: We can add the window argument to sort, or we can hold sort up until we figure out to window threading.
Floor: We could hold up windowing up for future study.
Chair: [Asks for humming for change sort vs. not changing sort, there's no clear consensus.]

Discussion of view vs. sort/thread, and complexity and IESG problems.

Chris: If we did a lightweight view we might be able to get it through.

[3pm, meeting ends]

Ned: If you want to proceed with 3 proposals, they need to identify why they're different and orthoganal.

Chair: We need a document that makes this orthoganal. Send it to the list.
Ned: That's a very good idea.


None received.