Re: Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt

On 5 March 2015 at 11:09, Alexey Melnikov <[email protected]> wrote:

>
> On 19/12/2014 09:26, Dave Cridland wrote:
>
>
> On 17 December 2014 at 18:35, Alexey Melnikov <[email protected]>
> wrote:
>
>>  I revived and updated LITERAL+ extension. I also added LITERAL-
>> extension (same as LITERAL+, but disallowed in APPEND).
>>
>>
>  Given the current discussions, wouldn't LITERAL- be better expressed as
> a LITERAL+ with a limited size?
>
> I can go along with that. What is a reasonable limit?
>

Configurable and advertised, but I'd go for around 2048 octets for a single
token.


> Also, this has interactions with APPENDLIMIT.
>
> Any other opinions on what people prefer?
>
>   I accept that the normal case for a large literal is APPEND,  but the
> issue is a general one with the size of the literal rather than the
> specific case of APPEND, isn't it?
>
>  This could even be an advertised token-sequence limit, but that's
> probably too hard to express.
>
> Sounds like overkill. Either way, can you suggest how this is going to
> look like?
>
>
Not in any way that'd be useful as a formal description.

It's a matter of saying something along the lines of a command line length,
including any non-synchronizing literals, must not exceed X octets.

>   Possible, though, to limit the amount of non-synchronized literal data
> with an entire command, which'd handle the MULTIAPPEND case as well.
>
>  To give an specific case, a client can always side-step a simple APPEND
> LITERAL+ limit by just using CATENATE in a fairly abusive manner.
>
>
> A client that can append can do all sort of damage. Selecting INBOX and
> doing "COPY 1:* INBOX" in a loop is my favourite.
>


I meant to side-step the limits in an annoying manner by abusing CATENATE,
stringing together hundreds of TEXT sections.

Overall I think a per-literal limit works best, though, since anything else
is clearly abuse. But abandoning literals within an APPEND command entirely
is silly - if a message fits within 2048 (unlikely, though possible for
small notes) or a TEXT item in CATENATE (quite likely), then a non-synch
literal seems the best solution.

Conversely, a non-synch literal size limit also would help with any
(present or future) case where large literals might be used with commands
other than APPEND.

Dave.

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