Re: Three kinds of IMAP extensions

I agree

we need to take into account the cost also of complications to other 
extensions.

At the moment for us appendlimit looks to have negative value overall, 
and we don't plan to implement.

Adrien


------ Original Message ------
From: "Arnt Gulbrandsen" <[email protected]>
To: "[email protected]" <[email protected]>
Sent: 17/10/2015 10:39:31 p.m.
Subject: [imapext] Three kinds of IMAP extensions

>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).
>
>Arnt
>
>_______________________________________________
>imapext mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/imapext

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