Re: [IMAP] APPEND Command Usage

Inline comments

On 12/15/14 6:52 AM, Alexey Melnikov wrote:
> 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.

That certainly simplifies things. Sounds good.

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

Makes complete sense.

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