Re: [IMAP] APPEND Command Usage

Hi Stuart,

On 10/12/2014 19:58, Stuart Brandt wrote:
> From a server perspective, the proposal solves my concern. From a 
> client perspective, I'm not sure whether the addition of [SP 
> nz-number] to the TOOBIG response would present problems for clients 
> that only implement CATENATE and not APPENDLIMIT. I too would like to 
> see others chime in on that part.
>
> From what I see, most IMAP sessions either precede an APPEND with a 
> SELECT/EXAMINE or LIST...likely to confirm the existence of the target 
> mailbox into which they're going to append.  The proposal already 
> covers SELECT/EXAMINE, so would it be reasonable to add the 
> APPENDLIMIT=x as an attribute to the LIST response data in order to 
> reflect any per-mailbox limit and avoid trying to convey the limit as 
> part of the TOOBIG response code to APPEND? Something along the line of:
>
> C: t1 LIST "" "%"
> S: * LIST (\Marked \HasNoChildren) "/" Inbox
> S: * LIST (\HasNoChildren) "/" ToDo
> S: * LIST (\HasChildren) "/" Projects
> S: * LIST (\Sent \HasNoChildren) "/" SentMail
> S: * LIST (\Marked \Drafts \HasNoChildren \APPENDLIMIT=257890) "/" 
> MyDrafts
> S: * LIST (\Trash \HasNoChildren) "/" Trash
All mailbox attributes are typically checked for equality, so this this 
a departure from this principle. (I know we started to violate this rule 
in CAPABILITY response)
So personally, I prefer if we add a new STATUS item for APPEND limit. 
Then we can use STATUS-in-LIST bridge 
(https://tools.ietf.org/html/rfc5819) to return this information.

As clients that want to obey APPENDLIMIT would need to be modified 
anyway, they might as well be modified to support RFC 5819 syntax.

But otherwise I am Ok with being able to return this information in LIST.
> S: t1 OK done
>
> Comments?
>
> - Stuart
>
> On 12/10/14 11:20 AM, Jayantheesh S B wrote:
>> Yes, I agree with your comments. Existing functionality should be 
>> broken with this new proposal.
>>
>> But the TOOBIG response syntax does not convey the size supported by 
>> the server
>>
>> resp-text-code =/ toobig-response-code / badurl-response-code
>> toobig-response-code = "TOOBIG"
>>
>> Reusing the TOOBIG response code with updated syntax like below 
>> solves the issue
>>
>> toobig-response-code = " TOOBIG " [SP nz-number]
>> resp-text-code /=  toobig-response-code
>>
>> Please share your comments.
>>
>> Regards,
>> Jay
>>
>> -----Original Message-----
>> From: Stuart Brandt [mailto:[email protected]]
>> Sent: Tuesday, December 09, 2014 8:25 PM
>> To: Jayantheesh S B; 'Alexey Melnikov'
>> Cc: '[email protected]'
>> Subject: Re: [imapext] [IMAP] APPEND Command Usage
>>
>> If I'm understanding the proposal correctly, a server that has 
>> already implemented CATENATE and now implements APPENDLIMIT is left 
>> in an ambiguous state whenever the limit is exceeded. If it returns 
>> [TOOBIG], then it's not compliant with the APPENDLIMIT 
>> recommendation. If it returns [APPENDLIMIT x] then it's returning an 
>> unexpected response to clients that have yet to implement 
>> APPENDLIMIT, thereby "breaking"
>> existing functionality.
>>
>>
>> On 12/9/14 5:16 PM, Jayantheesh S B wrote:
>>> Hi All,
>>>
>>> Thanks for your response.
>>>
>>> New response code APPENDLIMIT will be returned as part of SELECT 
>>> response to convey per mailbox limit
>>>    and APPEND command response, if the APPENTLIMIT size is exceeded.
>>>
>>> C: t2 SELECT INBOX
>>> S: * 172 EXISTS
>>> S: * OK [APPENDLIMIT 257890] Maximum upload limit
>>> S: [...]
>>> S: t2 OK [READ-WRITE] SELECT completed
>>>
>>> C: t1 APPEND "Draft" (\SEEN \DRAFT) {98994952}
>>> S: t1 NO [APPENDLIMIT 257890] Exceeds the maximum allowed size
>>>
>>> Whereas TOOBIG response, does not covey the size restriction applied 
>>> by the server.
>>>
>>>    resp-text-code =/ toobig-response-code / badurl-response-code
>>>    toobig-response-code = "TOOBIG"
>>>
>>> We feel APPENDLIMIT response can convey per mailbox size restriction 
>>> and it can overcome the limitation of TOOBIG response.
>>>
>>> Please share your thoughts.
>>>
>>> Regards,
>>> Jay

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