idnits 2.17.1 draft-ietf-extra-quota-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. -- The abstract seems to indicate that this document obsoletes RFC9051, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (22 October 2021) is 916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) ** Downref: Normative reference to an Experimental RFC: RFC 5257 -- Obsolete informational reference (is this intentional?): RFC 2087 (Obsoleted by RFC 9208) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Melnikov 3 Internet-Draft Isode 4 Obsoletes: 2087 (if approved) 22 October 2021 5 Intended status: Standards Track 6 Expires: 25 April 2022 8 IMAP QUOTA Extension 9 draft-ietf-extra-quota-09 11 Abstract 13 This document defines a QUOTA extension of the Internet Message 14 Access Protocol (RFC 3501/RFC 9051) that permits administrative 15 limits on resource usage (quotas) to be manipulated through the IMAP 16 protocol. 18 This document obsoletes RFC 2087, but attempts to remain backwards 19 compatible whenever possible. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on 25 April 2022. 38 Copyright Notice 40 Copyright (c) 2021 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 (https://trustee.ietf.org/ 45 license-info) in effect on the date of publication of this document. 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. Code Components 48 extracted from this document must include Simplified BSD License text 49 as described in Section 4.e of the Trust Legal Provisions and are 50 provided without warranty as described in the Simplified BSD License. 52 This document may contain material from IETF Documents or IETF 53 Contributions published or made publicly available before November 54 10, 2008. The person(s) controlling the copyright in some of this 55 material may not have granted the IETF Trust the right to allow 56 modifications of such material outside the IETF Standards Process. 57 Without obtaining an adequate license from the person(s) controlling 58 the copyright in such materials, this document may not be modified 59 outside the IETF Standards Process, and derivative works of it may 60 not be created outside the IETF Standards Process, except to format 61 it for publication as an RFC or to translate it into languages other 62 than English. 64 Table of Contents 66 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 67 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 68 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 71 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 72 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7 77 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 78 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 79 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 80 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10 81 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 82 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 83 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11 84 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 85 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 89 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14 90 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 93 9.1. Changes/additions to the IMAP4 capabilities registry . . 17 94 9.2. IMAP quota resource type registry . . . . . . . . . . . . 18 95 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18 96 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 97 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 98 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 20 99 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 101 13.2. Informative References . . . . . . . . . . . . . . . . . 21 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 104 1. Document Conventions 106 In protocol examples, this document uses a prefix of "C: " to denote 107 lines sent by the client to the server, and "S: " for lines sent by 108 the server to the client. Lines prefixed with "// " are comments 109 explaining the previous protocol line. These prefixes and comments 110 are not part of the protocol. Lines without any of these prefixes 111 are continuations of the previous line, and no line break is present 112 in the protocol before such lines unless specifically mentioned. 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 116 "OPTIONAL" in this document are to be interpreted as described in BCP 117 14 [RFC2119] [RFC8174] when, and only when, they appear in all 118 capitals, as shown here. 120 Other capitalised words are IMAP keywords [RFC3501][RFC9051] or 121 keywords from this document. 123 2. Introduction and Overview 125 This document defines a couple of extensions to the Internet Message 126 Access Protocol [RFC3501] for querying and manipulating 127 administrative limits on resource usage (quotas). This extension is 128 compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. 130 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 131 Some responses and response codes defined in this document are not 132 present in such servers (see Section 12 for more details), and 133 clients MUST NOT rely on their presence in the absence of any 134 capability beginning with "QUOTA=". 136 Any server compliant with this document MUST also return at least one 137 capability starting with "QUOTA=RES-" prefix, as described in 138 Section 3.1. 140 Any server compliant with this document that implements the SETQUOTA 141 command (see Section 4.1.3) MUST also return the "QUOTASET" 142 capability. 144 This document also reserves all other capabilities starting with 145 "QUOTA=" prefix for future IETF stream standard track, informational 146 or experimental extensions to this document. 148 Quotas can be used to restrict clients for administrative reasons, 149 but the QUOTA extension can also be used to indicate system limits 150 and current usage levels to clients. 152 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 153 this has seen deployment in servers, it has seen little deployment in 154 clients. Since the meaning of the resources was left implementation- 155 dependent, it was impossible for a client implementation to determine 156 which resources were supported, and impossible to determine which 157 mailboxes were in a given quota root (see Section 3.2), without a 158 priori knowledge of the implementation. 160 3. Terms 162 3.1. Resource 164 A resource has a name, a formal definition. 166 3.1.1. Name 168 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. 169 These MUST be registered with IANA. Implementation specific 170 resources begin with "V-" . 172 Supported resource names MUST be advertised as a capability, by 173 prepending the resource name with "QUOTA=RES-". A server compliant 174 with this specification is not required to support all reported 175 resource types on all quota roots. 177 3.1.2. Definition 179 The resource definition or document containing it, while not visible 180 through the protocol, SHOULD be registered with IANA. 182 The usage of a resource MUST be represented as a 63 bit unsigned 183 integer. 0 indicates that the resource is exhausted. Usage integers 184 don't necessarily represent proportional use, so clients MUST NOT 185 compare available resource between two separate quota roots on the 186 same or different servers. 188 Limits will be specified as, and MUST be represented as, an integer. 189 0 indicates that any usage is prohibited. 191 Limits may be hard or soft - that is, an implementation MAY choose, 192 or be configured, to disallow any command if the limit on a resource 193 is or would be exceeded. 195 All resources which the server handles MUST be advertised in a 196 CAPABILITY response/response code consisting of the resource name 197 prefixed by "QUOTA=RES-". 199 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX 200 (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in 201 this document. 203 3.2. Quota Root 205 This document introduces a concept of a "quota root", as resource 206 limits can apply across multiple IMAP mailboxes. 208 Each mailbox has zero or more implementation-defined named "quota 209 roots". Each quota root has zero or more resource limits (quotas). 210 All mailboxes that share the same named quota root share the resource 211 limits of the quota root. 213 Quota root names need not be mailbox names, nor is there any 214 relationship defined by this document between a quota root name and a 215 mailbox name. A quota root name is an astring, as defined in IMAP4 216 [RFC3501]. It SHOULD be treated as an opaque string by any clients. 218 Quota roots are used since not all implementations may be able to 219 calculate usage, or apply quotas, on arbitrary mailboxes or mailbox 220 hierarchies. 222 Not all resources may be limitable or calculable for all quota roots. 223 Further, not all resources may support all limits - some limits may 224 be present in the underlying system. A server implementation of this 225 memo SHOULD advise the client of such inherent limits, by generating 226 QUOTA (Section 4.2.1) responses, and SHOULD advise the client of 227 which resources are limitable for a particular quota root. A 228 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, and similarly 236 STORAGE (Section 5.1) may be rounded to the nearest block and limited 237 by free filesystem space. 239 4. Definitions 241 4.1. Commands 243 The following commands exist for manipulation and querying quotas. 245 4.1.1. GETQUOTA 247 Arguments: quota root 249 Responses: REQUIRED untagged responses: QUOTA 251 Result: OK - getquota completed 253 NO - getquota error: no such quota root, permission denied 255 BAD - command unknown or arguments invalid 257 The GETQUOTA command takes the name of a quota root and returns the 258 quota root's resource usage and limits in an untagged QUOTA response. 259 (Names of quota roots applicable to a particular mailbox can be 260 discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.) 261 Note that the server is not required to support any specific resource 262 type (as advertised in the CAPABILITY response, i.e. all capability 263 items with the "QUOTA=RES-" prefix) for any particular quota root. 265 Example: 267 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 269 [...] 271 C: G0001 GETQUOTA "!partition/sda4" 273 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 275 S: G0001 OK Getquota complete 277 4.1.2. GETQUOTAROOT 279 Arguments: mailbox name 281 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 283 Result: OK - getquotaroot completed 285 NO - getquotaroot error: permission denied 287 BAD - command unknown or arguments invalid 289 The GETQUOTAROOT command takes a mailbox name and returns the list of 290 quota roots for the mailbox in an untagged QUOTAROOT response. For 291 each listed quota root, it also returns the quota root's resource 292 usage and limits in an untagged QUOTA response. 294 Note that the mailbox name parameter doesn't have to reference an 295 existing mailbox. This can be handy in order to determine which 296 quotaroot would apply to a mailbox when it gets created. 298 Example: 300 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 301 [...] 303 [...] 305 C: G0002 GETQUOTAROOT INBOX 307 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 309 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 311 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 313 S: G0002 OK Getquotaroot complete 315 4.1.3. SETQUOTA 317 Arguments: quota root 319 list of resource limits 321 Responses: untagged responses: QUOTA 323 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 SETQUOTA command requires the server to 330 advertise "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 be 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 340 root.) 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 348 QUOTA responses. 350 Example: 352 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- 353 MESSAGE [...] 355 [...] 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 the 368 nearest 512 blocks of 1024 octects, or else another client has 369 performed a near simultaneous SETQUOTA, using a limit of 512. 371 S: S0001 OK Rounded quota 372 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 374 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 376 // The server has not changed the quota, since this is a 377 filesystem limit, and cannot be changed. The QUOTA response here 378 is entirely optional. 380 S: S0002 NO Cannot change system limit 382 4.1.4. New STATUS attributes 384 DELETED and DELETED-STORAGE status data items allow to estimate the 385 amount of resource freed by an EXPUNGE on a mailbox. 387 The DELETED status data item requests the server to return the number 388 of messages with \Deleted flag set. The DELETED status data item is 389 only required to be implemented when the server advertises QUOTA=RES- 390 MESSAGE capability. 392 The DELETED-STORAGE status data item requests the server to return 393 the amount of storage space that can be reclaimed by performing 394 EXPUNGE on the mailbox. The server SHOULD return the exact value, 395 however it is recognized that the server may have to do non-trivial 396 amount of work to calculate it. If the calculation of the exact 397 value would take a long time, the server MAY instead return the sum 398 of RFC822.SIZEs of messages with the \Deleted flag set. The DELETED- 399 STORAGE status data item is only required to be implemented when the 400 server advertises QUOTA=RES-STORAGE capability. 402 Example: 404 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 405 [...] 407 [...] 409 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) 411 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) 413 // 12 messages, 4 of which would be deleted when an EXPUNGE 414 happens. 416 S: S0003 OK Status complete. 418 4.2. Responses 420 The following responses may be sent by the server. 422 4.2.1. QUOTA 424 Data: quota root name 426 list of resource names, usages, and limits 428 This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a 429 SETQUOTA command. The first string is the name of the quota root for 430 which this quota applies. 432 The name is followed by a S-expression format list of the resource 433 usage and limits of the quota root. The list contains zero or more 434 triplets. Each triplet contains a resource name, the current usage 435 of the resource, and the resource limit. 437 Resources not named in the list are not limited in the quota root. 438 Thus, an empty list means there are no administrative resource limits 439 in the quota root. 441 Example: S: * QUOTA "" (STORAGE 10 512) 443 4.2.2. QUOTAROOT 445 Data: mailbox name 447 zero or more quota root names 449 This response occurs as a result of a GETQUOTAROOT command. The 450 first string is the mailbox and the remaining strings are the names 451 of the quota roots for the mailbox. 453 Examples: 455 S: * QUOTAROOT INBOX "" 457 // The INBOX mailbox is covered by a single quota root with name "". 459 S: * QUOTAROOT comp.mail.mime 461 // The comp.mail.mime mailbox has no quota root associated with it, 462 but one can be created. 464 4.3. Response Codes 465 4.3.1. OVERQUOTA 467 OVERQUOTA response code SHOULD be returned in the tagged NO response 468 to an APPEND/COPY/MOVE when the addition of the message(s) puts the 469 target mailbox over any one of its quota limits. 471 Example 1: C: A003 APPEND saved-messages (\Seen) {326} 472 S: + Ready for literal data 473 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 474 C: From: Fred Foobar 475 C: Subject: afternoon meeting 476 C: To: mooch@owatagu.siam.edu.example 477 C: Message-Id: 478 C: MIME-Version: 1.0 479 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 480 C: 481 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 482 C: 483 S: A003 NO [OVERQUOTA] APPEND Failed 485 The OVERQUOTA response code MAY also be returned in an untagged NO 486 response in the authenticated or the selected state, when a mailbox 487 exceeds soft quota. For example, such OVERQUOTA response code might 488 be sent as a result of an external event (e.g. LMTP delivery or 489 COPY/MOVE/APPEND in another IMAP connection) that causes the 490 currently selected mailbox to exceed soft quota. Note that such 491 OVERQUOTA response code might be ambiguous, because it might relate 492 to the target mailbox (as specified in COPY/MOVE/APPEND) or to the 493 currently selected mailbox. (The WG chose not to address this 494 deficiency due to syntactic limitations of IMAP response codes and 495 because such events are likely to be rare.) This form of the 496 OVERQUOTA response codes MUST NOT be returned if there is no mailbox 497 selected and no command in progress that adds a message to a mailbox 498 (e.g. APPEND). 500 Example 2: C: A003 APPEND saved-messages (\Seen) {326} 501 S: + Ready for literal data 502 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 503 C: From: Fred Foobar 504 C: Subject: afternoon meeting 505 C: To: mooch@owatagu.siam.edu.example 506 C: Message-Id: 507 C: MIME-Version: 1.0 508 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 509 C: 510 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 511 C: 512 S: * NO [OVERQUOTA] Soft quota has been exceeded 513 S: A003 OK [APPENDUID 38505 3955] APPEND completed 515 Example 3: C: A004 COPY 2:4 MEETING 516 S: * NO [OVERQUOTA] Soft quota has been exceeded 517 S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY 518 command completed 520 5. Resource Type Definitions 522 The following resource types are defined in this memo. A server 523 supporting a resource type MUST advertise this as a CAPABILITY with a 524 name consisting of the resource name prefixed by "QUOTA=RES-". A 525 server MAY support multiple resource types, and MUST advertise all 526 resource types it supports. 528 5.1. STORAGE 530 The physical space estimate, in units of 1024 octets, of the 531 mailboxes governed by the quota root. This MAY not be the same as 532 the sum of the RFC822.SIZE of the messages. Some implementations MAY 533 include metadata sizes for the messages and mailboxes, other 534 implementations MAY store messages in such a way that the physical 535 space used is smaller, for example due to use of compression. 536 Additional messages might not increase the usage. Client MUST NOT 537 use the usage figure for anything other than informational purposes, 538 for example, they MUST NOT refuse to APPEND a message if the limit 539 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 540 message, but it MAY warn about such condition. 542 The usage figure may change as a result of performing actions not 543 associated with adding new messages to the mailbox, such as SEARCH, 544 since this may increase the amount of metadata included in the 545 calculations. 547 When the server supports this resource type, it MUST also support the 548 DELETED-STORAGE status data item. 550 Support for this resource MUST be indicated by the server by 551 advertising the CAPABILITY "QUOTA=RES-STORAGE". 553 A resource named the same was also given as an example in RFC2087 554 [RFC2087]. This document provides a more precise definition. 556 5.2. MESSAGE 558 The number of messages stored within the mailboxes governed by the 559 quota root. This MUST be an exact number, however, clients MUST NOT 560 assume that a change in the usage indicates a change in the number of 561 messages available, since the quota root may include mailboxes the 562 client has no access to. 564 When the server supports this resource type, it MUST also support the 565 DELETED status data item. 567 Support for this resource MUST be indicated by the server by 568 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 570 A resource named the same was also given as an example in RFC2087 571 [RFC2087]. This document provides a more precise definition. 573 5.3. MAILBOX 575 The number of mailboxes governed by the quota root. This MUST be an 576 exact number, however, clients MUST NOT assume that a change in the 577 usage indicates a change in the number of mailboxes, since the quota 578 root may include mailboxes the client has no access to. 580 Support for this resource MUST be indicated by the server by 581 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 583 5.4. ANNOTATION-STORAGE 585 The maximum size of all annotations [RFC5257], in units of 1024 586 octets, associated with all messages in the mailboxes governed by the 587 quota root. 589 Support for this resource MUST be indicated by the server by 590 advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". 592 6. Interaction with IMAP ACL extension (RFC 4314) 594 This section lists [RFC4314] rights required to execute quota related 595 commands when both RFC 4314 and this document are implemented. 597 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 598 | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non | 599 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 600 | GETQUOTA | | | | | | | | | | | | + | 601 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 602 | GETQUOTAROOT | |*| | | | | | | | | | * | 603 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 604 | SETQUOTA | | | | | | | | | | + | | | 605 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 607 Table 1 609 See Section 4 of RFC 4314 for conventions used in this table. 611 Legend: 613 + - The right is required 615 * - Only one of the rights marked with * is required 617 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 618 required 620 "Non" - no rights required to perform the command 622 Note that which permissions are needed in order to perform 623 GETQUOTAROOT command depends on the quota resource type being 624 requested. For example, a quota on number of messages (MESSAGE 625 resource type) or total size of messages (STORAGE resource type) 626 requires "r" right on the mailbox in question, since the quota 627 involved would reveal information about the number (or total size) of 628 messages in the mailbox. By comparison, the MAILBOX resource type 629 doesn't require any right. 631 7. Formal syntax 633 The following syntax specification uses the Augmented Backus-Naur 634 Form (ABNF) notation as specified in [ABNF]. 636 Non-terminals referenced but not defined below are as defined by 637 IMAP4 [RFC3501]. 639 Except as noted otherwise, all alphabetic characters are case- 640 insensitive. The use of upper or lower case characters to define 641 token strings is for editorial clarity only. Implementations MUST 642 accept these strings in a case-insensitive fashion. 644 getquota = "GETQUOTA" SP quota-root-name 646 getquotaroot = "GETQUOTAROOT" SP mailbox 648 quota-list = "(" quota-resource *(SP quota-resource) ")" 650 quota-resource = resource-name SP resource-usage SP resource-limit 652 quota-response = "QUOTA" SP quota-root-name SP quota-list 654 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 656 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 658 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 659 ")" 661 setquota-resource = resource-name SP resource-limit 663 quota-root-name = astring 665 resource-limit = number64 667 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 669 "ANNOTATION-STORAGE" / resource-name-vnd / 671 resource-name-ext 673 resource-name-vnd = "V-" atom 675 ;; Vendor specific, must be registered with IANA. 677 ;; The "V-" prefix should be followed by a domain 678 name 680 ;; under vendor's control. 682 resource-name-ext = atom 684 ;; Not starting with V- and defined 686 ;; in an IETF Stream RFC 688 resource-usage = number64 690 ;; must be less than corresponding resource-limit 692 capability-quota = capa-quota-res / "QUOTASET" 694 ;; One or more capa-quota-res must be returned. 696 ;; Also "QUOTASET" can optionally be returned. 698 capa-quota-res = "QUOTA=RES-" resource-name 700 status-att =/ "DELETED" / "DELETED-STORAGE" 702 ;; DELETED status data item MUST be supported 704 ;; when "QUOTA=RES-MESSAGE" capability is 706 ;; advertised. 708 ;; DELETED-STORAGE status data item MUST be 710 ;; supported when "QUOTA=RES-STORAGE" capability 712 ;; is advertised. 714 status-att-val =/ status-att-deleted / 716 status-att-deleted-storage 718 status-att-deleted = "DELETED" SP number 720 ;; DELETED status data item MUST be supported 722 ;; when "QUOTA=RES-MESSAGE" capability is 724 ;; advertised. 726 status-att-deleted-storage = "DELETED-STORAGE" SP number64 728 ;; DELETED-STORAGE status data item MUST be 730 ;; supported when "QUOTA=RES-STORAGE" capability 732 ;; is advertised. 734 resp-text-code =/ "OVERQUOTA" 735 number64 = 737 8. Security Considerations 739 Implementors should be careful to make sure the implementation of 740 these commands does not violate the site's security policy. The 741 resource usage of other users is likely to be considered confidential 742 information and should not be divulged to unauthorized persons. In 743 particular, no quota information should be disclosed to anonymous 744 users. 746 As for any resource shared across users (for example a quota root 747 attached to a set of shared mailboxes), a user that can consume or 748 render unusable the resource can affect the resources available to 749 the other users; this might occur, for example, by a user with 750 permission to execute SETQUOTA setting an artificially small value. 752 Note that computing resource usage might incur a heavy load on the 753 server. Server implementers should consider implementation 754 techniques that lower load on servers, such as caching of resource 755 usage information or usage of less precise computations when under 756 heavy load. 758 9. IANA Considerations 760 9.1. Changes/additions to the IMAP4 capabilities registry 762 IMAP4 capabilities are registered by publishing a standards track or 763 IESG approved Informational or Experimental RFC. The registry is 764 currently located at: 766 https://www.iana.org/assignments/imap4-capabilities 768 IANA is requested to update definition of the QUOTA extension to 769 point to this document. IANA is also requested to add the "QUOTASET" 770 capability to the IMAP4 capabilities registry, with this document as 771 the reference. 773 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 774 capabilities registry and add a pointer to this document and to the 775 IMAP quota resource type registry (see Section 9.2). 777 IANA is requested to reserve all other capabilities starting with 778 "QUOTA=" prefix for future IETF Stream extensions to this document. 780 9.2. IMAP quota resource type registry 782 IANA is requested to create a new registry for IMAP quota resource 783 types. Registration policy for this registry is "Specification 784 Required". When registering a new quota resource type, the 785 registrant need to provide the following: Name of the quota resource 786 type, Author/Change Controller name and email address, short 787 description, extra (if any) required and optional IMAP commands/ 788 responses, and a reference to a specification that describes the 789 quota resource type in more details. 791 Designated Experts should check that provided references are correct, 792 that they describe the quota resource type being registered in 793 sufficient details to be implementable, that syntax of any optional 794 commands/responses is correct (e.g. ABNF validates), and their 795 syntax/description complies with rules and limitations imposed by 796 IMAP [RFC3501][RFC9051]. Designated Experts should avoid registering 797 multiple identical quota resource types under different names and 798 should provide advice to requestors about other possible quota 799 resource types to use. 801 This document includes initial registrations for the following IMAP 802 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), 803 MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 804 Section 9.3 for the registration templates. 806 9.3. Registrations of IMAP Quota Resource Types 808 Name of the quota resource type: STORAGE 810 Author: Alexey Melnikov 812 Change Controller: IESG 814 Description: The physical space estimate, in units of 1024 octets, 815 of the mailboxes governed by the quota root. 817 Extra required IMAP commands/responses: DELETED-STORAGE STATUS 818 request data item and response data item 820 Extra optional IMAP commands/responses: N/A 822 Reference: Section 5.1 of RFCXXXX 824 Name of the quota resource type: MESSAGE 826 Author: Alexey Melnikov 827 Change Controller: IESG 829 Description: The number of messages stored within the mailboxes 830 governed by the quota root. 832 Extra required IMAP commands/responses: DELETED STATUS request data 833 item and response data item 835 Extra optional IMAP commands/responses: N/A 837 Reference: Section 5.2 of RFCXXXX 839 Name of the quota resource type: MAILBOX 841 Author: Alexey Melnikov 843 Change Controller: IESG 845 Description: The number of mailboxes governed by the quota root. 847 Extra required IMAP commands/responses: N/A 849 Extra optional IMAP commands/responses: N/A 851 Reference: Section 5.3 of RFCXXXX 853 Name of the quota resource type: ANNOTATION-STORAGE 855 Author: Alexey Melnikov 857 Change Controller: IESG 859 Description: The maximum size of all annotations [RFC5257], in units 860 of 1024 octets, associated with all messages in the mailboxes 861 governed by the quota root. 863 Extra required IMAP commands/responses: N/A 865 Extra optional IMAP commands/responses: N/A 867 Reference: Section 5.4 of RFCXXXX 869 10. Contributors 871 Dave Cridland wrote lots of text in an earlier draft that became the 872 basis for this document. 874 11. Acknowledgments 876 Editor of this document would like to thank the following people who 877 provided useful comments or participated in discussions that lead to 878 this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg, 879 Benjamin Kaduk, Roman Danyliw, Eric Vyncke. 881 This document is a revision of RFC 2087. It borrows a lot of text 882 from RFC 2087. Thus work of the RFC 2087 author John Myers is 883 appreciated. 885 12. Changes since RFC 2087 887 This document is a revision of RFC 2087. It tries to clarify the 888 meaning of different terms used by RFC 2087. It also provides more 889 examples, gives guidance on allowed server behaviour, defines IANA 890 registry for quota resource types and provides initial registrations 891 for 4 of them. 893 When compared with RFC 2087, this document defines two more commonly 894 used resource type, adds optional OVERQUOTA response code and defines 895 two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The 896 DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE 897 capability is advertised. The DELETED-STORAGE STATUS data item must 898 be implemented if the QUOTA=RES-STORAGE capability is advertised. 899 For extensibility quota usage and quota limits are now 63 bit 900 unsigned integers. 902 13. References 904 13.1. Normative References 906 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 907 Syntax Specifications: ABNF", RFC 5234, January 2008, 908 . 910 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 911 Requirement Levels", BCP 14, RFC 2119, 912 DOI 10.17487/RFC2119, March 1997, 913 . 915 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 916 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 917 . 919 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 920 RFC 4314, DOI 10.17487/RFC4314, December 2005, 921 . 923 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 924 Protocol - ANNOTATE Extension", RFC 5257, 925 DOI 10.17487/RFC5257, June 2008, 926 . 928 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 929 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 930 May 2017, . 932 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 933 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 934 DOI 10.17487/RFC9051, August 2021, 935 . 937 13.2. Informative References 939 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 940 DOI 10.17487/RFC2087, January 1997, 941 . 943 Author's Address 945 Alexey Melnikov 946 Isode Limited 948 Email: alexey.melnikov@isode.com 949 URI: https://www.isode.com