Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension

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 protected]]
Sent: Thursday, July 23, 2015 3:46 PM
To: Jayantheesh S B
Cc: Jayantheesh S.B ([email protected]); [email protected]; [email protected]
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 protected]<mailto:[email protected]>> wrote:
HI Jamie,

Thanks for reviewing the document again.

Please find my response.

Regards,
Jay
---------- Forwarded message ----------
From: Jamie Nicolson <[email protected]<mailto:[email protected]>>
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 protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Jayantheesh S.B"
<[email protected]<mailto:[email protected]>>


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

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



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


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.




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


“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<tel: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 protected]<mailto:[email protected]>> wrote:
>
> 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-extens
> ion/
>
> --
> Thanks & Regards
> -Naren
>
> _______________________________________________
> imapext mailing list
> [email protected]<mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/imapext
>

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