MBOX-Line: From blong at google.com  Thu Mar 28 12:23:36 2013
To: imap-protocol@u.washington.edu
From: Brandon Long <blong@google.com>
Date: Fri Jun  8 12:34:50 2018
Subject: [Imap-protocol] Working around the evils of LITERAL+
In-Reply-To: <515490A1.3070301@psaux.com>
References: <CABa8R6s3rK5JkXBtV7RWbav9T2GBCg+pw-aWd9=5Szv3ocDS_g@mail.gmail.com>
	<5152E3E6.40506@aj.jp.nec.com> <1364388724.13923.97.camel@innu>
	<CABa8R6vv_fupAVX6bv018L9j-uW=YdW5wJ+oACrd3W_WVJq9Ow@mail.gmail.com>
	<CAKHUCzyfA2ZnDn3hXQt=DCj5O4y_fRSaW6ocDLMd1VpDWEn6zQ@mail.gmail.com>
	<4F401469-14A2-48FA-A6F7-B667A52E46C4@orthanc.ca>
	<515490A1.3070301@psaux.com>
Message-ID: <CABa8R6sM6NbCYMSzTJbvTh7wG-JNcQ+w41psaknFuAy1FHMazw@mail.gmail.com>

I could see advertising LITERAL+=10000 for example, a max limit for
LITERAL+.

or LITERAL=35000000 for max size of literals period.

The folder level limit, while may be useful, is undiscoverable unless the
client issues a STATUS or its returned in LIST-EXTENDED.

Brandon


On Thu, Mar 28, 2013 at 11:49 AM, Tim Showalter <tjs@psaux.com> wrote:

> On 3/27/13 7:35 PM, Lyndon Nerenberg wrote:
>
>  I'm hesitant to suggest it, but is it worth sending BYE and dropping the
>>> connection? It's sailing just within the lines of the specification, I
>>> think.
>>>
>>
>> I think this is perfectly valid behaviour, and well within the spec.  A
>> smart server might choose whether the eat-and-continue vs. bye-and-punt
>> based on the size of the proposed literal+, but punting is entirely valid.
>>
>
> I would recommend against this, or at least advise caution.  A lot of
> clients, particularly mobile phone clients of a couple years ago, are both
> stupid and single-minded.  Hanging up is going to be treated as an obvious
> temporary failure and they will retry.
>
> We (my former employer) had somebody with like 80k messages in their
> "Sent" folder at one point because our SEARCH was broken, couldn't find the
> Message-ID, and the client really, really, really wanted to make sure it
> had been added.
>
> That said, BYE is compliant in my opinion; I just don't expect it to help.
>
>
>  And while the "nibble at the data slowly" idea is eeevily enticing, it's
>> going to wreak havoc with the battery on my mobile, which is almost
>> guaranteed to be running the most brain-dead IMAP client on the planet.
>>  (Servers factoring in aggregate data link speed in their eat-vs-bye
>> calculations will score many karma points in my book.)
>>
>
> The cleverness of this is appealing but it can't be worth the debugging
> cost.
>
> I'm all in favor of advertising the limit, and recommending that LITERAL+
> be used exclusively to replace quoted-strings for short uses. I don't think
> there's a good workaround otherwise.
>
> Tim
>
>
> ______________________________**_________________
> Imap-protocol mailing list
> Imap-protocol@u.washington.edu
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman13.u.washington.edu/pipermail/imap-protocol/attachments/20130328/6809a248/attachment.html>
