--- 1/draft-ietf-extra-quota-02.txt 2020-11-17 04:15:10.213504121 -0800 +++ 2/draft-ietf-extra-quota-03.txt 2020-11-17 04:15:13.909597690 -0800 @@ -1,18 +1,18 @@ Network Working Group A. Melnikov Internet-Draft Isode -Intended status: Standards Track July 1, 2020 -Expires: January 2, 2021 +Intended status: Standards Track November 17, 2020 +Expires: May 21, 2021 IMAP QUOTA Extension - draft-ietf-extra-quota-02 + draft-ietf-extra-quota-03 Abstract The QUOTA extension of the Internet Message Access Protocol (RFC 3501) permits administrative limits on resource usage (quotas) to be manipulated through the IMAP protocol. This memo obsoletes RFC 2087, but attempts to remain backwards compatible whenever possible. @@ -24,21 +24,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 2, 2021. + This Internet-Draft will expire on May 21, 2021. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -71,40 +71,40 @@ 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 - 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9 - 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9 + 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 + 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12 - 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 + 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15 - 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 - 13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16 - 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 14.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 14.2. Informative References . . . . . . . . . . . . . . . . . 17 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 + 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 + 13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 17 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 14.2. Informative References . . . . . . . . . . . . . . . . . 18 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 1. Document Conventions In protocol examples, this document uses a prefix of "C: " to denote lines sent by the client to the server, and "S: " for lines sent by the server to the client. Lines prefixed with "// " are comments explaining the previous protocol line. These prefixes and comments 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. @@ -188,24 +188,20 @@ Limits will be specified as, and MUST be represented as, an integer. 0 indicates that any usage is prohibited. Limits may be hard or soft - that is, an implementation MAY choose, or be configured, to disallow any command if the limit on a resource is or would be exceeded. All resources which the server handles must be advertised in a CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". - For compatability with RFC 2087 [RFC2087], a client which discovers - resources available on the server which are not advertised through - this mechanism MUST treat them as if they were completely opaque, and - without any meaning. The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in this document. 3.2. Quota Root Each mailbox has zero or more implementation-defined named "quota roots". Each quota root has zero or more resource limits (quotas). All mailboxes that share the same named quota root share the resource @@ -352,38 +348,41 @@ is entirely optional. S: S0002 NO Cannot change system limit 4.1.4. New STATUS attributes DELETED and DELETED-STORAGE status data items allow to estimate the amount of resource freed by an EXPUNGE on a mailbox. DELETED status data item requests the server to return the number of - messages with \Deleted flag set. + messages with \Deleted flag set. DELETED status data item is only + required to be implemented when the server advertises QUOTA=RES- + MESSAGE capability. DELETED-STORAGE status data item requests the server to return the amount of storage space that can be reclaimed by performing EXPUNGE on the mailbox. The server SHOULD return the exact value, however it is recognized that the server may have to do non-trivial amount of work to calculate it. If the calculation of the exact value would take a long time, the server MAY instead return the sum of - RFC822.SIZEs of messages with the \Deleted flag set. + RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE + status data item is only required to be implemented when the server + advertises QUOTA=RES-STORAGE capability. Example: S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE [...] [...] C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) - // 12 messages, 4 of which would be deleted when an EXPUNGE happens. S: S0003 OK Status complete. 4.2. Responses The following responses may be sent by the server. 4.2.1. QUOTA @@ -495,34 +494,40 @@ use the usage figure for anything other than informational purposes, for example, they MUST NOT refuse to APPEND a message if the limit less the usage is smaller than the RFC822.SIZE divided by 1024 of the message, but it MAY warn about such condition. The usage figure may change as a result of performing actions not associated with adding new messages to the mailbox, such as SEARCH, since this may increase the amount of metadata included in the calculations. + When the server supports this resource type, it MUST also support + DELETED-STORAGE status data item. + Support for this resource MUST be indicated by the server by advertising the CAPABILITY "QUOTA=RES-STORAGE". A resource named the same was also given as an example in RFC2087 [RFC2087]. This document provides a more precise definition. 5.2. MESSAGE The number of messages stored within the mailboxes governed by the quota root. This MUST be an exact number, however, clients MUST NOT assume that a change in the usage indicates a change in the number of messages available, since the quota root may include mailboxes the client has no access to. + When the server supports this resource type, it MUST also support + DELETED status data item. + Support for this resource MUST be indicated by the server by advertising the CAPABILITY "QUOTA=RES-MESSAGE". A resource named the same was also given as an example in RFC2087 [RFC2087]. This document provides a more precise definition. 5.3. MAILBOX The number of mailboxes governed by the quota root. This MUST be an exact number, however, clients MUST NOT assume that a change in the @@ -544,21 +549,21 @@ 6. Interaction with IMAP ACL extension (RFC 4314) This section lists [RFC4314] rights required to execute quota related commands when both RFC 4314 and this document are implemented. +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ | Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non | | ghts | | | | | | | | | | | | | +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ - | GETQUOTA | | | | | | | | | | | | * | + | GETQUOTA | | | | | | | | | | | | + | | GETQUOTAROOT | | * | | | | | | | | | | * | | SETQUOTA | | | | | | | | | | + | | | +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ See Section 4 of RFC 4314 for conventions used in this table. [[CREF2: The above table needs to be reviewed based on feedback from existing and planned implementations.]] 7. Formal syntax @@ -617,27 +622,44 @@ resource-usage = number64 ;; must be less than corresponding resource-limit capability-quota = capa-quota-res / "QUOTASET" ;; One or more capa-quota-res must be returned. ;; Also "QUOTASET" can optionally be returned. capa-quota-res = "QUOTA=RES-" resource-name status-att =/ "DELETED" / "DELETED-STORAGE" + ;; DELETED status data item MUST be supported + ;; when "QUOTA=RES-MESSAGE" capability is + ;; advertised. + ;; DELETED-STORAGE status data item MUST be + ;; supported when "QUOTA=RES-STORAGE" capability + ;; is advertised. - status-att-val =/ ("DELETED" SP number) / - ("DELETED-STORAGE" SP number64) + status-att-val =/ status-att-deleted / + status-att-deleted-storage + + status-att-deleted =/ "DELETED" SP number + ;; DELETED status data item MUST be supported + ;; when "QUOTA=RES-MESSAGE" capability is + ;; advertised. + + status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 + ;; DELETED-STORAGE status data item MUST be + ;; supported when "QUOTA=RES-STORAGE" capability + ;; is advertised. resp-text-code =/ "OVERQUOTA" [SP tag] - number64 = 1*DIGIT ;; Unsigned 63-bit integer. + number64 = 1*DIGIT + ;; Unsigned 63-bit integer. ;; (0 <= n <= 9,223,372,036,854,775,807) 8. Security Considerations Implementors should be careful to make sure the implementation of these commands does not violate the site's security policy. The resource usage of other users is likely to be considered confidential information and should not be divulged to unauthorized persons. 9. IANA Considerations @@ -649,21 +671,22 @@ http://www.iana.org/assignments/imap4-capabilities IANA is requested to update definition of the QUOTA extension to point to this document. IANA is also requested to create a new registry for IMAP quota resource types. Registration policy for this registry is "Specification Required". When registering a new quota resource type, the registrant need to provide the following: Name of the quota resource type, Author/Change Controller name and email address, short - description and a reference to a specification that describes the + description, extra (if any) required and optional IMAP commands/ + responses, and a reference to a specification that describes the quota resource type in more details. This document includes initial registrations for the following IMAP quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See details below. IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 capabilities registry and add a pointer to this document and to the IMAP quota resource type registry established above. @@ -672,70 +695,83 @@ "QUOTA=" prefix for future IETF stream standard track or experimental extensions to this document. 9.1. Registrations of IMAP Quota Resource Types Name of the quota resource type: STORAGE Author: Alexey Melnikov Change Controller: IESG - 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: Section 5.1 of RFCXXXX Name of the quota resource type: MESSAGE Author: Alexey Melnikov Change Controller: IESG 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 5.2 of RFCXXXX Name of the quota resource type: MAILBOX Author: Alexey Melnikov Change Controller: IESG 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: Section 5.3 of RFCXXXX Name of the quota resource type: Author: Alexey Melnikov Change Controller: IESG + 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. [[CREF3: Recheck against the final description of "ANNOTATION-STORAGE".]] + Extra required IMAP commands/responses: N/A + + Extra optional IMAP commands/responses: N/A + Reference: Section 5.4 of RFCXXXX 10. Open Issues '"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for "]", which is not allowed in response codes. Should we drop this variant or change IMAP4rev2 to disallow "]" in tags? - Should "DELETED" status item be required to be implemented for - anything other than QUOTA-RES=MESSAGE? Similarly, should "DELETED- - STORAGE" status item be required to be implemented for anything other - than QUOTA-RES=STORAGE? - 11. Contributors Dave Cridland wrote lots of text in an earlier draft that became the basis for this document. 12. Acknowledgments Editors of this document would like to thank the following people who provided useful comments or participated in discussions that lead to this update to RFC 2087: