Subject: Re: [imapext] [IMAP] APPEND Command Usage

From: Jayantheesh S B <[email-masked]>
Date: Tue, 9 Dec 2014 22:16:55 +0000

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

-----Original Message-----
From: Alexey Melnikov [mailto:[email-masked]] 
Sent: Sunday, November 23, 2014 11:32 PM
To: Stuart Brandt
Cc: [email-masked]
Subject: Re: [imapext] [IMAP] APPEND Command Usage

Hi Stuart,

> On 21 Nov 2014, at 03:04, Stuart Brandt <[email-masked]> wrote:
> 
> Is it appropriate to cover interaction with the CATENATE extension (rfc4469) in the draft? That RFC already suggests that the server return TOOBIG if construction of the server-side message exceeds a server-specific limit, but I'd imagine APPENDLIMIT=<n> would be a more useful response for those servers/clients that support APPENDLIMIT.

You have a very good point!
And yes, we should reuse the TOOBIG response code, if it can convey the per-mailbox limit.
> 
> - Stuart
> 
> 
>> On 11/17/14 12:16 PM, Jayantheesh S B wrote:
>> Hi All,
>> 
>> I have incorporated all the review comments and updated the next 
>> version of the draft.
>> 
>> Kindly review and share your valuable comments.
>> 
>> Regards,
>> 
>> Jay
> 
> _______________________________________________
> imapext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/imapext

---

From: Stuart Brandt <[email-masked]>
Date: Tue, 09 Dec 2014 20:25:00 -0500

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.

---

From: Jayantheesh S B <[email-masked]>
Date: Wed, 10 Dec 2014 16:20:29 +0000

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 

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-masked]] 
Sent: Tuesday, December 09, 2014 8:25 PM
To: Jayantheesh S B; 'Alexey Melnikov'
Cc: [email-masked]'
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.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 10 Dec 2014 17:43:47 +0000

Hi,

> Please share your comments.
Other people should weight in, but I am a bit unsure how safe is 
extending already registered response codes. I can be convinced that 
this is a non issue though.

---

From: Dave Cridland <[email-masked]>
Date: Wed, 10 Dec 2014 19:31:53 +0000

> Other people should weight in, but I am a bit unsure how safe is
extending already registered response codes. I can be convinced that this
is a non issue though.

Seems fraught with danger to me. We could always use enable and since the
problem by negotiation.

>> 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"
>>> We feel APPENDLIMIT response can convey per mailbox size restriction
and it can overcome the limitation of TOOBIG response.

---

From: Stuart Brandt <[email-masked]>
Date: Wed, 10 Dec 2014 14:58:01 -0500

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
S: t1 OK done

Comments?

- Stuart

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 11 Dec 2014 17:42:01 +0000

Sounds OK. By this way, we can avoid changing the already registered response "TOOBIG" for APPEND command as part of CATENATE extension (rfc4469). 

-----Original Message-----
From: Stuart Brandt [mailto:[email-masked]] 
Sent: Wednesday, December 10, 2014 2:58 PM
To: Jayantheesh S B; 'Alexey Melnikov'
Cc: [email-masked]'
Subject: Re: [imapext] [IMAP] APPEND Command Usage

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

Comments?

- Stuart

On 12/10/14 11:20 AM, Jayantheesh S B wrote:
> toobig-response-code = " TOOBIG " [SP nz-number] resp-text-code /=  
> toobig-response-code
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Dec 2014 10:24:35 +0000

Hi Stuart,

On 10/12/2014 19:58, Stuart Brandt wrote:
> 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.
>
> 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 "" "%"
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.
>> 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.
>>
>>

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 12 Dec 2014 22:03:42 +1100

> But otherwise I am Ok with being able to return this information in LIST.

Adding something in STATUS that doesn't also exist in the SELECT response
seems somewhat weird to me.

(speaking of STATUS-IN-LIST, I appear to have just pushed back my non-standard
MYRIGHTS-IN-LIST extension to Cyrus master.  It makes sense - while you're
grabbing the status, you also want to grab permissions for the purpose of UI display.
We should write that up too)

Bron.

-- 
  Bron Gondwana
  [email-masked]

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 12 Dec 2014 11:51:04 +0000

> seems somewhat weird to me.
I think we already agreed that APPENDLIMIT response code will be 
returned on SELECT?
> We should write that up too)
Sounds good. I would be happy to implement both client side and server side.

---

From: Stuart Brandt <[email-masked]>
Date: Fri, 12 Dec 2014 10:40:09 -0500

Inline comments

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

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 15 Dec 2014 11:52:25 +0000

Hi Stuart,

On 12/12/2014 15:40, Stuart Brandt wrote:
> *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.

---

From: Stuart Brandt <[email-masked]>
Date: Mon, 15 Dec 2014 10:07:06 -0500

Inline comments

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

> signalling mechanism for requesting this information.

