Re: Three kinds of IMAP extensions

Stu Brandt writes:
> On 10/19/15 11:44 AM, [email protected] wrote:
>> The drafts folder does not count because nothing appended there is big
>> enough to care about this extension.
>
> Anything with photos or videos or other rich media/files in it 
> runs the risk of being too large. Clients are increasingly doing 
> incremental save-to-draft as users compose messages, so whatever 
> the user composes ends up "in the cloud" within a few minutes.

Consider that.

Suppose you write a mail reader and want to save drafts every two minutes 
and support IMAPAPND. So you write a function:

  1. If the server supports IMAPAPND, and the draft message including
     attachments is within the mailbox' size limit, write it.
  2. Otherwise write the draft to the mailbox, but with references instead
     of the attachments. Perhaps a header field called 
"X-Myclient-Attachment:
     <local file name here>"

IMAPAPND has a limit, so you have to write step 2. The question you now 
have to consider is: why value does step 1 give you?

It gets worse. Suppose that your mail reader is on a mobile device with 
both WLAN and mobile data, and that in your target market many people may 
per gigabyte for mobile data, and that sending costs no money but eats the 
battery. So someone on your team suggests the following change:

  1. If on WLAN, set a high limit for how big messages can be.
  2. If on mobile data, set a lower limit.
  3. If server supports IMAPAPND, use its limit instead.
  4. If the draft message including attachments is within the mailbox' size
     limit, write it.
  5. Otherwise write the draft to the mailbox, but with references instead
     of the attachments. Perhaps a header field called 
"X-Myclient-Attachment:
     <local file name here>"

A third member asks: Why don't se skip step 3? What value does IMAPAPND 
bring us? And it's a really good question. You can change step 3 to be 
conditional, but the question remains.

IMAPAPND has to be simple enough to survive discussion of whether 
implementing and testing step 3 takes too much time.

> For server dev, I'd think the simplest is to add 
> "APPENDLIMIT=<your-servers-appendsize-limit>" where 
> your-servers-appendsize-limit ideally comes from some existent 
> limit configured in your server. This is what we implemented.
>
> For client dev, I'd think the simplest is to look for 
> "APPENDLIMIT=" capability and steer users away from trying to do 
> operations that would require appending oversized messages -- 
> "Your draft/note is too large to save" or "Sorry, that message 
> is too large to copy from AccountA to AccountB. AccountB only 
> accepts messages less than <appendlimit> bytes."
>
> Perhaps I'm oversimplifying, though :)

I think you may be simplifying enough, but I'm not sure.

Arnt

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