NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01
Pete Resnick <presnick@qualcomm.com>
Ned Freed <ned.freed@mrochek.com>
Patrik Faltstrom <paf@cisco.com>
Patrik Faltstrom <paf@cisco.com>
General Discussion:ietf-imapext@imc.org
To Subscribe: ietf-imapext-request@imc.org
Archive: http://www.imc.org/ietf-imapext/
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.
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 MESSAGE ACCESS PROTOCOL - SORT EXTENSION
· INTERNET MESSAGE ACCESS PROTOCOL - THREAD EXTENSION
Minutes of the IMAPEXT Working Group
51st IETF - London
Chair: Pete Resnick
Minutes taker: Lawrence Greenfield (edited by Pete Resnick)
Issues discussed:
1. Access Control List document
Chair notes that the current document editor has been unable to spend enough time on it and is therefore handing it off to Alexey Melnikov. Alexey will submit a new draft soon accounting for earlier comments as possible. Chair will assure that notes taken from a bar-BOF at Minneapolis (taken by Chris Newman, we think) will be forwarded to Alexey.
2. ANNOTATE document (Cyrus Daboo)
a) Should IMAP flags be mirrored in annotations?
Clearly opposed: Crispin, Nerenberg, Gahrns
- Having two ways to do things is bad with no real benefit
- Additional flags can be done in current protocol which is superior
- Will cause increased complexity (what kinds of responses, do they always store to old/new)
Clearly supporting: Resnick, Stebbens
- Clients would prefer to use one mechanism for all annotation-like data if it is available
- Easier extensibility
- Features are available that don't exist in base flags (personal v. shared)
Issue to be taken to the list
b) Should there be a suffix default capability (.priv/.shared/nothing)
- List consensus: Explicit statement necessary
- No argument in room
- If system flags are mapped on annotations (see (a)), do they get defaults? Room reamined depressed on the matter.
c) Unsolicited annotation responses
- Room agreeds that unsolicited responses are only cache invalidations, they aren't the data
- Take to list the issue of whether they should they come only after an annotate command has been issued
d) Should the 's' bit be used for "can store private annotations?"
Should the 'w' bit be used for "can store shared annotations?"
- Greenfield and Daboo debate issue of more bits vs. overloading bits discussed
- Crispin and Resnick agree that since private annotations are private to the one storing the annotations and should be stored in the space of the annotator, there is no reason for the mailbox owner to grant permission for those annotations to exist
- Further discussion indicates that ACL is not where this belongs
3. SORT/THREAD
- IESG has given pushback that some sort of internationalized comparison/collation need to exist
- Some folks indicated that a global command that set up comaparison/collation for all other commands might not be desirable
- AD (Patrik) indicates that a reasonable default is at least need. Unicode technical standard #10 is a good candidate
- Crispin will take two issues to the list: a) What is the default comparator? b) What is the correct way of choosing comparators?
4. CONDSTORE
a) MODTIME is currently like ACAP, based off a timestamp
- move it to a 64-bit number, strictly ascending, opaque
- make sure time goes forward if it's used
b) Highest modtime for mailbox added
- Base spec doesn't allow 64-bit numbers in status, but we'll deal.
c) Do we want per message or per flag modtime?
- No opposition to per message.
- No opposition to dropping per flag.
d) Do we need to unify flags & annotations?
- No, but it creates syntax problems.
e) Should we return all items that have changed or just one?
- Alexey wants all.
- Some concerns for servers, but hey, what's a few more comparisons?
5. WINDOW
- Discussion of whether WINDOW/SORT need to move together. Chair indicates that extensive cross references aren't needed.
6. LIST extensions
- Greenfield wants to allow "()" at the end of a LIST response to allow for extensibility such as referrals or arbitrary status information
- Gahrns notes that referrals should be optional
7. BINARY
[Minutes taker notes something was said, but not available]
8. CHANNEL
- Issue is settling down
9. ANNOTATEMORE
So far, no objections
10. LITERAL+/MULTIAPPEND
- Crispin indicates that there are reasons for LITERAL+ that he understands
- Some discussion about whether TRANSACTIONS are necessary, or whether they will address some folks concerns in IESG/IAB about the complication of the protocol
11. LANGUAGE
Issues brought up:
- server responses
- matching (search/thread)
- collation (sort/list/thread?)
- [annotate]
Some light discussion of going from mUTF-7 to UTF-8
Meeting adjourned.
None received.