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

From: [email-masked]
Date: Fri, 11 Sep 2015 07:41:29 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

        Title           : The IMAP APPENDLIMIT Extension
        Authors         : Samsung Telecommunications America
                          Narendra Singh Bisht
	Filename        : draft-ietf-imapapnd-appendlimit-extension-03.txt
	Pages           : 7
	Date            : 2015-09-11

Abstract:
This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY, STATUS and LIST commands.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-appendlimit-extension-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Timo Sirainen <[email-masked]>
Date: Thu, 1 Oct 2015 02:16:20 +0300

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