Re: [IMAP] APPEND Command Usage

Hi Stuart,

On 12/12/2014 15:40, Stuart Brandt wrote:
> Inline comments
>
> On 12/12/14 5:24 AM, Alexey Melnikov wrote:
>> 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.
>
> And same goes for the server, because the client will want to query 
> *every* server that supports APPENDLIMIT just in case it has 
> per-mailbox limits. Unless I'm way off base here, a server with a 
> simple mailbox-wide APPEND limit would need to implement APPENDLIMIT 
> *plus* 5819 and 5258 to support the client asking about per-mailbox 
> limits -- unless we have the client assume that lack of support for 
> 5819/5258 implies that the server has no per-mailbox limits. Seems 
> pretty involved.
Actually, I was thinking of something simpler, which is syntactically 
compatible:

C: A01 LIST "" % RETURN (STATUS (APPENDLIMIT))
S: * LIST () "."  "INBOX"
S: * STATUS "INBOX" (APPENDLIMIT 1024000)

So basically server should recognize an extra "RETURN (STATUS (APPENDLIMIT))" at the end of a list command and emit an extra STATUS response for each matching mailbox. Support for RFC 5819 and RFC 5258 is optional.


My reason for recommending this (other than "compatibility with RFC 
5819/5258 is a good thing") is that if the limit is per mailbox, it 
might be stored with mailbox information and thus might be relatively 
expensive to retrieve. So a compliant server shouldn't try to retrieve 
it unless a client asks for this information. So basically we need a 
signalling mechanism for requesting this information.
>> But otherwise I am Ok with being able to return this information in 
>> LIST.

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