draft-ietf-extra-quota-05.txt   draft-ietf-extra-quota-06.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Obsoletes: 2087 (if approved) 19 August 2021 Obsoletes: 2087 (if approved) 27 August 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 20 February 2022 Expires: 28 February 2022
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-05 draft-ietf-extra-quota-06
Abstract Abstract
The QUOTA extension of the Internet Message Access Protocol (RFC The QUOTA extension of the Internet Message Access Protocol (RFC
3501) permits administrative limits on resource usage (quotas) to be 3501/RFC 9051) permits administrative limits on resource usage
manipulated through the IMAP protocol. (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. compatible whenever possible.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 3, line 6 skipping to change at page 3, line 6
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13
6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA 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 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 19
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Document Conventions 1. Document Conventions
In protocol examples, this document uses a prefix of "C: " to denote 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 lines sent by the client to the server, and "S: " for lines sent by
the server to the client. Lines prefixed with "// " are comments the server to the client. Lines prefixed with "// " are comments
explaining the previous protocol line. These prefixes and comments explaining the previous protocol line. These prefixes and comments
are not part of the protocol. Lines without any of these prefixes are not part of the protocol. Lines without any of these prefixes
are continuations of the previous line, and no line break is present are continuations of the previous line, and no line break is present
skipping to change at page 3, line 35 skipping to change at page 3, line 37
Again, for examples, the hierarchy separator on the IMAP server is Again, for examples, the hierarchy separator on the IMAP server is
presumed to be "/" throughout. None of these assumptions is required presumed to be "/" throughout. None of these assumptions is required
nor recommended by this document. nor recommended by this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Other capitalised words are IMAP4 [RFC3501] keywords or keywords from Other capitalised words are IMAP keywords [RFC3501][RFC9051] or
this document. keywords from this document.
2. Introduction and Overview 2. Introduction and Overview
This document defines a couple of extension to the Internet Message This document defines a couple of extension to the Internet Message
Access Protocol [RFC3501] for querying and manipulating Access Protocol [RFC3501] for querying and manipulating
administrative limits on resource usage (quotas). This extension is administrative limits on resource usage (quotas). This extension is
compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 (draft-ietf- compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
extra-imap4rev2).
The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server.
Some responses and response codes defined in this document are not Some responses and response codes defined in this document are not
present in such servers (see Section 12 for more details), and present in such servers (see Section 12 for more details), and
clients MUST NOT rely on their presence in the absence of any clients MUST NOT rely on their presence in the absence of any
capability beginning with "QUOTA=". capability beginning with "QUOTA=".
Any server compliant with this document MUST also return at least one Any server compliant with this document MUST also return at least one
capability starting with "QUOTA=RES-" prefix, as described in capability starting with "QUOTA=RES-" prefix, as described in
Section 3.1. Section 3.1.
skipping to change at page 4, line 26 skipping to change at page 4, line 26
Quotas can be used to restrict clients for administrative reasons, Quotas can be used to restrict clients for administrative reasons,
but the QUOTA extension can also be used to indicate system limits but the QUOTA extension can also be used to indicate system limits
and current usage levels to clients. and current usage levels to clients.
Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and
this has seen deployment in servers, it has seen little deployment in this has seen deployment in servers, it has seen little deployment in
clients. Since the meaning of the resources was left implementation- clients. Since the meaning of the resources was left implementation-
dependant, it was impossible for a client implementation to determine dependant, it was impossible for a client implementation to determine
which resources were supported, and impossible to determine which which resources were supported, and impossible to determine which
mailboxes were in a given quota root, without a priori knowledge of mailboxes were in a given quota root (see Section 3.2), without a
the implementation. priori knowledge of the implementation.
3. Terms 3. Terms
3.1. Resource 3.1. Resource
A resource has a name, a formal definition. A resource has a name, a formal definition.
3.1.1. Name 3.1.1. Name
The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. The resource name is an atom, as defined in IMAP4rev1 [RFC3501].
skipping to change at page 5, line 5 skipping to change at page 5, line 5
Supported resource names MUST be advertised as a capability, by Supported resource names MUST be advertised as a capability, by
prepending the resource name with "QUOTA=RES-". A server compliant prepending the resource name with "QUOTA=RES-". A server compliant
with this specification is not required to support all reported with this specification is not required to support all reported
resource types on all quota roots. resource types on all quota roots.
3.1.2. Definition 3.1.2. Definition
The resource definition or document containing it, while not visible The resource definition or document containing it, while not visible
through the protocol, SHOULD be registered with IANA. 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 integer. 0 indicates that the resource is exhausted. Usage integers
don't necessarily represent proportional use, so clients MUST NOT don't necessarily represent proportional use, so clients MUST NOT
compare available resource between two separate quota roots on the compare available resource between two separate quota roots on the
same or different servers. same or different servers.
Limits will be specified as, and MUST be represented as, an integer. Limits will be specified as, and MUST be represented as, an integer.
0 indicates that any usage is prohibited. 0 indicates that any usage is prohibited.
Limits may be hard or soft - that is, an implementation MAY choose, 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 or be configured, to disallow any command if the limit on a resource
is or would be exceeded. is or would be exceeded.
All resources which the server handles must be advertised in a All resources which the server handles MUST be advertised in a
CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". CAPABILITY response/response code consisting of the resource name
prefixed by "QUOTA=RES-".
The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
(Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in
this document. this document.
3.2. Quota Root 3.2. Quota Root
Each mailbox has zero or more implementation-defined named "quota Each mailbox has zero or more implementation-defined named "quota
roots". Each quota root has zero or more resource limits (quotas). roots". Each quota root has zero or more resource limits (quotas).
All mailboxes that share the same named quota root share the resource All mailboxes that share the same named quota root share the resource
limits of the quota root. limits of the quota root.
Quota root names need not be mailbox names, nor is there any 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 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. [RFC3501]. It SHOULD be treated as an opaque string by any clients.
Quota roots are used since not all implementations may be able to 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 arbitary mailboxes or mailbox
hierarchies. hierarchies.
Not all resources may be limitable or calculatable for all quota Not all resources may be limitable or calculatable for all quota
roots. Further, not all resources may support all limits - some roots. Further, not all resources may support all limits - some
limits may be present in the underlying system. A server limits may be present in the underlying system. A server
skipping to change at page 16, line 10 skipping to change at page 16, line 10
status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 status-att-deleted-storage =/ "DELETED-STORAGE" SP number64
;; DELETED-STORAGE status data item MUST be ;; DELETED-STORAGE status data item MUST be
;; supported when "QUOTA=RES-STORAGE" capability ;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised. ;; is advertised.
resp-text-code =/ "OVERQUOTA" resp-text-code =/ "OVERQUOTA"
number64 = 1*DIGIT number64 = <Defined in RFC 9051>
;; Unsigned 63-bit integer.
;; (0 <= n <= 9,223,372,036,854,775,807)
8. Security Considerations 8. Security Considerations
Implementors should be careful to make sure the implementation of Implementors should be careful to make sure the implementation of
these commands does not violate the site's security policy. The these commands does not violate the site's security policy. The
resource usage of other users is likely to be considered confidential resource usage of other users is likely to be considered confidential
information and should not be divulged to unauthorized persons. In information and should not be divulged to unauthorized persons. In
particular, no quota information should be disclosed to anonymous particular, no quota information should be disclosed to anonymous
users. users.
9. IANA Considerations 9. IANA Considerations
9.1. Changes/additions to the IMAP4 capabilities registry
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved experimental RFC. The registry is currently located IESG approved Informational or Experimental RFC. The registry is
at: currently located at:
http://www.iana.org/assignments/imap4-capabilities http://www.iana.org/assignments/imap4-capabilities
IANA is requested to update definition of the QUOTA extension to IANA is requested to update definition of the QUOTA extension to
point to this document. IANA is also requested to add the "QUOTASET" point to this document. IANA is also requested to add the "QUOTASET"
capability to the IMAP4 capabilities registry, with this document as capability to the IMAP4 capabilities registry, with this document as
the reference. the reference.
IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4
capabilities registry and add a pointer to this document and to the 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 IANA is requested to reserve all other capabilities starting with
"QUOTA=" prefix for future IETF stream standard track, informational "QUOTA=" prefix for future IETF stream standard track, informational
or experimental extensions to this document. or experimental extensions to this document.
IANA is also requested to create a new registry for IMAP quota 9.2. IMAP quota resource type registry
resource types. Registration policy for this registry is
"Specification Required". When registering a new quota resource IANA is requested to create a new registry for IMAP quota resource
type, the registrant need to provide the following: Name of the quota types. Registration policy for this registry is "Specification
resource type, Author/Change Controller name and email address, short 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/ description, extra (if any) required and optional IMAP commands/
responses, and a reference to a specification that describes the responses, and a reference to a specification that describes the
quota resource type in more details. 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 This document includes initial registrations for the following IMAP
quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2),
MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 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 Name of the quota resource type: STORAGE
Author: Alexey Melnikov <alexey.melnikov@isode.com> Author: Alexey Melnikov <alexey.melnikov@isode.com>
Change Controller: IESG <iesg@ietf.org> Change Controller: IESG <iesg@ietf.org>
Description: The physical space estimate, in units of 1024 octets, Description: The physical space estimate, in units of 1024 octets,
of the mailboxes governed by the quota root. of the mailboxes governed by the quota root.
skipping to change at page 19, line 49 skipping to change at page 19, line 49
[RFC5257] Daboo, C. and R. Gellens, "Internet Message Access [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
Protocol - ANNOTATE Extension", RFC 5257, Protocol - ANNOTATE Extension", RFC 5257,
DOI 10.17487/RFC5257, June 2008, DOI 10.17487/RFC5257, June 2008,
<https://www.rfc-editor.org/info/rfc5257>. <https://www.rfc-editor.org/info/rfc5257>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>.
13.2. Informative References 13.2. Informative References
[RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
DOI 10.17487/RFC2087, January 1997, DOI 10.17487/RFC2087, January 1997,
<https://www.rfc-editor.org/info/rfc2087>. <https://www.rfc-editor.org/info/rfc2087>.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
 End of changes. 23 change blocks. 
34 lines changed or deleted 51 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/