draft-ietf-extra-quota-01.txt   draft-ietf-extra-quota-02.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Intended status: Standards Track June 15, 2020 Intended status: Standards Track July 1, 2020
Expires: December 17, 2020 Expires: January 2, 2021
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-01 draft-ietf-extra-quota-02
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) permits administrative limits on resource usage (quotas) to be
manipulated through the IMAP protocol. manipulated through the IMAP protocol.
This memo obsoletes RFC 2087, but attempts to remain backwards This memo obsoletes RFC 2087, but attempts to remain backwards
compatible whenever possible. compatible whenever possible.
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 December 17, 2020. This Internet-Draft will expire on January 2, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 28 skipping to change at page 2, line 28
Table of Contents Table of Contents
1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3
2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4
3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6
4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9
5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 10 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11
5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12
6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. Registrations of IMAP Quota Resource Types . . . . . . . 14 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . 16 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
13.2. Informative References . . . . . . . . . . . . . . . . . 17 14.1. Normative References . . . . . . . . . . . . . . . . . . 17
14.2. Informative References . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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 34 skipping to change at page 3, line 35
"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 [RFC2119] 8174 [RFC8174] when, and only when, they appear 14 RFC2119 [RFC2119] 8174 [RFC8174] when, and only when, they appear
in all capitals, as shown here. in all capitals, as shown here.
Other capitalised words are IMAP4 [RFC3501] keywords or keywords from Other capitalised words are IMAP4 [RFC3501] keywords or keywords from
this document. this document.
2. Introduction and Overview 2. Introduction and Overview
This document defines a couple of extension to the Internet Message
Access Protocol [RFC3501] for querying and manipulating
administrative limits on resource usage (quotas).
The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server.
Some commands and responses defined in this document are not present Some responses and response codes defined in this document are not
in such servers, and clients MUST NOT rely on their presence in the present in such servers (see Section 13 for more details), and
absence of any capability beginning with "QUOTA=". clients MUST NOT rely on their presence in the absence of any
capability beginning with "QUOTA=".
Any server compliant with this document MUST also return at least one 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.
Any server compliant with this document that implements the SETQUOTA
command (see Section 4.1.3) MUST also return the "QUOTASET"
capability.
This document also reserves all other capabilities starting with This document also reserves all other capabilities starting with
"QUOTA=" prefix to future standard track or experimental extensions "QUOTA=" prefix for future IETF stream standard track or experimental
to this document. 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 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
skipping to change at page 4, line 50 skipping to change at page 5, line 11
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 constisting of the resource name prefixed by "QUOTA=RES-".
For compatability with RFC2087 [RFC2087], a client which discovers For compatability with RFC 2087 [RFC2087], a client which discovers
resources available on the server which are not advertised through resources available on the server which are not advertised through
this mechanism MUST treat them as if they were completely opaque, and this mechanism MUST treat them as if they were completely opaque, and
without any meaning. without any meaning.
The resources STORAGE (Section 5.1), MESSAGE (Section 5.2) and The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
MAILBOX (Section 5.3) are defined in this document. (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in
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 memo between a Quota root name and a
skipping to change at page 6, line 37 skipping to change at page 6, line 43
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: no such mailbox, 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. quotaroot would apply to a mailbox when it gets created.
skipping to change at page 7, line 24 skipping to change at page 7, line 32
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
this document, support for SETQUOTA command requires the server to
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.
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 QUOTA=RES-STORAGE QUOTA=RES-MESSAGE S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
[...] 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 the
nearest 512 blocks of 1024 octects, or else another client has nearest 512 blocks of 1024 octects, or else another client has
performed a near simultaneous SETQUOTA, using a limit of 512. performed a near simultaneous SETQUOTA, using a limit of 512.
skipping to change at page 8, line 15 skipping to change at page 8, line 28
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 cannot be changed. The QUOTA response here
is entirely optional. 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-MESSAGES and DELETED-STORAGE status data items allow to DELETED and DELETED-STORAGE status data items allow to estimate the
estimate the amount of resource freed by an EXPUNGE on a mailbox. amount of resource freed by an EXPUNGE on a mailbox.
DELETED-MESSAGES status data item requests the server to return the DELETED status data item requests the server to return the number of
number of messages with \Deleted flag set. messages with \Deleted flag set.
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 EXPUNGE amount of storage space that can be reclaimed by performing EXPUNGE
on the mailbox. The server SHOULD return the exact value, however it on the mailbox. The server SHOULD return the exact value, however it
is recognized that the server may have to do non-trivial amount of is recognized that the server may have to do non-trivial amount of
work to calculate it. If the calculation of the exact value would work to calculate it. If the calculation of the exact value would
take a long time, the server MAY instead return the sum of take a long time, the server MAY instead return the sum of
RFC822.SIZEs of messages with the \Deleted flag set. RFC822.SIZEs of messages with the \Deleted flag set.
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-MESSAGES DELETED-STORAGE) C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
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.
S: S0003 OK Status complete. S: S0003 OK Status complete.
4.2. Responses 4.2. Responses
The following responses may be sent by the server. The following responses may be sent by the server.
skipping to change at page 11, line 28 skipping to change at page 11, line 36
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.
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 CAPABILITY "QUOTA=RES-STORAGE".
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]. In absence of information to the contrary, clients [RFC2087]. This document provides a more precise definition.
conformant to this specification connecting to servers which do not
advertise "QUOTA=RES-STORAGE", yet allow a resource named STORAGE,
MUST NOT assume that it is the same resource. [[CREF1: Is the above
restriction useful and will it be obeyed? If the answer is "no",
delete it.]]
5.2. MESSAGE 5.2. MESSAGE
The number of messages stored within the mailboxes governed by the The number of messages stored within the mailboxes governed by the
quota root. This MUST be an exact number, however, clients MUST NOT quota root. This MUST be an exact number, however, clients MUST NOT
assume that a change in the usage indicates a change in the number of assume that a change in the usage indicates a change in the number of
messages available, since the quota root may include mailboxes the messages available, since the quota root may include mailboxes the
client has no access to. 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-MESSAGE". advertising the CAPABILITY "QUOTA=RES-MESSAGE".
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], clients conformant to this specification connecting to [RFC2087]. This document provides a more precise definition.
servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a
resource named MESSAGE, MUST NOT assume that it is the same resource.
[[CREF2: As above.]]
5.3. MAILBOX 5.3. MAILBOX
The number of mailboxes governed by the quota root. This MUST be an The number of mailboxes governed by the quota root. This MUST be an
exact number, however, clients MUST NOT assume that a change in the exact number, however, clients MUST NOT assume that a change in the
usage indicates a change in the number of mailboxes, since the quota usage indicates a change in the number of mailboxes, since the quota
root may include mailboxes the client has no access to. 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 CAPABILITY "QUOTA=RES-MAILBOX".
5.4. ANNOTATION-STORAGE 5.4. ANNOTATION-STORAGE
[[CREF3: Bron to check whether this is a sensible description and [[CREF1: Bron to check whether this is a sensible description and
whether it is needed at all:]] The maximum size of all annotations whether it is needed at all:]] The maximum size of all annotations
[RFC5257], in units of 1024 octets, associated with all messages in [RFC5257], in units of 1024 octets, associated with all messages in
the mailboxes governed by the 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 CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE".
6. Interaction with IMAP ACL extension (RFC 4314) 6. Interaction with IMAP ACL extension (RFC 4314)
[[CREF4: TBD]] This section lists [RFC4314] rights required to execute quota related
commands when both RFC 4314 and this document are implemented.
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
| Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non |
| ghts | | | | | | | | | | | | |
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
| GETQUOTA | | | | | | | | | | | | * |
| GETQUOTAROOT | | * | | | | | | | | | | * |
| SETQUOTA | | | | | | | | | | + | | |
+---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+
See Section 4 of RFC 4314 for conventions used in this table.
[[CREF2: The above table needs to be reviewed based on feedback from
existing and planned implementations.]]
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-
skipping to change at page 13, line 15 skipping to change at page 13, line 32
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 = number resource-limit = number64
resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
resource-name-vnd / "ANNOTATION-STORAGE" / resource-name-vnd /
resource-name-ext resource-name-ext
resource-name-vnd = "V-" atom resource-name-vnd = "V-" atom
;; Vendor specific, must be registered with IANA. ;; Vendor specific, must be registered with IANA.
;; The "V-" prefix should be followed by a domain ;; The "V-" prefix should be followed by a domain
name name
;; under vendor's control. ;; under vendor's control.
resource-name-ext = atom resource-name-ext = atom
;; Not starting with V- and defined ;; Not starting with V- and defined
;; in a Standard Track or Experimental RFC ;; in a Standard Track or Experimental RFC
resource-names = "(" [resource-name *(SP resource-name)] ")" resource-names = "(" [resource-name *(SP resource-name)] ")"
resource-usage = number resource-usage = number64
;; must be less than corresponding resource-limit ;; must be less than corresponding resource-limit
capability-quota = capa-quota-res 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 capa-quota-res = "QUOTA=RES-" resource-name
status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE" status-att =/ "DELETED" / "DELETED-STORAGE"
[[CREF5: Should the above be optional unless the status-att-val =/ ("DELETED" SP number) /
server implements MESSAGE/STORAGE? Also sync ("DELETED-STORAGE" SP number64)
this with IMAP4rev2.]]
resp-text-code =/ "OVERQUOTA" [SP tag] resp-text-code =/ "OVERQUOTA" [SP tag]
number64 = 1*DIGIT ;; 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. information and should not be divulged to unauthorized persons.
9. IANA Considerations 9. IANA Considerations
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
skipping to change at page 14, line 38 skipping to change at page 15, line 7
description and a reference to a specification that describes the description and a reference to a specification that describes the
quota resource type in more details. quota resource type in more details.
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. details below.
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 quote resource type registry established above. IMAP quota resource type registry established above.
IANA is requested to reserve all other capabilities starting with IANA is requested to reserve all other capabilities starting with
"QUOTA=" prefix for future standard track or experimental extensions "QUOTA=" prefix for future IETF stream standard track or experimental
to this document. extensions to this document.
9.1. Registrations of IMAP Quota Resource Types 9.1. 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.
Reference: Section 5.1 of RFCXXXX Reference: Section 5.1 of RFCXXXX
Name of the quota resource type: MESSAGE Name of the quota resource type: MESSAGE
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>
skipping to change at page 15, line 35 skipping to change at page 16, line 4
Description: The number of mailboxes governed by the quota root. Description: The number of mailboxes governed by the quota root.
Reference: Section 5.3 of RFCXXXX Reference: Section 5.3 of RFCXXXX
Name of the quota resource type: Name of the quota resource type:
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 maximum size of all annotations [RFC5257], in units Description: The maximum size of all annotations [RFC5257], in units
of 1024 octets, associated with all messages in the mailboxes of 1024 octets, associated with all messages in the mailboxes
governed by the quota root. [[CREF6: Recheck against the final governed by the quota root. [[CREF3: Recheck against the final
description of "ANNOTATION-STORAGE".]] description of "ANNOTATION-STORAGE".]]
Reference: Section 5.4 of RFCXXXX Reference: Section 5.4 of RFCXXXX
10. Contributors 10. Open Issues
'"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for
"]", which is not allowed in response codes. Should we drop this
variant or change IMAP4rev2 to disallow "]" in tags?
Should "DELETED" status item be required to be implemented for
anything other than QUOTA-RES=MESSAGE? Similarly, should "DELETED-
STORAGE" status item be required to be implemented for anything other
than QUOTA-RES=STORAGE?
11. Contributors
Dave Cridland wrote lots of text in an earlier draft that became the Dave Cridland wrote lots of text in an earlier draft that became the
basis for this document. basis for this document.
11. Acknowledgments 12. Acknowledgments
Editors of this document would like to thank the following people who Editors of this document would like to thank the following people who
provided useful comments or participated in discussions that lead to provided useful comments or participated in discussions that lead to
this update to RFC 2087: this update to RFC 2087:
John Myers, John Myers,
Cyrus Daboo, Cyrus Daboo,
Lyndon Nerenberg Lyndon Nerenberg
This document is a revision of RFC 2087. It borrows a lot of text This document is a revision of RFC 2087. It borrows a lot of text
from RFC 2087. Thus work of the RFC 2087 author John Myers is from RFC 2087. Thus work of the RFC 2087 author John Myers is
appreciated. appreciated.
12. Changes since RFC 2087 13. Changes since RFC 2087
This document is a revision of RFC 2087. It tries to clarify meaning This document is a revision of RFC 2087. It tries to clarify meaning
of different terms used by RFC 2087. It also provides more examples, of different terms used by RFC 2087. It also provides more examples,
gives guidance on allowed server behaviour, defines IANA registry for gives guidance on allowed server behaviour, defines IANA registry for
quota resource types and provides initial registrations for 3 of quota resource types and provides initial registrations for 3 of
them. them.
When compared with RFC 2087, this document defines one more commonly When compared with RFC 2087, this document defines two more commonly
used resource type, adds optional OVERQUOTA response code and defines used resource type, adds optional OVERQUOTA response code and defines
two extra STATUS data items ("DELETED-MESSAGES" and "DELETED- two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that
STORAGE") must be implemented. For extensibility quota usage and quota limits
are now 63 bit unsigned integers.
13. References 14. References
13.1. Normative References 14.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for
Syntax Specifications: ABNF", RFC 5234, January 2008. Syntax Specifications: ABNF", RFC 5234, January 2008.
[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
skipping to change at page 17, line 14 skipping to change at page 17, line 36
[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>.
13.2. Informative References 14.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. 43 change blocks. 
68 lines changed or deleted 106 lines changed or added

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