Subject: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-quota-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Mon, 18 Oct 2021 18:53:22 -0700

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-quota-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-quota/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

The description of the QUOTA response in §4.2.1 only says that the
response can occur due to GETQUOTA and GETQUOTAROOT, but it is also
described as a possible result of SETQUOTA, in §4.1.3.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Oct 2021 14:22:44 +0100

Hi Ben,

Thank you for your detailed review.

> DISCUSS:
Fair enough. Fixed.
Yes.
> the ABNF and not here as well.
I will come back to you on this.
> SETQUOTA") or something like that?)
Coincidentally I've noticed this as well. This is trying to say that the 
client should ignore resource types that it doesn't recognize from 
QUOTA=RES-* capabilities. I will attempt to reword this.
> not explicitly listed, are removed", which might be worth a specific

I think only specified resource limits are reset. Having said that, I 
haven't implemented multiple resource limits per single quota root, so I 
am not sure what is the best behaviour here.

> adminstrative resources associated with the comp.mail.mime quota root.
Yes, sound like a good idea.
> about it, but if not, it might also be worth calling out.
Empty string ("") and missing value are not the same in this context.
> alternative phrasings to suggest, so this may just be a non-actionable
The WG decided that it is better be explicit about this than having a 
gotcha.
> for GETQUOTAROOT -- doesn't that just degenerate to "no rights are
This basically depends on the resource type. For example, in order to 
enforce/calculate "MAILBOX" quota one doesn't need "r" access to open 
any of mailboxes covered by a quota root. Should I make this clearer?
> The <resource-names> construction appears to be defined but not used.
Good point. Deleted.
> I don't see them in RFC 9051.
You are right. This is cut & paste error.
> when a user runs SETQUOTA for a quota root shared with other users?
Possibly. Can you suggest some text?
> QUOTA extension to [IMAP, RFC 3051/9051]" that permits ..."?
Yes, thank you.
> end of each "C:" or "S:" line, which is a little hard to get to from the

Yes.

This is pretty much the same text in every IMAP related RFC... Can you 
recommend how to express this better?

> Does the "also" refer to "in addition to the QUOTA capability"?
Yes.
> "SHOULD advise the client of such inherent limits".
Fixed.
> Also "The DELETED-STORAGE" in the following paragraph, twice.
Fixed, thanks.
> "the DELETED-STORAGE" (and similarly for §5.2).

Fixed.

Best Regards,

Alexey

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 21 Oct 2021 18:26:04 -0700

Hi Alexey,

> > described as a possible result of SETQUOTA, in §4.1.3.

Indeed, and cleared on the -08.

> I will come back to you on this.

Ok.

> QUOTA=RES-* capabilities. I will attempt to reword this.

Ah, that makes sense.  Maybe something about clients typically ignoring any
resource types in the GETQUOTA response that were not indicated in the
CAPABILITY response?

> am not sure what is the best behaviour here.

I am not sure, either :)
But it seems better to pick one than to make people guess on their own.

> Empty string ("") and missing value are not the same in this context.

Okay, thanks for confirming.

> The WG decided that it is better be explicit about this than having a 

Sure -- my comment was more along the lines of what John said about using a
phrasing that is accessible to most readers.

> any of mailboxes covered by a quota root. Should I make this clearer?

Yes, please; maybe something about "which permissions are needed in order
to perform GETQUOTAROOT depends on the resource being requested.  For
example, a quota on number of messages might require read permissions on
the mailbox in question, since the quota involved would reveal information
about the number of messages in the mailbox."  (If that's even true, of
course...I didn't put too much thought into the actual example, just the
framing of it.)

> Possibly. Can you suggest some text?

% As for any resource shared across users, a user that can consume or
% render unusable the resource can affect the resources available to the
% other users; this might occur, for example, by a user with permission to
% run SETQUOTA setting an artificially small value.

> recommend how to express this better?

Well, I would not want to introduce divergence from the main corpus of IMAP
work just for this one document.  Maybe something like "and line breaks
other than at the end of the C:- and S:-prefixed lines are not part of the
protocol unless specifically mentioned", though that's admittedly not
great.

Thanks,

Ben

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 22 Oct 2021 14:00:22 +0100

Hi Ben,

> resource types in the GETQUOTA response that were not indicated in the

On a second thought, talking about client here is a bit pointless. They 
can only deal with resource types they know about anyway. So I replaced 
the sentence with:

             Note that the server is not required to support any 
specific resource type

             (as advertised in the CAPABILITY response, i.e. all 
capability items with

             the "QUOTA=RES-" prefix) for any particular quota root.

> But it seems better to pick one than to make people guess on their own.
Ok, I made it explicit.

> course...I didn't put too much thought into the actual example, just the
I used extended version of your text, thank you.
> protocol unless specifically mentioned", though that's admittedly not

So actually the definition of "line" comes from IMAP (RFC 3501/9051) and 
it includes the terminating CRLF. So I improved the definition a little 
bit, but in a different way.

Hopefully I will post -09 later today.

Best Regards,

Alexey