Last Modified: 2003-10-16
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 |
eoprivIMAPEXT WG minutes document status: - ANNOTATE: ready for list last-call - ANNOTATEMORE: one issue - SORT/THREAD: submitted to IESG, blocked on Chris's i18n draft - Ted will bump status and ping Ned - LISTEXT: chair to ping Barry to unstick draft and get it into WG last call - ACL2: many issues still being worked out - CONDSTORE: - Alexey to submit updated draft that resolves issue from AD review - lemonade stuff: - COMPOSE: ain't written - URLAUTH: will get pushed further, probably one or two more revs - CHANNEL: in limbo - Pete thinks his mailto: text should be stripped - initial-response for SASL: Rob asks for review, a couple impls so far - i18n: Chris to update draft per discussion below discussion: - ANNOTATEMORE - how to handle partial failure when changing multiple mailboxes 1) require rollback 2) allow partial failure/success 3) don't allow multiple mailbox changes - Alexey noted that ACL2 behavior in similar case is #2 - example of an annotation to apply to a hierarchy: setting the sort/thread type on all mailboxes beneath your 'list' folder - since creating a new mailbox doesn't result in the mailbox inheriting annotations from its parent, clients already have to implement search up tree - consensus is to disallow multiple mailbox setannotation - Crispin asked for more impl advice: how should a client fake annotations when working with a server that doesn't support them? (that advice should help servers that use legacy mailbox formats) - ACL2 - issue: how to express the acl models in use - query: webdav acl rfc status? - passed IESG, but with both security ADs abstaining(!) - now, in rfc-editor queue, last draft was #12 - servers can advertise all sorts of mappings and tieing of rights that vary, with result that clients just end up presenting results to the user; automated clients suffer - main question is how a client can predict results when making a change - Marc reiterates Cyrus's comment about GUI interface exposing just simple bits - Klensin disagrees: in enterprises you do need fine-grained control - chair: specific open issues and comments? no, so take it to the list - i18n - revised comparator draft - various tweaks to format and wording - registration template is now XML and its URL is part of standard - Ted Hardie: concern about putting requirements on IANA, in particular guarantees of stability. On the otherhand, DDDS and URNs *can* be guaranteed; can we do those or perhaps push stability requirement onto W3C? - Michael Meeling's doc on XML namespaces as example, ditto provreg - upcoming changes - reference to Unicode Consortium doc on tailoring - review by W3C and Unicode Consortium - open issues - nameprep processing for basic collation? - no, just use straight unicode collation, no IETF-specific processing - way to download unicode collation customizations/tailoring - may do if a stable spec for format et al can be found - IMAP i18n changes and open issues - add examples - not going to add command to fetch lookup table - Cyrus: capability for comparator only to be displayed after entering authenticated state. Why? - default can change - advertising default via capability (vs a separate unsolicited response) seems...odd... - lemonade - COMPOSE - to work as an append that can take pieces from the currently selected mailbox - looking to address simple case of composing simple forwards, not grand unified document building - URLAUTH - request for feedback - "we [imapext] may be nuts, but some [lemonade] people really are crazy" - contention: URLAUTH is useful outside of lemonade - "are [the authors] under the belief that it [the URL authorization bits] apply to other schemas, because they don't" - why are they linking the location identifier and the authorization token? - want to use urlauth to publicly export data too - "use of IMAP as general purpose object access protocol is unwise" - conflating location and identification has costs as well as benefits - imap-url spec is old and is poorly deployed - partly because you need a mostly full imap client - complete fine-grained access vs broad strokes? - result: study of use cases needs more study? More to happen on |