--- 1/draft-ietf-extra-quota-07.txt 2021-10-21 07:13:16.969158298 -0700 +++ 2/draft-ietf-extra-quota-08.txt 2021-10-21 07:13:17.013159401 -0700 @@ -1,45 +1,46 @@ Network Working Group A. Melnikov Internet-Draft Isode -Obsoletes: 2087 (if approved) 24 September 2021 +Obsoletes: 2087 (if approved) 21 October 2021 Intended status: Standards Track -Expires: 28 March 2022 +Expires: 24 April 2022 IMAP QUOTA Extension - draft-ietf-extra-quota-07 + draft-ietf-extra-quota-08 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 defines a QUOTA extension of the Internet Message + Access Protocol (RFC 3501/RFC 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 28 March 2022. + This Internet-Draft will expire on 24 April 2022. Copyright Notice Copyright (c) 2021 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 carefully, as they describe your rights @@ -65,45 +66,45 @@ 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 - 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 + 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 - 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 - 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 + 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 - 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 + 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 - 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13 + 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Changes/additions to the IMAP4 capabilities registry . . 16 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 + 9.1. Changes/additions to the IMAP4 capabilities registry . . 17 9.2. IMAP quota resource type registry . . . . . . . . . . . . 17 - 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17 + 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 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 @@ -148,21 +149,21 @@ "QUOTA=" prefix for future IETF stream standard track, informational or experimental extensions to this document. Quotas can be used to restrict clients for administrative reasons, but the QUOTA extension can also be used to indicate system limits and current usage levels to clients. Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and this has seen deployment in servers, it has seen little deployment in clients. Since the meaning of the resources was left implementation- - dependant, it was impossible for a client implementation to determine + dependent, it was impossible for a client implementation to determine which resources were supported, and impossible to determine which mailboxes were in a given quota root (see Section 3.2), without a priori knowledge of the implementation. 3. Terms 3.1. Resource A resource has a name, a formal definition. @@ -198,44 +199,47 @@ All resources which the server handles MUST be advertised in a CAPABILITY response/response code consisting of the resource name prefixed by "QUOTA=RES-". 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 + This document introduces a concept of a "quota root", as resource + limits can apply across multiple IMAP mailboxes. + 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 limits of the quota root. Quota root names need not be mailbox names, nor is there any relationship defined by this document between a quota root name and a mailbox name. A quota root name is an astring, as defined in IMAP4 [RFC3501]. It SHOULD be treated as an opaque string by any clients. Quota roots are used since not all implementations may be able to - calculate usage, or apply quotas, on arbitary mailboxes or mailbox + calculate usage, or apply quotas, on arbitrary mailboxes or mailbox hierarchies. - Not all resources may be limitable or calculatable for all quota - roots. Further, not all resources may support all limits - some - limits may be present in the underlying system. 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. A SETQUOTA (Section 4.1.3) command MAY also round a - quota limit in an implementation dependant way, if the granularity of - the underlying system demands it. A client MUST be prepared for a - SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. + Not all resources may be limitable or calculable for all quota roots. + Further, not all resources may support all limits - some limits may + be present in the underlying system. 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. A + SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an + implementation-dependent way, if the granularity of the underlying + system demands it. A client MUST be prepared for a SETQUOTA + (Section 4.1.3) command to fail if a limit cannot be set. Implementation Notes: This means that, for example under UNIX, a quota root may have a MESSAGE (Section 5.2) quota always set due to the number of inodes available on the filesystem, and similarly STORAGE (Section 5.1) may be rounded to the nearest block and limited by free filesystem space. 4. Definitions 4.1. Commands @@ -249,20 +253,22 @@ Responses: REQUIRED untagged responses: QUOTA Result: OK - getquota completed NO - getquota error: no such quota root, permission denied BAD - command unknown or arguments invalid The GETQUOTA command takes the name of a quota root and returns the quota root's resource usage and limits in an untagged QUOTA response. + (Names of quota roots applicable to a particular mailbox can be + discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.) The client can try using any of the resource types returned in CAPABILITY response (i.e. all capability items with "QUOTA=RES-" prefix), however the server is not required to support any specific resource type for any particular quota root. Example: S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] [...] @@ -372,34 +377,34 @@ filesystem limit, and cannot be changed. The QUOTA response here 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. DELETED status data item is only - required to be implemented when the server advertises QUOTA=RES- + The DELETED status data item requests the server to return the number + of messages with \Deleted flag set. The 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. DELETED-STORAGE - status data item is only required to be implemented when the server - advertises QUOTA=RES-STORAGE capability. + The 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. The 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) @@ -413,23 +417,23 @@ 4.2. Responses The following responses may be sent by the server. 4.2.1. QUOTA Data: quota root name list of resource names, usages, and limits - This response occurs as a result of a GETQUOTA or GETQUOTAROOT - command. The first string is the name of the quota root for which - this quota applies. + This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a + SETQUOTA command. The first string is the name of the quota root for + which this quota applies. The name is followed by a S-expression format list of the resource usage and limits of the quota root. The list contains zero or more triplets. Each triplet contains a resource name, the current usage of the resource, and the resource limit. Resources not named in the list are not limited in the quota root. Thus, an empty list means there are no administrative resource limits in the quota root. @@ -496,23 +499,23 @@ C: To: mooch@owatagu.siam.edu.example C: Message-Id: C: MIME-Version: 1.0 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: S: * NO [OVERQUOTA] Soft quota has been exceeded S: A003 OK [APPENDUID 38505 3955] APPEND completed - Example 3: C: A003 COPY 2:4 MEETING + Example 3: C: A004 COPY 2:4 MEETING S: * NO [OVERQUOTA] Soft quota has been exceeded - S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY + S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY command completed 5. Resource Type Definitions The following resource types are defined in this memo. A server supporting a resource type MUST advertise this as a CAPABILITY with a name consisting of the resource name prefixed by "QUOTA=RES-". A server MAY support multiple resource types, and MUST advertise all resource types it supports. @@ -528,38 +531,38 @@ 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 + When the server supports this resource type, it MUST also support the 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 + When the server supports this resource type, it MUST also support the 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 @@ -657,23 +660,21 @@ ;; The "V-" prefix should be followed by a domain name ;; under vendor's control. resource-name-ext = atom ;; Not starting with V- and defined - ;; in a Standard Track or Experimental RFC - - resource-names = "(" [resource-name *(SP resource-name)] ")" + ;; in an IETF Stream RFC 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. @@ -691,70 +692,76 @@ ;; DELETED-STORAGE status data item MUST be ;; supported when "QUOTA=RES-STORAGE" capability ;; is advertised. status-att-val =/ status-att-deleted / status-att-deleted-storage - status-att-deleted =/ "DELETED" SP number + 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 + 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" number64 = 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. In particular, no quota information should be disclosed to anonymous users. + Note that computing resource usage might incur a heavy load on the + server. Server implementers should consider implementation + techniques that lower load on servers, such as caching of resource + usage information or usage of less precise computations when under + heavy load. + 9. IANA Considerations 9.1. Changes/additions to the IMAP4 capabilities registry IMAP4 capabilities are registered by publishing a standards track or IESG approved Informational or Experimental RFC. The registry is currently located at: - http://www.iana.org/assignments/imap4-capabilities + https://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 add the "QUOTASET" capability to the IMAP4 capabilities registry, with this document as the reference. 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 (see Section 9.2). IANA is requested to reserve all other capabilities starting with - "QUOTA=" prefix for future IETF stream standard track, informational - or experimental extensions to this document. + "QUOTA=" prefix for future IETF Stream extensions to this document. 9.2. IMAP quota resource type registry IANA is 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, extra (if any) required and optional IMAP commands/ responses, and a reference to a specification that describes the @@ -840,47 +847,51 @@ 10. Contributors Dave Cridland wrote lots of text in an earlier draft that became the basis for this document. 11. Acknowledgments Editor 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: John Myers, Cyrus Daboo, Lyndon Nerenberg. + this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg, + Benjamin Kaduk, Roman Danyliw, Eric Vyncke. This document is a revision of RFC 2087. It borrows a lot of text from RFC 2087. Thus work of the RFC 2087 author John Myers is appreciated. 12. Changes since RFC 2087 This document is a revision of RFC 2087. It tries to clarify the meaning of different terms used by RFC 2087. It also provides more examples, gives guidance on allowed server behaviour, defines IANA registry for quota resource types and provides initial registrations for 4 of them. 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. For extensibility quota usage and quota limits - are now 63 bit unsigned integers. + two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The + DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE + capability is advertised. The DELETED-STORAGE STATUS data item must + be implemented if the QUOTA=RES-STORAGE capability is advertised. + For extensibility quota usage and quota limits are now 63 bit + unsigned integers. 13. References 13.1. Normative References [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008, - . + . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, .