Makes complete sense.

---

From: Jayantheesh S B <[email-masked]>
Date: Tue, 16 Dec 2014 23:21:41 +0000

Hi All,

Please find the updated version of the draft attached.

Changes in this version:

1.  APPEND command response handling changes (Reused TOOBIG response-text from rfc4469 )
2.  Retrieval of per mailbox limit in  authenticated state by using LIST and STATUS command (Reference rfc5819)

Kindly share your comments. 

Regards,
Jay

-----Original Message-----
From: Stuart Brandt [mailto:[email-masked]] 
Sent: Monday, December 15, 2014 10:07 AM
To: Alexey Melnikov; Jayantheesh S B
Cc: [email-masked]'
Subject: Re: [imapext] [IMAP] APPEND Command Usage

Inline comments

On 12/15/14 6:52 AM, Alexey Melnikov wrote:
>>>> 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.
>>>>
>>>> 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 
>>>> 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 "" "%"
>>> 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.
> response for each matching mailbox. Support for RFC 5819 and RFC 5258 
> is optional.

Makes complete sense.

---

From: Michael M Slusarz <[email-masked]>
Date: Wed, 17 Dec 2014 05:01:02 -0700

Quoting Jayantheesh S B <[email-masked]>:

> 2.  Retrieval of per mailbox limit in  authenticated state by using  
> LIST and STATUS command (Reference rfc5819)
>

Some quick thoughts:

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

- Section 4: It seems like a good place to reiterate that LITERAL+  
SHOULD NOT be used, even if APPENDLIMIT is available, since there may  
be other reasons why a server would reject an APPEND and the client  
should only proceed with APPENDs only when the initial "handshake" has  
been accepted by the server.  APPEND is a place where we probably need  
the extra round-trip in exchange for preventing potentially large  
amounts of bandwidth to be used.

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

michael

___________________________________
Michael Slusarz [[email-masked]]

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 17 Dec 2014 12:44:15 +0000

Hi Michael,

> explicitly ignoring process/resource limits advertised by the server.
SHALL and MUST have the same meaning according to RFC 2119.
> amounts of bandwidth to be used.
Right. Or I can add this text to my update to LITERAL+ (currently 
expired draft-melnikov-rfc2088bis-00.txt)
> reasons, that's fine.  But seems to be a policy decision rather than a 
This section is not quite right, but I need to rereview it in more details.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Dec 2014 12:34:38 +0000

Comments on the new section 3.2 that you've added:
> 3.2 LIST response
>
> IMAP client can get the mailbox specific APPENDLIMIT in authenticated
> state, where it do not need to issue SELECT/EXAMINE command.  LIST
> command in combination with STATUS command can be issued to get the per
> mailbox specific APPENDLIMIT set by the server.  Refer rfc5819 for the
> usage of LIST command in combination with STATUS command usage.
Nit: drop the last "usage".

I suggest you add the following sentence after the one quoted above:

Note that a server implementing this extension, is syntactically 
compatible with RFC 5819, however support for RFC 5258 or RFC 5819 is 
not required when implementing this extension.
>
> The following example demonstrates, its usage.
>
> C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
> S: * LIST () "."  "INBOX"
> S: * STATUS "INBOX" (APPENDLIMIT 257890)
> S: t1 OK List completed.
>
> New attribute APPNDLIMIT is added to get the limit set by the server for
Typo: APPENDLIMIT
> this mailbox as part of STATUS command.  The STATUS response occurs as a
> result of an STATUS command.  It returns the mailbox name that matches
> the STATUS specification and the requested mailbox status information.
> IMAP server should recognize an extra "RETURN (STATUS(APPENDLIMIT))" at
Please change "RETURN (STATUS(APPENDLIMIT))" to ""RETURN (STATUS 
(APPENDLIMIT))", as spaces are significant.
> the end of a list command and emit an extra STATUS response for each
> matching mailbox.  Refer to section [5] for the syntax.

How did you manage to generate [5]? This is going to be misinterpreted as a document reference by various IETF tools. Just use "5".

It might also be worth pointing out that just calling STATUS with APPENDLIMIT is also acceptable. It would be worth adding an example of that as well.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Dec 2014 17:03:24 +0000

On 10/12/2014 01:25, Stuart Brandt wrote:
> 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.
Clients are supposed to ignore response codes they don't understand. I 
think this general rule from RFC 3501 works in practice.

As far as the APPENDLIMIT draft is concerned, I am wondering if it 
should mention CATENATE explicitly?

---

From: Jamie Nicolson (倪志明) <[email-masked]>
Date: Thu, 18 Dec 2014 09:19:57 -0800

