Re: The IMAP APPENDLIMIT Extension

On 16/02/2015 06:07, Michael M Slusarz wrote:
> Quoting Jayantheesh S B <[email protected]>:
>
>> Please find the next version of the draft updated with APPENDLIMIT=0 
>> case addressed.
>
> Was working on a test server implementation of this, and ran into 
> several issues that need to be addressed/clarified.
>
> 1) The APPENDLIMIT value is defined in ABNF as a "number", which is 
> limited to 32-bits.  Seems like this should be 64-bits instead to 
> better reflect modern resource limitations (or at least an unsigned 
> 63-bit number, such as MODSEQs).
A very good point. +1.
> 2) I don't believe the APPENDLIMIT response code should be returned 
> for an EXAMINE operation.  The value is irrelevant since you can't 
> append to a read-only mailbox.
Actually you are wrong on this one, because the APPEND command takes a 
mailbox name as a parameter, so it can be used from any mailbox (or no 
mailbox). So the currently selected mailbox and its state is irrelevant.
> It's possible that APPENDLIMIT may be somewhat expensive to generate - 
> i.e. a quota value that needs to be determined/parsed/updated - so 
> there's no need to report it when it is not directly usable.
>
> 3) I believe this was mentioned by at least one other person, but the 
> current handling of the response code in the mailbox is not correct, 
> at least according to the draft specification.
>
> Take this example:
>
> <QUOTA active; user currently has 100 bytes left in account>
> a1 SELECT INBOX
> <...>
> * OK [APPENDLIMIT 100]
> a1 OK [READ-WRITE] Done
> a2 STORE 1 +flags \deleted
> * 1 FETCH (FLAGS (\Deleted))
> a2 OK
> a3 EXPUNGE
> * 1 EXPUNGE
> * 0 EXISTS
> a3 OK
>
> Assuming that message 1 was 100 bytes, the quota for the user is now 
> up to 200 bytes.  This should be the new APPENDLIMIT value, but 
> according to the spec this does not need to be reported/updated.
>
> This needs to be handled similarly to the way that message counts are 
> updated when in the selected state.  Although, as mentioned above, the 
> appendlimit value may not be a trivial item to calculate so this can 
> start to become a fairly expensive feature add.
I think I am agreeing with Cyrus who said that APPENDLIMIT should not be 
affected by outstanding quota. It is a hint anyway. Not linking it to 
quotas would make implementations easier (and clients need to handle 
errors anyway).
>
> It makes me wonder whether adding this response code this is the 
> correct approach.  APPENDs will normally happen in an unselected state 
> (there are at least 2 server implementations that I am aware of that 
> don't allow APPENDs to a selected mailbox), so this information is 
> better obtained by using one of the other two methods anyway.
>
> michael
>
> ___________________________________
> Michael Slusarz [[email protected]]
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

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