Re: [Imap-protocol] Working around the evils of LITERAL+

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 <[email protected]> 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
> [email protected]
> http://mailman2.u.washington.**edu/mailman/listinfo/imap-**protocol<http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol>
>

_______________________________________________
Imap-protocol mailing list
[email protected]
http://mailman2.u.washington.edu/mailman/listinfo/imap-protocol