Re: [IMAP] APPEND Command Usage

Hi Michael,

> On 18 Dec 2014, at 19:22, Michael M Slusarz <[email protected]> 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).
> 
> 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 implementation would probably issue a single LIST command with all options that might be needed and caching results.

But yes, issuing a couple of extra STATUS calls might be more efficient.

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