Re: Three kinds of IMAP extensions

Hi Adrien,

> On 19 Oct 2015, at 01:02, Adrien de Croy <[email protected]> wrote:
> 
> 
> understood, although the situation for SMTP is entirely different.
> 
> With IMAP you're dealing with authenticated / trusted users.  We've had requests about quota, but no request to limit an individual message size.
> 
> Also APPEND is hardly ever used -

It is used less frequently than FETCH, but I generally disagree with this statement.

> only to copy to sent folder after you already submitted with SMTP (drafts folder doesn't really count does it?

Oh yes, it does count a lot. Look at what Thunderbird is doing. Also automatic saving of Notes in iOS.
> ).  It would be better to solve the requirement to transmit the message twice in the first place (e.g. SUBMIT command).
> 
> It does not address the problem of what happens when a message is appended to an IMAP mailbox by something other than IMAP APPEND (e.g. the much more usual case, when the message came in by SMTP and is placed in the inbox).  Or is this intended to be a different case?

It is different. It can frequently be controlled by the same setting, if the mailstore also implements LMTP or SMTP.

> In which case how do we explain all this to server admins, which didn't even ask for it?  If someone sets the value too low they just create problems.  Is there really that much pain associated with this?

Yes, especially for big providers.
> 
> Adrien
> 
> 
> ------ Original Message ------
> From: "Stu Brandt" <[email protected]>
> To: "[email protected]" <[email protected]>
> Sent: 19/10/2015 12:54:50 p.m.
> Subject: Re: [imapext] 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
> 
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

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