Re: The IMAP APPENDLIMIT Extension

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

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

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