Subject: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension

From: Naren <[email-masked]>
Date: Mon, 20 Jul 2015 18:29:07 -0400

Hello Working Group,

We have published the first draft for
*draft-ietf-imapapnd-appendlimit-extension.*

Please review the draft and drop your comments.

http://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

-- 
Thanks & Regards
-Naren

---

From: Jamie Nicolson <[email-masked]>
Date: Thu, 23 Jul 2015 10:41:52 -0700

Thanks Jay. A few comments.

Section 3.2: This section seems to imply that the extended list syntax for
STATUS APPENDLIMIT must be supported by any server that advertises the
APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and
LIST-STATUS. I think we should clarify that this section will only apply to
servers that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT.
Supporting the new syntax might be non-trivial, and will be wasted work for
servers that don't support per-mailbox limits (see below).

Mailbox-specific appendlimits: Our server will have a single appendlimit
for all mailboxes, so we don't need the per-mailbox limits. However, the
only way for a client to determine this will be to issue a SELECT or
extended LIST on the target mailbox and note the absence of a per-mailbox
appendlimit response. SELECT is expensive, and not all servers support
extended list. Is there a way we could annotate the APPENDLIMIT capability
to indicate that per-mailbox limits are not supported, so clients needn't
bother querying them? It could be something as simple as adding a magic
atom-char like '+' or '!':

APPENDLIMIT=25000000!   ; system-wide append limit is 25000000, applies to
all mailboxes

On Mon, Jul 20, 2015 at 3:29 PM, Naren <[email-masked]>
wrote:

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

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 23 Jul 2015 19:05:09 +0000

HI Jamie,

Thanks for reviewing the document again.

Please find my response.

Regards,
Jay
---------- Forwarded message ----------
From: Jamie Nicolson <[email-masked]<mailto:[email-masked]>>
Date: Thu, Jul 23, 2015 at 1:41 PM
Subject: Re: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension
To: Naren <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jayantheesh S.B"
<[email-masked]<mailto:[email-masked]>>

Section 3.2: This section seems to imply that the extended list syntax for STATUS APPENDLIMIT must be supported by any server that advertises the APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and LIST-STATUS. I think we should clarify that this section will only apply to servers that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the new syntax might be non-trivial, and will be wasted work for servers that don't support per-mailbox limits (see below).

[Jay] When server does not support the mailbox specific limit, then capability response is enough for the client to know the limit.

SELECT and LIST response is needed only when server supports mailbox specific limit. It is not mandatory for the server to implement LIST STATUS, LIST-EXTENDED to get the mailbox specific limit.

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

Mailbox-specific appendlimits: Our server will have a single appendlimit for all mailboxes, so we don't need the per-mailbox limits. However, the only way for a client to determine this will be to issue a SELECT or extended LIST on the target mailbox and note the absence of a per-mailbox appendlimit response. SELECT is expensive, and not all servers support extended list. Is there a way we could annotate the APPENDLIMIT capability to indicate that per-mailbox limits are not supported, so clients needn't bother querying them? It could be something as simple as adding a magic atom-char like '+' or
'!':

APPENDLIMIT=25000000!   ; system-wide append limit is 25000000,
applies to all mailboxes

[Jay] In Section 2, its mentioned that, when an IMAP server does not support the mailbox specific limit (Google server case), then as part of capability response, supported limit value can be published. But, if the server supports mailbox specific limit, then APPENDLIMIT value will be omitted as part of Capability response. It will send only APPENDLIMIT string in the capability, then client can always get the mailbox specific limit as part of SELECT, LIST response.

“The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific
limit set by the server.  New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.

The following example demonstrates, its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed”

Kindly let us know, if this answers your question. Please revert back for any clarification.

Regards,
Jay

On Mon, Jul 20, 2015 at 3:29 PM, Naren <[email-masked]<mailto:[email-masked]>> wrote:
>
> Hello Working Group,
>
> We have published the first draft for draft-ietf-imapapnd-appendlimit-extension.
>
> [email-masked]<mailto:[email-masked]>

---

From: Jamie Nicolson <[email-masked]>
Date: Thu, 23 Jul 2015 12:46:26 -0700

