78 lines
3.1 KiB
Plaintext
78 lines
3.1 KiB
Plaintext
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>
|