Re: The IMAP APPENDLIMIT Extension - version 04

--On February 27, 2015 20:57:05 +0000 Jayantheesh S B <[email protected]>
wrote:
> Please find the next version (04) of the draft attached with review comments
> addressed.
> 
> Changes in this version:
> 
> 1.       Append-limit-value changed from 32 bits to 64 bits unsigned number

Please use a 63-bit number to align with the new condstore RFC 7162. For those
who write IMAP software in C/C++, there is a technical argument to prefer use
of signed integers:
 http://google-styleguide.googlecode.com/svn/trunk/cppguide.html#Integer_Types
 (see "On Unsigned Integers")
So a 63-bit protocol limit allows the implementer freedom to choose the type.

The document should state that an append limit in excess of UINT32_MAX means
the server accepts larger-than 32-bit-unsigned integer lengths in append
command data literals (this change means this document updates the IMAP base
spec).

Q for list: If the server has a message larger than UINT32_MAX in the store and
a client tries to fetch it, should the server just go ahead and violate the
base-spec's UINT32_MAX limit or should the data be NIL unless the client uses
ENABLE to tell the server it accepts larger-than-uint32-max literals on
messages? If this extension fixes that base spec limitation in addition to
enabling better client diagnostics for overlarge messages, I think that's cool.

Having two different ways to access a per-folder limit is a violation of good
protocol design practices. Specifically 3.1 and 3.2 provide two ways to access
the same appendlimit. I believe the document would be improved by the removal
of section 3.1. Some problems with the current two-mechanism proposal:

* Which limit will the client use if the two limits are different?
* Should a client SELECT a mailbox before doing an APPEND? This is not required
by the base spec and is less efficient. The presence of section 3.1 implies a
client should do this. I do not think a client should do this. Removing section
3.1 removes this issue as a problem.
* The addition of APPENDLIMIT as a response to SELECT even for clients that
don't understand it penalizes all clients with unnecessary network traffic.
While it's not a big response by itself, we're starting to get a
death-of-1000-cuts problem with SELECT responses, so unless it's really
important (and in most cases I think the capability is good enough) I'd rather
not add that extra traffic (and potential battery life cost on mobile devices).
* The document does not state if the APPENDLIMIT response is a MUST/SHOULD/MAY.
If it's a MAY, my server implementation won't send it, in which case why is it
in the spec? If it's a SHOULD, I'll include a product option so admins can
disable it. If it's a MUST, I object to advancing the proposal.

I'm also curious, does anyone intend to implement different per-mailbox append
limits? If nobody speaks up, then perhaps we should just remove all of section
3.

One suggestion for the list to discuss; should we allow the limit to be
expressed in terms of Megabytes or Gigabytes via a suffix? Thus we'd have:

append-limit-value = 1*DIGIT ["G" / "M"]
                     ; M = Megabyte (* 1,000,000)
                     ; G = Gigabyte (* 1,000,000,000)
                     ; Unsigned 63-bit integer after multiplier
                     ; (1 <= n <= 9,223,372,036,854,775,807).

Not much additional code and makes the protocol both more concise and human
readable. Just a suggestion (we have some product config options like this).

FYI, I am interested in implementing this when it approaches rough consensus.

		- Chris

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