Minutes for the MOrg BoF, taken by RL "Bob" Morgan (slightly edited by Alexey) goals be able to find messages in a mailstore easily support deverce email clients ( optimized access for mobile devices proposals search/sort/thread multimbox search, virtual mailboxes grouping and stats presentation: SEARCH=INTHREAD add 4 new search keys INTHREAD: algorithm + key, match messages in thread makes search/sort/thread return threads instead of messages Barry: might be better as a FETCH, rather than unexpected Cyrus: clients can do this today, this is minor optimization other keys ... THREAD=REFS like THREAD=REFS but no merging threads based on subject sort thread roots based on last recvd message, not by root's date ie, moving recent threads to top Barry: some clients don't use refs correctly (Pine?) sometimes subject changes on a reply heuristics needed when threading, throwing away Subject isn't good Cyrus: totally disagree, think this is important often messages with same Subject are different threads (discussion of relation between subjects and threads ...) ChrisN: should we ignore semantics because some clients get it wrong? Timo: client could let you start new thread Barry: most clients don't, some do Randy: this is optimization for clients with poor connectivity or shallow caches, reduces false positives, so useful Barry: (pondering) problem is adding yet another thing that is close but not quite right creates confusing complexity Alexey: may deprecate thread refs ... Barry: if this becomes The One, that's OK, if not, it's confusing Cyrus: client implementors have to do this too to make disconnected mode be same as connected Cyrus: other ways of sorting than Date? Timo: could merge thread / sort ... should THREAD=REFS use in-reply-to if no refs? Barry: sure, but makes point that this is heuristic Dave: seems that there is interest in new threading algorithms presentation: draft-karp-morg-sortdisplay (Alexey presenting) clients display displayname even when not used for sorting so results appear out of order issues: defines DISPLAYFROM, also need for CC and To? Alexey: yes for TO (at least) should alg consider RFC2822 comments? commentor: No EAI makes this worse? no ... Harald: requirement for charset registry? Alexey: another open issue presentation: multimailbox search Barry: resurrecting old idea SEARCH on LIST, list could contain wildcards, depth limit to control damage, SEARCH responses tagged to identify results issues: need more than simple DEPTH option? eg notify Timo: virtual view from multiple mailboxes as alternative? Barry: sure Timo: (accepts being volunteered to write up this proposal) presentation: per-mailbox/per-server attributes Cyrus: already at -14, recently simplified issues: interaction with NOTIFY new permissions needed? kind of a system thing, not a user thing, hence right, not priv no place to anchor the server-level right ... ChrisN: use S right for per-user private annotations? Alexey: W probably better CN: that would be for shared annotations CD: main question is whether new rights are needed easy to add, but more complexity Timo: don't like using S for private annotations Alexey: arguing for L for private? Timo: yes (other issues all obvious) option to restrict size of returned values? Alexey: here like in other places Timo: prohibit mailbox names with control characters? Alexey: could just strongly advise against using ccs ... presentation: draft-melnikov-imapext-status-in-list E.g. to report number of unseen messages in LIST Barry: examples should show that LIST and STATUS responses may not be adjacent issues: adds more failure cases eg ACL prevents STATUS reply options for letting clients know about failures: Barry: like STATUS replies with empty params ChrisN: this would apply to remote mailboxes? Randy: would wildcards apply? Alexey: yes, access control would be enforced Barry: should return STATUS with each name ... Dave: emply STATUS is silly, since client always knows via tagged OK Barry: agree we don't want to optimize for broken clients Cyrus: another option: untagged NO with mailbox name Alexey: sure, maybe with a new response code presentation: new collations/comparators for IMAP and Sieve (presented by Alexey) various new comparators suggested: space-ignoring, eg for Japanese signed-numeric, to grok plus and minus telephone number, ignore ' ', '-', '(', ')', etc Barry: not really mapping, can't match different renderings not really telephone-number-specific Cyrus: space-ignoring is subset of this one ie, "ignore these chars", but can't feed input into comparator so stuck with fixed set Chris: good, makes indexing easier Randy: suggest "id number" Zoltan: Finland has characters in national id "number" ChrisN: regexp is protocol, not comparators can do it, but have to recognize dangers case-sensitive version of i;unicode-casemap ie, normalization but not casemap presentation: sorting by relevancy (presented by Timo) a la search engine searches relevancy is impl-specific ChrisN: good idea, this is a comparator make it clear that this is server-specific collation registry is expert-review-gated Cyrus: agree with CN Dave: this is the "i;mumble" comparator? Timo: SCORE can't be fetched ... new SCORE SEARCH key? return score to clients so they can show to user in some way? Barry: agree this is useful, maybe have number for top N? presentation: flag/keyword management (presented by Timo) allow explicitly adding/removing keywords and keywords shared or private Barry: keywords are opaque to his server, just client data Alexey: removing keyword could be very expensive op Timo: MC's server keeps keywords for client ... Cyrus: how about new more generic tagging mechanism? Timo: how different from keywords? Alexey: just say keywords are UTF8? Cyrus: still need public/private Randy: tags are more fundamental part of protocol can be used in lieu of individual mailboxes Zoltan: separate user and client/machine keywords/tags Dave: doesn't flags + multimailbox search address this? Randy: need three things ... Barry: do users care about private tags any more? Dave: brand new tagging scheme won't take off, better to add incremental tagging to flags WG questions Eric B: yes, this seems like WG stuff worry about server complexity? Lisa D: someone quickly wrote a http-imap gateway via ATOM supporting web mashups planning to submit a draft on it Cyrus: distinct lack of client implementors here, we're all server guys need them here before going too far with this John Klensin: IMAP getting more complicated, interop limited maybe real question is cool access to mail store, without IMAP Chris: types of clients are changing, is that a bad thing? John Klensin: no, but may imply asking more fundamental questions ie, whether it's time to start afresh Lisa: email clients are very disappointing, little innovation some good stuff, Opera 9, mobile devices features not adopted by major clients are pointless, often some features may be server-only, that's OK Timo: protocol redesign not realistic many features driven by webmail usage Eric: fundamental questions really to apps area, not IMAP per se Cyrus: innovation is in client-side behavior, non-server-dependent shouldn't we be supporting that rather than cool new server features John K: if all clients suck, this means model and servers are broken might want to wait for clients to catch up if webmail is driver, what requirements are coming from that space? Chris N: ACAP is clean well-designed protocol, but no uptake so protocol beauty doesn't guarantee success IMAP replacement, if it is to happen, has to start with doc and/or implementation, not committee work Randy: IMAP has been difficult for clients to get right and complexity has made it worse but maybe: IMAP5 on new port, but with old junk removed, compliant but feature-limited this is a lot of what lemonade wants John K: +1. big clients say most users use POP or proprietary IMAP is checklist item, they do quick and dirty job to add it Chris: looking at proposals, some are good and will be used by web clients, others maybe not but support making a WG Barry: still a problem that not enough client implementors in the room Chris: could set a bar: if no client implementation, spec doesn't advance Carlo: client writers have to deal with so many servers that's why they do client-side features Dave: IMAP5 path could be attractive to client implementors Cyrus: need buyin from the big clients and ultimately from the users, who influence client makers John Levine: have 1000 users, only 5% use IMAP avoidance is due to the basic model, not features many people just want mail on their PC for search speed Barry: demand isn't going to come from most users, they're naive Jim Fenton: even some sophisticated users are scared away often due to interop fears Chris: IETF can't do user studies will anyone volunteer to write IMAP5 or IMAP-Lite spec? Randy: maybe Barry: we should form a WG, but what John K said? Alexey: people who want to work on this? (8-10 hands) anyone opposed? (none) Chris: let's see charter proposal on MORG list, get consensus, I'll take to IESG Alexey: key item will be identifying specific WG-to-be documents as there are too many Dave: the way forward on IMAP5 would be to float the idea and see whether client implementerss go for it Randy: agree, please do so, will set up new list for it Seed with membership of imapext list?