rfc9208.original   rfc9208.txt 
Network Working Group A. Melnikov Internet Engineering Task Force (IETF) A. Melnikov
Internet-Draft Isode Request for Comments: 9208 Isode
Obsoletes: 2087 (if approved) 18 November 2021 Obsoletes: 2087 March 2022
Intended status: Standards Track Category: Standards Track
Expires: 22 May 2022 ISSN: 2070-1721
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-10
Abstract Abstract
This document defines a QUOTA extension of the Internet Message This document defines a QUOTA extension of the Internet Message
Access Protocol (RFC 3501/RFC 9051) that permits administrative Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits
limits on resource usage (quotas) to be manipulated through the IMAP administrative limits on resource usage (quotas) to be manipulated
protocol. through the IMAP protocol.
This document 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 is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 22 May 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9208.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 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
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Simplified BSD License text to this document. Code Components extracted from this document must
as described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Simplified BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Overview
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Document Conventions
3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terms
3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Resource
3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Name
3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Definition
3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Quota Root
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Definitions
4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Commands
4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA
4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7 4.1.2. GETQUOTAROOT
4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. SETQUOTA
4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 4.1.4. New STATUS attributes
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. Responses
4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2.1. QUOTA
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. QUOTAROOT
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 4.3. Response Codes
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. OVERQUOTA
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 5. Resource Type Definitions
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. STORAGE
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. MESSAGE
5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3. MAILBOX
5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 5.4. ANNOTATION-STORAGE
6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14 6. Interaction with IMAP ACL Extension (RFC 4314)
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Formal Syntax
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations
9.1. Changes/additions to the IMAP4 capabilities registry . . 17 9.1. Changes/Additions to the IMAP Capabilities Registry
9.2. IMAP quota resource type registry . . . . . . . . . . . . 17 9.2. IMAP Quota Resource Type Registry
9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18 10. Changes Since RFC 2087
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References
12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 20 11.2. Informative References
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 Acknowledgments
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 Contributors
13.2. Informative References . . . . . . . . . . . . . . . . . 21 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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 before such lines unless specifically mentioned.
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 IMAP keywords [RFC3501][RFC9051] or
keywords from this document.
2. Introduction and Overview 1. Introduction and Overview
This document defines a couple of extensions to the Internet Message This document defines a couple of extensions to the Internet Message
Access Protocol [RFC3501] for querying and manipulating Access Protocol [RFC3501] [RFC9051] 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 [RFC9051]. compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. The "QUOTA" capability denotes a server compliant with [RFC2087].
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 10 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 the "QUOTA=RES-" prefix, as described in
Section 3.1. Section 3.1.
Any server compliant with this document that implements the SETQUOTA Any server compliant with this document that implements the SETQUOTA
command (see Section 4.1.3) MUST also return the "QUOTASET" command (see Section 4.1.3) MUST also return the "QUOTASET"
capability. capability.
This document also reserves all other capabilities starting with This document also reserves all other capabilities starting with the
"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.
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 the IMAP4 QUOTA extension specified in [RFC2087] has seen
this has seen deployment in servers, it has seen little deployment in deployment in servers, it has seen little deployment in clients.
clients. Since the meaning of the resources was left implementation- Since the meaning of the resources was implementation dependent, it
dependent, it was impossible for a client implementation to determine was impossible for a client implementation to determine which
which resources were supported, and impossible to determine which resources were supported, and it was impossible to determine which
mailboxes were in a given quota root (see Section 3.2), without a mailboxes were in a given quota root (see Section 3.2) without a
priori knowledge of the implementation. priori knowledge of the implementation.
2. 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 before such lines unless specifically mentioned.
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 capitalized words are IMAP keywords [RFC3501] [RFC9051] or
keywords from this document.
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].
These MUST be registered with IANA. These MUST be registered with IANA.
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 63 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 an 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
or be configured, to disallow any command if the limit on a resource be configured, to disallow any command if the limit on a resource is
is or would be exceeded. or would be exceeded.
All resources which the server handles MUST be advertised in a All resources that the server handles MUST be advertised in a
CAPABILITY response/response code consisting of the resource name CAPABILITY response/response code consisting of the resource name
prefixed by "QUOTA=RES-". 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
This document introduces a concept of a "quota root", as resource This document introduces the concept of a "quota root", as resource
limits can apply across multiple IMAP mailboxes. limits can apply across multiple IMAP mailboxes.
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 document 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] [RFC9051]. 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 arbitrary mailboxes or mailbox calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
hierarchies. hierarchies.
Not all resources may be limitable or calculable for all quota roots. Not all resources may be limitable or calculable for all quota roots.
Further, not all resources may support all limits - some limits may Furthermore, not all resources may support all limits; some limits
be present in the underlying system. A server implementation of this may be present in the underlying system. A server implementation of
memo SHOULD advise the client of such inherent limits, by generating this memo SHOULD advise the client of such inherent limits, by
QUOTA (Section 4.2.1) responses, and SHOULD advise the client of generating QUOTA (Section 4.2.1) responses, and SHOULD advise the
which resources are limitable for a particular quota root. A client of which resources are limitable for a particular quota root.
SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an
implementation-dependent way, if the granularity of the underlying implementation-dependent way, if the granularity of the underlying
system demands it. A client MUST be prepared for a SETQUOTA system demands it. A client MUST be prepared for a SETQUOTA
(Section 4.1.3) command to fail if a limit cannot be set. (Section 4.1.3) command to fail if a limit cannot be set.
Implementation Notes: This means that, for example under UNIX, a Implementation Notes: This means that, for example, under UNIX, a
quota root may have a MESSAGE (Section 5.2) quota always set due to quota root may have a MESSAGE (Section 5.2) quota always set due to
the number of inodes available on the filesystem, and similarly the number of inodes available on the filesystem; similarly, STORAGE
STORAGE (Section 5.1) may be rounded to the nearest block and limited (Section 5.1) may be rounded to the nearest block and limited by free
by free filesystem space. filesystem space.
4. Definitions 4. Definitions
4.1. Commands 4.1. Commands
The following commands exist for manipulation and querying quotas. The following commands exist for manipulation and querying quotas.
4.1.1. GETQUOTA 4.1.1. GETQUOTA
Arguments: quota root Arguments: quota root
Responses: REQUIRED untagged responses: QUOTA Responses: REQUIRED untagged responses: QUOTA
Result: OK - getquota completed Result: OK - getquota completed
NO - getquota error: no such quota root, permission denied NO - getquota error: no such quota root, permission
denied
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The GETQUOTA command takes the name of a quota root and returns the 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. quota root's resource usage and limits in an untagged QUOTA response.
(Names of quota roots applicable to a particular mailbox can be (Names of quota roots applicable to a particular mailbox can be
discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.) discovered by issuing the GETQUOTAROOT command; see Section 4.1.2.)
Note that the server is not required to support any specific resource Note that the server is not required to support any specific resource
type (as advertised in the CAPABILITY response, i.e. all capability type (as advertised in the CAPABILITY response, i.e., all capability
items with the "QUOTA=RES-" prefix) for any particular quota root. items with the "QUOTA=RES-" prefix) for any particular quota root.
Example: Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
[...] [...]
C: G0001 GETQUOTA "!partition/sda4" C: G0001 GETQUOTA "!partition/sda4"
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0001 OK Getquota complete S: G0001 OK Getquota complete
4.1.2. GETQUOTAROOT 4.1.2. GETQUOTAROOT
Arguments: mailbox name Arguments: mailbox name
Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
Result: OK - getquotaroot completed Result: OK - getquotaroot completed
NO - getquotaroot error: permission denied NO - getquotaroot error: permission denied
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
The GETQUOTAROOT command takes a mailbox name and returns the list of The GETQUOTAROOT command takes a mailbox name and returns the list of
quota roots for the mailbox in an untagged QUOTAROOT response. For quota roots for the mailbox in an untagged QUOTAROOT response. For
each listed quota root, it also returns the quota root's resource each listed quota root, it also returns the quota root's resource
usage and limits in an untagged QUOTA response. usage and limits in an untagged QUOTA response.
Note that the mailbox name parameter doesn't have to reference an Note that the mailbox name parameter doesn't have to reference an
existing mailbox. This can be handy in order to determine which existing mailbox. This can be handy in order to determine which
quotaroot would apply to a mailbox when it gets created. quota root would apply to a mailbox when it gets created.
Example: Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
[...] [...]
[...] [...]
C: G0002 GETQUOTAROOT INBOX C: G0002 GETQUOTAROOT INBOX
S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
S: * QUOTA "#user/alice" (MESSAGE 42 1000) S: * QUOTA "#user/alice" (MESSAGE 42 1000)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
S: G0002 OK Getquotaroot complete S: G0002 OK Getquotaroot complete
4.1.3. SETQUOTA 4.1.3. SETQUOTA
Arguments: quota root Arguments: quota root list of resource limits
list of resource limits Responses: untagged responses: QUOTA
Responses: untagged responses: QUOTA Result: OK - setquota completed
Result: OK - setquota completed NO - setquota error: can't set that data
NO - setquota error: can't set that data
BAD - command unknown or arguments invalid BAD - command unknown or arguments invalid
Note that unlike other command/responses/response codes defined in Note that unlike other command/responses/response codes defined in
this document, support for SETQUOTA command requires the server to this document, support for the SETQUOTA command requires the server
advertise "QUOTASET" capability. to advertise the "QUOTASET" capability.
The SETQUOTA command takes the name of a mailbox quota root and a The SETQUOTA command takes the name of a mailbox quota root and a
list of resource limits. The resource limits for the named quota list of resource limits. The resource limits for the named quota
root are changed to be the specified limits. Any previous resource root are changed to the specified limits. Any previous resource
limits for the named quota root are discarded, even resource limits limits for the named quota root are discarded, even resource limits
not explicitly listed in the SETQUOTA command. (For example, if the not explicitly listed in the SETQUOTA command. (For example, if the
quota root had both STORAGE and MESSAGE limits assigned to the quota quota root had both STORAGE and MESSAGE limits assigned to the quota
root before the SETQUOTA is called and the SETQUOTA only includes the root before the SETQUOTA is called and the SETQUOTA only includes the
STORAGE limit, then the MESSAGE limit is removed from the quota STORAGE limit, then the MESSAGE limit is removed from the quota
root.) root.)
If the named quota root did not previously exist, an implementation If the named quota root did not previously exist, an implementation
may optionally create it and change the quota roots for any number of may optionally create it and change the quota roots for any number of
existing mailboxes in an implementation-defined manner. existing mailboxes in an implementation-defined manner.
If the implementation chooses to change the quota roots for some If the implementation chooses to change the quota roots for some
existing mailboxes such changes SHOULD be announced with untagged existing mailboxes, such changes SHOULD be announced with untagged
QUOTA responses. QUOTA responses.
Example: Example:
S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
MESSAGE [...] MESSAGE [...]
[...] [...]
C: S0000 GETQUOTA "#user/alice" C: S0000 GETQUOTA "#user/alice"
S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
S: S0000 OK Getquota completed S: S0000 OK Getquota completed
C: S0001 SETQUOTA "#user/alice" (STORAGE 510) C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
S: * QUOTA "#user/alice" (STORAGE 58 512) S: * QUOTA "#user/alice" (STORAGE 58 512)
// The server has rounded the STORAGE quota limit requested to the // The server has rounded the STORAGE quota limit requested to
nearest 512 blocks of 1024 octects, or else another client has the nearest 512 blocks of 1024 octets; otherwise, another client
performed a near simultaneous SETQUOTA, using a limit of 512. has performed a near-simultaneous SETQUOTA using a limit of 512.
S: S0001 OK Rounded quota S: S0001 OK Rounded quota
C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)
S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
// The server has not changed the quota, since this is a // The server has not changed the quota, since this is a
filesystem limit, and cannot be changed. The QUOTA response here filesystem limit, and it cannot be changed. The QUOTA
is entirely optional. response here is entirely optional.
S: S0002 NO Cannot change system limit S: S0002 NO Cannot change system limit
4.1.4. New STATUS attributes 4.1.4. New STATUS attributes
DELETED and DELETED-STORAGE status data items allow to estimate the The DELETED and DELETED-STORAGE status data items allow for
amount of resource freed by an EXPUNGE on a mailbox. estimation of the amount of resources that could be freed by an
EXPUNGE on a mailbox.
The DELETED status data item requests the server to return the number The DELETED status data item requests the server to return the number
of messages with \Deleted flag set. The DELETED status data item is of messages with the \Deleted flag set. The DELETED status data item
only required to be implemented when the server advertises QUOTA=RES- is only required to be implemented when the server advertises the
MESSAGE capability. "QUOTA=RES-MESSAGE" capability.
The DELETED-STORAGE status data item requests the server to return The DELETED-STORAGE status data item requests the server to return
the amount of storage space that can be reclaimed by performing the amount of storage space that can be reclaimed by performing
EXPUNGE on the mailbox. The server SHOULD return the exact value, EXPUNGE on the mailbox. The server SHOULD return the exact value;
however it is recognized that the server may have to do non-trivial however, it is recognized that the server may have to do a non-
amount of work to calculate it. If the calculation of the exact trivial amount of work to calculate it. If the calculation of the
value would take a long time, the server MAY instead return the sum exact value would take a long time, the server MAY instead return the
of RFC822.SIZEs of messages with the \Deleted flag set. The DELETED- sum of the RFC822.SIZE of the messages with the \Deleted flag set.
STORAGE status data item is only required to be implemented when the The DELETED-STORAGE status data item is only required to be
server advertises QUOTA=RES-STORAGE capability. implemented when the server advertises the "QUOTA=RES-STORAGE"
capability.
Example: Example:
S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
[...] MESSAGE [...]
[...] [...]
C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
// 12 messages, 4 of which would be deleted when an EXPUNGE // 12 messages, 4 of which would be deleted when an EXPUNGE
happens. happens.
skipping to change at page 10, line 15 skipping to change at line 427
4.2. Responses 4.2. Responses
The following responses may be sent by the server. The following responses may be sent by the server.
4.2.1. QUOTA 4.2.1. QUOTA
Data: quota root name Data: quota root name
list of resource names, usages, and limits list of resource names, usages, and limits
This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or
SETQUOTA command. The first string is the name of the quota root for SETQUOTA command. The first string is the name of the quota root for
which this quota applies. which this quota applies.
The name is followed by a S-expression format list of the resource The name is followed by an S-expression format list of the resource
usage and limits of the quota root. The list contains zero or more usage and limits of the quota root. The list contains zero or more
triplets. Each triplet contains a resource name, the current usage triplets. Each triplet contains a resource name, the current usage
of the resource, and the resource limit. of the resource, and the resource limit.
Resources not named in the list are not limited in the quota root. Resources not named in the list are not limited in the quota root.
Thus, an empty list means there are no administrative resource limits Thus, an empty list means there are no administrative resource limits
in the quota root. in the quota root.
Example: S: * QUOTA "" (STORAGE 10 512) Example:
S: * QUOTA "" (STORAGE 10 512)
4.2.2. QUOTAROOT 4.2.2. QUOTAROOT
Data: mailbox name Data: mailbox name
zero or more quota root names zero or more quota root names
This response occurs as a result of a GETQUOTAROOT command. The This response occurs as a result of a GETQUOTAROOT command. The
first string is the mailbox and the remaining strings are the names first string is the mailbox and the remaining strings are the names
of the quota roots for the mailbox. of the quota roots for the mailbox.
Examples: Examples:
S: * QUOTAROOT INBOX "" S: * QUOTAROOT INBOX ""
// The INBOX mailbox is covered by a single quota root with name "". // The INBOX mailbox is covered by a single quota root with
name "".
S: * QUOTAROOT comp.mail.mime S: * QUOTAROOT comp.mail.mime
// The comp.mail.mime mailbox has no quota root associated with it, // The comp.mail.mime mailbox has no quota root associated
but one can be created. with it, but one can be created.
4.3. Response Codes 4.3. Response Codes
4.3.1. OVERQUOTA 4.3.1. OVERQUOTA
OVERQUOTA response code SHOULD be returned in the tagged NO response The OVERQUOTA response code SHOULD be returned in the tagged NO
to an APPEND/COPY/MOVE when the addition of the message(s) puts the response to an APPEND/COPY/MOVE when the addition of the message(s)
target mailbox over any one of its quota limits. puts the target mailbox over any one of its quota limits.
Example 1: C: A003 APPEND saved-messages (\Seen) {326} Example 1:
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: A003 APPEND saved-messages (\Seen) {326}
C: From: Fred Foobar <foobar@Blurdybloop.example> S: + Ready for literal data
C: Subject: afternoon meeting C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: To: mooch@owatagu.siam.edu.example C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Message-Id: <B27397-0100000@Blurdybloop.example> C: Subject: afternoon meeting
C: MIME-Version: 1.0 C: To: mooch@owatagu.siam.edu.example
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: C: MIME-Version: 1.0
C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
S: A003 NO [OVERQUOTA] APPEND Failed C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C:
S: A003 NO [OVERQUOTA] APPEND Failed
The OVERQUOTA response code MAY also be returned in an untagged NO The OVERQUOTA response code MAY also be returned in an untagged NO
response in the authenticated or the selected state, when a mailbox response in the authenticated or the selected state when a mailbox
exceeds soft quota. For example, such OVERQUOTA response code might exceeds soft quota. For example, such OVERQUOTA response codes might
be sent as a result of an external event (e.g. LMTP delivery or be sent as a result of an external event (e.g., Local Mail Transfer
COPY/MOVE/APPEND in another IMAP connection) that causes the Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another
currently selected mailbox to exceed soft quota. Note that such IMAP connection) that causes the currently selected mailbox to exceed
OVERQUOTA response code might be ambiguous, because it might relate soft quota. Note that such an OVERQUOTA response code might be
to the target mailbox (as specified in COPY/MOVE/APPEND) or to the ambiguous because it might relate to the target mailbox (as specified
currently selected mailbox. (The WG chose not to address this in COPY/MOVE/APPEND) or to the currently selected mailbox. (The
deficiency due to syntactic limitations of IMAP response codes and EXTRA WG chose not to address this deficiency due to syntactic
because such events are likely to be rare.) This form of the limitations of IMAP response codes and because such events are likely
OVERQUOTA response codes MUST NOT be returned if there is no mailbox to be rare.) This form of the OVERQUOTA response codes MUST NOT be
selected and no command in progress that adds a message to a mailbox returned if there is no mailbox selected and no command in progress
(e.g. APPEND). that adds a message to a mailbox (e.g., APPEND).
Example 2: C: A003 APPEND saved-messages (\Seen) {326} Example 2:
S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
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: A004 COPY 2:4 MEETING C: A003 APPEND saved-messages (\Seen) {326}
S: * NO [OVERQUOTA] Soft quota has been exceeded S: + Ready for literal data
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
command completed C: From: Fred Foobar <foobar@Blurdybloop.example>
C: Subject: afternoon meeting
C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example>
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: A004 COPY 2:4 MEETING
S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
command completed
5. Resource Type Definitions 5. Resource Type Definitions
The following resource types are defined in this memo. A server The following resource types are defined in this memo. A server
supporting a resource type MUST advertise this as a CAPABILITY with a supporting a resource type MUST advertise this as a CAPABILITY with a
name consisting of the resource name prefixed by "QUOTA=RES-". A name consisting of the resource name prefixed by "QUOTA=RES-". A
server MAY support multiple resource types, and MUST advertise all server MAY support multiple resource types and MUST advertise all
resource types it supports. resource types it supports.
5.1. STORAGE 5.1. STORAGE
The physical space estimate, in units of 1024 octets, of the "STORAGE" is the physical space estimate, in units of 1024 octets, of
mailboxes governed by the quota root. This MAY not be the same as the mailboxes governed by the quota root. This MAY not be the same
the sum of the RFC822.SIZE of the messages. Some implementations MAY as the sum of the RFC822.SIZE of the messages. Some implementations
include metadata sizes for the messages and mailboxes, other MAY include metadata sizes for the messages and mailboxes, and other
implementations MAY store messages in such a way that the physical implementations MAY store messages in such a way that the physical
space used is smaller, for example due to use of compression. space used is smaller, for example, due to use of compression.
Additional messages might not increase the usage. Client MUST NOT Additional messages might not increase the usage. Clients MUST NOT
use the usage figure for anything other than informational purposes, use the usage figure for anything other than informational purposes;
for example, they MUST NOT refuse to APPEND a message if the limit 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 less the usage is smaller than the RFC822.SIZE divided by 1024 octets
message, but it MAY warn about such condition. of the message, but it MAY warn about such condition.
The usage figure may change as a result of performing actions not The usage figure may change as a result of performing actions not
associated with adding new messages to the mailbox, such as SEARCH, associated with adding new messages to the mailbox, such as SEARCH,
since this may increase the amount of metadata included in the since this may increase the amount of metadata included in the
calculations. calculations.
When the server supports this resource type, it MUST also support the When the server supports this resource type, it MUST also support the
DELETED-STORAGE status data item. DELETED-STORAGE status data item.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-STORAGE". advertising the "QUOTA=RES-STORAGE" capability.
A resource named the same was also given as an example in RFC2087 A resource named the same was also given as an example in [RFC2087].
[RFC2087]. This document provides a more precise definition. This document provides a more precise definition.
5.2. MESSAGE 5.2. MESSAGE
The number of messages stored within the mailboxes governed by the "MESSAGE" is the number of messages stored within the mailboxes
quota root. This MUST be an exact number, however, clients MUST NOT governed by the quota root. This MUST be an exact number; however,
assume that a change in the usage indicates a change in the number of clients MUST NOT assume that a change in the usage indicates a change
messages available, since the quota root may include mailboxes the in the number of messages available, since the quota root may include
client has no access to. mailboxes the client has no access to.
When the server supports this resource type, it MUST also support the When the server supports this resource type, it MUST also support the
DELETED status data item. DELETED status data item.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-MESSAGE". advertising the "QUOTA=RES-MESSAGE" capability.
A resource named the same was also given as an example in RFC2087 A resource named the same was also given as an example in [RFC2087].
[RFC2087]. This document provides a more precise definition. This document provides a more precise definition.
5.3. MAILBOX 5.3. MAILBOX
The number of mailboxes governed by the quota root. This MUST be an "MAILBOX" is the number of mailboxes governed by the quota root.
exact number, however, clients MUST NOT assume that a change in the This MUST be an exact number; however, clients MUST NOT assume that a
usage indicates a change in the number of mailboxes, since the quota change in the usage indicates a change in the number of mailboxes,
root may include mailboxes the client has no access to. since the quota root may include mailboxes the client has no access
to.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-MAILBOX". advertising the "QUOTA=RES-MAILBOX" capability.
5.4. ANNOTATION-STORAGE 5.4. ANNOTATION-STORAGE
The maximum size of all annotations [RFC5257], in units of 1024 "ANNOTATION-STORAGE" is the maximum size of all annotations
octets, associated with all messages in the mailboxes governed by the [RFC5257], in units of 1024 octets, associated with all messages in
quota root. the mailboxes governed by the quota root.
Support for this resource MUST be indicated by the server by Support for this resource MUST be indicated by the server by
advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability.
6. Interaction with IMAP ACL extension (RFC 4314) 6. Interaction with IMAP ACL Extension (RFC 4314)
This section lists [RFC4314] rights required to execute quota related This section lists [RFC4314] rights required to execute quota-related
commands when both RFC 4314 and this document are implemented. commands when both RFC 4314 and this document are implemented.
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non | | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non |
+===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
| GETQUOTA | | | | | | | | | | | | + | | GETQUOTA | | | | | | | | | | | | + |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| GETQUOTAROOT | |*| | | | | | | | | | * | | GETQUOTAROOT | |*| | | | | | | | | | * |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
| SETQUOTA | | | | | | | | | | + | | | | SETQUOTA | | | | | | | | | | + | | |
+-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
Table 1 Table 1
See Section 4 of RFC 4314 for conventions used in this table. See Section 4 of [RFC4314] for conventions used in this table.
Legend: Legend:
+ - The right is required "+": The right is required
* - Only one of the rights marked with * is required "*": Only one of the rights marked with * is required
"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is "Any": At least one of the "l", "r", "i", "k", "x", or "a" rights is
required required
"Non" - no rights required to perform the command "Non": No rights required to perform the command
Note that which permissions are needed in order to perform Note that which permissions are needed in order to perform a
GETQUOTAROOT command depends on the quota resource type being GETQUOTAROOT command depends on the quota resource type being
requested. For example, a quota on number of messages (MESSAGE requested. For example, a quota on the number of messages (MESSAGE
resource type) or total size of messages (STORAGE resource type) resource type) or total size of messages (STORAGE resource type)
requires "r" right on the mailbox in question, since the quota requires "r" right on the mailbox in question, since the quota
involved would reveal information about the number (or total size) of involved would reveal information about the number (or total size) of
messages in the mailbox. By comparison, the MAILBOX resource type messages in the mailbox. By comparison, the MAILBOX resource type
doesn't require any right. doesn't require any right.
7. Formal syntax 7. Formal Syntax
The following syntax specification uses the Augmented Backus-Naur The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [ABNF]. Form (ABNF) notation as specified in [ABNF].
Non-terminals referenced but not defined below are as defined by Non-terminals referenced but not defined below are as defined by
IMAP4 [RFC3501]. IMAP4 [RFC3501] [RFC9051].
Except as noted otherwise, all alphabetic characters are case- Except as noted otherwise, all alphabetic characters are case
insensitive. The use of upper or lower case characters to define insensitive. The use of uppercase or lowercase characters to define
token strings is for editorial clarity only. Implementations MUST token strings is for editorial clarity only. Implementations MUST
accept these strings in a case-insensitive fashion. accept these strings in a case-insensitive fashion.
getquota = "GETQUOTA" SP quota-root-name getquota = "GETQUOTA" SP quota-root-name
getquotaroot = "GETQUOTAROOT" SP mailbox getquotaroot = "GETQUOTAROOT" SP mailbox
quota-list = "(" quota-resource *(SP quota-resource) ")" quota-list = "(" quota-resource *(SP quota-resource) ")"
quota-resource = resource-name SP resource-usage SP resource-limit quota-resource = resource-name SP resource-usage SP resource-limit
quota-response = "QUOTA" SP quota-root-name SP quota-list quota-response = "QUOTA" SP quota-root-name SP quota-list
quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name)
setquota = "SETQUOTA" SP quota-root-name SP setquota-list setquota = "SETQUOTA" SP quota-root-name SP setquota-list
setquota-list = "(" [setquota-resource *(SP setquota-resource)] setquota-list = "(" [setquota-resource *(SP setquota-resource)]
")" ")"
setquota-resource = resource-name SP resource-limit setquota-resource = resource-name SP resource-limit
quota-root-name = astring quota-root-name = astring
resource-limit = number64
resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / resource-limit = number64
"ANNOTATION-STORAGE" / resource-name-ext resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
"ANNOTATION-STORAGE" / resource-name-ext
resource-name-ext = atom resource-name-ext = atom
;; Future resource registrations
;; Future resource registrations resource-usage = number64
;; must be less than corresponding resource-limit
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 capability-quota = capa-quota-res / "QUOTASET"
;; One or more capa-quota-res must be returned.
;; Also "QUOTASET" can optionally be returned.
;; is advertised. capa-quota-res = "QUOTA=RES-" resource-name
status-att-val =/ status-att-deleted / status-att =/ "DELETED" / "DELETED-STORAGE"
;; DELETED status data item MUST be supported
;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
;; DELETED-STORAGE status data item MUST be
;; supported when the "QUOTA=RES-STORAGE"
;; capability is advertised.
status-att-deleted-storage 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
;; DELETED status data item MUST be supported ;; when the "QUOTA=RES-MESSAGE" capability is
;; advertised.
;; 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 the "QUOTA=RES-STORAGE"
;; capability is advertised.
;; DELETED-STORAGE status data item MUST be resp-text-code =/ "OVERQUOTA"
;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised.
resp-text-code =/ "OVERQUOTA"
number64 = <Defined in RFC 9051> number64 = <Defined in RFC 9051>
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.
As for any resource shared across users (for example a quota root As for any resource shared across users (for example, a quota root
attached to a set of shared mailboxes), a user that can consume or attached to a set of shared mailboxes), a user that can consume or
render unusable the resource can affect the resources available to render unusable the resource can affect the resources available to
the other users; this might occur, for example, by a user with the other users; this might occur, for example, by a user with
permission to execute SETQUOTA setting an artificially small value. permission to execute the SETQUOTA setting, which sets an
artificially small value.
Note that computing resource usage might incur a heavy load on the Note that computing resource usage might incur a heavy load on the
server. Server implementers should consider implementation server. Server implementers should consider implementation
techniques that lower load on servers, such as caching of resource techniques that lower the load on servers such as caching of resource
usage information or usage of less precise computations when under usage information or usage of less precise computations when under
heavy load. heavy load.
9. IANA Considerations 9. IANA Considerations
9.1. Changes/additions to the IMAP4 capabilities registry 9.1. Changes/Additions to the IMAP Capabilities Registry
IMAP4 capabilities are registered by publishing a standards track or
IESG approved Informational or Experimental RFC. The registry is
currently located at:
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 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
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
Section 9.3 for the registration templates.
9.3. Registrations of IMAP Quota Resource Types
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: Section 5.1 of RFCXXXX
Name of the quota resource type: MESSAGE IMAP4 capabilities are registered by publishing a Standards Track or
an IESG-approved Informational or Experimental RFC. The "IMAP
Capabilities" registry is currently located at
<https://www.iana.org/assignments/imap4-capabilities>.
Author: Alexey Melnikov <alexey.melnikov@isode.com> IANA has updated the reference for the QUOTA extension to point to
this document. IANA has also added the "QUOTA=" prefix and the
"QUOTASET" capability to the "IMAP Capabilities" registry with this
document as the reference.
Change Controller: IESG <iesg@ietf.org> IANA has added the following notes to the "IMAP Capabilities"
registry:
Description: The number of messages stored within the mailboxes The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See
governed by the quota root. Section 9.2 of that document for values that follow this prefix.
Extra required IMAP commands/responses: DELETED STATUS request data All other capabilities starting with the "QUOTA=" prefix are reserved
item and response data item for future IETF Stream extensions to RFC 9208.
Extra optional IMAP commands/responses: N/A 9.2. IMAP Quota Resource Type Registry
Reference: Section 5.2 of RFCXXXX IANA has created a new registry for IMAP quota resource types. The
registration policy for the "IMAP Quota Resource Types" registry is
"Specification Required" [RFC8126].
Name of the quota resource type: MAILBOX When registering a new quota resource type, the registrant needs to
Author: Alexey Melnikov <alexey.melnikov@isode.com> provide the following:
Change Controller: IESG <iesg@ietf.org> * the name of the quota resource type
Description: The number of mailboxes governed by the quota root. * a short description
Extra required IMAP commands/responses: N/A * extra required IMAP commands/responses (if any)
Extra optional IMAP commands/responses: N/A * extra optional IMAP commands/responses (if any)
Reference: Section 5.3 of RFCXXXX * name and email address of author
Name of the quota resource type: ANNOTATION-STORAGE * name and email address of change controller
Author: Alexey Melnikov <alexey.melnikov@isode.com> * a reference to a specification that describes the quota resource
type in more detail
Change Controller: IESG <iesg@ietf.org> Designated experts should check that the provided references are
correct, the references describe the quota resource type being
registered in sufficient detail to be implementable, the syntax of
any optional commands/responses is correct (e.g., ABNF validates),
and the 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.
Description: The maximum size of all annotations [RFC5257], in units The initial contents of the "IMAP Quota Resource Types" registry are
of 1024 octets, associated with all messages in the mailboxes as follows:
governed by the quota root.
Extra required IMAP commands/responses: N/A +===================+=======================================+
| field name | field value |
+===================+=======================================+
| Name of the quota | STORAGE |
| resource type: | |
+-------------------+---------------------------------------+
| Description: | The physical space estimate, in units |
| | of 1024 octets, of the mailboxes |
| | governed by the quota root. |
+-------------------+---------------------------------------+
| Extra required | DELETED-STORAGE STATUS request data |
| IMAP commands/ | item and response data item |
| responses: | |
+-------------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+-------------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+-------------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+-------------------+---------------------------------------+
| Reference: | Section 5.1 of RFC 9208 |
+-------------------+---------------------------------------+
Extra optional IMAP commands/responses: N/A Table 2: STORAGE
Reference: Section 5.4 of RFCXXXX +=====================+==========================================+
| field name | field value |
+=====================+==========================================+
| Name of the quota | MESSAGE |
| resource type: | |
+---------------------+------------------------------------------+
| Description: | The number of messages stored within the |
| | mailboxes governed by the quota root. |
+---------------------+------------------------------------------+
| Extra required IMAP | DELETED STATUS request data item and |
| commands/responses: | response data item |
+---------------------+------------------------------------------+
| Extra optional IMAP | N/A |
| commands/responses: | |
+---------------------+------------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+---------------------+------------------------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+---------------------+------------------------------------------+
| Reference: | Section 5.2 of RFC 9208 |
+---------------------+------------------------------------------+
10. Contributors Table 3: MESSAGE
Dave Cridland wrote lots of text in an earlier draft that became the +==================================+=============================+
basis for this document. | field name | field value |
+==================================+=============================+
| Name of the quota resource type: | MAILBOX |
+----------------------------------+-----------------------------+
| Description: | The number of mailboxes |
| | governed by the quota root. |
+----------------------------------+-----------------------------+
| Extra required IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Extra optional IMAP commands/ | N/A |
| responses: | |
+----------------------------------+-----------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------------------------+-----------------------------+
| Change Controller: | IESG <iesg@ietf.org> |
+----------------------------------+-----------------------------+
| Reference: | Section 5.3 of RFC 9208 |
+----------------------------------+-----------------------------+
11. Acknowledgments Table 4: MAILBOX
Editor of this document would like to thank the following people who +================+=======================================+
provided useful comments or participated in discussions that lead to | field name | field value |
this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg, +================+=======================================+
Benjamin Kaduk, Roman Danyliw, Eric Vyncke. | Name of the | ANNOTATION-STORAGE |
| quota resource | |
| type: | |
+----------------+---------------------------------------+
| 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 | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Extra optional | N/A |
| IMAP commands/ | |
| responses: | |
+----------------+---------------------------------------+
| Author: | Alexey Melnikov |
| | <alexey.melnikov@isode.com> |
+----------------+---------------------------------------+
| Change | IESG <iesg@ietf.org> |
| Controller: | |
+----------------+---------------------------------------+
| Reference: | Section 5.4 of RFC 9208 |
+----------------+---------------------------------------+
This document is a revision of RFC 2087. It borrows a lot of text Table 5: ANNOTATION-STORAGE
from RFC 2087. Thus work of the RFC 2087 author John Myers is
appreciated.
12. Changes since RFC 2087 10. Changes Since RFC 2087
This document is a revision of RFC 2087. It tries to clarify the This document is a revision of [RFC2087], and it aims to clarify the
meaning of different terms used by RFC 2087. It also provides more meaning of different terms that were used in that RFC. It also
examples, gives guidance on allowed server behaviour, defines IANA provides more examples, gives guidance on allowed server behavior,
registry for quota resource types and provides initial registrations defines an IANA registry for quota resource types, and provides
for 4 of them. initial registrations for 4 of them.
When compared with RFC 2087, this document defines two more commonly When compared with [RFC2087], this document defines two more commonly
used resource type, adds optional OVERQUOTA response code and defines used resource types, adds an optional OVERQUOTA response code, and
two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The defines two extra STATUS data items ("DELETED" and "DELETED-
DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE STORAGE"). The DELETED STATUS data item must be implemented if the
capability is advertised. The DELETED-STORAGE STATUS data item must "QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE
be implemented if the QUOTA=RES-STORAGE capability is advertised. STATUS data item must be implemented if the "QUOTA=RES-STORAGE"
For extensibility quota usage and quota limits are now 63 bit capability is advertised. For extensibility, quota usage and quota
unsigned integers. limits are now 63-bit unsigned integers.
13. References 11. References
13.1. Normative References 11.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Syntax Specifications: ABNF", RFC 5234, January 2008, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>. <https://www.rfc-editor.org/info/rfc3501>.
skipping to change at page 21, line 10 skipping to change at line 961
[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 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
Access Protocol (IMAP) - Version 4rev2", RFC 9051, Access Protocol (IMAP) - Version 4rev2", RFC 9051,
DOI 10.17487/RFC9051, August 2021, DOI 10.17487/RFC9051, August 2021,
<https://www.rfc-editor.org/info/rfc9051>. <https://www.rfc-editor.org/info/rfc9051>.
13.2. Informative References 11.2. Informative References
[RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
DOI 10.17487/RFC2033, October 1996,
<https://www.rfc-editor.org/info/rfc2033>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
Acknowledgments
The editor of this document would like to thank the following people
who provided useful comments or participated in discussions that lead
to this update of [RFC2087]: John Myers, Cyrus Daboo, Lyndon
Nerenberg, Benjamin Kaduk, Roman Danyliw, and Éric Vyncke.
This document is a revision of [RFC2087], and it borrows a lot of
text from that RFC. Thus, the work of John Myers, the author of
[RFC2087], is appreciated.
Contributors
Dave Cridland wrote a lot of text in an earlier draft version that
became the basis for this document.
Author's Address Author's Address
Alexey Melnikov Alexey Melnikov
Isode Limited Isode Limited
Email: alexey.melnikov@isode.com Email: alexey.melnikov@isode.com
URI: https://www.isode.com URI: https://www.isode.com
 End of changes. 158 change blocks. 
441 lines changed or deleted 503 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/