On Thu, Jul 23, 2015 at 12:05 PM, Jayantheesh S B <[email-masked]>
wrote:

> From: Jamie Nicolson <[email-masked]>
> Subject: Re: [imapext] Review for first draft for
> draft-ietf-imapapnd-appendlimit-extension
> To: Naren <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Jayantheesh S.B"
> <[email-masked]>
>
>
>   [Jay] When server does not support the mailbox specific limit, then
> capability response is enough for the client to know the limit.
>
> SELECT and LIST response is needed *only* when server supports mailbox
> specific limit. It is not mandatory for the server to implement LIST
> STATUS, LIST-EXTENDED to get the mailbox specific limit.
>

How does the client know whether there is a mailbox-specific limit unless
it issues a SELECT or LIST command? If a limit is specified in the
CAPABILITY, does that mean there are no mailbox-specific limits? I thought
it was possible to have both.

> when implementing this extension.”

Even if they don't have to support all of LIST-EXTENDED and LIST-STATUS,
doesn't this require the server to change their parser to accept this new
syntax, and their LIST implementation to return it? That is a non-trivial
amount of work.

>   [Jay] In Section 2, its mentioned that, when an IMAP server does not
> support the mailbox specific limit (Google server case), then as part of
> capability response, supported limit value can be published. But, if the
> server supports mailbox specific limit, then APPENDLIMIT *value* will be
> omitted as part of Capability response. It will send only APPENDLIMIT
> string in the capability, then client can always get the mailbox specific
> limit as part of SELECT, LIST response.
>

The spec says that the server can return a limit in the capability AND also
have per-mailbox limits:

The
> advertised upload limit is common across the mailboxes, but client
> can still issue SELECT/EXAMINE or LIST command to get the mailbox
> specific upload limit set by the IMAP server.  In this case,
> APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
> takes precedence over the value returned as part of CAPABILITY
> response
>
>
So a client that sees a limit in the capability still does not know whether
there are per-mailbox limits, and must issue a SELECT or LIST to find out.

> *If APPENDLIMIT value is omitted in CAPABILITY response, then client*
> *SHOULD issue SELECT/EXAMINE or LIST** command to get the mailbox
> specific*
> *limit set by the server.*  New response code APPENDLIMIT is added to get
> draft-ietf-imapapnd-appendlimit-extension.
> >

---

From: Jayantheesh S B <[email-masked]>
Date: Thu, 23 Jul 2015 20:41:56 +0000

Hi Jamie,

How does the client know whether there is a mailbox-specific limit unless it issues a SELECT or LIST command? If a limit is specified in the CAPABILITY, does that mean there are no mailbox-specific limits? I thought it was possible to have both.

Let’s keep it simple.
We cannot have both.

When APPENDLIMIT value is specified in the capability response, that indicates that server does not support mailbox specific limit.
It’s one for everyone.
E.g.
CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890

When APPENDLIMIT is omitted in capability response, that means server is having mailbox specific append limits.
E.g.
CAPABILITY IMAP4rev1 ID APPENDLIMIT
In this case client can get it by LIST or SELECT response.

Even if they don't have to support all of LIST-EXTENDED and LIST-STATUS, doesn't this require the server to change their parser to accept this new syntax, and their LIST implementation to return it? That is a non-trivial amount of work.

Yes, If server is supporting mailbox-specific append limit then they have to have append limit value in LIST or SELECT response.

We can edit the spec, to make it more clear in the next revision.

Regards,
Jay

From: Jamie Nicolson [mailto:[email-masked]]
Sent: Thursday, July 23, 2015 3:46 PM
To: Jayantheesh S B
Cc: Jayantheesh S.B ([email-masked]); [email-masked]; [email-masked]
Subject: Re: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension

On Thu, Jul 23, 2015 at 12:05 PM, Jayantheesh S B <[email-masked]<mailto:[email-masked]>> wrote:
HI Jamie,

Please find my response.

Regards,
Jay
---------- Forwarded message ----------
From: Jamie Nicolson <[email-masked]<mailto:[email-masked]>>
Date: Thu, Jul 23, 2015 at 1:41 PM
Subject: Re: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension
To: Naren <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Jayantheesh S.B"

