Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension

On Mon, Jul 20, 2015 at 3:29 PM, Naren <[email protected]> wrote:

>> Hello Working Group,
>>
>> We have published the first draft for
>> *draft-ietf-imapapnd-appendlimit-extension.*
>>
>> Please review the draft and drop your comments.
>>
>> http://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

We had previously discussed the interactions between APPENDLIMIT and  
other extensions that may limit the actual data size a particular  
mailbox allows.

For example, ACLs might prohibit appending to a certain mailbox (in  
which case the actual APPENDLIMIT for that mailbox is 0).  Or, due to  
QUOTA status for the current mailbox, the actual APPENDLIMIT for a  
mailbox might be a value less than what the globally advertised  
APPENDLIMIT is.

While it would be nice if APPENDLIMIT was an actual, up-to-the second  
accurate count of the maximum size of message octets that can be added  
to the mailbox, I agree that APPENDLIMIT is better served as an upper  
limit rather than an exact value, which may be expensive to calculate.

With that being said, I think there does need to be discussion about  
the interaction between APPENDLIMIT and ACL/QUOTA (and other future  
extensions).  Mainly that just because message data to be appended by  
a client is less than APPENDLIMIT does NOT mean that the data might  
not still be rejected on sizing grounds.

I would also like to see better reference to Alexey's LITERAL+ update.  
  Or, at a minimum, that APPENDLIMIT does NOT fully solve the issue  
with non-synchronizing literal usage if APPENDLIMIT is not a precise  
value of maximum append size.  i.e. on a server that supports  
APPENDLIMIT + LITERAL+, a client SHOULD continue to heed the advice in  
RFC 4549 [4.2.2.3] and not send APPEND data in a non-synchronizing  
literal for messages that are less than APPENDLIMIT in size.

For APPENDLIMIT + LITERAL+ servers, APPENDLIMIT will prevent an  
unnecessary round-trip if message data is above APPENDLIMIT.  But  
absent LITERAL- support, APPENDLIMIT does not prevent the need for a  
necessary additional round-trip when APPENDing a message.

MULTIAPPENDs should probably also be directly referenced in the same  
discussion.

At a minimum, the statement "Client can avoid use of LITERAL+, when  
maximum upload size supported by the IMAP server is unknown." in  
section 4 is probably better handled by a reference to RFC 4549.   
Although my preference would be to have some discussion of the above  
information in that section instead.


michael

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