Last Modifield: 11/06/2001
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 Extension WG minutes, Thu Nov 21 2002 reported by Rob Siemborski <email@example.com> 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.