diff options
Diffstat (limited to 'doc/rfc/rfc9208.txt')
| -rw-r--r-- | doc/rfc/rfc9208.txt | 1001 |
1 files changed, 1001 insertions, 0 deletions
diff --git a/doc/rfc/rfc9208.txt b/doc/rfc/rfc9208.txt new file mode 100644 index 0000000..120a9ea --- /dev/null +++ b/doc/rfc/rfc9208.txt @@ -0,0 +1,1001 @@ + + + + +Internet Engineering Task Force (IETF) A. Melnikov +Request for Comments: 9208 Isode +Obsoletes: 2087 March 2022 +Category: Standards Track +ISSN: 2070-1721 + + + IMAP QUOTA Extension + +Abstract + + This document defines a QUOTA extension of the Internet Message + Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits + administrative limits on resource usage (quotas) to be manipulated + through the IMAP protocol. + + This document obsoletes RFC 2087 but attempts to remain backwards + compatible whenever possible. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + 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 (c) 2022 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (https://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Revised BSD License text as described in Section 4.e of the + 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 + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + +Table of Contents + + 1. Introduction and Overview + 2. Document Conventions + 3. Terms + 3.1. Resource + 3.1.1. Name + 3.1.2. Definition + 3.2. Quota Root + 4. Definitions + 4.1. Commands + 4.1.1. GETQUOTA + 4.1.2. GETQUOTAROOT + 4.1.3. SETQUOTA + 4.1.4. New STATUS attributes + 4.2. Responses + 4.2.1. QUOTA + 4.2.2. QUOTAROOT + 4.3. Response Codes + 4.3.1. OVERQUOTA + 5. Resource Type Definitions + 5.1. STORAGE + 5.2. MESSAGE + 5.3. MAILBOX + 5.4. ANNOTATION-STORAGE + 6. Interaction with IMAP ACL Extension (RFC 4314) + 7. Formal Syntax + 8. Security Considerations + 9. IANA Considerations + 9.1. Changes/Additions to the IMAP Capabilities Registry + 9.2. IMAP Quota Resource Type Registry + 10. Changes Since RFC 2087 + 11. References + 11.1. Normative References + 11.2. Informative References + Acknowledgments + Contributors + Author's Address + +1. Introduction and Overview + + This document defines a couple of extensions to the Internet Message + Access Protocol [RFC3501] [RFC9051] for querying and manipulating + administrative limits on resource usage (quotas). This extension is + compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. + + The "QUOTA" capability denotes a server compliant with [RFC2087]. + Some responses and response codes defined in this document are not + present in such servers (see Section 10 for more details), and + 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 + capability starting with the "QUOTA=RES-" prefix, as described in + 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 the + "QUOTA=" prefix for future IETF Stream Standard Track, Informational, + or Experimental extensions to this document. + + Quotas can be used to restrict clients for administrative reasons, + but the QUOTA extension can also be used to indicate system limits + and current usage levels to clients. + + Although the IMAP4 QUOTA extension specified in [RFC2087] has seen + deployment in servers, it has seen little deployment in clients. + Since the meaning of the resources was implementation dependent, it + was impossible for a client implementation 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 + 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.1. Resource + + A resource has a name, a formal definition. + +3.1.1. Name + + The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. + These MUST be registered with IANA. + + Supported resource names MUST be advertised as a capability by + prepending the resource name with "QUOTA=RES-". A server compliant + with this specification is not required to support all reported + resource types on all quota roots. + +3.1.2. Definition + + The resource definition or document containing it, while not visible + through the protocol, SHOULD be registered with IANA. + + The usage of a resource MUST be represented as a 63-bit unsigned + integer. 0 indicates that the resource is exhausted. Usage integers + don't necessarily represent proportional use, so clients MUST NOT + compare an available resource between two separate quota roots on the + same or different servers. + + Limits will be specified as, and MUST be represented as, an integer. + 0 indicates that any usage is prohibited. + + 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 is + or would be exceeded. + + All resources that the server handles MUST be advertised in a + CAPABILITY response/response code consisting of the resource name + prefixed by "QUOTA=RES-". + + The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX + (Section 5.3), and ANNOTATION-STORAGE (Section 5.4) are defined in + this document. + +3.2. Quota Root + + This document introduces the concept of a "quota root", as resource + limits can apply across multiple IMAP mailboxes. + + Each mailbox has zero or more implementation-defined named "quota + roots". Each quota root has zero or more resource limits (quotas). + All mailboxes that share the same named quota root share the resource + limits of the quota root. + + Quota root names need not be mailbox names, nor is there any + 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 + [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 + calculate usage, or apply quotas, on arbitrary mailboxes or mailbox + hierarchies. + + Not all resources may be limitable or calculable for all quota roots. + Furthermore, not all resources may support all limits; some limits + may be present in the underlying system. A server implementation of + this memo SHOULD advise the client of such inherent limits, by + generating QUOTA (Section 4.2.1) responses, and SHOULD advise the + client of which resources are limitable for a particular quota root. + A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an + implementation-dependent way, if the granularity of the underlying + system demands it. A client MUST be prepared for a SETQUOTA + (Section 4.1.3) command to fail if a limit cannot be set. + + Implementation Notes: This means that, for example, under UNIX, a + quota root may have a MESSAGE (Section 5.2) quota always set due to + the number of inodes available on the filesystem; similarly, STORAGE + (Section 5.1) may be rounded to the nearest block and limited by free + filesystem space. + +4. Definitions + +4.1. Commands + + The following commands exist for manipulation and querying quotas. + +4.1.1. GETQUOTA + + Arguments: quota root + + Responses: REQUIRED untagged responses: QUOTA + + Result: OK - getquota completed + + NO - getquota error: no such quota root, permission + denied + + BAD - command unknown or arguments invalid + + 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. + (Names of quota roots applicable to a particular mailbox can be + discovered by issuing the GETQUOTAROOT command; see Section 4.1.2.) + Note that the server is not required to support any specific resource + type (as advertised in the CAPABILITY response, i.e., all capability + items with the "QUOTA=RES-" prefix) for any particular quota root. + + Example: + + S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] + + [...] + + C: G0001 GETQUOTA "!partition/sda4" + + S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) + + S: G0001 OK Getquota complete + +4.1.2. GETQUOTAROOT + + Arguments: mailbox name + + Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA + + Result: OK - getquotaroot completed + + NO - getquotaroot error: permission denied + + BAD - command unknown or arguments invalid + + The GETQUOTAROOT command takes a mailbox name and returns the list of + quota roots for the mailbox in an untagged QUOTAROOT response. For + each listed quota root, it also returns the quota root's resource + usage and limits in an untagged QUOTA response. + + Note that the mailbox name parameter doesn't have to reference an + existing mailbox. This can be handy in order to determine which + quota root would apply to a mailbox when it gets created. + + Example: + + S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE + [...] + + [...] + + C: G0002 GETQUOTAROOT INBOX + + S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" + + S: * QUOTA "#user/alice" (MESSAGE 42 1000) + + S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) + + S: G0002 OK Getquotaroot complete + +4.1.3. SETQUOTA + + Arguments: quota root list of resource limits + + Responses: untagged responses: QUOTA + + Result: OK - setquota completed + + NO - setquota error: can't set that data + + BAD - command unknown or arguments invalid + + Note that unlike other command/responses/response codes defined in + this document, support for the SETQUOTA command requires the server + to advertise the "QUOTASET" capability. + + The SETQUOTA command takes the name of a mailbox quota root and a + list of resource limits. The resource limits for the named quota + root are changed to the specified limits. Any previous resource + 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 + may optionally create it and change the quota roots for any number of + existing mailboxes in an implementation-defined manner. + + If the implementation chooses to change the quota roots for some + existing mailboxes, such changes SHOULD be announced with untagged + QUOTA responses. + + Example: + + S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- + MESSAGE [...] + + [...] + + C: S0000 GETQUOTA "#user/alice" + + S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) + + S: S0000 OK Getquota completed + + C: S0001 SETQUOTA "#user/alice" (STORAGE 510) + + S: * QUOTA "#user/alice" (STORAGE 58 512) + + // The server has rounded the STORAGE quota limit requested to + the nearest 512 blocks of 1024 octets; otherwise, another client + has performed a near-simultaneous SETQUOTA using a limit of 512. + + S: S0001 OK Rounded quota + + C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) + + S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) + + // The server has not changed the quota, since this is a + filesystem limit, and it cannot be changed. The QUOTA + response here is entirely optional. + + S: S0002 NO Cannot change system limit + +4.1.4. New STATUS attributes + + The DELETED and DELETED-STORAGE status data items allow for + 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 + of messages with the \Deleted flag set. The DELETED status data item + is only required to be implemented when the server advertises the + "QUOTA=RES-MESSAGE" capability. + + The DELETED-STORAGE status data item requests the server to return + the amount of storage space that can be reclaimed by performing + EXPUNGE on the mailbox. The server SHOULD return the exact value; + however, it is recognized that the server may have to do a non- + trivial amount of work to calculate it. If the calculation of the + exact value would take a long time, the server MAY instead return the + sum of the RFC822.SIZE of the messages with the \Deleted flag set. + The DELETED-STORAGE status data item is only required to be + implemented when the server advertises the "QUOTA=RES-STORAGE" + capability. + + Example: + + S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES- + MESSAGE [...] + + [...] + + C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) + + S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) + + // 12 messages, 4 of which would be deleted when an EXPUNGE + happens. + + S: S0003 OK Status complete. + +4.2. Responses + + The following responses may be sent by the server. + +4.2.1. QUOTA + + Data: quota root name + + list of resource names, usages, and limits + + This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or + SETQUOTA command. The first string is the name of the quota root for + which this quota applies. + + 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 + triplets. Each triplet contains a resource name, the current usage + of the resource, and the resource limit. + + Resources not named in the list are not limited in the quota root. + Thus, an empty list means there are no administrative resource limits + in the quota root. + + Example: + + S: * QUOTA "" (STORAGE 10 512) + +4.2.2. QUOTAROOT + + Data: mailbox name + + zero or more quota root names + + This response occurs as a result of a GETQUOTAROOT command. The + first string is the mailbox and the remaining strings are the names + of the quota roots for the mailbox. + + Examples: + + S: * QUOTAROOT INBOX "" + + // The INBOX mailbox is covered by a single quota root with + name "". + + 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.1. OVERQUOTA + + The 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 target mailbox over any one of its quota limits. + + Example 1: + + C: A003 APPEND saved-messages (\Seen) {326} + 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: A003 NO [OVERQUOTA] APPEND Failed + + The OVERQUOTA response code MAY also be returned in an untagged NO + response in the authenticated or the selected state when a mailbox + exceeds soft quota. For example, such OVERQUOTA response codes might + be sent as a result of an external event (e.g., Local Mail Transfer + Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another + IMAP connection) that causes the currently selected mailbox to exceed + soft quota. Note that such an OVERQUOTA response code might be + ambiguous because it might relate to the target mailbox (as specified + in COPY/MOVE/APPEND) or to the currently selected mailbox. (The + EXTRA WG chose not to address this deficiency due to syntactic + limitations of IMAP response codes and because such events are likely + to be rare.) This form of the OVERQUOTA response codes MUST NOT be + returned if there is no mailbox selected and no command in progress + that adds a message to a mailbox (e.g., APPEND). + + Example 2: + + C: A003 APPEND saved-messages (\Seen) {326} + 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 + 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 + + The following resource types are defined in this memo. A server + supporting a resource type MUST advertise this as a CAPABILITY with a + name consisting of the resource name prefixed by "QUOTA=RES-". A + server MAY support multiple resource types and MUST advertise all + resource types it supports. + +5.1. STORAGE + + "STORAGE" is the physical space estimate, in units of 1024 octets, of + the mailboxes governed by the quota root. This MAY not be the same + as the sum of the RFC822.SIZE of the messages. Some implementations + MAY include metadata sizes for the messages and mailboxes, and other + implementations MAY store messages in such a way that the physical + space used is smaller, for example, due to use of compression. + Additional messages might not increase the usage. Clients MUST NOT + use the usage figure for anything other than informational purposes; + 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 octets + of the message, but it MAY warn about such condition. + + The usage figure may change as a result of performing actions not + associated with adding new messages to the mailbox, such as SEARCH, + since this may increase the amount of metadata included in the + calculations. + + When the server supports this resource type, it MUST also support the + DELETED-STORAGE status data item. + + Support for this resource MUST be indicated by the server by + advertising the "QUOTA=RES-STORAGE" capability. + + A resource named the same was also given as an example in [RFC2087]. + This document provides a more precise definition. + +5.2. MESSAGE + + "MESSAGE" is the number of messages stored within the mailboxes + governed by the 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 messages available, since the quota root may include + mailboxes the client has no access to. + + When the server supports this resource type, it MUST also support the + DELETED status data item. + + Support for this resource MUST be indicated by the server by + advertising the "QUOTA=RES-MESSAGE" capability. + + A resource named the same was also given as an example in [RFC2087]. + This document provides a more precise definition. + +5.3. MAILBOX + + "MAILBOX" is 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 usage indicates a change in the number of mailboxes, + since the quota root may include mailboxes the client has no access + to. + + Support for this resource MUST be indicated by the server by + advertising the "QUOTA=RES-MAILBOX" capability. + +5.4. ANNOTATION-STORAGE + + "ANNOTATION-STORAGE" is the maximum size of all annotations + [RFC5257], in units of 1024 octets, associated with all messages in + the mailboxes governed by the quota root. + + Support for this resource MUST be indicated by the server by + advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability. + +6. Interaction with IMAP ACL Extension (RFC 4314) + + This section lists [RFC4314] rights required to execute quota-related + commands when both RFC 4314 and this document are implemented. + + +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ + | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non | + +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ + | GETQUOTA | | | | | | | | | | | | + | + +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ + | GETQUOTAROOT | |*| | | | | | | | | | * | + +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ + | SETQUOTA | | | | | | | | | | + | | | + +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ + + Table 1 + + See Section 4 of [RFC4314] for conventions used in this table. + + Legend: + + "+": The right is required + + "*": Only one of the rights marked with * is required + + "Any": At least one of the "l", "r", "i", "k", "x", or "a" rights is + required + + "Non": No rights required to perform the command + + Note that which permissions are needed in order to perform a + GETQUOTAROOT command depends on the quota resource type being + requested. For example, a quota on the 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 + + The following syntax specification uses the Augmented Backus-Naur + Form (ABNF) notation as specified in [ABNF]. + + Non-terminals referenced but not defined below are as defined by + IMAP4 [RFC3501] [RFC9051]. + + Except as noted otherwise, all alphabetic characters are case + insensitive. The use of uppercase or lowercase characters to define + token strings is for editorial clarity only. Implementations MUST + accept these strings in a case-insensitive fashion. + + getquota = "GETQUOTA" SP quota-root-name + + getquotaroot = "GETQUOTAROOT" SP mailbox + + quota-list = "(" quota-resource *(SP quota-resource) ")" + + quota-resource = resource-name SP resource-usage SP resource-limit + + quota-response = "QUOTA" SP quota-root-name SP quota-list + + quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) + + setquota = "SETQUOTA" SP quota-root-name SP setquota-list + + setquota-list = "(" [setquota-resource *(SP setquota-resource)] + ")" + + setquota-resource = resource-name SP resource-limit + + quota-root-name = astring + + resource-limit = number64 + + resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / + "ANNOTATION-STORAGE" / resource-name-ext + + resource-name-ext = atom + ;; Future resource registrations + + 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 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-val =/ status-att-deleted / + status-att-deleted-storage + + status-att-deleted = "DELETED" SP number + ;; DELETED status data item MUST be supported + ;; when the "QUOTA=RES-MESSAGE" capability is + ;; advertised. + + status-att-deleted-storage = "DELETED-STORAGE" SP number64 + ;; DELETED-STORAGE status data item MUST be + ;; supported when the "QUOTA=RES-STORAGE" + ;; capability is advertised. + + resp-text-code =/ "OVERQUOTA" + + number64 = <Defined in RFC 9051> + +8. Security Considerations + + Implementors should be careful to make sure the implementation of + these commands does not violate the site's security policy. The + resource usage of other users is likely to be considered confidential + information and should not be divulged to unauthorized persons. In + particular, no quota information should be disclosed to anonymous + 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 the SETQUOTA setting, which sets an + artificially small value. + + Note that computing resource usage might incur a heavy load on the + server. Server implementers should consider implementation + techniques that lower the load on servers such as caching of resource + usage information or usage of less precise computations when under + heavy load. + +9. IANA Considerations + +9.1. Changes/Additions to the IMAP Capabilities Registry + + 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>. + + 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. + + IANA has added the following notes to the "IMAP Capabilities" + registry: + + The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See + Section 9.2 of that document for values that follow this prefix. + + All other capabilities starting with the "QUOTA=" prefix are reserved + for future IETF Stream extensions to RFC 9208. + +9.2. IMAP Quota Resource Type Registry + + 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]. + + When registering a new quota resource type, the registrant needs to + provide the following: + + * the name of the quota resource type + + * a short description + + * extra required IMAP commands/responses (if any) + + * extra optional IMAP commands/responses (if any) + + * name and email address of author + + * name and email address of change controller + + * a reference to a specification that describes the quota resource + type in more detail + + 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. + + The initial contents of the "IMAP Quota Resource Types" registry are + as follows: + + +===================+=======================================+ + | 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 | + +-------------------+---------------------------------------+ + + Table 2: STORAGE + + +=====================+==========================================+ + | 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 | + +---------------------+------------------------------------------+ + + Table 3: MESSAGE + + +==================================+=============================+ + | 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 | + +----------------------------------+-----------------------------+ + + Table 4: MAILBOX + + +================+=======================================+ + | field name | field value | + +================+=======================================+ + | 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 | + +----------------+---------------------------------------+ + + Table 5: ANNOTATION-STORAGE + +10. Changes Since RFC 2087 + + This document is a revision of [RFC2087], and it aims to clarify the + meaning of different terms that were used in that RFC. It also + provides more examples, gives guidance on allowed server behavior, + defines an IANA registry for quota resource types, and provides + initial registrations for 4 of them. + + When compared with [RFC2087], this document defines two more commonly + used resource types, adds an optional OVERQUOTA response code, and + defines two extra STATUS data items ("DELETED" and "DELETED- + STORAGE"). The DELETED STATUS data item must be implemented if the + "QUOTA=RES-MESSAGE" 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. + +11. References + +11.1. Normative References + + [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, + DOI 10.17487/RFC5234, January 2008, + <https://www.rfc-editor.org/info/rfc5234>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <https://www.rfc-editor.org/info/rfc2119>. + + [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION + 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, + <https://www.rfc-editor.org/info/rfc3501>. + + [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", + RFC 4314, DOI 10.17487/RFC4314, December 2005, + <https://www.rfc-editor.org/info/rfc4314>. + + [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access + Protocol - ANNOTATE Extension", RFC 5257, + DOI 10.17487/RFC5257, June 2008, + <https://www.rfc-editor.org/info/rfc5257>. + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, <https://www.rfc-editor.org/info/rfc8174>. + + [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message + Access Protocol (IMAP) - Version 4rev2", RFC 9051, + DOI 10.17487/RFC9051, August 2021, + <https://www.rfc-editor.org/info/rfc9051>. + +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, + DOI 10.17487/RFC2087, January 1997, + <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 + + Alexey Melnikov + Isode Limited + Email: alexey.melnikov@isode.com + URI: https://www.isode.com |