Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2022-04-04
10 (System) IANA registries were updated to include RFC9208
2022-03-31
10 (System)
Received changes through RFC Editor sync (created alias RFC 9208, changed abstract to 'This document defines a QUOTA extension of the Internet Message Access …
Received changes through RFC Editor sync (created alias RFC 9208, changed abstract to 'This document defines a QUOTA extension of the Internet Message Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol.

This document obsoletes RFC 2087 but attempts to remain backwards compatible whenever possible.', changed pages to 19, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2022-03-31, changed IESG state to RFC Published, created obsoletes relation between draft-ietf-extra-quota and RFC 2087)
2022-03-31
10 (System) RFC published
2022-03-23
10 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9208">AUTH48-DONE</a> from AUTH48
2022-02-24
10 (System) RFC Editor state changed to <a href="https://www.rfc-editor.org/auth48/rfc9208">AUTH48</a>
2022-01-19
10 (System) RFC Editor state changed to RFC-EDITOR from IANA
2021-12-20
10 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2021-12-20
10 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2021-12-20
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-12-17
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-12-17
10 (System) IANA Action state changed to In Progress from Waiting on Authors
2021-12-14
10 (System) RFC Editor state changed to IANA from RFC-EDITOR
2021-12-14
10 (System) RFC Editor state changed to RFC-EDITOR from EDIT
2021-12-09
10 (System) IANA Action state changed to Waiting on Authors from In Progress
2021-12-06
10 (System) RFC Editor state changed to EDIT
2021-12-06
10 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2021-12-06
10 (System) Announcement was received by RFC Editor
2021-12-06
10 (System) IANA Action state changed to In Progress
2021-12-06
10 Amy Vezza Downref to RFC 5257 approved by Last Call for draft-ietf-extra-quota-10
2021-12-06
10 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2021-12-06
10 Amy Vezza IESG has approved the document
2021-12-06
10 Amy Vezza Closed "Approve" ballot
2021-12-06
10 Amy Vezza Ballot approval text was generated
2021-12-03
10 (System) Removed all action holders (IESG state changed)
2021-12-03
10 Murray Kucherawy IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2021-11-18
10 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-11-18
10 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-11-18
10 Alexey Melnikov New version available: draft-ietf-extra-quota-10.txt
2021-11-18
10 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-11-18
10 Alexey Melnikov Uploaded new revision
2021-11-09
09 Murray Kucherawy Discussion of vendor prefixes with the WG is pending.
2021-11-09
09 (System) Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed)
2021-11-09
09 Murray Kucherawy IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation::AD Followup
2021-10-22
09 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-10-22
09 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-10-22
09 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-22
09 Alexey Melnikov New version available: draft-ietf-extra-quota-09.txt
2021-10-22
09 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-10-22
09 Alexey Melnikov Uploaded new revision
2021-10-21
08 Benjamin Kaduk
[Ballot comment]
Thank you for addressing my Discuss point!
The COMMENT section from my ballot on the -07 is preserved unchanged below
for convenience, even …
[Ballot comment]
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).
2021-10-21
08 Benjamin Kaduk [Ballot Position Update] Position for Benjamin Kaduk has been changed to No Objection from Discuss
2021-10-21
08 (System) Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed)
2021-10-21
08 Cindy Morgan IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation
2021-10-21
08 Lars Eggert [Ballot Position Update] Position for Lars Eggert has been changed to No Objection from Discuss
2021-10-21
08 Michelle Cotton IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-10-21
08 John Scudder
[Ballot comment]
Thanks for the very readable document.

