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

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

>  HI Jamie,
>
> Thanks for reviewing the document again.
>
> Please find my response.
>
> Regards,
> Jay
> ---------- Forwarded message ----------
> From: Jamie Nicolson <[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]>
> Cc: "[email protected]" <[email protected]>, "Jayantheesh S.B"
> <[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] 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]>
> 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]
> > https://www.ietf.org/mailman/listinfo/imapext
> >
>
>

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