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

Alexey Melnikov <[email protected]> Fri, 24 Jul 2015 12:45:57 +0200
Newsgroups gmane.ietf.imapext
Message-ID <[email protected]>
Hi,

On 24 Jul 2015, at 02:02, Jamie Nicolson <[email protected]> wrote:

>> On Thu, Jul 23, 2015 at 1:41 PM, Jayantheesh S B <[email protected]> wrote:
>> Hi Jamie,
>> 
>>  
>> 
>> How does the client know whether there is a mailbox-specific limit unless it issues a SELECT or LIST command? If a limit is specified in the CAPABILITY, does that mean there are no mailbox-specific limits? I thought it was possible to have both.
>> 
>>  
>> 
>> Let’s keep it simple.
>> 
>> We cannot have both.
>> 
>>  
>> 
>> When APPENDLIMIT value is specified in the capability response, that indicates that server does not support mailbox specific limit.
>> 
>> It’s one for everyone.
>> 
>> E.g.
>> 
>> CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
>> 
>>  
>> 
>> When APPENDLIMIT is omitted in capability response, that means server is having mailbox specific append limits.
>> 
>> E.g.
>> 
>> CAPABILITY IMAP4rev1 ID APPENDLIMIT
>> 
>> In this case client can get it by LIST or SELECT response.
>> 
> 
> OK, so a server implementor that wants system-wide mailbox limits can just specify APPENDLIMIT=XXX in the CAPABILITY and then ignore the parts of the spec that discuss per-mailbox limits? Sounds good to me.

From a server implementor's point of view this is easier to implement.

From a client implementor's point of view, having a new STATUS item which is only available some of the time adds asymmetry to the protocol, which makes it slightly more difficult to implement, especially in presence of multiple extensions.

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