draft-ietf-extra-quota-08.txt   draft-ietf-extra-quota-09.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Obsoletes: 2087 (if approved) 21 October 2021 Obsoletes: 2087 (if approved) 22 October 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 24 April 2022 Expires: 25 April 2022
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-08 draft-ietf-extra-quota-09
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 (RFC 3501/RFC 9051) that permits administrative
limits on resource usage (quotas) to be manipulated through the IMAP limits on resource usage (quotas) to be manipulated through the IMAP
protocol. 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.
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 24 April 2022. This Internet-Draft will expire on 25 April 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 4 skipping to change at page 3, line 4
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13
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) . . . . . . . 14 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Changes/additions to the IMAP4 capabilities registry . . 17 9.1. Changes/additions to the IMAP4 capabilities registry . . 17
9.2. IMAP quota resource type registry . . . . . . . . . . . . 17 9.2. IMAP quota resource type registry . . . . . . . . . . . . 18
9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 20
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 20 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21
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
in the protocol unless specifically mentioned. in the protocol before such lines unless specifically mentioned.
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", 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 IMAP keywords [RFC3501][RFC9051] or Other capitalised words are IMAP keywords [RFC3501][RFC9051] or
keywords from this document. keywords from this document.
skipping to change at page 6, line 44 skipping to change at page 6, line 33
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.)
The client can try using any of the resource types returned in Note that the server is not required to support any specific resource
CAPABILITY response (i.e. all capability items with "QUOTA=RES-" type (as advertised in the CAPABILITY response, i.e. all capability
prefix), however the server is not required to support any specific items with the "QUOTA=RES-" prefix) for any particular quota root.
resource type 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)
skipping to change at page 8, line 23 skipping to change at page 8, line 15
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 SETQUOTA command requires the server to
advertise "QUOTASET" capability. advertise "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 be the specified limits. Any previous resource
limits for the named quota root are discarded. limits for the named quota root are discarded, even resource limits
not explicitly listed in the SETQUOTA command. (For example, if the
quota root had both STORAGE and MESSAGE limits assigned to the quota
root before the SETQUOTA is called and the SETQUOTA only includes the
STORAGE limit, then the MESSAGE limit is removed from the quota
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:
skipping to change at page 10, line 44 skipping to change at page 10, line 40
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.
Example: Examples:
S: * QUOTAROOT INBOX "" S: * QUOTAROOT INBOX ""
// 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,
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 OVERQUOTA response code SHOULD be returned in the tagged NO response
to an APPEND/COPY/MOVE when the addition of the message(s) puts the to an APPEND/COPY/MOVE when the addition of the message(s) puts the
target mailbox over any one of its quota limits. target mailbox over any one of its quota limits.
Example 1: C: A003 APPEND saved-messages (\Seen) {326} Example 1: C: A003 APPEND saved-messages (\Seen) {326}
S: + Ready for literal data S: + Ready for literal data
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
skipping to change at page 14, line 35 skipping to change at page 14, line 35
+ - 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", "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
GETQUOTAROOT command depends on the quota resource type being
requested. For example, a quota on number of messages (MESSAGE
resource type) or total size of messages (STORAGE resource type)
requires "r" right on the mailbox in question, since the quota
involved would reveal information about the number (or total size) of
messages in the mailbox. By comparison, the MAILBOX resource type
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].
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 upper or lower case characters to define
skipping to change at page 17, line 5 skipping to change at page 17, line 15
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
attached to a set of shared mailboxes), a user that can consume or
render unusable the resource can affect the resources available to
the other users; this might occur, for example, by a user with
permission to execute SETQUOTA setting 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 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 IMAP4 capabilities registry
 End of changes. 16 change blocks. 
21 lines changed or deleted 41 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/