How does the client know whether there is a mailbox-specific limit unless it issues a SELECT or LIST command? If a limit is specified in the CAPABILITY, does that mean there are no mailbox-specific limits? I thought it was possible to have both.

Even if they don't have to support all of LIST-EXTENDED and LIST-STATUS, doesn't this require the server to change their parser to accept this new syntax, and their LIST implementation to return it? That is a non-trivial amount of work.

The spec says that the server can return a limit in the capability AND also have per-mailbox limits:

The

response

So a client that sees a limit in the capability still does not know whether there are per-mailbox limits, and must issue a SELECT or LIST to find out.

C: t1 CAPABILITY

C: t1 CAPABILITY

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [UIDVALIDITY 3857529045<tel:3857529045>] UIDs valid

Regards,
Jay

---

From: Jamie Nicolson <[email-masked]>
Date: Thu, 23 Jul 2015 17:02:29 -0700

On Thu, Jul 23, 2015 at 1:41 PM, Jayantheesh S B <[email-masked]>
wrote:

> When APPENDLIMIT value is specified in the capability response, that
> indicates that server does not support mailbox specific limit.
>
> It’s one for everyone.
>
> E.g.
>

OK, so a server implementor that wants system-wide mailbox limits can just
specify APPENDLIMIT=XXX in the CAPABILITY and then ignore the parts of the
spec that discuss per-mailbox limits? Sounds good to me.

> Yes, If server is supporting mailbox-specific append limit then they have
> to have append limit value in LIST or SELECT response.
>

You said "LIST or SELECT". Does that mean they don't need to support both?
I propose the server only needs to support the append limit in LIST if it
supports LIST-EXTENDED and LIST-STATUS. That way a client, having seen the
server's capabilities, can decide whether to get the per-mailbox append
limit from LIST (which is presumably more efficient) or, if the server does
not have these capabilities, by SELECT (probably slower).

> *From:* Jamie Nicolson [mailto:[email-masked]]
> *Sent:* Thursday, July 23, 2015 3:46 PM
> *To:* Jayantheesh S B
> *Cc:* Jayantheesh S.B ([email-masked]);
> [email-masked]; [email-masked]
>
> *Subject:* Re: [imapext] Review for first draft for
> atom-char like '+' or
> So a client that sees a limit in the capability still does not know
> whether there are per-mailbox limits, and must issue a SELECT or LIST to
> find out.
>
>
>
>
>
> > http://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extens
>
> > ion/
>
> >
>
> > --
>
> > Thanks & Regards
>
> > -Naren
>
> >
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jul 2015 12:28:58 +0200

Hi Jamie,

> On 23 Jul 2015, at 19:41, Jamie Nicolson <[email-masked]> wrote:
> 
> Section 3.2: This section seems to imply that the extended list syntax for STATUS APPENDLIMIT must be supported by any server that advertises the APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and LIST-STATUS.

That is my preference.

> I think we should clarify that this section will only apply to servers that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the new syntax might be non-trivial, and will be wasted work for servers that don't support per-mailbox limits (see below).

Can you elaborate on why handling one extra STATUS attribute name is complicated for you?

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jul 2015 12:45:57 +0200

Hi,

On 24 Jul 2015, at 02:02, Jamie Nicolson <[email-masked]> wrote:

>> On Thu, Jul 23, 2015 at 1:41 PM, Jayantheesh S B <[email-masked]> wrote:
>> Hi Jamie,
>> 
>>  
>> 
> OK, so a server implementor that wants system-wide mailbox limits can just specify APPENDLIMIT=XXX in the CAPABILITY and then ignore the parts of the spec that discuss per-mailbox limits? Sounds good to me.

From a server implementor's point of view this is easier to implement.

From a client implementor's point of view, having a new STATUS item which is only available some of the time adds asymmetry to the protocol, which makes it slightly more difficult to implement, especially in presence of multiple extensions.

---

From: Jamie Nicolson <[email-masked]>
Date: Fri, 24 Jul 2015 09:15:28 -0700

