Re: Fwd: I-D Action: draft-melnikov-rfc2088bis-01.txt
Alexey Melnikov <[email protected]>
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <[email protected]> |
On 19/12/2014 09:26, Dave Cridland wrote: > > On 17 December 2014 at 18:35, Alexey Melnikov > <[email protected] <mailto:[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? 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? > 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. Best Regards, Alexey _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext