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

[Benjamin Kaduk <[e-mail]>]

Hi Alexey,

On Thu, Oct 21, 2021 at 02:22:44PM +0100, Alexey Melnikov wrote:
> Hi Ben,
> 
> Thank you for your detailed review.
> 
> On 19/10/2021 02:53, Benjamin Kaduk via Datatracker wrote:
> > 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.
> Fair enough. Fixed.

Indeed, and cleared on the -08.

> > ----------------------------------------------------------------------
> > 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".
> Yes.
> > 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.
> I will come back to you on this.

Ok.

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

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?

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

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

> > 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.
> Yes, sound like a good idea.
> > 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.
> Empty string ("") and missing value are not the same in this context.

Okay, thanks for confirming.

> > 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...
> The WG decided that it is better be explicit about this than having a 
> gotcha.

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

> > 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"?
> 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?

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

> > Section 7
> >
> > The <resource-names> construction appears to be defined but not used.
> Good point. Deleted.
> > 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.
> You are right. This is cut & paste error.
> > 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?
> 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.

> > 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 ..."?
> Yes, thank you.
> > 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.
> 
> Yes.
> 
> This is pretty much the same text in every IMAP related RFC... Can you 
> 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

> > 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"?
> Yes.
> > 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".
> Fixed.
> > 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.
> Fixed, thanks.
> > 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).
> 
> Fixed.
> 
> Best Regards,
> 
> Alexey
>