Last Modified: 2004-06-15
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 |
|
IMAPEXT WG
IETF-60 TOPIC: Status of i18n and sort drafts Summary: These are blocked on the comparator draft, which needs IANA review and buyin. Chris Newman reports that he has had a meeting with Michelle Cotton (IANA) and progress was made TOPIC: List extensions Issue: What to do about \Placeholder (Mark Crispin has asked if we can get rid of it). We need comments from mail client writers on how useful different flags and options are - Mark thinks it is overengineered. After discussion, we asked client people to post to the list asking if they would use \Placeholder. Alexey Melnikov will formulate the question and post it to the list and Cyrus Daboo to try to answer. Issue: Currently filter/select concepts are combined. Propose: Two parts, one to match mailboxes, other to control info returned. e.g. LIST <match-options> mailbox-spec RETURN <return-options> Some argument that all options need to be returned. Cyrus argues that this is good for use with ANNOTATEMORE. Lisa proposed that we could change only the name to be clearer, e.g. changing <return-options> to <also-return>. In this proposal, any responses that are implied by what you're asking for will be provided automatically. E.g. if you say "no standard flags" you'll still get subscribed if you're querying on that. A Proposal will be sent to the list. TOPIC: Annotate draft ACL issues: Cyrus says he tried to keep ACL as informative. Noted that ACL can be referenced because it is already an RFC; ACL2 is not done yet. All the bits needed are in ACL but some of the explanation of what the bits mean appears to be missing, specifically what the old [READ-ONLY] and [READ-WRITE] mean and whether ACL should imply one or the other. Pete Resnick is concerned about how mailbox access rights tie into annotations. ACL2 apparently resolves this but is not ready to reference. Shared annotations only interact with read-only/read-write -- private annotations are where the problem is. Pete argues for clearly separating these things. One option is to base it on ACL2 and add another bit controlling the ability to write private annotations. Proposal for ACL issue: could solve this with a new bit added to _old_ ACL. Chris Newman, channeling Mark Crispin, says adding stuff to ACL is bad because there are implementation that do not/cannot support old ACL. Need to warn that clients should not copy ACL bits they do not recognize -- they may inadvertently set or clear the bit. If they delete the flag they will remove rights. We need to add this text to security considerations of annotate. This also needs to be added to ACL2. Issue: Shared v private annotations. We need text in draft of the meaning or private annotations; make it clear that this is per-user (not access restricted). Cyrus suggests changing name from .prv to .user. This issue is left to document editor. Issue: Security considerations may be weak. Lisa asks for addiitional review of this section. Issue: Can set \deleted flag with D right, can set it with annotations with different rights. Put another way: What is "allowed to set annotation is on" but "allowed to set \deleted flag" is off? Issue: What happens if you set the shared and private versions of the annotation flags to different values? Answer: This is server-dependent. Then how does the client learn where to go to set them? Proposal 1: Don't use the suffix on flags in annotate, at least for special-cases \seen and \deleted. These two would not use suffix (or either suffix would be identical). Focusing on \seen for the moment: for \seen, FETCH implicitly updates something (per-user or shared, depending on server) Proposal 2: Don't map flags to annotate. Problem with this is that old clients will use flags. new ones use annotations, don't interop... Resolution: Need a history review of why the tie was done in the first place.) Punting to the list. TOPIC: ACL2 This draft waits for LISTEXT - depends on LISTEXT syntax. Proposal: Publish separately an update to existing IMAP ACL doc, containing the complete list of rights linked to the appropriate operations. This would also clarify when to return read-only/read-write. Proposal (for update to existing ACL doc): RIGHTS=rightlist capability. Some skepticism that "this will just be a little tweak to ACL" is what led to the present ACL2 delay. TOPIC Charter bashing. See revised charter (already posted). |