On Fri, Jul 24, 2015 at 3:28 AM, Alexey Melnikov <[email-masked]>
wrote:

> > Section 3.2: This section seems to imply that the extended list syntax
> for STATUS APPENDLIMIT must be supported by any server that advertises the
> LIST-STATUS.
> > I think we should clarify that this section will only apply to servers
> that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the
> new syntax might be non-trivial, and will be wasted work for servers that
> don't support per-mailbox limits (see below).
>

It's only one extra STATUS attribute if the server already supports
LIST-EXTENDED and LIST-STATUS, and in that case I agree, the server should
add support for the APPENDLIMIT attribute. I was talking about a
hypothetical server that doesn't support LIST-EXTENDED at all (like Gmail
until recently). In order to conform to this APPENDLIMIT spec, if they
wanted per-mailbox limits they would have to add support for a " RETURN
(STATUS (APPENDLIMIT))" at the end of their LIST command, right? Maybe not
a lot of work, but it seems unnecessary, and odd to support a syntax that
is similar to LIST-EXTENDED without actually supporting LIST-EXTENDED.

This doesn't actually matter to our implementation, because we won't
support per-mailbox limits.

---

From: Jamie Nicolson <[email-masked]>
Date: Fri, 24 Jul 2015 09:20:15 -0700

On Fri, Jul 24, 2015 at 3:45 AM, Alexey Melnikov <[email-masked]>
wrote:

> From a client implementor's point of view, having a new STATUS item which
> is only available some of the time adds asymmetry to the protocol, which
> makes it slightly more difficult to implement, especially in presence of
> multiple extensions.
>
>
You're saying it's burdensome on the client to implement a fallback to
SELECT in order to determine per-mailbox limits if the server doesn't
include it in the LIST response? OK, I can see that, although the client
already has to deal with whether or not the server supports LIST-EXTENDED,
LIST-STATUS, APPENDLIMIT, etc.

---

From: Michael M Slusarz <[email-masked]>
Date: Fri, 24 Jul 2015 15:05:42 -0600

>> http://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

We had previously discussed the interactions between APPENDLIMIT and  
other extensions that may limit the actual data size a particular  
mailbox allows.

For example, ACLs might prohibit appending to a certain mailbox (in  
which case the actual APPENDLIMIT for that mailbox is 0).  Or, due to  
QUOTA status for the current mailbox, the actual APPENDLIMIT for a  
mailbox might be a value less than what the globally advertised  
APPENDLIMIT is.

While it would be nice if APPENDLIMIT was an actual, up-to-the second  
accurate count of the maximum size of message octets that can be added  
to the mailbox, I agree that APPENDLIMIT is better served as an upper  
limit rather than an exact value, which may be expensive to calculate.

With that being said, I think there does need to be discussion about  
the interaction between APPENDLIMIT and ACL/QUOTA (and other future  
extensions).  Mainly that just because message data to be appended by  
a client is less than APPENDLIMIT does NOT mean that the data might  
not still be rejected on sizing grounds.

I would also like to see better reference to Alexey's LITERAL+ update.  
  Or, at a minimum, that APPENDLIMIT does NOT fully solve the issue  
with non-synchronizing literal usage if APPENDLIMIT is not a precise  
value of maximum append size.  i.e. on a server that supports  
APPENDLIMIT + LITERAL+, a client SHOULD continue to heed the advice in  
RFC 4549 [4.2.2.3] and not send APPEND data in a non-synchronizing  
literal for messages that are less than APPENDLIMIT in size.

For APPENDLIMIT + LITERAL+ servers, APPENDLIMIT will prevent an  
unnecessary round-trip if message data is above APPENDLIMIT.  But  
absent LITERAL- support, APPENDLIMIT does not prevent the need for a  
necessary additional round-trip when APPENDing a message.

MULTIAPPENDs should probably also be directly referenced in the same  
discussion.

At a minimum, the statement "Client can avoid use of LITERAL+, when  
maximum upload size supported by the IMAP server is unknown." in  
section 4 is probably better handled by a reference to RFC 4549.   
Although my preference would be to have some discussion of the above  
information in that section instead.

michael