idnits 2.17.1 draft-ietf-extra-quota-07.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 1 instance 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 == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (24 September 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) 24 September 2021 5 Intended status: Standards Track 6 Expires: 28 March 2022 8 IMAP QUOTA Extension 9 draft-ietf-extra-quota-07 11 Abstract 13 The QUOTA extension of the Internet Message Access Protocol (RFC 14 3501/RFC 9051) permits administrative limits on resource usage 15 (quotas) to be manipulated through the IMAP protocol. 17 This document obsoletes RFC 2087, but attempts to remain backwards 18 compatible whenever possible. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 28 March 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 66 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 67 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 71 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 73 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 76 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 77 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 78 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 81 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 82 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 84 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 85 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 86 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 88 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13 89 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Changes/additions to the IMAP4 capabilities registry . . 16 93 9.2. IMAP quota resource type registry . . . . . . . . . . . . 17 94 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17 95 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 96 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 97 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 98 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 99 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 100 13.2. Informative References . . . . . . . . . . . . . . . . . 20 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 103 1. Document Conventions 105 In protocol examples, this document uses a prefix of "C: " to denote 106 lines sent by the client to the server, and "S: " for lines sent by 107 the server to the client. Lines prefixed with "// " are comments 108 explaining the previous protocol line. These prefixes and comments 109 are not part of the protocol. Lines without any of these prefixes 110 are continuations of the previous line, and no line break is present 111 in the protocol unless specifically mentioned. 113 Again, for examples, the hierarchy separator on the IMAP server is 114 presumed to be "/" throughout. None of these assumptions is required 115 nor recommended by this document. 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 Other capitalised words are IMAP keywords [RFC3501][RFC9051] or 124 keywords from this document. 126 2. Introduction and Overview 128 This document defines a couple of extensions to the Internet Message 129 Access Protocol [RFC3501] for querying and manipulating 130 administrative limits on resource usage (quotas). This extension is 131 compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. 133 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 134 Some responses and response codes defined in this document are not 135 present in such servers (see Section 12 for more details), and 136 clients MUST NOT rely on their presence in the absence of any 137 capability beginning with "QUOTA=". 139 Any server compliant with this document MUST also return at least one 140 capability starting with "QUOTA=RES-" prefix, as described in 141 Section 3.1. 143 Any server compliant with this document that implements the SETQUOTA 144 command (see Section 4.1.3) MUST also return the "QUOTASET" 145 capability. 147 This document also reserves all other capabilities starting with 148 "QUOTA=" prefix for future IETF stream standard track, informational 149 or experimental extensions to this document. 151 Quotas can be used to restrict clients for administrative reasons, 152 but the QUOTA extension can also be used to indicate system limits 153 and current usage levels to clients. 155 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 156 this has seen deployment in servers, it has seen little deployment in 157 clients. Since the meaning of the resources was left implementation- 158 dependant, it was impossible for a client implementation to determine 159 which resources were supported, and impossible to determine which 160 mailboxes were in a given quota root (see Section 3.2), without a 161 priori knowledge of the implementation. 163 3. Terms 165 3.1. Resource 167 A resource has a name, a formal definition. 169 3.1.1. Name 171 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. 172 These MUST be registered with IANA. Implementation specific 173 resources begin with "V-" . 175 Supported resource names MUST be advertised as a capability, by 176 prepending the resource name with "QUOTA=RES-". A server compliant 177 with this specification is not required to support all reported 178 resource types on all quota roots. 180 3.1.2. Definition 182 The resource definition or document containing it, while not visible 183 through the protocol, SHOULD be registered with IANA. 185 The usage of a resource MUST be represented as a 63 bit unsigned 186 integer. 0 indicates that the resource is exhausted. Usage integers 187 don't necessarily represent proportional use, so clients MUST NOT 188 compare available resource between two separate quota roots on the 189 same or different servers. 191 Limits will be specified as, and MUST be represented as, an integer. 192 0 indicates that any usage is prohibited. 194 Limits may be hard or soft - that is, an implementation MAY choose, 195 or be configured, to disallow any command if the limit on a resource 196 is or would be exceeded. 198 All resources which the server handles MUST be advertised in a 199 CAPABILITY response/response code consisting of the resource name 200 prefixed by "QUOTA=RES-". 202 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX 203 (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in 204 this document. 206 3.2. Quota Root 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 arbitary mailboxes or mailbox 220 hierarchies. 222 Not all resources may be limitable or calculatable for all quota 223 roots. Further, not all resources may support all limits - some 224 limits may be present in the underlying system. A server 225 implementation of this memo SHOULD advise the client of such inherent 226 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 227 advise the client of which resources are limitable for a particular 228 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 229 quota limit in an implementation dependant way, if the granularity of 230 the underlying system demands it. A client MUST be prepared for a 231 SETQUOTA (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 The client can try using any of the resource types returned in 260 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 261 prefix), however the server is not required to support any specific 262 resource type for any particular quota root. 264 Example: 266 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 268 [...] 270 C: G0001 GETQUOTA "!partition/sda4" 272 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 274 S: G0001 OK Getquota complete 276 4.1.2. GETQUOTAROOT 278 Arguments: mailbox name 279 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 281 Result: OK - getquotaroot completed 283 NO - getquotaroot error: permission denied 285 BAD - command unknown or arguments invalid 287 The GETQUOTAROOT command takes a mailbox name and returns the list of 288 quota roots for the mailbox in an untagged QUOTAROOT response. For 289 each listed quota root, it also returns the quota root's resource 290 usage and limits in an untagged QUOTA response. 292 Note that the mailbox name parameter doesn't have to reference an 293 existing mailbox. This can be handy in order to determine which 294 quotaroot would apply to a mailbox when it gets created. 296 Example: 298 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 299 [...] 301 [...] 303 C: G0002 GETQUOTAROOT INBOX 305 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 307 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 309 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 311 S: G0002 OK Getquotaroot complete 313 4.1.3. SETQUOTA 315 Arguments: quota root 317 list of resource limits 319 Responses: untagged responses: QUOTA 321 Result: OK - setquota completed 323 NO - setquota error: can't set that data 325 BAD - command unknown or arguments invalid 327 Note that unlike other command/responses/response codes defined in 328 this document, support for SETQUOTA command requires the server to 329 advertise "QUOTASET" capability. 331 The SETQUOTA command takes the name of a mailbox quota root and a 332 list of resource limits. The resource limits for the named quota 333 root are changed to be the specified limits. Any previous resource 334 limits for the named quota root are discarded. 336 If the named quota root did not previously exist, an implementation 337 may optionally create it and change the quota roots for any number of 338 existing mailboxes in an implementation-defined manner. 340 If the implementation chooses to change the quota roots for some 341 existing mailboxes such changes SHOULD be announced with untagged 342 QUOTA responses. 344 Example: 346 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- 347 MESSAGE [...] 349 [...] 351 C: S0000 GETQUOTA "#user/alice" 353 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 355 S: S0000 OK Getquota completed 357 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 359 S: * QUOTA "#user/alice" (STORAGE 58 512) 361 // The server has rounded the STORAGE quota limit requested to the 362 nearest 512 blocks of 1024 octects, or else another client has 363 performed a near simultaneous SETQUOTA, using a limit of 512. 365 S: S0001 OK Rounded quota 367 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 369 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 371 // The server has not changed the quota, since this is a 372 filesystem limit, and cannot be changed. The QUOTA response here 373 is entirely optional. 375 S: S0002 NO Cannot change system limit 377 4.1.4. New STATUS attributes 379 DELETED and DELETED-STORAGE status data items allow to estimate the 380 amount of resource freed by an EXPUNGE on a mailbox. 382 DELETED status data item requests the server to return the number of 383 messages with \Deleted flag set. DELETED status data item is only 384 required to be implemented when the server advertises QUOTA=RES- 385 MESSAGE capability. 387 DELETED-STORAGE status data item requests the server to return the 388 amount of storage space that can be reclaimed by performing EXPUNGE 389 on the mailbox. The server SHOULD return the exact value, however it 390 is recognized that the server may have to do non-trivial amount of 391 work to calculate it. If the calculation of the exact value would 392 take a long time, the server MAY instead return the sum of 393 RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE 394 status data item is only required to be implemented when the server 395 advertises QUOTA=RES-STORAGE capability. 397 Example: 399 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 400 [...] 402 [...] 404 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) 406 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) 408 // 12 messages, 4 of which would be deleted when an EXPUNGE 409 happens. 411 S: S0003 OK Status complete. 413 4.2. Responses 415 The following responses may be sent by the server. 417 4.2.1. QUOTA 419 Data: quota root name 421 list of resource names, usages, and limits 423 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 424 command. The first string is the name of the quota root for which 425 this quota applies. 427 The name is followed by a S-expression format list of the resource 428 usage and limits of the quota root. The list contains zero or more 429 triplets. Each triplet contains a resource name, the current usage 430 of the resource, and the resource limit. 432 Resources not named in the list are not limited in the quota root. 433 Thus, an empty list means there are no administrative resource limits 434 in the quota root. 436 Example: S: * QUOTA "" (STORAGE 10 512) 438 4.2.2. QUOTAROOT 440 Data: mailbox name 442 zero or more quota root names 444 This response occurs as a result of a GETQUOTAROOT command. The 445 first string is the mailbox and the remaining strings are the names 446 of the quota roots for the mailbox. 448 Example: 450 S: * QUOTAROOT INBOX "" 452 S: * QUOTAROOT comp.mail.mime 454 4.3. Response Codes 456 4.3.1. OVERQUOTA 458 OVERQUOTA response code SHOULD be returned in the tagged NO response 459 to an APPEND/COPY/MOVE when the addition of the message(s) puts the 460 target mailbox over any one of its quota limits. 462 Example 1: C: A003 APPEND saved-messages (\Seen) {326} 463 S: + Ready for literal data 464 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 465 C: From: Fred Foobar 466 C: Subject: afternoon meeting 467 C: To: mooch@owatagu.siam.edu.example 468 C: Message-Id: 469 C: MIME-Version: 1.0 470 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 471 C: 472 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 473 C: 474 S: A003 NO [OVERQUOTA] APPEND Failed 476 The OVERQUOTA response code MAY also be returned in an untagged NO 477 response in the authenticated or the selected state, when a mailbox 478 exceeds soft quota. For example, such OVERQUOTA response code might 479 be sent as a result of an external event (e.g. LMTP delivery or 480 COPY/MOVE/APPEND in another IMAP connection) that causes the 481 currently selected mailbox to exceed soft quota. Note that such 482 OVERQUOTA response code might be ambiguous, because it might relate 483 to the target mailbox (as specified in COPY/MOVE/APPEND) or to the 484 currently selected mailbox. (The WG chose not to address this 485 deficiency due to syntactic limitations of IMAP response codes and 486 because such events are likely to be rare.) This form of the 487 OVERQUOTA response codes MUST NOT be returned if there is no mailbox 488 selected and no command in progress that adds a message to a mailbox 489 (e.g. APPEND). 491 Example 2: C: A003 APPEND saved-messages (\Seen) {326} 492 S: + Ready for literal data 493 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 494 C: From: Fred Foobar 495 C: Subject: afternoon meeting 496 C: To: mooch@owatagu.siam.edu.example 497 C: Message-Id: 498 C: MIME-Version: 1.0 499 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 500 C: 501 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 502 C: 503 S: * NO [OVERQUOTA] Soft quota has been exceeded 504 S: A003 OK [APPENDUID 38505 3955] APPEND completed 506 Example 3: C: A003 COPY 2:4 MEETING 507 S: * NO [OVERQUOTA] Soft quota has been exceeded 508 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY 509 command completed 511 5. Resource Type Definitions 513 The following resource types are defined in this memo. A server 514 supporting a resource type MUST advertise this as a CAPABILITY with a 515 name consisting of the resource name prefixed by "QUOTA=RES-". A 516 server MAY support multiple resource types, and MUST advertise all 517 resource types it supports. 519 5.1. STORAGE 521 The physical space estimate, in units of 1024 octets, of the 522 mailboxes governed by the quota root. This MAY not be the same as 523 the sum of the RFC822.SIZE of the messages. Some implementations MAY 524 include metadata sizes for the messages and mailboxes, other 525 implementations MAY store messages in such a way that the physical 526 space used is smaller, for example due to use of compression. 527 Additional messages might not increase the usage. Client MUST NOT 528 use the usage figure for anything other than informational purposes, 529 for example, they MUST NOT refuse to APPEND a message if the limit 530 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 531 message, but it MAY warn about such condition. 533 The usage figure may change as a result of performing actions not 534 associated with adding new messages to the mailbox, such as SEARCH, 535 since this may increase the amount of metadata included in the 536 calculations. 538 When the server supports this resource type, it MUST also support 539 DELETED-STORAGE status data item. 541 Support for this resource MUST be indicated by the server by 542 advertising the CAPABILITY "QUOTA=RES-STORAGE". 544 A resource named the same was also given as an example in RFC2087 545 [RFC2087]. This document provides a more precise definition. 547 5.2. MESSAGE 549 The number of messages stored within the mailboxes governed by the 550 quota root. This MUST be an exact number, however, clients MUST NOT 551 assume that a change in the usage indicates a change in the number of 552 messages available, since the quota root may include mailboxes the 553 client has no access to. 555 When the server supports this resource type, it MUST also support 556 DELETED status data item. 558 Support for this resource MUST be indicated by the server by 559 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 561 A resource named the same was also given as an example in RFC2087 562 [RFC2087]. This document provides a more precise definition. 564 5.3. MAILBOX 566 The number of mailboxes governed by the quota root. This MUST be an 567 exact number, however, clients MUST NOT assume that a change in the 568 usage indicates a change in the number of mailboxes, since the quota 569 root may include mailboxes the client has no access to. 571 Support for this resource MUST be indicated by the server by 572 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 574 5.4. ANNOTATION-STORAGE 576 The maximum size of all annotations [RFC5257], in units of 1024 577 octets, associated with all messages in the mailboxes governed by the 578 quota root. 580 Support for this resource MUST be indicated by the server by 581 advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". 583 6. Interaction with IMAP ACL extension (RFC 4314) 585 This section lists [RFC4314] rights required to execute quota related 586 commands when both RFC 4314 and this document are implemented. 588 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 589 | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non | 590 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 591 | GETQUOTA | | | | | | | | | | | | + | 592 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 593 | GETQUOTAROOT | |*| | | | | | | | | | * | 594 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 595 | SETQUOTA | | | | | | | | | | + | | | 596 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 598 Table 1 600 See Section 4 of RFC 4314 for conventions used in this table. 602 Legend: 604 + - The right is required 605 * - Only one of the rights marked with * is required 607 "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is 608 required 610 "Non" - no rights required to perform the command 612 7. Formal syntax 614 The following syntax specification uses the Augmented Backus-Naur 615 Form (ABNF) notation as specified in [ABNF]. 617 Non-terminals referenced but not defined below are as defined by 618 IMAP4 [RFC3501]. 620 Except as noted otherwise, all alphabetic characters are case- 621 insensitive. The use of upper or lower case characters to define 622 token strings is for editorial clarity only. Implementations MUST 623 accept these strings in a case-insensitive fashion. 625 getquota = "GETQUOTA" SP quota-root-name 627 getquotaroot = "GETQUOTAROOT" SP mailbox 629 quota-list = "(" quota-resource *(SP quota-resource) ")" 631 quota-resource = resource-name SP resource-usage SP resource-limit 633 quota-response = "QUOTA" SP quota-root-name SP quota-list 635 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 637 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 639 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 640 ")" 642 setquota-resource = resource-name SP resource-limit 644 quota-root-name = astring 646 resource-limit = number64 648 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 650 "ANNOTATION-STORAGE" / resource-name-vnd / 652 resource-name-ext 654 resource-name-vnd = "V-" atom 656 ;; Vendor specific, must be registered with IANA. 658 ;; The "V-" prefix should be followed by a domain 659 name 661 ;; under vendor's control. 663 resource-name-ext = atom 665 ;; Not starting with V- and defined 667 ;; in a Standard Track or Experimental RFC 669 resource-names = "(" [resource-name *(SP resource-name)] ")" 671 resource-usage = number64 673 ;; must be less than corresponding resource-limit 675 capability-quota = capa-quota-res / "QUOTASET" 677 ;; One or more capa-quota-res must be returned. 679 ;; Also "QUOTASET" can optionally be returned. 681 capa-quota-res = "QUOTA=RES-" resource-name 683 status-att =/ "DELETED" / "DELETED-STORAGE" 685 ;; DELETED status data item MUST be supported 687 ;; when "QUOTA=RES-MESSAGE" capability is 689 ;; advertised. 691 ;; DELETED-STORAGE status data item MUST be 693 ;; supported when "QUOTA=RES-STORAGE" capability 695 ;; is advertised. 697 status-att-val =/ status-att-deleted / 699 status-att-deleted-storage 701 status-att-deleted =/ "DELETED" SP number 702 ;; DELETED status data item MUST be supported 704 ;; when "QUOTA=RES-MESSAGE" capability is 706 ;; advertised. 708 status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 710 ;; DELETED-STORAGE status data item MUST be 712 ;; supported when "QUOTA=RES-STORAGE" capability 714 ;; is advertised. 716 resp-text-code =/ "OVERQUOTA" 718 number64 = 720 8. Security Considerations 722 Implementors should be careful to make sure the implementation of 723 these commands does not violate the site's security policy. The 724 resource usage of other users is likely to be considered confidential 725 information and should not be divulged to unauthorized persons. In 726 particular, no quota information should be disclosed to anonymous 727 users. 729 9. IANA Considerations 731 9.1. Changes/additions to the IMAP4 capabilities registry 733 IMAP4 capabilities are registered by publishing a standards track or 734 IESG approved Informational or Experimental RFC. The registry is 735 currently located at: 737 http://www.iana.org/assignments/imap4-capabilities 739 IANA is requested to update definition of the QUOTA extension to 740 point to this document. IANA is also requested to add the "QUOTASET" 741 capability to the IMAP4 capabilities registry, with this document as 742 the reference. 744 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 745 capabilities registry and add a pointer to this document and to the 746 IMAP quota resource type registry (see Section 9.2). 748 IANA is requested to reserve all other capabilities starting with 749 "QUOTA=" prefix for future IETF stream standard track, informational 750 or experimental extensions to this document. 752 9.2. IMAP quota resource type registry 754 IANA is requested to create a new registry for IMAP quota resource 755 types. Registration policy for this registry is "Specification 756 Required". When registering a new quota resource type, the 757 registrant need to provide the following: Name of the quota resource 758 type, Author/Change Controller name and email address, short 759 description, extra (if any) required and optional IMAP commands/ 760 responses, and a reference to a specification that describes the 761 quota resource type in more details. 763 Designated Experts should check that provided references are correct, 764 that they describe the quota resource type being registered in 765 sufficient details to be implementable, that syntax of any optional 766 commands/responses is correct (e.g. ABNF validates), and their 767 syntax/description complies with rules and limitations imposed by 768 IMAP [RFC3501][RFC9051]. Designated Experts should avoid registering 769 multiple identical quota resource types under different names and 770 should provide advice to requestors about other possible quota 771 resource types to use. 773 This document includes initial registrations for the following IMAP 774 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), 775 MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 776 Section 9.3 for the registration templates. 778 9.3. Registrations of IMAP Quota Resource Types 780 Name of the quota resource type: STORAGE 782 Author: Alexey Melnikov 784 Change Controller: IESG 786 Description: The physical space estimate, in units of 1024 octets, 787 of the mailboxes governed by the quota root. 789 Extra required IMAP commands/responses: DELETED-STORAGE STATUS 790 request data item and response data item 792 Extra optional IMAP commands/responses: N/A 794 Reference: Section 5.1 of RFCXXXX 795 Name of the quota resource type: MESSAGE 797 Author: Alexey Melnikov 799 Change Controller: IESG 801 Description: The number of messages stored within the mailboxes 802 governed by the quota root. 804 Extra required IMAP commands/responses: DELETED STATUS request data 805 item and response data item 807 Extra optional IMAP commands/responses: N/A 809 Reference: Section 5.2 of RFCXXXX 811 Name of the quota resource type: MAILBOX 813 Author: Alexey Melnikov 815 Change Controller: IESG 817 Description: The number of mailboxes governed by the quota root. 819 Extra required IMAP commands/responses: N/A 821 Extra optional IMAP commands/responses: N/A 823 Reference: Section 5.3 of RFCXXXX 825 Name of the quota resource type: ANNOTATION-STORAGE 827 Author: Alexey Melnikov 829 Change Controller: IESG 831 Description: The maximum size of all annotations [RFC5257], in units 832 of 1024 octets, associated with all messages in the mailboxes 833 governed by the quota root. 835 Extra required IMAP commands/responses: N/A 837 Extra optional IMAP commands/responses: N/A 839 Reference: Section 5.4 of RFCXXXX 841 10. Contributors 843 Dave Cridland wrote lots of text in an earlier draft that became the 844 basis for this document. 846 11. Acknowledgments 848 Editor of this document would like to thank the following people who 849 provided useful comments or participated in discussions that lead to 850 this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg. 852 This document is a revision of RFC 2087. It borrows a lot of text 853 from RFC 2087. Thus work of the RFC 2087 author John Myers is 854 appreciated. 856 12. Changes since RFC 2087 858 This document is a revision of RFC 2087. It tries to clarify the 859 meaning of different terms used by RFC 2087. It also provides more 860 examples, gives guidance on allowed server behaviour, defines IANA 861 registry for quota resource types and provides initial registrations 862 for 4 of them. 864 When compared with RFC 2087, this document defines two more commonly 865 used resource type, adds optional OVERQUOTA response code and defines 866 two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that 867 must be implemented. For extensibility quota usage and quota limits 868 are now 63 bit unsigned integers. 870 13. References 872 13.1. Normative References 874 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 875 Syntax Specifications: ABNF", RFC 5234, January 2008, 876 . 878 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 879 Requirement Levels", BCP 14, RFC 2119, 880 DOI 10.17487/RFC2119, March 1997, 881 . 883 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 884 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 885 . 887 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 888 RFC 4314, DOI 10.17487/RFC4314, December 2005, 889 . 891 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 892 Protocol - ANNOTATE Extension", RFC 5257, 893 DOI 10.17487/RFC5257, June 2008, 894 . 896 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 897 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 898 May 2017, . 900 [RFC9051] Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message 901 Access Protocol (IMAP) - Version 4rev2", RFC 9051, 902 DOI 10.17487/RFC9051, August 2021, 903 . 905 13.2. Informative References 907 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 908 DOI 10.17487/RFC2087, January 1997, 909 . 911 Author's Address 913 Alexey Melnikov 914 Isode Limited 916 Email: alexey.melnikov@isode.com 917 URI: https://www.isode.com