One minor note, while “The WG chose not to address this…” is both helpful while reviewing, and …
[Ballot comment]
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…”
2021-10-21
08 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2021-10-21
08 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-10-21
08 Alexey Melnikov New version available: draft-ietf-extra-quota-08.txt
2021-10-21
08 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-10-21
08 Alexey Melnikov Uploaded new revision
2021-10-21
07 Zaheduzzaman Sarker
[Ballot comment]
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 …
[Ballot comment]
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.
2021-10-21
07 Zaheduzzaman Sarker [Ballot Position Update] New position, No Objection, has been recorded for Zaheduzzaman Sarker
2021-10-21
07 Francesca Palombini [Ballot comment]
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
2021-10-21
07 Francesca Palombini Ballot comment text updated for Francesca Palombini
2021-10-20
07 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2021-10-20
07 Warren Kumari [Ballot comment]
I support Benjamin Kaduk's Discuss, but other than that don't have anything useful to add....
2021-10-20
07 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2021-10-20
07 Francesca Palombini
[Ballot comment]
Thank you for the work on this document.

Many thanks to Todd Herr for the ART ART review.

I only have two comments; …
[Ballot comment]
Thank you for the work on this document.

Many thanks to Todd Herr for the ART ART review.

I only have two comments; although not worth a DISCUSS (because in the examples), I'd really appreciate an answer.

Francesca

1. -----

      S: S0001 OK Rounded quota

FP: This is not defined - should it be "OK setquota completed" ?

2. -----

      C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)

      S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)

