Re: I-D Action: draft-ietf-imapapnd-appendlimit-extension-03.txt

On 11 Sep 2015, at 17:41, [email protected] wrote:
>        Title           : The IMAP APPENDLIMIT Extension

Sorry for a bit late reply, I haven't had time/energy/brains/thoughts to look into my imapext folder for almost half a year:

I like the APPENDLIMIT=n CAPABILITY, but isn't the STATUS going a bit overboard? LITERAL+ is already an optimization for APPEND. APPENDLIMIT=n specifies a hard limit to that. QUOTA also can limit that. A folder-specific APPENDLIMIT also limits that, but  not exactly in the same way as QUOTA would. A client that really wanted to be almost (but not entirely) sure that it could do a LITERAL+ APPEND would have to issue GETQUOTA and STATUS (APPENDLIMIT) for the destination folder to make sure it can do that. Which wouldn't make a whole lot of sense in most situations, as that adds back the roundtrip that the LITERAL+ was supposed to give in the first place. It could of course cache the results in case it was APPENDing multiple messages, or maybe even for a longer time..

Anyway, I just don't see why a client developer would bother implementing STATUS (APPENDLIMIT). Even if it was used, it still wouldn't be perfectly reliable (due to quota and maybe other issues). Why implement something that going to be a problem in only some very rare cases? I only see these two APPENDLIMIT=n vs APPENDLIMIT capabilities as causing bugs in client implementations as the developers test their client against one server implementation that implements one of those.

The RFC already specifies that [TOOBIG] resp-text-code is returned back to APPEND if it's too large. I think the simplest solution here would be to require that the server sends that back immediately after it it receives a too large literal+ and that the client should try to read it back as soon as possible, and after receiving it disconnects from server. Dovecot is already almost compatible with this - it just doesn't send the [TOOBIG] resp-text-code yet. I think this would solve most of the rare cases that the global APPENDLIMIT=n capability wouldn't solve. And if wanted, before the NO [TOOBIG] the server could also send an untagged * OK [APPENDLIMIT n] reply to tell the client what the limit is. Or maybe even * OK [APPENDLIMIT n m] where n is the normal limit and m is what the current l
 imit is due to quotas (and/or other issues).

Also in any case: I think the RFC should mention something that the APPENDLIMIT=n CAPABILITY might be sent only after the user has logged in. This allows per-user limits. Dovecot sends most of the capabilities only after login nowadays.

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