Subject: Re: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-03.txt

From: Alexey Melnikov <[email-masked]>
Date: Sat, 3 Oct 2015 20:00:04 +0100

Hi Timo,

> On 1 Oct 2015, at 00:16, Timo Sirainen <[email-masked]> wrote:
> 
> 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.

Yes, mentioning this is a good idea.

> This allows per-user limits. Dovecot sends most of the capabilities only after login nowadays.

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 6 Oct 2015 22:39:56 +0000

Hi Timo,

Thanks for your review comments. 

We will  address your recommendation in next version of the draft.

Regards,
Jay
-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Saturday, October 03, 2015 3:00 PM
To: Timo Sirainen
Cc: [email-masked]
Subject: Re: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-03.txt

Hi Timo,

---

From: S Moonesamy <[email-masked]>
Date: Wed, 07 Oct 2015 00:19:36 -0700

Hi Jay,
>We will  address your recommendation in next version of the draft.

Timo sent several comments and also asked a question: "Why implement 
something that going to be a problem in only some very rare cases?" 
[1].  It is the sort of question which you could also get during 
IETF-wide review or during IESG Evaluation.  The draft might or not 
be the ideal place to have all the answers.  It would useful if there 
is a discussion on the mailing list about the comments (and the 
question) which Timo sent.

Regards,
S. Moonesamy

1. http://www.ietf.org/mail-archive/web/imapext/current/msg05562.html

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 7 Oct 2015 10:57:12 +0100

S Moonesamy writes:
> Timo sent several comments and also asked a question: "Why 
> implement something that going to be a problem in only some very 
> rare cases?" [1].  It is the sort of question which you could 
> also get during IETF-wide review or during IESG Evaluation.  The 
> draft might or not be the ideal place to have all the answers.  
> It would useful if there is a discussion on the mailing list 
> about the comments (and the question) which Timo sent.

IMO the document should answer this particular question.

Most drafts/RFCs don't; there is a silent assumption that the reader knows 
the problem well before starting to read. That's plausible for the imapext 
subscribers, but less so for random programmers who just follow a link on 
Stack Overflow. And it's particularly bad when an extension helps seldom, 
as in this case.

A document that helps in only a few cases must explain its utility, or else 
it will be pushed down the readers' priority list.

I'm afraid I cannot suggest a good answer to the question, however.

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 7 Oct 2015 21:59:50 +0000

Hi Timo,

Please find our response inline.

Regards,
Jay
-----Original Message-----
From: Timo Sirainen [mailto:[email-masked]] 
Sent: Wednesday, September 30, 2015 7:16 PM
To: [email-masked]
Subject: Re: [imapext] I-D Action: draft-ietf-imapapnd-appendlimit-extension-03.txt

On 11 Sep 2015, at 17:41, [email-masked] 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 limit 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.