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

Hi Timo,

Please find our response inline.

Regards,
Jay
-----Original Message-----
From: Timo Sirainen [mailto:[email protected]] 
Sent: Wednesday, September 30, 2015 7:16 PM
To: [email protected]
Subject: Re: [imapext] 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..

[Jay] The STATUS response comes into picture ONLY when the server supports Mailbox-specific APPENDLIMIT. So a server supporting APPENDLIMIT=n CAPABILITY need not to bother about the STATUS response.
Practically most of the server will not have mailbox-specific APPENDLIMIT, they will have one APPENDLIMIT for all the Mailboxes. That really doesn't make STATUS a bit overboard. If the server really wants to have a Mailbox-specific APPENDLIMIT then it has to take care of the STATUS, which I think will be rare.  

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.

[Jay] This draft provides flexibility to server implementers to have any one of the two ways of publishing the APPENDLIMIT. If a server decides to have mailbox-specific APPENDLIMIT then it has to have the STATUS support.
It is expected that client developer has to have it validated against both kind of server implementation.

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).

[Jay] By providing the APPENDLIMIT=n CAPABILITY we are avoiding the round trip in the too-big scenario.
Moreover data usage for mobile client is of utmost importance. By introducing this draft, I feel that we would address that concern very effectively.

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.

[Jay] This will be taken care in the next version (04) of the draft.

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