5Internet Engineering Task Force (IETF) A. Melnikov
6Request for Comments: 9208 Isode
7Obsoletes: 2087 March 2022
8Category: Standards Track
16 This document defines a QUOTA extension of the Internet Message
17 Access Protocol (IMAP) (see RFCs 3501 and 9051) that permits
18 administrative limits on resource usage (quotas) to be manipulated
19 through the IMAP protocol.
21 This document obsoletes RFC 2087 but attempts to remain backwards
22 compatible whenever possible.
26 This is an Internet Standards Track document.
28 This document is a product of the Internet Engineering Task Force
29 (IETF). It represents the consensus of the IETF community. It has
30 received public review and has been approved for publication by the
31 Internet Engineering Steering Group (IESG). Further information on
32 Internet Standards is available in Section 2 of RFC 7841.
34 Information about the current status of this document, any errata,
35 and how to provide feedback on it may be obtained at
36 https://www.rfc-editor.org/info/rfc9208.
40 Copyright (c) 2022 IETF Trust and the persons identified as the
41 document authors. All rights reserved.
43 This document is subject to BCP 78 and the IETF Trust's Legal
44 Provisions Relating to IETF Documents
45 (https://trustee.ietf.org/license-info) in effect on the date of
46 publication of this document. Please review these documents
47 carefully, as they describe your rights and restrictions with respect
48 to this document. Code Components extracted from this document must
49 include Revised BSD License text as described in Section 4.e of the
50 Trust Legal Provisions and are provided without warranty as described
51 in the Revised BSD License.
53 This document may contain material from IETF Documents or IETF
54 Contributions published or made publicly available before November
55 10, 2008. The person(s) controlling the copyright in some of this
56 material may not have granted the IETF Trust the right to allow
57 modifications of such material outside the IETF Standards Process.
58 Without obtaining an adequate license from the person(s) controlling
59 the copyright in such materials, this document may not be modified
60 outside the IETF Standards Process, and derivative works of it may
61 not be created outside the IETF Standards Process, except to format
62 it for publication as an RFC or to translate it into languages other
67 1. Introduction and Overview
68 2. Document Conventions
79 4.1.4. New STATUS attributes
85 5. Resource Type Definitions
89 5.4. ANNOTATION-STORAGE
90 6. Interaction with IMAP ACL Extension (RFC 4314)
92 8. Security Considerations
93 9. IANA Considerations
94 9.1. Changes/Additions to the IMAP Capabilities Registry
95 9.2. IMAP Quota Resource Type Registry
96 10. Changes Since RFC 2087
98 11.1. Normative References
99 11.2. Informative References
1041. Introduction and Overview
106 This document defines a couple of extensions to the Internet Message
107 Access Protocol [RFC3501] [RFC9051] for querying and manipulating
108 administrative limits on resource usage (quotas). This extension is
109 compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051].
112 Some responses and response codes defined in this document are not
113 present in such servers (see Section 10 for more details), and
114 clients MUST NOT rely on their presence in the absence of any
115 capability beginning with "QUOTA=".
117 Any server compliant with this document MUST also return at least one
118 capability starting with the "QUOTA=RES-" prefix, as described in
121 Any server compliant with this document that implements the SETQUOTA
122 command (see Section 4.1.3) MUST also return the "QUOTASET"
125 This document also reserves all other capabilities starting with the
126 "QUOTA=" prefix for future IETF Stream Standard Track, Informational,
127 or Experimental extensions to this document.
129 Quotas can be used to restrict clients for administrative reasons,
130 but the QUOTA extension can also be used to indicate system limits
131 and current usage levels to clients.
133 Although the IMAP4 QUOTA extension specified in [RFC2087] has seen
134 deployment in servers, it has seen little deployment in clients.
135 Since the meaning of the resources was implementation dependent, it
136 was impossible for a client implementation to determine which
137 resources were supported, and it was impossible to determine which
138 mailboxes were in a given quota root (see Section 3.2) without a
139 priori knowledge of the implementation.
1412. Document Conventions
143 In protocol examples, this document uses a prefix of "C: " to denote
144 lines sent by the client to the server and "S: " for lines sent by
145 the server to the client. Lines prefixed with "//" are comments
146 explaining the previous protocol line. These prefixes and comments
147 are not part of the protocol. Lines without any of these prefixes
148 are continuations of the previous line, and no line break is present
149 in the protocol before such lines unless specifically mentioned.
151 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
152 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
153 "OPTIONAL" in this document are to be interpreted as described in
154 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
155 capitals, as shown here.
157 Other capitalized words are IMAP keywords [RFC3501] [RFC9051] or
158 keywords from this document.
164 A resource has a name, a formal definition.
168 The resource name is an atom, as defined in IMAP4rev1 [RFC3501].
169 These MUST be registered with IANA.
171 Supported resource names MUST be advertised as a capability by
172 prepending the resource name with "QUOTA=RES-". A server compliant
173 with this specification is not required to support all reported
174 resource types on all quota roots.
178 The resource definition or document containing it, while not visible
179 through the protocol, SHOULD be registered with IANA.
181 The usage of a resource MUST be represented as a 63-bit unsigned
182 integer. 0 indicates that the resource is exhausted. Usage integers
183 don't necessarily represent proportional use, so clients MUST NOT
184 compare an available resource between two separate quota roots on the
185 same or different servers.
187 Limits will be specified as, and MUST be represented as, an integer.
188 0 indicates that any usage is prohibited.
190 Limits may be hard or soft; that is, an implementation MAY choose, or
191 be configured, to disallow any command if the limit on a resource is
192 or would be exceeded.
194 All resources that the server handles MUST be advertised in a
195 CAPABILITY response/response code consisting of the resource name
196 prefixed by "QUOTA=RES-".
198 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX
199 (Section 5.3), and ANNOTATION-STORAGE (Section 5.4) are defined in
204 This document introduces the concept of a "quota root", as resource
205 limits can apply across multiple IMAP mailboxes.
207 Each mailbox has zero or more implementation-defined named "quota
208 roots". Each quota root has zero or more resource limits (quotas).
209 All mailboxes that share the same named quota root share the resource
210 limits of the quota root.
212 Quota root names need not be mailbox names, nor is there any
213 relationship defined by this document between a quota root name and a
214 mailbox name. A quota root name is an astring, as defined in IMAP4
215 [RFC3501] [RFC9051]. It SHOULD be treated as an opaque string by any
218 Quota roots are used since not all implementations may be able to
219 calculate usage, or apply quotas, on arbitrary mailboxes or mailbox
222 Not all resources may be limitable or calculable for all quota roots.
223 Furthermore, not all resources may support all limits; some limits
224 may be present in the underlying system. A server implementation of
225 this memo SHOULD advise the client of such inherent limits, by
226 generating QUOTA (Section 4.2.1) responses, and SHOULD advise the
227 client of which resources are limitable for a particular quota root.
228 A SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an
229 implementation-dependent way, if the granularity of the underlying
230 system demands it. A client MUST be prepared for a SETQUOTA
231 (Section 4.1.3) command to fail if a limit cannot be set.
233 Implementation Notes: This means that, for example, under UNIX, a
234 quota root may have a MESSAGE (Section 5.2) quota always set due to
235 the number of inodes available on the filesystem; similarly, STORAGE
236 (Section 5.1) may be rounded to the nearest block and limited by free
243 The following commands exist for manipulation and querying quotas.
247 Arguments: quota root
249 Responses: REQUIRED untagged responses: QUOTA
251 Result: OK - getquota completed
253 NO - getquota error: no such quota root, permission
256 BAD - command unknown or arguments invalid
258 The GETQUOTA command takes the name of a quota root and returns the
259 quota root's resource usage and limits in an untagged QUOTA response.
260 (Names of quota roots applicable to a particular mailbox can be
261 discovered by issuing the GETQUOTAROOT command; see Section 4.1.2.)
262 Note that the server is not required to support any specific resource
263 type (as advertised in the CAPABILITY response, i.e., all capability
264 items with the "QUOTA=RES-" prefix) for any particular quota root.
268 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...]
272 C: G0001 GETQUOTA "!partition/sda4"
274 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
276 S: G0001 OK Getquota complete
280 Arguments: mailbox name
282 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA
284 Result: OK - getquotaroot completed
286 NO - getquotaroot error: permission denied
288 BAD - command unknown or arguments invalid
290 The GETQUOTAROOT command takes a mailbox name and returns the list of
291 quota roots for the mailbox in an untagged QUOTAROOT response. For
292 each listed quota root, it also returns the quota root's resource
293 usage and limits in an untagged QUOTA response.
296 existing mailbox. This can be handy in order to determine which
297 quota root would apply to a mailbox when it gets created.
301 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE
306 C: G0002 GETQUOTAROOT INBOX
308 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4"
310 S: * QUOTA "#user/alice" (MESSAGE 42 1000)
312 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
314 S: G0002 OK Getquotaroot complete
318 Arguments: quota root list of resource limits
320 Responses: untagged responses: QUOTA
322 Result: OK - setquota completed
324 NO - setquota error: can't set that data
326 BAD - command unknown or arguments invalid
328 Note that unlike other command/responses/response codes defined in
329 this document, support for the SETQUOTA command requires the server
330 to advertise the "QUOTASET" capability.
332 The SETQUOTA command takes the name of a mailbox quota root and a
333 list of resource limits. The resource limits for the named quota
334 root are changed to the specified limits. Any previous resource
335 limits for the named quota root are discarded, even resource limits
336 not explicitly listed in the SETQUOTA command. (For example, if the
337 quota root had both STORAGE and MESSAGE limits assigned to the quota
338 root before the SETQUOTA is called and the SETQUOTA only includes the
339 STORAGE limit, then the MESSAGE limit is removed from the quota
342 If the named quota root did not previously exist, an implementation
343 may optionally create it and change the quota roots for any number of
344 existing mailboxes in an implementation-defined manner.
346 If the implementation chooses to change the quota roots for some
347 existing mailboxes, such changes SHOULD be announced with untagged
352 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES-
357 C: S0000 GETQUOTA "#user/alice"
359 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000)
361 S: S0000 OK Getquota completed
363 C: S0001 SETQUOTA "#user/alice" (STORAGE 510)
365 S: * QUOTA "#user/alice" (STORAGE 58 512)
367 // The server has rounded the STORAGE quota limit requested to
368 the nearest 512 blocks of 1024 octets; otherwise, another client
369 has performed a near-simultaneous SETQUOTA using a limit of 512.
371 S: S0001 OK Rounded quota
373 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999)
375 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847)
377 // The server has not changed the quota, since this is a
378 filesystem limit, and it cannot be changed. The QUOTA
379 response here is entirely optional.
381 S: S0002 NO Cannot change system limit
3834.1.4. New STATUS attributes
385 The DELETED and DELETED-STORAGE status data items allow for
386 estimation of the amount of resources that could be freed by an
387 EXPUNGE on a mailbox.
389 The DELETED status data item requests the server to return the number
390 of messages with the \Deleted flag set. The DELETED status data item
391 is only required to be implemented when the server advertises the
392 "QUOTA=RES-MESSAGE" capability.
395 the amount of storage space that can be reclaimed by performing
396 EXPUNGE on the mailbox. The server SHOULD return the exact value;
397 however, it is recognized that the server may have to do a non-
398 trivial amount of work to calculate it. If the calculation of the
399 exact value would take a long time, the server MAY instead return the
400 sum of the RFC822.SIZE of the messages with the \Deleted flag set.
401 The DELETED-STORAGE status data item is only required to be
402 implemented when the server advertises the "QUOTA=RES-STORAGE"
407 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-
412 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE)
414 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8)
416 // 12 messages, 4 of which would be deleted when an EXPUNGE
419 S: S0003 OK Status complete.
423 The following responses may be sent by the server.
427 Data: quota root name
429 list of resource names, usages, and limits
431 This response occurs as a result of a GETQUOTA, GETQUOTAROOT, or
432 SETQUOTA command. The first string is the name of the quota root for
433 which this quota applies.
435 The name is followed by an S-expression format list of the resource
436 usage and limits of the quota root. The list contains zero or more
437 triplets. Each triplet contains a resource name, the current usage
438 of the resource, and the resource limit.
440 Resources not named in the list are not limited in the quota root.
441 Thus, an empty list means there are no administrative resource limits
446 S: * QUOTA "" (STORAGE 10 512)
452 zero or more quota root names
454 This response occurs as a result of a GETQUOTAROOT command. The
455 first string is the mailbox and the remaining strings are the names
456 of the quota roots for the mailbox.
460 S: * QUOTAROOT INBOX ""
462 // The INBOX mailbox is covered by a single quota root with
465 S: * QUOTAROOT comp.mail.mime
467 // The comp.mail.mime mailbox has no quota root associated
468 with it, but one can be created.
474 The OVERQUOTA response code SHOULD be returned in the tagged NO
475 response to an APPEND/COPY/MOVE when the addition of the message(s)
476 puts the target mailbox over any one of its quota limits.
480 C: A003 APPEND saved-messages (\Seen) {326}
481 S: + Ready for literal data
482 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
483 C: From: Fred Foobar <foobar@Blurdybloop.example>
484 C: Subject: afternoon meeting
485 C: To: mooch@owatagu.siam.edu.example
486 C: Message-Id: <B27397-0100000@Blurdybloop.example>
488 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
490 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
492 S: A003 NO [OVERQUOTA] APPEND Failed
494 The OVERQUOTA response code MAY also be returned in an untagged NO
495 response in the authenticated or the selected state when a mailbox
496 exceeds soft quota. For example, such OVERQUOTA response codes might
497 be sent as a result of an external event (e.g., Local Mail Transfer
498 Protocol (LMTP) [RFC2033] delivery or COPY/MOVE/APPEND in another
499 IMAP connection) that causes the currently selected mailbox to exceed
500 soft quota. Note that such an OVERQUOTA response code might be
501 ambiguous because it might relate to the target mailbox (as specified
502 in COPY/MOVE/APPEND) or to the currently selected mailbox. (The
503 EXTRA WG chose not to address this deficiency due to syntactic
504 limitations of IMAP response codes and because such events are likely
505 to be rare.) This form of the OVERQUOTA response codes MUST NOT be
506 returned if there is no mailbox selected and no command in progress
507 that adds a message to a mailbox (e.g., APPEND).
511 C: A003 APPEND saved-messages (\Seen) {326}
512 S: + Ready for literal data
513 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST)
514 C: From: Fred Foobar <foobar@Blurdybloop.example>
515 C: Subject: afternoon meeting
516 C: To: mooch@owatagu.siam.edu.example
517 C: Message-Id: <B27397-0100000@Blurdybloop.example>
519 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
521 C: Hello Joe, do you think we can meet at 3:30 tomorrow?
523 S: * NO [OVERQUOTA] Soft quota has been exceeded
524 S: A003 OK [APPENDUID 38505 3955] APPEND completed
528 C: A004 COPY 2:4 MEETING
529 S: * NO [OVERQUOTA] Soft quota has been exceeded
530 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY
535 The following resource types are defined in this memo. A server
536 supporting a resource type MUST advertise this as a CAPABILITY with a
537 name consisting of the resource name prefixed by "QUOTA=RES-". A
538 server MAY support multiple resource types and MUST advertise all
539 resource types it supports.
543 "STORAGE" is the physical space estimate, in units of 1024 octets, of
544 the mailboxes governed by the quota root. This MAY not be the same
545 as the sum of the RFC822.SIZE of the messages. Some implementations
546 MAY include metadata sizes for the messages and mailboxes, and other
547 implementations MAY store messages in such a way that the physical
548 space used is smaller, for example, due to use of compression.
549 Additional messages might not increase the usage. Clients MUST NOT
550 use the usage figure for anything other than informational purposes;
551 for example, they MUST NOT refuse to APPEND a message if the limit
552 less the usage is smaller than the RFC822.SIZE divided by 1024 octets
553 of the message, but it MAY warn about such condition.
555 The usage figure may change as a result of performing actions not
556 associated with adding new messages to the mailbox, such as SEARCH,
557 since this may increase the amount of metadata included in the
560 When the server supports this resource type, it MUST also support the
561 DELETED-STORAGE status data item.
563 Support for this resource MUST be indicated by the server by
564 advertising the "QUOTA=RES-STORAGE" capability.
566 A resource named the same was also given as an example in [RFC2087].
567 This document provides a more precise definition.
571 "MESSAGE" is the number of messages stored within the mailboxes
572 governed by the quota root. This MUST be an exact number; however,
573 clients MUST NOT assume that a change in the usage indicates a change
574 in the number of messages available, since the quota root may include
575 mailboxes the client has no access to.
577 When the server supports this resource type, it MUST also support the
578 DELETED status data item.
580 Support for this resource MUST be indicated by the server by
581 advertising the "QUOTA=RES-MESSAGE" capability.
583 A resource named the same was also given as an example in [RFC2087].
584 This document provides a more precise definition.
588 "MAILBOX" is the number of mailboxes governed by the quota root.
589 This MUST be an exact number; however, clients MUST NOT assume that a
590 change in the usage indicates a change in the number of mailboxes,
591 since the quota root may include mailboxes the client has no access
594 Support for this resource MUST be indicated by the server by
595 advertising the "QUOTA=RES-MAILBOX" capability.
5975.4. ANNOTATION-STORAGE
599 "ANNOTATION-STORAGE" is the maximum size of all annotations
600 [RFC5257], in units of 1024 octets, associated with all messages in
601 the mailboxes governed by the quota root.
603 Support for this resource MUST be indicated by the server by
604 advertising the "QUOTA=RES-ANNOTATION-STORAGE" capability.
6066. Interaction with IMAP ACL Extension (RFC 4314)
608 This section lists [RFC4314] rights required to execute quota-related
609 commands when both RFC 4314 and this document are implemented.
611 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
612 | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non |
613 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+
614 | GETQUOTA | | | | | | | | | | | | + |
615 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
616 | GETQUOTAROOT | |*| | | | | | | | | | * |
617 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
618 | SETQUOTA | | | | | | | | | | + | | |
619 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+
623 See Section 4 of [RFC4314] for conventions used in this table.
627 "+": The right is required
629 "*": Only one of the rights marked with * is required
631 "Any": At least one of the "l", "r", "i", "k", "x", or "a" rights is
634 "Non": No rights required to perform the command
636 Note that which permissions are needed in order to perform a
637 GETQUOTAROOT command depends on the quota resource type being
638 requested. For example, a quota on the number of messages (MESSAGE
639 resource type) or total size of messages (STORAGE resource type)
640 requires "r" right on the mailbox in question, since the quota
641 involved would reveal information about the number (or total size) of
642 messages in the mailbox. By comparison, the MAILBOX resource type
643 doesn't require any right.
647 The following syntax specification uses the Augmented Backus-Naur
648 Form (ABNF) notation as specified in [ABNF].
650 Non-terminals referenced but not defined below are as defined by
651 IMAP4 [RFC3501] [RFC9051].
653 Except as noted otherwise, all alphabetic characters are case
654 insensitive. The use of uppercase or lowercase characters to define
655 token strings is for editorial clarity only. Implementations MUST
656 accept these strings in a case-insensitive fashion.
662 quota-list = "(" quota-resource *(SP quota-resource) ")"
664 quota-resource = resource-name SP resource-usage SP resource-limit
670 setquota = "SETQUOTA" SP quota-root-name SP setquota-list
672 setquota-list = "(" [setquota-resource *(SP setquota-resource)]
675 setquota-resource = resource-name SP resource-limit
677 quota-root-name = astring
679 resource-limit = number64
681 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" /
682 "ANNOTATION-STORAGE" / resource-name-ext
684 resource-name-ext = atom
685 ;; Future resource registrations
687 resource-usage = number64
688 ;; must be less than corresponding resource-limit
690 capability-quota = capa-quota-res / "QUOTASET"
691 ;; One or more capa-quota-res must be returned.
692 ;; Also "QUOTASET" can optionally be returned.
694 capa-quota-res = "QUOTA=RES-" resource-name
697 ;; DELETED status data item MUST be supported
698 ;; when the "QUOTA=RES-MESSAGE" capability is
700 ;; DELETED-STORAGE status data item MUST be
701 ;; supported when the "QUOTA=RES-STORAGE"
702 ;; capability is advertised.
704 status-att-val =/ status-att-deleted /
705 status-att-deleted-storage
707 status-att-deleted = "DELETED" SP number
708 ;; DELETED status data item MUST be supported
709 ;; when the "QUOTA=RES-MESSAGE" capability is
713 ;; DELETED-STORAGE status data item MUST be
714 ;; supported when the "QUOTA=RES-STORAGE"
715 ;; capability is advertised.
717 resp-text-code =/ "OVERQUOTA"
719 number64 = <Defined in RFC 9051>
7218. Security Considerations
723 Implementors should be careful to make sure the implementation of
724 these commands does not violate the site's security policy. The
725 resource usage of other users is likely to be considered confidential
726 information and should not be divulged to unauthorized persons. In
727 particular, no quota information should be disclosed to anonymous
730 As for any resource shared across users (for example, a quota root
731 attached to a set of shared mailboxes), a user that can consume or
732 render unusable the resource can affect the resources available to
733 the other users; this might occur, for example, by a user with
734 permission to execute the SETQUOTA setting, which sets an
735 artificially small value.
737 Note that computing resource usage might incur a heavy load on the
738 server. Server implementers should consider implementation
739 techniques that lower the load on servers such as caching of resource
740 usage information or usage of less precise computations when under
7439. IANA Considerations
7459.1. Changes/Additions to the IMAP Capabilities Registry
747 IMAP4 capabilities are registered by publishing a Standards Track or
748 an IESG-approved Informational or Experimental RFC. The "IMAP
749 Capabilities" registry is currently located at
750 <https://www.iana.org/assignments/imap4-capabilities>.
752 IANA has updated the reference for the QUOTA extension to point to
753 this document. IANA has also added the "QUOTA=" prefix and the
754 "QUOTASET" capability to the "IMAP Capabilities" registry with this
755 document as the reference.
757 IANA has added the following notes to the "IMAP Capabilities"
760 The prefix "QUOTA=RES-" is reserved per RFC 9208, Section 9.1. See
761 Section 9.2 of that document for values that follow this prefix.
763 All other capabilities starting with the "QUOTA=" prefix are reserved
764 for future IETF Stream extensions to RFC 9208.
7669.2. IMAP Quota Resource Type Registry
768 IANA has created a new registry for IMAP quota resource types. The
769 registration policy for the "IMAP Quota Resource Types" registry is
770 "Specification Required" [RFC8126].
772 When registering a new quota resource type, the registrant needs to
773 provide the following:
775 * the name of the quota resource type
777 * a short description
779 * extra required IMAP commands/responses (if any)
781 * extra optional IMAP commands/responses (if any)
783 * name and email address of author
785 * name and email address of change controller
787 * a reference to a specification that describes the quota resource
790 Designated experts should check that the provided references are
791 correct, the references describe the quota resource type being
792 registered in sufficient detail to be implementable, the syntax of
793 any optional commands/responses is correct (e.g., ABNF validates),
794 and the syntax/description complies with rules and limitations
795 imposed by IMAP [RFC3501] [RFC9051]. Designated experts should avoid
796 registering multiple identical quota resource types under different
797 names and should provide advice to requestors about other possible
798 quota resource types to use.
800 The initial contents of the "IMAP Quota Resource Types" registry are
803 +===================+=======================================+
804 | field name | field value |
805 +===================+=======================================+
806 | Name of the quota | STORAGE |
808 +-------------------+---------------------------------------+
809 | Description: | The physical space estimate, in units |
810 | | of 1024 octets, of the mailboxes |
811 | | governed by the quota root. |
812 +-------------------+---------------------------------------+
813 | Extra required | DELETED-STORAGE STATUS request data |
814 | IMAP commands/ | item and response data item |
816 +-------------------+---------------------------------------+
817 | Extra optional | N/A |
820 +-------------------+---------------------------------------+
821 | Author: | Alexey Melnikov |
822 | | <alexey.melnikov@isode.com> |
823 +-------------------+---------------------------------------+
824 | Change | IESG <iesg@ietf.org> |
826 +-------------------+---------------------------------------+
827 | Reference: | Section 5.1 of RFC 9208 |
828 +-------------------+---------------------------------------+
832 +=====================+==========================================+
833 | field name | field value |
834 +=====================+==========================================+
835 | Name of the quota | MESSAGE |
837 +---------------------+------------------------------------------+
838 | Description: | The number of messages stored within the |
839 | | mailboxes governed by the quota root. |
840 +---------------------+------------------------------------------+
841 | Extra required IMAP | DELETED STATUS request data item and |
842 | commands/responses: | response data item |
843 +---------------------+------------------------------------------+
844 | Extra optional IMAP | N/A |
845 | commands/responses: | |
846 +---------------------+------------------------------------------+
847 | Author: | Alexey Melnikov |
848 | | <alexey.melnikov@isode.com> |
849 +---------------------+------------------------------------------+
850 | Change Controller: | IESG <iesg@ietf.org> |
851 +---------------------+------------------------------------------+
852 | Reference: | Section 5.2 of RFC 9208 |
853 +---------------------+------------------------------------------+
857 +==================================+=============================+
858 | field name | field value |
859 +==================================+=============================+
860 | Name of the quota resource type: | MAILBOX |
861 +----------------------------------+-----------------------------+
862 | Description: | The number of mailboxes |
863 | | governed by the quota root. |
864 +----------------------------------+-----------------------------+
865 | Extra required IMAP commands/ | N/A |
867 +----------------------------------+-----------------------------+
868 | Extra optional IMAP commands/ | N/A |
870 +----------------------------------+-----------------------------+
871 | Author: | Alexey Melnikov |
872 | | <alexey.melnikov@isode.com> |
873 +----------------------------------+-----------------------------+
874 | Change Controller: | IESG <iesg@ietf.org> |
875 +----------------------------------+-----------------------------+
876 | Reference: | Section 5.3 of RFC 9208 |
877 +----------------------------------+-----------------------------+
881 +================+=======================================+
882 | field name | field value |
883 +================+=======================================+
884 | Name of the | ANNOTATION-STORAGE |
887 +----------------+---------------------------------------+
888 | Description: | The maximum size of all annotations |
889 | | [RFC5257], in units of 1024 octets, |
890 | | associated with all messages in the |
891 | | mailboxes governed by the quota root. |
892 +----------------+---------------------------------------+
893 | Extra required | N/A |
896 +----------------+---------------------------------------+
897 | Extra optional | N/A |
900 +----------------+---------------------------------------+
901 | Author: | Alexey Melnikov |
902 | | <alexey.melnikov@isode.com> |
903 +----------------+---------------------------------------+
904 | Change | IESG <iesg@ietf.org> |
906 +----------------+---------------------------------------+
907 | Reference: | Section 5.4 of RFC 9208 |
908 +----------------+---------------------------------------+
910 Table 5: ANNOTATION-STORAGE
91210. Changes Since RFC 2087
914 This document is a revision of [RFC2087], and it aims to clarify the
915 meaning of different terms that were used in that RFC. It also
916 provides more examples, gives guidance on allowed server behavior,
917 defines an IANA registry for quota resource types, and provides
918 initial registrations for 4 of them.
920 When compared with [RFC2087], this document defines two more commonly
921 used resource types, adds an optional OVERQUOTA response code, and
922 defines two extra STATUS data items ("DELETED" and "DELETED-
923 STORAGE"). The DELETED STATUS data item must be implemented if the
924 "QUOTA=RES-MESSAGE" capability is advertised. The DELETED-STORAGE
925 STATUS data item must be implemented if the "QUOTA=RES-STORAGE"
926 capability is advertised. For extensibility, quota usage and quota
927 limits are now 63-bit unsigned integers.
93111.1. Normative References
933 [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
934 Specifications: ABNF", STD 68, RFC 5234,
935 DOI 10.17487/RFC5234, January 2008,
936 <https://www.rfc-editor.org/info/rfc5234>.
938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
939 Requirement Levels", BCP 14, RFC 2119,
940 DOI 10.17487/RFC2119, March 1997,
941 <https://www.rfc-editor.org/info/rfc2119>.
943 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
944 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
945 <https://www.rfc-editor.org/info/rfc3501>.
947 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
948 RFC 4314, DOI 10.17487/RFC4314, December 2005,
949 <https://www.rfc-editor.org/info/rfc4314>.
951 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access
952 Protocol - ANNOTATE Extension", RFC 5257,
953 DOI 10.17487/RFC5257, June 2008,
954 <https://www.rfc-editor.org/info/rfc5257>.
956 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
957 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
958 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
960 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
961 Access Protocol (IMAP) - Version 4rev2", RFC 9051,
962 DOI 10.17487/RFC9051, August 2021,
963 <https://www.rfc-editor.org/info/rfc9051>.
96511.2. Informative References
967 [RFC2033] Myers, J., "Local Mail Transfer Protocol", RFC 2033,
968 DOI 10.17487/RFC2033, October 1996,
969 <https://www.rfc-editor.org/info/rfc2033>.
971 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087,
972 DOI 10.17487/RFC2087, January 1997,
973 <https://www.rfc-editor.org/info/rfc2087>.
975 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
976 Writing an IANA Considerations Section in RFCs", BCP 26,
977 RFC 8126, DOI 10.17487/RFC8126, June 2017,
978 <https://www.rfc-editor.org/info/rfc8126>.
982 The editor of this document would like to thank the following people
983 who provided useful comments or participated in discussions that lead
984 to this update of [RFC2087]: John Myers, Cyrus Daboo, Lyndon
985 Nerenberg, Benjamin Kaduk, Roman Danyliw, and Éric Vyncke.
987 This document is a revision of [RFC2087], and it borrows a lot of
988 text from that RFC. Thus, the work of John Myers, the author of
989 [RFC2087], is appreciated.
993 Dave Cridland wrote a lot of text in an earlier draft version that
994 became the basis for this document.
1000 Email: alexey.melnikov@isode.com
1001 URI: https://www.isode.com