draft-ietf-extra-quota-07.txt   draft-ietf-extra-quota-08.txt 
Network Working Group A. Melnikov Network Working Group A. Melnikov
Internet-Draft Isode Internet-Draft Isode
Obsoletes: 2087 (if approved) 24 September 2021 Obsoletes: 2087 (if approved) 21 October 2021
Intended status: Standards Track Intended status: Standards Track
Expires: 28 March 2022 Expires: 24 April 2022
IMAP QUOTA Extension IMAP QUOTA Extension
draft-ietf-extra-quota-07 draft-ietf-extra-quota-08
Abstract Abstract
The QUOTA extension of the Internet Message Access Protocol (RFC This document defines a QUOTA extension of the Internet Message
3501/RFC 9051) permits administrative limits on resource usage Access Protocol (RFC 3501/RFC 9051) that permits administrative
(quotas) to be manipulated through the IMAP protocol. limits on resource usage (quotas) to be manipulated 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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 March 2022. This Internet-Draft will expire on 24 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 2, line 38 skipping to change at page 2, line 38
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 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6
4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7
4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7
4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9
4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10
4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . . 12 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) . . . . . . . 13 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14
7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Changes/additions to the IMAP4 capabilities registry . . 16 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 . . . . . . . . . . . . 17
9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
13.1. Normative References . . . . . . . . . . . . . . . . . . 19 13.1. Normative References . . . . . . . . . . . . . . . . . . 20
13.2. Informative References . . . . . . . . . . . . . . . . . 20 13.2. Informative References . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Document Conventions 1. Document Conventions
In protocol examples, this document uses a prefix of "C: " to denote In protocol examples, this document uses a prefix of "C: " to denote
lines sent by the client to the server, and "S: " for lines sent by lines sent by the client to the server, and "S: " for lines sent by
the server to the client. Lines prefixed with "// " are comments the server to the client. Lines prefixed with "// " are comments
explaining the previous protocol line. These prefixes and comments explaining the previous protocol line. These prefixes and comments
are not part of the protocol. Lines without any of these prefixes are not part of the protocol. Lines without any of these prefixes
skipping to change at page 4, line 24 skipping to change at page 4, line 24
"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 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 dependent, it was impossible for a client implementation to determine
which resources were supported, and impossible to determine which which resources were supported, and impossible to determine which
mailboxes were in a given quota root (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.
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.
skipping to change at page 5, line 28 skipping to change at page 5, line 28
All resources which the server handles MUST be advertised in a All resources which 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
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]. It SHOULD be treated as an opaque string by any clients.
Quota roots are used since not all implementations may be able to Quota roots are used since not all implementations may be able to
calculate usage, or apply quotas, on arbitary mailboxes or mailbox calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
hierarchies. hierarchies.
Not all resources may be limitable or calculatable for all quota Not all resources may be limitable or calculable for all quota roots.
roots. Further, not all resources may support all limits - some Further, not all resources may support all limits - some limits may
limits may be present in the underlying system. A server be present in the underlying system. A server implementation of this
implementation of this memo SHOULD advise the client of such inherent memo SHOULD advise the client of such inherent limits, by generating
limits, by generating QUOTA (Section 4.2.1) responses and SHOULD QUOTA (Section 4.2.1) responses, and SHOULD advise the client of
advise the client of which resources are limitable for a particular which resources are limitable for a particular quota root. A
quota root. A SETQUOTA (Section 4.1.3) command MAY also round a SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an
quota limit in an implementation dependant way, if the granularity of implementation-dependent way, if the granularity of the underlying
the underlying system demands it. A client MUST be prepared for a system demands it. A client MUST be prepared for a SETQUOTA
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, and similarly
STORAGE (Section 5.1) may be rounded to the nearest block and limited STORAGE (Section 5.1) may be rounded to the nearest block and limited
by free filesystem space. by free filesystem space.
4. Definitions 4. Definitions
4.1. Commands 4.1. Commands
skipping to change at page 6, line 31 skipping to change at page 6, line 42
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
discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.)
The client can try using any of the resource types returned in The client can try using any of the resource types returned in
CAPABILITY response (i.e. all capability items with "QUOTA=RES-" CAPABILITY response (i.e. all capability items with "QUOTA=RES-"
prefix), however the server is not required to support any specific prefix), however the server is not required to support any specific
resource type 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 [...]
[...] [...]
skipping to change at page 9, line 12 skipping to change at page 9, line 25
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 and DELETED-STORAGE status data items allow to estimate the DELETED and DELETED-STORAGE status data items allow to estimate the
amount of resource freed by an EXPUNGE on a mailbox. amount of resource freed by an EXPUNGE on a mailbox.
DELETED status data item requests the server to return the number of The DELETED status data item requests the server to return the number
messages with \Deleted flag set. DELETED status data item is only of messages with \Deleted flag set. The DELETED status data item is
required to be implemented when the server advertises QUOTA=RES- only required to be implemented when the server advertises QUOTA=RES-
MESSAGE capability. MESSAGE capability.
DELETED-STORAGE status data item requests the server to return the The DELETED-STORAGE status data item requests the server to return
amount of storage space that can be reclaimed by performing EXPUNGE the amount of storage space that can be reclaimed by performing
on the mailbox. The server SHOULD return the exact value, however it EXPUNGE on the mailbox. The server SHOULD return the exact value,
is recognized that the server may have to do non-trivial amount of however it is recognized that the server may have to do non-trivial
work to calculate it. If the calculation of the exact value would amount of work to calculate it. If the calculation of the exact
take a long time, the server MAY instead return the sum of value would take a long time, the server MAY instead return the sum
RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE of RFC822.SIZEs of messages with the \Deleted flag set. The DELETED-
status data item is only required to be implemented when the server STORAGE status data item is only required to be implemented when the
advertises QUOTA=RES-STORAGE capability. server advertises 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)
skipping to change at page 10, line 5 skipping to change at page 10, line 19
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 or GETQUOTAROOT This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a
command. The first string is the name of the quota root for which SETQUOTA command. The first string is the name of the quota root for
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 a 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.
skipping to change at page 11, line 49 skipping to change at page 12, line 20
C: To: mooch@owatagu.siam.edu.example C: To: mooch@owatagu.siam.edu.example
C: Message-Id: <B27397-0100000@Blurdybloop.example> C: Message-Id: <B27397-0100000@Blurdybloop.example>
C: MIME-Version: 1.0 C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
C: C:
C: Hello Joe, do you think we can meet at 3:30 tomorrow? C: Hello Joe, do you think we can meet at 3:30 tomorrow?
C: C:
S: * NO [OVERQUOTA] Soft quota has been exceeded S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A003 OK [APPENDUID 38505 3955] APPEND completed S: A003 OK [APPENDUID 38505 3955] APPEND completed
Example 3: C: A003 COPY 2:4 MEETING Example 3: C: A004 COPY 2:4 MEETING
S: * NO [OVERQUOTA] Soft quota has been exceeded S: * NO [OVERQUOTA] Soft quota has been exceeded
S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
command completed 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.
skipping to change at page 12, line 32 skipping to change at page 13, line 5
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 of the
message, but it MAY warn about such condition. 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 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 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]. This document provides a more precise definition. [RFC2087]. This document provides a more precise definition.
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.
When the server supports this resource type, it MUST also support 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 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]. This document provides a more precise definition. [RFC2087]. This document provides a more precise definition.
5.3. MAILBOX 5.3. MAILBOX
skipping to change at page 15, line 18 skipping to change at page 15, line 40
;; 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 an IETF Stream RFC
resource-names = "(" [resource-name *(SP resource-name)] ")"
resource-usage = number64 resource-usage = number64
;; must be less than corresponding resource-limit ;; must be less than corresponding resource-limit
capability-quota = capa-quota-res / "QUOTASET" capability-quota = capa-quota-res / "QUOTASET"
;; One or more capa-quota-res must be returned. ;; One or more capa-quota-res must be returned.
;; Also "QUOTASET" can optionally be returned. ;; Also "QUOTASET" can optionally be returned.
skipping to change at page 15, line 52 skipping to change at page 16, line 25
;; DELETED-STORAGE status data item MUST be ;; DELETED-STORAGE status data item MUST be
;; supported when "QUOTA=RES-STORAGE" capability ;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised. ;; is advertised.
status-att-val =/ status-att-deleted / status-att-val =/ status-att-deleted /
status-att-deleted-storage 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 "QUOTA=RES-MESSAGE" capability is ;; when "QUOTA=RES-MESSAGE" capability is
;; advertised. ;; advertised.
status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 status-att-deleted-storage = "DELETED-STORAGE" SP number64
;; DELETED-STORAGE status data item MUST be ;; DELETED-STORAGE status data item MUST be
;; supported when "QUOTA=RES-STORAGE" capability ;; supported when "QUOTA=RES-STORAGE" capability
;; is advertised. ;; is advertised.
resp-text-code =/ "OVERQUOTA" resp-text-code =/ "OVERQUOTA"
number64 = <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.
Note that computing resource usage might incur a heavy load on the
server. Server implementers should consider implementation
techniques that lower load on servers, such as caching of resource
usage information or usage of less precise computations when under
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
IMAP4 capabilities are registered by publishing a standards track or IMAP4 capabilities are registered by publishing a standards track or
IESG approved Informational or Experimental RFC. The registry is IESG approved Informational or Experimental RFC. The registry is
currently located at: currently located at:
http://www.iana.org/assignments/imap4-capabilities https://www.iana.org/assignments/imap4-capabilities
IANA is requested to update definition of the QUOTA extension to IANA is requested to update definition of the QUOTA extension to
point to this document. IANA is also requested to add the "QUOTASET" point to this document. IANA is also requested to add the "QUOTASET"
capability to the IMAP4 capabilities registry, with this document as capability to the IMAP4 capabilities registry, with this document as
the reference. the reference.
IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4
capabilities registry and add a pointer to this document and to the capabilities registry and add a pointer to this document and to the
IMAP quota resource type registry (see Section 9.2). IMAP quota resource type registry (see Section 9.2).
IANA is requested to reserve all other capabilities starting with IANA is requested to reserve all other capabilities starting with
"QUOTA=" prefix for future IETF stream standard track, informational "QUOTA=" prefix for future IETF Stream extensions to this document.
or experimental extensions to this document.
9.2. IMAP quota resource type registry 9.2. IMAP quota resource type registry
IANA is requested to create a new registry for IMAP quota resource IANA is requested to create a new registry for IMAP quota resource
types. Registration policy for this registry is "Specification types. Registration policy for this registry is "Specification
Required". When registering a new quota resource type, the Required". When registering a new quota resource type, the
registrant need to provide the following: Name of the quota resource registrant need to provide the following: Name of the quota resource
type, Author/Change Controller name and email address, short type, Author/Change Controller name and email address, short
description, extra (if any) required and optional IMAP commands/ description, extra (if any) required and optional IMAP commands/
responses, and a reference to a specification that describes the responses, and a reference to a specification that describes the
skipping to change at page 19, line 14 skipping to change at page 19, line 33
10. Contributors 10. 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 11. Acknowledgments
Editor of this document would like to thank the following people who Editor 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: John Myers, Cyrus Daboo, Lyndon Nerenberg. this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg,
Benjamin Kaduk, Roman Danyliw, Eric Vyncke.
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 12. Changes since RFC 2087
This document is a revision of RFC 2087. It tries to clarify the This document is a revision of RFC 2087. It tries to clarify the
meaning of different terms used by RFC 2087. It also provides more meaning of different terms used by RFC 2087. It also provides more
examples, gives guidance on allowed server behaviour, defines IANA examples, gives guidance on allowed server behaviour, defines IANA
registry for quota resource types and provides initial registrations registry for quota resource types and provides initial registrations
for 4 of them. for 4 of them.
When compared with RFC 2087, this document defines two 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" and "DELETED-STORAGE") that two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The
must be implemented. For extensibility quota usage and quota limits DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE
are now 63 bit unsigned integers. capability is advertised. The DELETED-STORAGE STATUS data item must
be implemented if the QUOTA=RES-STORAGE capability is advertised.
For extensibility quota usage and quota limits are now 63 bit
unsigned integers.
13. References 13. References
13.1. Normative References 13.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,
<ftp://ftp.isi.edu/in-notes/rfc5234.txt>. <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>.
 End of changes. 34 change blocks. 
62 lines changed or deleted 76 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/