Re: Three kinds of IMAP extensions

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 - only to copy to sent folder after you 
already submitted with SMTP (drafts folder doesn't really count does 
it?).  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?  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?

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