Re: The IMAP APPENDLIMIT Extension - version 04

Chris,

Thanks for your time in reviewing the document. 

Please find my response inline. 

Regards,
Jay

-----Original Message-----
From: Chris Newman [mailto:[email protected]] 
Sent: Tuesday, March 03, 2015 8:33 PM
To: Jayantheesh S B; [email protected]
Subject: Re: [imapext] 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).

[Jay] Really I am wondering if anyone have the APPENDLIMIT value for individual mail greater than 2^32. Because, I see most of the providers like Gmail, restricts supporting the attachment handling with Max of ~25 MB.
I see in real time use case, supporting more than 512 MB of APPENDLIMIT per mail is practically not the going to happen. Appending mail with attachment more than 512MB of data is not realistic. Moreover, this value is not directly
 related to physical mailbox limit. So, am thinking to restrict the APPENDLIMIT value to 32 bits. Please share if you have any comments. 

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:


[Jay] Agree with you. But APPEND command can be sent in both Authenticated as well as Selected state, that's why added APPENDLIMIT response in both LIST as well as SELECT.  Moreover in Capabilities, if APPENDLIMIT  string without any value is received indicates, server has per mailbox limit. In this case, client has to rely on the LIST or SELECT response to get the per mailbox specific limit. In case, if APPENDLIMIT is not published as part of capabilities indicates, this extension is not supported in the IMAP server, so client can assume it won't receive the APPENDLIMIT as part of LIST and SELECT. Even if server sends in this case, client can ignore. 
Regarding the per mailbox specific limit,  based on the earlier discussion review comments section 3 has been added. But if everybody feels, its unnecessary to have the mailbox specific limit for this use case. We can re-consider it.

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


[Jay] I will update your comments in the next version of the draft.

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