Re: Three kinds of IMAP extensions

On Sat, Oct 17, 2015, at 20:39, Arnt Gulbrandsen wrote:
> At risk of sounding like a broken record, we have three kinds of (non-
> proprietery) IMAP extensions:
>
> 1. Ones like CONDSTORE, which most readers know to be worthwhile, in
>    CONDSTORE's case because so many people have felt the pain of FETCH
>    1:* FLAGS.
>
> 2. Ones like COMPRESS=DEFLATE, whose RFC says "implementing this is
>    dead simple and you'll cut your traffic by two thirds" (no, that's
>    not a direct quote).
>
> 3. Ones that go unused.
>
> Please, IMAPAPND authors and anyone else, if your document doesn't
> solve a well-known pain point like CONDSTORE, make an attempt to argue
> like C=D. Make it seem as if the value of the implementation exceeds
> the effort to implement. And don't explain the value on this list,
> make it clear to the reader of the RFC itself. And doubleplusplease
> don't mistake a good intention for a valuable effect (as IMAPAPND does
> as far as I can see).

+1, despite my ideas of suggestions like LIST-RETURN-MYRIGHTS and LIST-RETURN-METADATA, which are probably not such big pain points that people care.

The main things that I think have proven value that need to be RFCed soon are THRID / MSGID (the main point of debate is whether to mandate that they are exactly compatible with GMail's 63 bit integer format, or whether the are more general opaque blobs a-la UIDL from pop3)

And also some form of uniqueid support for folder, so you can detect them after they've been moved, though if you have MSGID and it's really immutable, that becomes heaps less bad, because you can just fetch all the contents of the new folder (FETCH 1:* (UID FLAGS MSGID MODSEQ)) and you've got everything you need - just incref the MSGID records before you decref them for the folder which went away. 

Some form of cross folder sort/search would probably be popular too.  The fastmail XCONVMULTISORT is probably not quite the right interface, but it's not totally awful either.

Bron.

-- 
  Bron Gondwana
  [email protected]

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext