--- 1/draft-ietf-extra-quota-05.txt 2021-08-27 04:13:26.359540010 -0700 +++ 2/draft-ietf-extra-quota-06.txt 2021-08-27 04:13:26.399541015 -0700 @@ -1,45 +1,45 @@ Network Working Group A. Melnikov Internet-Draft Isode -Obsoletes: 2087 (if approved) 19 August 2021 +Obsoletes: 2087 (if approved) 27 August 2021 Intended status: Standards Track -Expires: 20 February 2022 +Expires: 28 February 2022 IMAP QUOTA Extension - draft-ietf-extra-quota-05 + draft-ietf-extra-quota-06 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. + 3501/RFC 9051) permits administrative limits on resource usage + (quotas) to be manipulated through the IMAP protocol. - This memo obsoletes RFC 2087, but attempts to remain backwards + 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 20 February 2022. + This Internet-Draft will expire on 28 February 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 @@ -82,27 +82,29 @@ 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 17 + 9.1. Changes/additions to the IMAP4 capabilities registry . . 16 + 9.2. IMAP quota resource type registry . . . . . . . . . . . . 16 + 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 - 13.2. Informative References . . . . . . . . . . . . . . . . . 19 + 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 are continuations of the previous line, and no line break is present @@ -111,30 +113,29 @@ Again, for examples, the hierarchy separator on the IMAP server is presumed to be "/" throughout. None of these assumptions is required nor recommended by this document. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. - Other capitalised words are IMAP4 [RFC3501] keywords or keywords from - this document. + Other capitalised words are IMAP keywords [RFC3501][RFC9051] or + keywords from this document. 2. Introduction and Overview This document defines a couple of extension to the Internet Message Access Protocol [RFC3501] for querying and manipulating administrative limits on resource usage (quotas). This extension is - compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 (draft-ietf- - extra-imap4rev2). + compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. Some responses and response codes defined in this document are not present in such servers (see Section 12 for more details), and clients MUST NOT rely on their presence in the absence of any capability beginning with "QUOTA=". Any server compliant with this document MUST also return at least one capability starting with "QUOTA=RES-" prefix, as described in Section 3.1. @@ -149,22 +150,22 @@ 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 which resources were supported, and impossible to determine which - mailboxes were in a given quota root, without a priori knowledge of - the implementation. + 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. 3.1.1. Name The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. @@ -174,49 +175,50 @@ Supported resource names MUST be advertised as a capability, by prepending the resource name with "QUOTA=RES-". A server compliant with this specification is not required to support all reported resource types on all quota roots. 3.1.2. Definition The resource definition or document containing it, while not visible through the protocol, SHOULD be registered with IANA. - The usage of a resource MUST be represented as a 32 bit unsigned + The usage of a resource MUST be represented as a 63 bit unsigned integer. 0 indicates that the resource is exhausted. Usage integers don't necessarily represent proportional use, so clients MUST NOT compare available resource between two separate quota roots on the same or different servers. 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-". + 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 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 memo between a Quota root name and a + 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 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 @@ -695,71 +697,81 @@ 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 = 1*DIGIT - - ;; Unsigned 63-bit integer. - - ;; (0 <= n <= 9,223,372,036,854,775,807) + 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. 9. IANA Considerations +9.1. Changes/additions to the IMAP4 capabilities registry + IMAP4 capabilities are registered by publishing a standards track or - IESG approved experimental RFC. The registry is currently located - at: + IESG approved Informational or Experimental RFC. The registry is + currently located at: 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 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 established above. + 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. - 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 +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 quota resource type in more details. + Designated Experts should check that provided references are correct, + that they describe the quota resource type being registered in + sufficient details to be implementable, that syntax of any optional + commands/responses is correct (e.g. ABNF validates), and their + syntax/description complies with rules and limitations imposed by + IMAP [RFC3501][RFC9051]. Designated Experts should avoid registering + multiple identical quota resource types under different names and + should provide advice to requestors about other possible quota + resource types to use. + 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. + Section 9.3 for the registration templates. -9.1. Registrations of IMAP Quota Resource Types +9.3. 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. @@ -867,20 +880,25 @@ [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access Protocol - ANNOTATE Extension", RFC 5257, DOI 10.17487/RFC5257, June 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . + [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message + Access Protocol (IMAP) - Version 4rev2", RFC 9051, + DOI 10.17487/RFC9051, August 2021, + . + 13.2. Informative References [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, DOI 10.17487/RFC2087, January 1997, . Author's Address Alexey Melnikov Isode Limited