Re: [IMAP] APPEND Command Usage

Inline

On 12/18/14 2:22 PM, Michael M Slusarz wrote:
> Quoting Alexey Melnikov <[email protected]>:
>
>> On 17/12/2014 12:01, Michael M Slusarz wrote:
>>
>>> - Section 2 says a "client SHALL not try to upload mail more than
>>> advertised limit in the APPEND command.".  I would think that should
>>> be MUST, not SHALL.  If a client understands APPENDLIMIT, it knows
>>> the maximum size the server would accept.  Sending data over this
>>> limit is explicitly ignoring process/resource limits advertised by
>>> the server.
>> SHALL and MUST have the same meaning according to RFC 2119.
>
> That is what I get for sending my message as I'm about to board a plane.
>
> You are correct, although FWIW it's one man's opinion that MUST is
> clearer than SHALL for this kind of language.
>
>>> - There's discussion of LIST + STATUS (RFC 5819).  But this is
>>> actually an addition to STATUS itself.  The spec should be written as
>>> extending STATUS, and then a discussion/example of how this can be
>>> used if 5819 is supported.  (If we want to force an APPENDLIMIT
>>> client/server to also be LIST-STATUS compliant for performance
>>> reasons, that's fine.  But seems to be a policy decision rather than
>>> a technical explanation.)
>> This section is not quite right, but I need to rereview it in more
>> details.
>
> Looks like you covered this in your subsequent review.
>
> In short, APPENDLIMIT status selector needs to be added to status-att,
> which is extending 3501.
>
>  From an implementation point of view, the STATUS case makes more sense
> than the LIST-STATUS case anyway.  A client /could/ add the APPENDLIMIT
> status return when creating the folder tree, but that's probably just
> wasted bandwidth since generally a client is only going to be appending
> to a small number of those mailboxes (i.e. a sent-mail mailbox).

Additional bandwidth would only be consumed in the case of per-mailbox 
limits, and only for those mailboxes that have a limit that is different 
than the global limit. I would imagine this condition will be pretty rare.

>
> I would imagine the most common behavior is that a client would grab the
> append limit before it's first append, and it is less expensive to issue
> "STATUS mailbox (APPENDLIMIT)" than a LIST command with APPENDLIMIT
> return in that situation since the status info is all that is needed.

My preference for the LIST-STATUS case over STATUS case comes from the 
following statement in section 6.3.10 of RFC3501:

       Unlike the LIST command, the STATUS command is not guaranteed to
       be fast in its response.  Under certain circumstances, it can be
       quite slow.  In some implementations, the server is obliged to
       open the mailbox read-only internally to obtain certain status
       information.  Also unlike the LIST command, the STATUS command
       does not accept wildcards.

This hints at LIST being both more responsive and more efficient on 
server resources.

>
> michael
>
> ___________________________________
> Michael Slusarz [[email protected]]
>
> _______________________________________________
> imapext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/imapext

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