Re: The IMAP APPENDLIMIT Extension

Quoting Alexey Melnikov <[email protected]>:

> On 16/02/2015 06:07, Michael M Slusarz wrote:
>
>> 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.

I disagree with you here.

Agreed that APPEND has a mailbox argument, so it can be called from a  
non-selected context.

But APPEND is also allowed to be called from within a mailbox.  And if  
that current selected context is read-only via EXAMINE, my  
understanding/belief is that an APPEND cannot be successful since that  
would be an action that causes a "change[] to the permanent state of  
the mailbox".

Regardless, not much reason to discuss this further in this context  
due to below comments.

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

If this is the correct behavior, what's the purpose of APPENDLIMIT in  
the first place?  APPENDLIMIT then becomes an "it might be correct  
value, but it might not be", so a client might be able to use it to  
determine beforehand whether an APPEND but then again you might not.

If APPENDLIMIT is not an accurate representation of the maximum size,  
what useful purpose does it serve over what we currently have?  In  
other words: how is this better/more efficient than calling APPEND  
without LITERAL+ to catch oversized data.  (Note: as the spec is  
written, APPENDLIMIT is solely designed as a limitation to prevent  
unnecessary network traffic.  It is not meant to be used as a UI  
limitation device, e.g. ensure a user can only create a message less  
than a certain size.)

michael

___________________________________
Michael Slusarz [[email protected]]

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