Re: Three kinds of IMAP extensions

To me, the value of APPENDLIMIT is clear -- It provides a way for a 
server to advertise its maximum upload size. Without it, a client is 
left to implement a try-and-see approach to uploading data, often to the 
detriment of the user, his/her mobile data plan, and the server's 
resources. It's the IMAP equivalent of today's ESTMP servers returning...
   250-SIZE [size]
...in response to EHLO

I'm curious if removal of section 3, cleanup of section 2 to remove 
handling in the per-mailbox limits case, and removal of the 3rd 
paragraph of section 4 would reduce the complications negative value 
described.

I'd hate to see this go nowhere because of its attempt to solve for 
*both* majority and minority cases.

- Stuart

On 10/18/15 4:59 PM, Adrien de Croy wrote:
>
> 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

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