FP: I think the above should be MESSAGE rather than MESSAGES.
2021-10-20
07 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2021-10-20
07 Robert Wilton
[Ballot comment]
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 …
[Ballot comment]
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
2021-10-20
07 Robert Wilton [Ballot Position Update] New position, No Objection, has been recorded for Robert Wilton
2021-10-18
07 Benjamin Kaduk
[Ballot 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 …
[Ballot 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.
2021-10-18
07 Benjamin Kaduk
[Ballot comment]
Section 2

  This document also reserves all other capabilities starting with
  "QUOTA=" prefix for future IETF stream standard track, informational
  …
[Ballot 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).
2021-10-18
07 Benjamin Kaduk [Ballot Position Update] New position, Discuss, has been recorded for Benjamin Kaduk
2021-10-18
07 Roman Danyliw
[Ballot comment]
** Section 8.  Should the prohibition on revealing quota information be a bit stronger?
OLD
In
  particular, no quota information should be …
[Ballot comment]
** 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/
2021-10-18
07 Roman Danyliw [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw
2021-10-15
07 (System) IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed
2021-10-15
07 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-quota-07. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-quota-07. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

https://www.iana.org/assignments/imap-capabilities/

the following actions will be taken:

IANA will update the current reference of the QUOTA extension to point to [ RFC-to-be ].

IANA will add a single new registration to the Capabilities Registry as follows:

Capability Name: QUOTASET
Reference: [ RFC-to-be ]

IANA will add a note to the registry indicating that the prefix "QUOTA=RES-" is reserved with a reference to [ RFC-to-be; Section 9.2 ].

IANA will also add a note to the registry which reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to [ RFC-to-be ].

Second, a new registry is to be created called IMAP Quota Resource Types. The new registry will be located on the Internet Message Access Protocol (IMAP) Capabilities Registry page located at:

https://www.iana.org/assignments/imap-capabilities/

The registration policy for the new registry is Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Name of the quota resource type: STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root.
Extra required IMAP commands/responses: DELETED-STORAGE STATUS request data item and response data item
Extra optional IMAP commands/responses: N/A
Reference: [ RFC-to-be; Section 5.1]

Name of the quota resource type: MESSAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The number of messages stored within the mailboxes governed by the quota root.
Extra required IMAP commands/responses: DELETED STATUS request data item and response data item
Extra optional IMAP commands/responses: N/A
Reference: Section [ RFC-to-be; Section 5.2]

Name of the quota resource type: MAILBOX
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The number of mailboxes governed by the quota root.
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: [ RFC-to-be; Section 5.3 ]

Name of the quota resource type: ANNOTATION-STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: Section [ RFC-to-be; Section 5.4 ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-10-11
07 Lars Eggert
[Ballot discuss]
DOWNREF [RFC5257] from this Proposed Standard to Experimental RFC5257, which the IESG needs to approve on the telechat. (No action …
[Ballot discuss]
DOWNREF [RFC5257] from this Proposed Standard to Experimental RFC5257, which the IESG needs to approve on the telechat. (No action for the authors.) I'll note that the ballot write-up suggests a status-change for RFC5257, in case an ART AD feels inclined to take this on.
2021-10-11
07 Lars Eggert
[Ballot comment]
Section 13.1. , paragraph 1, comment:
>    [ABNF]    Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
>      …
[Ballot comment]
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
2021-10-11
07 Lars Eggert [Ballot Position Update] New position, Discuss, has been recorded for Lars Eggert
2021-10-11
07 Éric Vyncke
[Ballot comment]
Thank you for the work put into this document.

Please find below COMMENT points, which are mere nits.

Special thanks to Bron Gondwana …
[Ballot comment]
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.
2021-10-11
07 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2021-10-07
07 Cindy Morgan Placed on agenda for telechat - 2021-10-21
2021-10-07
07 Murray Kucherawy [Ballot comment]
Thank you to Todd Herr for his ARTART review.
2021-10-07
07 Murray Kucherawy Ballot comment text updated for Murray Kucherawy
2021-10-07
07 Murray Kucherawy Ballot has been issued
2021-10-07
07 Murray Kucherawy [Ballot Position Update] New position, Yes, has been recorded for Murray Kucherawy
2021-10-07
07 Murray Kucherawy Created "Approve" ballot
2021-10-07
07 Murray Kucherawy IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2021-10-07
07 Murray Kucherawy Ballot writeup was changed
2021-10-07
07 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead from In Last Call
2021-10-04
07 Amy Vezza
The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, …
The following Last Call announcement was sent out (ends 2021-10-18):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-extra-quota-07.txt> (IMAP QUOTA Extension) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP QUOTA
Extension'
  <draft-ietf-extra-quota-07.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-10-18. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The QUOTA extension of the Internet Message Access Protocol (RFC
  3501
/RFC 9051) permits administrative limits on resource usage
  (quotas) to be manipulated through the IMAP protocol.

  This document obsoletes RFC 2087, but attempts to remain backwards
  compatible whenever possible.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-quota/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5257: Internet Message Access Protocol - ANNOTATE Extension (Experimental - Internet Engineering Task Force (IETF))



2021-10-04
07 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2021-10-04
07 Amy Vezza Last call announcement was generated
2021-10-04
07 Murray Kucherawy Last call was requested
2021-10-04
07 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-10-04
07 Murray Kucherawy IESG state changed to Last Call Requested from Waiting for AD Go-Ahead::AD Followup
2021-09-24
07 (System) Removed all action holders (IESG state changed)
2021-09-24
07 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-09-24
07 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2021-09-24
07 Alexey Melnikov New version available: draft-ietf-extra-quota-07.txt
2021-09-24
07 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-09-24
07 Alexey Melnikov Uploaded new revision
2021-09-22
06 Murray Kucherawy Changed action holders to Alexey Melnikov
2021-09-22
06 (System) Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed)
2021-09-22
06 Murray Kucherawy IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for Writeup
2021-09-13
06 Linda Dunbar Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Linda Dunbar. Sent review to list.
2021-09-10
06 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2021-09-10
06 (System) IESG state changed to Waiting for Writeup from In Last Call
2021-09-09
06 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2021-09-09
06 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-quota-06. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-extra-quota-06. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Functions Operator understands that, upon approval of this document, there are two actions which we must complete.

First, in the Internet Message Access Protocol (IMAP) Capabilities Registry located at:

https://www.iana.org/assignments/imap-capabilities/

the following actions will be taken:

IANA will update the current reference of the QUOTA extension to point to [ RFC-to-be ].

IANA will add a single new registration to the Capabilities Registry as follows:

Capability Name: QUOTASET
Reference: [ RFC-to-be ]

IANA will add a note to the registry indicating that the prefix "QUOTA=RES-" is reserved with a reference to [ RFC-to-be; Section 9.2 ].

IANA will also add a note to the registry which reserves all other capabilities starting with "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to [ RFC-to-be ].

Second, a new registry is to be created called IMAP Quota Resource Types.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page (for instance, the Internet Message Access Protocol (IMAP) Capabilities Registry located at:
https://www.iana.org/assignments/imap-capabilities/? If it needs a new page, does it also need a new category at http://www.iana.org/protocols (and if so, should the page and the category have the same name)?

The registration policy for the new registry is Specification Required as defined in RFC8126.

There are initial registrations in the new registry as follows:

Name of the quota resource type: STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root.
Extra required IMAP commands/responses: DELETED-STORAGE STATUS request data item and response data item
Extra optional IMAP commands/responses: N/A
Reference: [ RFC-to-be; Section 5.1]

Name of the quota resource type: MESSAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The number of messages stored within the mailboxes governed by the quota root.
Extra required IMAP commands/responses: DELETED STATUS request data item and response data item
Extra optional IMAP commands/responses: N/A
Reference: Section [ RFC-to-be; Section 5.2]

Name of the quota resource type: MAILBOX
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The number of mailboxes governed by the quota root.
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: [ RFC-to-be; Section 5.3 ]

Name of the quota resource type: ANNOTATION-STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org>
Description: The maximum size of all annotations [RFC5257], in units of 1024 octets, associated with all messages in the mailboxes governed by the quota root.
Extra required IMAP commands/responses: N/A
Extra optional IMAP commands/responses: N/A
Reference: Section [ RFC-to-be; Section 5.4 ]

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Lead IANA Services Specialist
2021-09-06
06 Shawn Emery Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Shawn Emery. Sent review to list.
2021-09-03
06 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2021-09-03
06 Jean Mahoney Request for Last Call review by GENART is assigned to Linda Dunbar
2021-09-02
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2021-09-02
06 Tero Kivinen Request for Last Call review by SECDIR is assigned to Shawn Emery
2021-08-31
06 Todd Herr Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Todd Herr. Sent review to list.
2021-08-30
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-08-30
06 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Fred Baker
2021-08-27
06 Barry Leiba Request for Last Call review by ARTART is assigned to Todd Herr
2021-08-27
06 Barry Leiba Request for Last Call review by ARTART is assigned to Todd Herr
2021-08-27
06 Cindy Morgan IANA Review state changed to IANA - Review Needed
2021-08-27
06 Cindy Morgan
The following Last Call announcement was sent out (ends 2021-09-10):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, …
The following Last Call announcement was sent out (ends 2021-09-10):<br><br>From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
CC: brong@fastmailteam.com, draft-ietf-extra-quota@ietf.org, extra-chairs@ietf.org, extra@ietf.org, superuser@gmail.com
Reply-To: last-call@ietf.org
Sender: <iesg-secretary@ietf.org>
Subject: Last Call: <draft-ietf-extra-quota-06.txt> (IMAP QUOTA Extension) to Proposed Standard


The IESG has received a request from the Email mailstore and eXtensions To
Revise or Amend WG (extra) to consider the following document: - 'IMAP QUOTA
Extension'
  <draft-ietf-extra-quota-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2021-09-10. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  The QUOTA extension of the Internet Message Access Protocol (RFC
  3501
/RFC 9051) permits administrative limits on resource usage
  (quotas) to be manipulated through the IMAP protocol.

  This document obsoletes RFC 2087, but attempts to remain backwards
  compatible whenever possible.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-extra-quota/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc5257: Internet Message Access Protocol - ANNOTATE Extension (Experimental - Internet Engineering Task Force (IETF))



2021-08-27
06 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2021-08-27
06 Murray Kucherawy Last call was requested
2021-08-27
06 Murray Kucherawy Ballot approval text was generated
2021-08-27
06 Murray Kucherawy Ballot writeup was generated
2021-08-27
06 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-08-27
06 Murray Kucherawy IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2021-08-27
06 Murray Kucherawy Last call announcement was generated
2021-08-27
06 (System) Removed all action holders (IESG state changed)
2021-08-27
06 (System) Sub state has been changed to AD Followup from Revised ID Needed
2021-08-27
06 Alexey Melnikov New version available: draft-ietf-extra-quota-06.txt
2021-08-27
06 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-08-27
06 Alexey Melnikov Uploaded new revision
2021-08-27
05 Murray Kucherawy Changed action holders to Alexey Melnikov
2021-08-27
05 (System) Changed action holders to Alexey Melnikov, Murray Kucherawy (IESG state changed)
2021-08-27
05 Murray Kucherawy IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation
2021-08-21
05 (System) Changed action holders to Murray Kucherawy (IESG state changed)
2021-08-21
05 Murray Kucherawy IESG state changed to AD Evaluation from Publication Requested
2021-08-19
05 Bron Gondwana
Document Shepherd Write-Up for draft-ietf-extra-quota

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501) …
Document Shepherd Write-Up for draft-ietf-extra-quota

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501) and obsoletes another
Proposed Standard (RFC2087).

The request type is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends IMAP with additional commands (GETQUOTA, GETQUOTAROOT,
  SETQUOTA) and new STATUS attributes (DELETED and DELETED-STORAGE),
  allowing clients to determine how much space is used by an IMAP account
  and how much additional space might be available.

Working Group Summary

  There was no significant disagreement.  The main questions were around
  whether particular features were worth including, and whether the syntax
  was reliably parseable for OVERQUOTA responses that included tags (they
  were eventually removed as being un-necessary and ambiguous).

Document Quality

  This spec is quite easy to implement.  Most IMAP servers are already
  basically compatible because they have implemented RFC2087.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Murray Kucherawy


3. The Document Shepherd has read the document through in detail and has
plans to implement it in the Cyrus IMAP server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool complains about a non-RFC2606-compliant FQDN, but this
is a false positive on a newsgroup name example.  It also complains that the
document date is February 2022, which also appears to be a tool bug, as that
is the expiry date on the draft.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There is a normative reference to an experimental RFC (RFC5257) however
this specification was written in 2008 and is widely enough used that we
should probably update it to a Proposed Standard as well.  The only reference
to that RFC is documenting an extension to allow quotas for those annotations
as well.

16. This RFC obsoletes one other RFC, RFC2087.

17. The IANA considerations ask that the imap4-capabilities registry both
have an entry updated, and have a prefix registered to restrict the use
of that prefix to IETF consesensus documents.

18. There is a new registry requested for IMAP quota resource types.  The
initial contents of the registry are set out clearly in the document.
The registration policy is "Specification Required".

19. The formal sections were validated with Chris Newman's ABNF
validator tool.

2021-08-19
05 Bron Gondwana Responsible AD changed to Murray Kucherawy
2021-08-19
05 Bron Gondwana IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2021-08-19
05 Bron Gondwana IESG state changed to Publication Requested from I-D Exists
2021-08-19
05 Bron Gondwana IESG process started in state Publication Requested
2021-08-19
05 Bron Gondwana Tag Revised I-D Needed - Issue raised by WG cleared.
2021-08-19
05 Bron Gondwana
Document Shepherd Write-Up for draft-ietf-extra-quota

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501) …
Document Shepherd Write-Up for draft-ietf-extra-quota

1. This document is being requested as an Proposed Standard because it
extends an existing Proposed Standard (RFC3501) and obsoletes another
Proposed Standard (RFC2087).

The request type is indicated in the title page header as "Standards Track".

2.

Technical Summary

  This spec extends IMAP with additional commands (GETQUOTA, GETQUOTAROOT,
  SETQUOTA) and new STATUS attributes (DELETED and DELETED-STORAGE),
  allowing clients to determine how much space is used by an IMAP account
  and how much additional space might be available.

Working Group Summary

  There was no significant disagreement.  The main questions were around
  whether particular features were worth including, and whether the syntax
  was reliably parseable for OVERQUOTA responses that included tags (they
  were eventually removed as being un-necessary and ambiguous).

Document Quality

  This spec is quite easy to implement.  Most IMAP servers are already
  basically compatible because they have implemented RFC2087.

Personnel

  Document Shepherd - Bron Gondwana (EXTRA co-chair)
  Responsible Area Director - Murray Kucherawy


3. The Document Shepherd has read the document through in detail and has
plans to implement it in the Cyrus IMAP server.

4. There are no concerns about reviews, this document has been well reviewed.

5. There is no review required for the document by other areas.

6. There are no concerns with this document that IESG should be aware of.

7. Yes, the author has been contacted and confirmed and confirmed that
they have no disclosures.

8. There have been no IPR disclosures filed.

9. The WG consensus is solid.

10. There has been no discontent.

11. The ID nits tool complains about a non-RFC2606-compliant FQDN, but this
is a false positive on a newsgroup name example.  It also complains that the
document date is February 2022, which also appears to be a tool bug, as that
is the expiry date on the draft.

12. This document doesn't define anything which needs formal review
outside the working group.

13. All references have been identified as either normative or
informative.

14. All normative references are published standards.

15. There is a normative reference to an experimental RFC (RFC5257) however
this specification was written in 2008 and is widely enough used that we
should probably update it to a Proposed Standard as well.  The only reference
to that RFC is documenting an extension to allow quotas for those annotations
as well.

16. This RFC obsoletes one other RFC, RFC2087.

17. The IANA considerations ask that the imap4-capabilities registry both
have an entry updated, and have a prefix registered to restrict the use
of that prefix to IETF consesensus documents.

18. There is a new registry requested for IMAP quota resource types.  The
initial contents of the registry are set out clearly in the document.
The registration policy is "Specification Required".

19. The formal sections were validated with Chris Newman's ABNF
validator tool.

2021-08-19
05 Alexey Melnikov New version available: draft-ietf-extra-quota-05.txt
2021-08-19
05 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-08-19
05 Alexey Melnikov Uploaded new revision
2021-03-01
04 Bron Gondwana Added to session: IETF-110: extra  Fri-1530
2021-02-22
04 Alexey Melnikov New version available: draft-ietf-extra-quota-04.txt
2021-02-22
04 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2021-02-22
04 Alexey Melnikov Uploaded new revision
2020-12-03
03 Bron Gondwana Notification list changed to brong@fastmailteam.com because the document shepherd was set
2020-12-03
03 Bron Gondwana Document shepherd changed to Bron Gondwana
2020-11-18
03 Bron Gondwana As discussed at IETF109.
2020-11-18
03 Bron Gondwana Tag Revised I-D Needed - Issue raised by WG set.
2020-11-18
03 Bron Gondwana IETF WG state changed to In WG Last Call from WG Document
2020-11-17
03 Alexey Melnikov New version available: draft-ietf-extra-quota-03.txt
2020-11-17
03 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-11-17
03 Alexey Melnikov Uploaded new revision
2020-07-01
02 Alexey Melnikov New version available: draft-ietf-extra-quota-02.txt
2020-07-01
02 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-07-01
02 Alexey Melnikov Uploaded new revision
2020-06-15
01 Alexey Melnikov New version available: draft-ietf-extra-quota-01.txt
2020-06-15
01 (System) New version accepted (logged-in submitter: Alexey Melnikov)
2020-06-15
01 Alexey Melnikov Uploaded new revision
2019-12-19
00 (System) Document has expired
2019-11-21
00 Bron Gondwana Changed consensus to Yes from Unknown
2019-11-21
00 Bron Gondwana Intended Status changed to Proposed Standard from None
2019-06-23
00 Alexey Melnikov This document now replaces draft-melnikov-extra-quota instead of None
2019-06-17
00 Alexey Melnikov New version available: draft-ietf-extra-quota-00.txt
2019-06-17
00 (System) WG -00 approved
2019-06-17
00 Alexey Melnikov Set submitter to "Alexey Melnikov <alexey.melnikov@isode.com>", replaces to (none) and sent approval email to group chairs: extra-chairs@ietf.org
2019-06-17
00 Alexey Melnikov Uploaded new revision