For servers that have a single APPENDLIMIT across all mailboxes, it's
easier (and saves bandwidth) to not have to specify any per-mailbox
APPENDLIMIT in the SELECT response. In this case the APPENDLIMIT specified
in the CAPABILITY should hold across all mailboxes. I think this is the
intent, but the only direct statement about this I see in the document is
for the APPENDLIMIT response code to SELECT in section 3.1: "If this is
missing, the client can always honour the value received as part of
CAPABILITY response." I'd like this to be a little more firm, so that the
server can choose to omit the per-mailbox APPENDLIMIT and know that the
client will respect the common limit.

Perhaps you could state this directly in the introduction to section 3,
something like, "If no per-mailbox APPENDLIMIT is specified for a folder,
but the server did specify a common APPENDLIMIT in the CAPABILITY response,
then the common APPENDLIMIT applies to that folder."

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Dec 2014 17:25:20 +0000

On 18/12/2014 17:19, Jamie Nicolson (倪志明) wrote:
> APPENDLIMIT in the SELECT response. In this case the APPENDLIMIT 
> specified in the CAPABILITY should hold across all mailboxes. I think 
> this is the intent, but the only direct statement about this I see in 
> the document is for the APPENDLIMIT response code to SELECT in section 
> 3.1: "If this is missing, the client can always honour the value 
> received as part of CAPABILITY response." I'd like this to be a little 
> more firm, so that the server can choose to omit the per-mailbox 
> APPENDLIMIT and know that the client will respect the common limit.
>
> Perhaps you could state this directly in the introduction to section 
> 3, something like, "If no per-mailbox APPENDLIMIT is specified for a 
> folder, but the server did specify a common APPENDLIMIT in the 
> CAPABILITY response, then the common APPENDLIMIT applies to that folder."
+1.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 18 Dec 2014 17:31:30 +0000

5530's codes are sent by many, many deployed servers. If a  significant number of clients have a  problem with unknown codes, we would have heard about it by now.

Arnt

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 18 Dec 2014 17:33:11 +0000

Thanks for your comments.

I will update the review comments in the next version.

Regards,
Jay
From: Alexey Melnikov [mailto:[email-masked]]
Sent: Thursday, December 18, 2014 7:35 AM
To: Jayantheesh S B; 'Stuart Brandt'; [email-masked]'
Subject: Re: [imapext] [IMAP] APPEND Command Usage

Hi All,

Changes in this version:

3.2 LIST response

Note that a server implementing this extension, is syntactically compatible with RFC 5819, however support for RFC 5258 or RFC 5819 is not required when implementing this extension.

Please change "RETURN (STATUS(APPENDLIMIT))" to ""RETURN (STATUS (APPENDLIMIT))", as spaces are significant.

Regards,

Jay

-----Original Message-----

Cc: [email-masked]<mailto:[email-masked]>'

Inline comments

Hi Stuart,

Inline comments

Hi Stuart,

line

of:

C: t1 LIST "" "%"

S: * LIST (\Marked \Drafts \HasNoChildren \APPENDLIMIT=257890) "/"

MyDrafts

pretty involved.

compatible:

S: * LIST () "."  "INBOX"

is optional.

Makes complete sense.

But otherwise I am Ok with being able to return this information in

LIST.

imapext mailing list

[email-masked]<mailto:[email-masked]>

---

From: Michael M Slusarz <[email-masked]>
Date: Thu, 18 Dec 2014 12:22:46 -0700

Quoting Alexey Melnikov <[email-masked]>:

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

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.

>> 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  
>> reasons, that's fine.  But seems to be a policy decision rather  
>> than a technical explanation.)

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.

michael

---

From: Stuart Brandt <[email-masked]>
Date: Thu, 18 Dec 2014 14:49:52 -0500

Inline

On 12/18/14 2:22 PM, Michael M Slusarz wrote:
>>> 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.
>>> reasons, that's fine.  But seems to be a policy decision rather than
>>> a technical explanation.)
>  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.

---

From: Michael M Slusarz <[email-masked]>
Date: Thu, 18 Dec 2014 13:02:21 -0700

Quoting Stuart Brandt <[email-masked]>:

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

I believe this references calculation of data like unseen and total  
message counts, where you potentially need to parse the mail store to  
determine the information.  APPENDLIMIT will almost certainly be a  
static configuration value that doesn't depend on the actual mailbox  
contents so performance concerns should be negligible.

LIST-STATUS suffers from the same concerns as the 3501 text: backend  
status calculations do not magically get any faster piped through  
LIST-STATUS rather than a STATUS.  LIST-STATUS brings advantages in  
that you can get status information from a list of mailboxes, or from  
a list of mailboxes that you do not yet know, and you save on having  
to deal with the pipelining of multiple mailboxes yourself which  
potentially allows a server to optimize the lookups, but it isn't any  
faster in returning the results from a single mailbox as far as I know.

michael

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 18 Dec 2014 20:26:31 +0000

Hi Michael,

> On 18 Dec 2014, at 19:22, Michael M Slusarz <[email-masked]> 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.
> 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.)
> 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.