IMAP QUOTA Extension
draft-ietf-extra-quota-10

Thank you for the work on this document. Many thanks to Todd Herr for the ART ART review: https://mailarchive.ietf.org/arch/msg/art/i8noFdN8QVycrT1bAgOktoAGsaM/

Francesca

Thanks for the very readable document. 

One minor note, while “The WG chose not to address this…” is both helpful while reviewing, and completely clear to any IETFer with a meeting or two under their belt, it might not be clear to an outsider. Please at minimum expand “WG”, and also consider writing it in a way that doesn’t assume knowledge of our process, as in the more stilted and less-specific :-( “it was chosen not to address this…”

** Section 8.  Should the prohibition on revealing quota information be a bit stronger?
OLD
In
   particular, no quota information should be disclosed to anonymous
   users.

NEW
In particular, quota information SHOULD be disclosed only to authenticated and authorized users

** Section 8.  Should it be noted that computing remaining resources might incur a load on the server.  Implementers might want to rate limit or return less precise computations when under higher load?

** Typos
Section 3.2.  Typo. s/arbitary/arbitrary/

Section 3.2.  Typo. s/dependant/dependant/

I support Benjamin Kaduk's Discuss, but other than that don't have anything useful to add....

I marked the discrepancies about the QUOTA response in section 4.2.1 and section 4.1.3. Ben already have a Discuss on it. I am supporting that discuss.

Moreover, I think section 6 needs to explain the  Operations\Rights for GETQUOTAROOT. There are two * for r and Non. Not sure why and how to interpret them.

Thank you for the work put into this document. 

Please find below COMMENT points, which are mere nits.

Special thanks to Bron Gondwana for his shepherd's write-up  about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric


-- Section 3.2 --

For a reader non familiar with the domain, this section is quite cryptic until the "implementation notes". Giving some early examples would be a plus.

-- Section 4.1.1 --
In the same vein as the comment above, a non-familiar reader (like myself :-O ) will wonder how the client knows to check the quota for "!partition/sda4". Suggest to explain the example a little more.

Thank you for addressing my Discuss point!
The COMMENT section from my ballot on the -07 is preserved unchanged below
for convenience, even though some parts of it are resolved by the -08.

Section 2

   This document also reserves all other capabilities starting with
   "QUOTA=" prefix for future IETF stream standard track, informational
   or experimental extensions to this document.

If we're allowing all three of those that doesn't leave much else.  It
might be simpler to just say "IETF stream extensions to this document".

Section 3.1.1

   The resource name is an atom, as defined in IMAP4rev1 [RFC3501].
   These MUST be registered with IANA.  Implementation specific
   resources begin with "V-" .

Are V- prefixes going to work out any better here than X- prefixes did
for header fields (viz BCP 178)?

Also, it's a little surprising that the "should be followed by a domain
name under vendor's control" guidance appears only as a comment within
the ABNF and not here as well.

Section 4.1.1

   The client can try using any of the resource types returned in
   CAPABILITY response (i.e. all capability items with "QUOTA=RES-"

This is the section about GETQUOTA, which only takes a quota root
argument, not a particular resource type(s).  Does it really make sense
to talk about "using any of the resource types" here?  (nit: if it does,
we haven't really covered what a client might do that would qualify as
"using" the resource types; is it worth putting in an "(e.g., for
SETQUOTA") or something like that?)

Section 4.1.3

   The SETQUOTA command takes the name of a mailbox quota root and a
   list of resource limits.  The resource limits for the named quota
   root are changed to be the specified limits.  Any previous resource
   limits for the named quota root are discarded.

That sounds like "any other quotas set on that quota root for resources
not explicitly listed, are removed", which might be worth a specific
note.

Section 4.2.2

   Example:

   S: * QUOTAROOT INBOX ""

   S: * QUOTAROOT comp.mail.mime

I wonder if it's worth some commentary about there being no
adminstrative resources associated with the comp.mail.mime quota root.
I also saw that we used the "" quota root in previous examples, but do
not have any commentary about whether it is distinct from an absent
quota root.  Maybe that's a natural part of IMAP and I've just forgotten
about it, but if not, it might also be worth calling out.

Section 4.3.1

   currently selected mailbox.  (The WG chose not to address this
   deficiency due to syntactic limitations of IMAP response codes and
   because such events are likely to be rare.)  This form of the

While I'm happy to see the WG's decision to not act documented, I'm not
sure how much precedent we have for documenting it as a parenthetical
sentence with the phrase "The WG chose".  Unfortunately I don't have any
alternative phrasings to suggest, so this may just be a non-actionable
remark...

Section 6

I'm not sure I understand how "only one of 'r' and 'none'" is required
for GETQUOTAROOT -- doesn't that just degenerate to "no rights are
required"?

Section 7

The <resource-names> construction appears to be defined but not used.

Where are <status-att-deleted> and <status-att-deleted-storage>
previously defined that we need to use the "=/" style definition?
I don't see them in RFC 9051.

Section 8

Is it worth saying anything about the potential for deleterious results
when a user runs SETQUOTA for a quota root shared with other users?

Relatedly, giving quota information to a user that shares a quota root
with other users (which AFAICT is something that must be known out of
band) gives an information channel about how effective a denial of
service via the shared resource is, though this is admittedly unlikely
to be of great practical impact.

Section 12

   When compared with RFC 2087, this document defines two more commonly
   used resource type, adds optional OVERQUOTA response code and defines
   two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that
   must be implemented.  [...]

Can you clarify the "must be implemented"?  I thought they were
mandatory only if QUOTA=RES-MESSAGE and QUOTA=RES-STORAGE were
advertised, respectively.

NITS

Abstract

   The QUOTA extension of the Internet Message Access Protocol (RFC
   3501/RFC 9051) permits administrative limits on resource usage

The reference is a bit ambiguous as to whether it means (core) IMAP or
the QUOTA extension.  Maybe something like "this document defines a
QUOTA extension to [IMAP, RFC 3051/9051]" that permits ..."?

Section 1

   are not part of the protocol.  Lines without any of these prefixes
   are continuations of the previous line, and no line break is present
   in the protocol unless specifically mentioned.

My understanding is that there is a "line break" in the protocol at the
end of each "C:" or "S:" line, which is a little hard to get to from the
phrasing here.

Section 2

   Any server compliant with this document MUST also return at least one
   capability starting with "QUOTA=RES-" prefix, as described in
   Section 3.1.

Does the "also" refer to "in addition to the QUOTA capability"?

Section 3.2

                                                    A server
   implementation of this memo SHOULD advise the client of such inherent
   limits, by generating QUOTA (Section 4.2.1) responses and SHOULD
   advise the client of which resources are limitable for a particular
   quota root.  [...]

I think this wants another comma before "and SHOULD advise", since "by
generating QUOTA responses" is a parenthetical expression expounding on
"SHOULD advise the client of such inherent limits".

Section 4.1.4

   DELETED status data item requests the server to return the number of
   messages with \Deleted flag set.  DELETED status data item is only

"The DELETED" (both instances).
Also "The DELETED-STORAGE" in the following paragraph, twice.

Section 4.3.1

Do we feel a desire to avoid request/response tag reuse for examples
within the same section?

Section 5.1

   When the server supports this resource type, it MUST also support
   DELETED-STORAGE status data item.

"the DELETED-STORAGE" (and similarly for §5.2).

Section 13.1. , paragraph 1, comment:
>    [ABNF]     Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
>               Syntax Specifications: ABNF", RFC 5234, January 2008,
>               <ftp://ftp.isi.edu/in-notes/rfc5234.txt>.

Please use https://www.rfc-editor.org/info/rfc5234 as the URL.

-------------------------------------------------------------------------------
All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2. , paragraph 8, nit:
-    dependant, it was impossible for a client implementation to determine
-          ^
+    dependent, it was impossible for a client implementation to determine
+          ^

Section 3.2. , paragraph 4, nit:
-    calculate usage, or apply quotas, on arbitary mailboxes or mailbox
+    calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
+                                              +

Section 3.2. , paragraph 5, nit:
-    Not all resources may be limitable or calculatable for all quota
-                                                 --
+    Not all resources may be limitable or calculable for all quota

Section 3.2. , paragraph 5, nit:
-    quota limit in an implementation dependant way, if the granularity of
-                                    ^      ^
+    quota limit in an implementation-dependent way, if the granularity of
+                                    ^      ^

Reference [RFC3501] to RFC3501, which was obsoleted by RFC9051 (this may be on
purpose).

Found non-HTTP URLs in the document:
 * ftp://ftp.isi.edu/in-notes/rfc5234.txt

These URLs in the document can probably be converted to HTTPS:
 * http://www.iana.org/assignments/imap4-capabilities

Hi,

One minor nit, the diagram in example 3 in 4.3.1 is indented beyond example 2.  I presume that this is just a nit, and is not intended to infer any meaning.

Rob