idnits 2.17.1 draft-ietf-extra-quota-05.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. 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 (19 August 2021) is 980 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 (==), 2 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) 19 August 2021 5 Intended status: Standards Track 6 Expires: 20 February 2022 8 IMAP QUOTA Extension 9 draft-ietf-extra-quota-05 11 Abstract 13 The QUOTA extension of the Internet Message Access Protocol (RFC 14 3501) permits administrative limits on resource usage (quotas) to be 15 manipulated through the IMAP protocol. 17 This memo 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 20 February 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 17 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 95 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 98 13.2. Informative References . . . . . . . . . . . . . . . . . 19 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 101 1. Document Conventions 103 In protocol examples, this document uses a prefix of "C: " to denote 104 lines sent by the client to the server, and "S: " for lines sent by 105 the server to the client. Lines prefixed with "// " are comments 106 explaining the previous protocol line. These prefixes and comments 107 are not part of the protocol. Lines without any of these prefixes 108 are continuations of the previous line, and no line break is present 109 in the protocol unless specifically mentioned. 111 Again, for examples, the hierarchy separator on the IMAP server is 112 presumed to be "/" throughout. None of these assumptions is required 113 nor recommended by this document. 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in BCP 118 14 [RFC2119] [RFC8174] when, and only when, they appear in all 119 capitals, as shown here. 121 Other capitalised words are IMAP4 [RFC3501] keywords or keywords from 122 this document. 124 2. Introduction and Overview 126 This document defines a couple of extension to the Internet Message 127 Access Protocol [RFC3501] for querying and manipulating 128 administrative limits on resource usage (quotas). This extension is 129 compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 (draft-ietf- 130 extra-imap4rev2). 132 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 133 Some responses and response codes defined in this document are not 134 present in such servers (see Section 12 for more details), and 135 clients MUST NOT rely on their presence in the absence of any 136 capability beginning with "QUOTA=". 138 Any server compliant with this document MUST also return at least one 139 capability starting with "QUOTA=RES-" prefix, as described in 140 Section 3.1. 142 Any server compliant with this document that implements the SETQUOTA 143 command (see Section 4.1.3) MUST also return the "QUOTASET" 144 capability. 146 This document also reserves all other capabilities starting with 147 "QUOTA=" prefix for future IETF stream standard track, informational 148 or experimental extensions to this document. 150 Quotas can be used to restrict clients for administrative reasons, 151 but the QUOTA extension can also be used to indicate system limits 152 and current usage levels to clients. 154 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 155 this has seen deployment in servers, it has seen little deployment in 156 clients. Since the meaning of the resources was left implementation- 157 dependant, it was impossible for a client implementation to determine 158 which resources were supported, and impossible to determine which 159 mailboxes were in a given quota root, without a priori knowledge of 160 the implementation. 162 3. Terms 164 3.1. Resource 166 A resource has a name, a formal definition. 168 3.1.1. Name 170 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. 171 These MUST be registered with IANA. Implementation specific 172 resources begin with "V-" . 174 Supported resource names MUST be advertised as a capability, by 175 prepending the resource name with "QUOTA=RES-". A server compliant 176 with this specification is not required to support all reported 177 resource types on all quota roots. 179 3.1.2. Definition 181 The resource definition or document containing it, while not visible 182 through the protocol, SHOULD be registered with IANA. 184 The usage of a resource MUST be represented as a 32 bit unsigned 185 integer. 0 indicates that the resource is exhausted. Usage integers 186 don't necessarily represent proportional use, so clients MUST NOT 187 compare available resource between two separate quota roots on the 188 same or different servers. 190 Limits will be specified as, and MUST be represented as, an integer. 191 0 indicates that any usage is prohibited. 193 Limits may be hard or soft - that is, an implementation MAY choose, 194 or be configured, to disallow any command if the limit on a resource 195 is or would be exceeded. 197 All resources which the server handles must be advertised in a 198 CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". 200 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX 201 (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in 202 this document. 204 3.2. Quota Root 206 Each mailbox has zero or more implementation-defined named "quota 207 roots". Each quota root has zero or more resource limits (quotas). 208 All mailboxes that share the same named quota root share the resource 209 limits of the quota root. 211 Quota root names need not be mailbox names, nor is there any 212 relationship defined by this memo between a Quota root name and a 213 mailbox name. A quota root name is an astring, as defined in IMAP4 214 [RFC3501]. It SHOULD be treated as an opaque string by any clients. 216 Quota roots are used since not all implementations may be able to 217 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 218 hierarchies. 220 Not all resources may be limitable or calculatable for all quota 221 roots. Further, not all resources may support all limits - some 222 limits may be present in the underlying system. A server 223 implementation of this memo SHOULD advise the client of such inherent 224 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 225 advise the client of which resources are limitable for a particular 226 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 227 quota limit in an implementation dependant way, if the granularity of 228 the underlying system demands it. A client MUST be prepared for a 229 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 231 Implementation Notes: This means that, for example under UNIX, a 232 quota root may have a MESSAGE (Section 5.2) quota always set due to 233 the number of inodes available on the filesystem, and similarly 234 STORAGE (Section 5.1) may be rounded to the nearest block and limited 235 by free filesystem space. 237 4. Definitions 239 4.1. Commands 241 The following commands exist for manipulation and querying quotas. 243 4.1.1. GETQUOTA 245 Arguments: quota root 247 Responses: REQUIRED untagged responses: QUOTA 249 Result: OK - getquota completed 251 NO - getquota error: no such quota root, permission denied 253 BAD - command unknown or arguments invalid 255 The GETQUOTA command takes the name of a quota root and returns the 256 quota root's resource usage and limits in an untagged QUOTA response. 257 The client can try using any of the resource types returned in 258 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 259 prefix), however the server is not required to support any specific 260 resource type for any particular quota root. 262 Example: 264 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 266 [...] 268 C: G0001 GETQUOTA "!partition/sda4" 270 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 272 S: G0001 OK Getquota complete 274 4.1.2. GETQUOTAROOT 276 Arguments: mailbox name 277 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 279 Result: OK - getquotaroot completed 281 NO - getquotaroot error: permission denied 283 BAD - command unknown or arguments invalid 285 The GETQUOTAROOT command takes a mailbox name and returns the list of 286 quota roots for the mailbox in an untagged QUOTAROOT response. For 287 each listed quota root, it also returns the quota root's resource 288 usage and limits in an untagged QUOTA response. 290 Note that the mailbox name parameter doesn't have to reference an 291 existing mailbox. This can be handy in order to determine which 292 quotaroot would apply to a mailbox when it gets created. 294 Example: 296 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 297 [...] 299 [...] 301 C: G0002 GETQUOTAROOT INBOX 303 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 305 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 307 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 309 S: G0002 OK Getquotaroot complete 311 4.1.3. SETQUOTA 313 Arguments: quota root 315 list of resource limits 317 Responses: untagged responses: QUOTA 319 Result: OK - setquota completed 321 NO - setquota error: can't set that data 323 BAD - command unknown or arguments invalid 325 Note that unlike other command/responses/response codes defined in 326 this document, support for SETQUOTA command requires the server to 327 advertise "QUOTASET" capability. 329 The SETQUOTA command takes the name of a mailbox quota root and a 330 list of resource limits. The resource limits for the named quota 331 root are changed to be the specified limits. Any previous resource 332 limits for the named quota root are discarded. 334 If the named quota root did not previously exist, an implementation 335 may optionally create it and change the quota roots for any number of 336 existing mailboxes in an implementation-defined manner. 338 If the implementation chooses to change the quota roots for some 339 existing mailboxes such changes SHOULD be announced with untagged 340 QUOTA responses. 342 Example: 344 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- 345 MESSAGE [...] 347 [...] 349 C: S0000 GETQUOTA "#user/alice" 351 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 353 S: S0000 OK Getquota completed 355 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 357 S: * QUOTA "#user/alice" (STORAGE 58 512) 359 // The server has rounded the STORAGE quota limit requested to the 360 nearest 512 blocks of 1024 octects, or else another client has 361 performed a near simultaneous SETQUOTA, using a limit of 512. 363 S: S0001 OK Rounded quota 365 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 367 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 369 // The server has not changed the quota, since this is a 370 filesystem limit, and cannot be changed. The QUOTA response here 371 is entirely optional. 373 S: S0002 NO Cannot change system limit 375 4.1.4. New STATUS attributes 377 DELETED and DELETED-STORAGE status data items allow to estimate the 378 amount of resource freed by an EXPUNGE on a mailbox. 380 DELETED status data item requests the server to return the number of 381 messages with \Deleted flag set. DELETED status data item is only 382 required to be implemented when the server advertises QUOTA=RES- 383 MESSAGE capability. 385 DELETED-STORAGE status data item requests the server to return the 386 amount of storage space that can be reclaimed by performing EXPUNGE 387 on the mailbox. The server SHOULD return the exact value, however it 388 is recognized that the server may have to do non-trivial amount of 389 work to calculate it. If the calculation of the exact value would 390 take a long time, the server MAY instead return the sum of 391 RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE 392 status data item is only required to be implemented when the server 393 advertises QUOTA=RES-STORAGE capability. 395 Example: 397 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 398 [...] 400 [...] 402 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) 404 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) 406 // 12 messages, 4 of which would be deleted when an EXPUNGE 407 happens. 409 S: S0003 OK Status complete. 411 4.2. Responses 413 The following responses may be sent by the server. 415 4.2.1. QUOTA 417 Data: quota root name 419 list of resource names, usages, and limits 421 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 422 command. The first string is the name of the quota root for which 423 this quota applies. 425 The name is followed by a S-expression format list of the resource 426 usage and limits of the quota root. The list contains zero or more 427 triplets. Each triplet contains a resource name, the current usage 428 of the resource, and the resource limit. 430 Resources not named in the list are not limited in the quota root. 431 Thus, an empty list means there are no administrative resource limits 432 in the quota root. 434 Example: S: * QUOTA "" (STORAGE 10 512) 436 4.2.2. QUOTAROOT 438 Data: mailbox name 440 zero or more quota root names 442 This response occurs as a result of a GETQUOTAROOT command. The 443 first string is the mailbox and the remaining strings are the names 444 of the quota roots for the mailbox. 446 Example: 448 S: * QUOTAROOT INBOX "" 450 S: * QUOTAROOT comp.mail.mime 452 4.3. Response Codes 454 4.3.1. OVERQUOTA 456 OVERQUOTA response code SHOULD be returned in the tagged NO response 457 to an APPEND/COPY/MOVE when the addition of the message(s) puts the 458 target mailbox over any one of its quota limits. 460 Example 1: C: A003 APPEND saved-messages (\Seen) {326} 461 S: + Ready for literal data 462 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 463 C: From: Fred Foobar 464 C: Subject: afternoon meeting 465 C: To: mooch@owatagu.siam.edu.example 466 C: Message-Id: 467 C: MIME-Version: 1.0 468 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 469 C: 470 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 471 C: 472 S: A003 NO [OVERQUOTA] APPEND Failed 474 The OVERQUOTA response code MAY also be returned in an untagged NO 475 response in the authenticated or the selected state, when a mailbox 476 exceeds soft quota. For example, such OVERQUOTA response code might 477 be sent as a result of an external event (e.g. LMTP delivery or 478 COPY/MOVE/APPEND in another IMAP connection) that causes the 479 currently selected mailbox to exceed soft quota. Note that such 480 OVERQUOTA response code might be ambiguous, because it might relate 481 to the target mailbox (as specified in COPY/MOVE/APPEND) or to the 482 currently selected mailbox. (The WG chose not to address this 483 deficiency due to syntactic limitations of IMAP response codes and 484 because such events are likely to be rare.) This form of the 485 OVERQUOTA response codes MUST NOT be returned if there is no mailbox 486 selected and no command in progress that adds a message to a mailbox 487 (e.g. APPEND). 489 Example 2: C: A003 APPEND saved-messages (\Seen) {326} 490 S: + Ready for literal data 491 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 492 C: From: Fred Foobar 493 C: Subject: afternoon meeting 494 C: To: mooch@owatagu.siam.edu.example 495 C: Message-Id: 496 C: MIME-Version: 1.0 497 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 498 C: 499 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 500 C: 501 S: * NO [OVERQUOTA] Soft quota has been exceeded 502 S: A003 OK [APPENDUID 38505 3955] APPEND completed 504 Example 3: C: A003 COPY 2:4 MEETING 505 S: * NO [OVERQUOTA] Soft quota has been exceeded 506 S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY 507 command completed 509 5. Resource Type Definitions 511 The following resource types are defined in this memo. A server 512 supporting a resource type MUST advertise this as a CAPABILITY with a 513 name consisting of the resource name prefixed by "QUOTA=RES-". A 514 server MAY support mupltiple resource types, and MUST advertise all 515 resource types it supports. 517 5.1. STORAGE 519 The physical space estimate, in units of 1024 octets, of the 520 mailboxes governed by the quota root. This MAY not be the same as 521 the sum of the RFC822.SIZE of the messages. Some implementations MAY 522 include metadata sizes for the messages and mailboxes, other 523 implementations MAY store messages in such a way that the physical 524 space used is smaller, for example due to use of compression. 525 Additional messages might not increase the usage. Client MUST NOT 526 use the usage figure for anything other than informational purposes, 527 for example, they MUST NOT refuse to APPEND a message if the limit 528 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 529 message, but it MAY warn about such condition. 531 The usage figure may change as a result of performing actions not 532 associated with adding new messages to the mailbox, such as SEARCH, 533 since this may increase the amount of metadata included in the 534 calculations. 536 When the server supports this resource type, it MUST also support 537 DELETED-STORAGE status data item. 539 Support for this resource MUST be indicated by the server by 540 advertising the CAPABILITY "QUOTA=RES-STORAGE". 542 A resource named the same was also given as an example in RFC2087 543 [RFC2087]. This document provides a more precise definition. 545 5.2. MESSAGE 547 The number of messages stored within the mailboxes governed by the 548 quota root. This MUST be an exact number, however, clients MUST NOT 549 assume that a change in the usage indicates a change in the number of 550 messages available, since the quota root may include mailboxes the 551 client has no access to. 553 When the server supports this resource type, it MUST also support 554 DELETED status data item. 556 Support for this resource MUST be indicated by the server by 557 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 559 A resource named the same was also given as an example in RFC2087 560 [RFC2087]. This document provides a more precise definition. 562 5.3. MAILBOX 564 The number of mailboxes governed by the quota root. This MUST be an 565 exact number, however, clients MUST NOT assume that a change in the 566 usage indicates a change in the number of mailboxes, since the quota 567 root may include mailboxes the client has no access to. 569 Support for this resource MUST be indicated by the server by 570 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 572 5.4. ANNOTATION-STORAGE 574 The maximum size of all annotations [RFC5257], in units of 1024 575 octets, associated with all messages in the mailboxes governed by the 576 quota root. 578 Support for this resource MUST be indicated by the server by 579 advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". 581 6. Interaction with IMAP ACL extension (RFC 4314) 583 This section lists [RFC4314] rights required to execute quota related 584 commands when both RFC 4314 and this document are implemented. 586 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 587 | Operations\Rights |l|r| s | w | i | c | x | t | e | a | Any | Non | 588 +===================+=+=+===+===+===+===+===+===+===+===+=====+=====+ 589 | GETQUOTA | | | | | | | | | | | | + | 590 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 591 | GETQUOTAROOT | |*| | | | | | | | | | * | 592 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 593 | SETQUOTA | | | | | | | | | | + | | | 594 +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ 596 Table 1 598 See Section 4 of RFC 4314 for conventions used in this table. 600 7. Formal syntax 602 The following syntax specification uses the Augmented Backus-Naur 603 Form (ABNF) notation as specified in [ABNF]. 605 Non-terminals referenced but not defined below are as defined by 606 IMAP4 [RFC3501]. 608 Except as noted otherwise, all alphabetic characters are case- 609 insensitive. The use of upper or lower case characters to define 610 token strings is for editorial clarity only. Implementations MUST 611 accept these strings in a case-insensitive fashion. 613 getquota = "GETQUOTA" SP quota-root-name 615 getquotaroot = "GETQUOTAROOT" SP mailbox 617 quota-list = "(" quota-resource *(SP quota-resource) ")" 619 quota-resource = resource-name SP resource-usage SP resource-limit 621 quota-response = "QUOTA" SP quota-root-name SP quota-list 623 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 625 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 627 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 628 ")" 630 setquota-resource = resource-name SP resource-limit 632 quota-root-name = astring 634 resource-limit = number64 636 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 638 "ANNOTATION-STORAGE" / resource-name-vnd / 640 resource-name-ext 642 resource-name-vnd = "V-" atom 644 ;; Vendor specific, must be registered with IANA. 646 ;; The "V-" prefix should be followed by a domain 647 name 649 ;; under vendor's control. 651 resource-name-ext = atom 652 ;; Not starting with V- and defined 654 ;; in a Standard Track or Experimental RFC 656 resource-names = "(" [resource-name *(SP resource-name)] ")" 658 resource-usage = number64 660 ;; must be less than corresponding resource-limit 662 capability-quota = capa-quota-res / "QUOTASET" 664 ;; One or more capa-quota-res must be returned. 666 ;; Also "QUOTASET" can optionally be returned. 668 capa-quota-res = "QUOTA=RES-" resource-name 670 status-att =/ "DELETED" / "DELETED-STORAGE" 672 ;; DELETED status data item MUST be supported 674 ;; when "QUOTA=RES-MESSAGE" capability is 676 ;; advertised. 678 ;; DELETED-STORAGE status data item MUST be 680 ;; supported when "QUOTA=RES-STORAGE" capability 682 ;; is advertised. 684 status-att-val =/ status-att-deleted / 686 status-att-deleted-storage 688 status-att-deleted =/ "DELETED" SP number 690 ;; DELETED status data item MUST be supported 692 ;; when "QUOTA=RES-MESSAGE" capability is 694 ;; advertised. 696 status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 698 ;; DELETED-STORAGE status data item MUST be 699 ;; supported when "QUOTA=RES-STORAGE" capability 701 ;; is advertised. 703 resp-text-code =/ "OVERQUOTA" 705 number64 = 1*DIGIT 707 ;; Unsigned 63-bit integer. 709 ;; (0 <= n <= 9,223,372,036,854,775,807) 711 8. Security Considerations 713 Implementors should be careful to make sure the implementation of 714 these commands does not violate the site's security policy. The 715 resource usage of other users is likely to be considered confidential 716 information and should not be divulged to unauthorized persons. In 717 particular, no quota information should be disclosed to anonymous 718 users. 720 9. IANA Considerations 722 IMAP4 capabilities are registered by publishing a standards track or 723 IESG approved experimental RFC. The registry is currently located 724 at: 726 http://www.iana.org/assignments/imap4-capabilities 728 IANA is requested to update definition of the QUOTA extension to 729 point to this document. IANA is also requested to add the "QUOTASET" 730 capability to the IMAP4 capabilities registry, with this document as 731 the reference. 733 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 734 capabilities registry and add a pointer to this document and to the 735 IMAP quota resource type registry established above. 737 IANA is requested to reserve all other capabilities starting with 738 "QUOTA=" prefix for future IETF stream standard track, informational 739 or experimental extensions to this document. 741 IANA is also requested to create a new registry for IMAP quota 742 resource types. Registration policy for this registry is 743 "Specification Required". When registering a new quota resource 744 type, the registrant need to provide the following: Name of the quota 745 resource type, Author/Change Controller name and email address, short 746 description, extra (if any) required and optional IMAP commands/ 747 responses, and a reference to a specification that describes the 748 quota resource type in more details. 750 This document includes initial registrations for the following IMAP 751 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), 752 MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 753 details below. 755 9.1. Registrations of IMAP Quota Resource Types 757 Name of the quota resource type: STORAGE 759 Author: Alexey Melnikov 761 Change Controller: IESG 763 Description: The physical space estimate, in units of 1024 octets, 764 of the mailboxes governed by the quota root. 766 Extra required IMAP commands/responses: DELETED-STORAGE STATUS 767 request data item and response data item 769 Extra optional IMAP commands/responses: N/A 771 Reference: Section 5.1 of RFCXXXX 773 Name of the quota resource type: MESSAGE 775 Author: Alexey Melnikov 777 Change Controller: IESG 779 Description: The number of messages stored within the mailboxes 780 governed by the quota root. 782 Extra required IMAP commands/responses: DELETED STATUS request data 783 item and response data item 785 Extra optional IMAP commands/responses: N/A 787 Reference: Section 5.2 of RFCXXXX 788 Name of the quota resource type: MAILBOX 790 Author: Alexey Melnikov 792 Change Controller: IESG 794 Description: The number of mailboxes governed by the quota root. 796 Extra required IMAP commands/responses: N/A 798 Extra optional IMAP commands/responses: N/A 800 Reference: Section 5.3 of RFCXXXX 802 Name of the quota resource type: 804 Author: Alexey Melnikov 806 Change Controller: IESG 808 Description: The maximum size of all annotations [RFC5257], in units 809 of 1024 octets, associated with all messages in the mailboxes 810 governed by the quota root. 812 Extra required IMAP commands/responses: N/A 814 Extra optional IMAP commands/responses: N/A 816 Reference: Section 5.4 of RFCXXXX 818 10. Contributors 820 Dave Cridland wrote lots of text in an earlier draft that became the 821 basis for this document. 823 11. Acknowledgments 825 Editors of this document would like to thank the following people who 826 provided useful comments or participated in discussions that lead to 827 this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg 829 This document is a revision of RFC 2087. It borrows a lot of text 830 from RFC 2087. Thus work of the RFC 2087 author John Myers is 831 appreciated. 833 12. Changes since RFC 2087 835 This document is a revision of RFC 2087. It tries to clarify meaning 836 of different terms used by RFC 2087. It also provides more examples, 837 gives guidance on allowed server behaviour, defines IANA registry for 838 quota resource types and provides initial registrations for 3 of 839 them. 841 When compared with RFC 2087, this document defines two more commonly 842 used resource type, adds optional OVERQUOTA response code and defines 843 two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that 844 must be implemented. For extensibility quota usage and quota limits 845 are now 63 bit unsigned integers. 847 13. References 849 13.1. Normative References 851 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 852 Syntax Specifications: ABNF", RFC 5234, January 2008, 853 . 855 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 856 Requirement Levels", BCP 14, RFC 2119, 857 DOI 10.17487/RFC2119, March 1997, 858 . 860 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 861 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 862 . 864 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 865 RFC 4314, DOI 10.17487/RFC4314, December 2005, 866 . 868 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 869 Protocol - ANNOTATE Extension", RFC 5257, 870 DOI 10.17487/RFC5257, June 2008, 871 . 873 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 874 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 875 May 2017, . 877 13.2. Informative References 879 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 880 DOI 10.17487/RFC2087, January 1997, 881 . 883 Author's Address 885 Alexey Melnikov 886 Isode Limited 888 Email: alexey.melnikov@isode.com 889 URI: https://www.isode.com