idnits 2.17.1 draft-ietf-extra-quota-03.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 RFC2087, 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 lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == 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 (November 17, 2020) is 1255 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) == Missing Reference: 'OVERQUOTA A003' is mentioned on line 474, but not defined ** 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 (~~), 5 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 Intended status: Standards Track November 17, 2020 5 Expires: May 21, 2021 7 IMAP QUOTA Extension 8 draft-ietf-extra-quota-03 10 Abstract 12 The QUOTA extension of the Internet Message Access Protocol (RFC 13 3501) permits administrative limits on resource usage (quotas) to be 14 manipulated through the IMAP protocol. 16 This memo obsoletes RFC 2087, but attempts to remain backwards 17 compatible whenever possible. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on May 21, 2021. 36 Copyright Notice 38 Copyright (c) 2020 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 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 . . . . . . . . . . . . . . . . 8 78 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 79 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 80 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 81 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 82 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 83 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 11 84 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 12 88 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 12 89 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 92 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 15 93 10. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 94 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17 95 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 96 13. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 17 97 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 14.1. Normative References . . . . . . . . . . . . . . . . . . 18 99 14.2. Informative References . . . . . . . . . . . . . . . . . 18 100 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 102 1. Document Conventions 104 In protocol examples, this document uses a prefix of "C: " to denote 105 lines sent by the client to the server, and "S: " for lines sent by 106 the server to the client. Lines prefixed with "// " are comments 107 explaining the previous protocol line. These prefixes and comments 108 are not part of the protocol. Lines without any of these prefixes 109 are continuations of the previous line, and no line break is present 110 in the protocol unless specifically mentioned. 112 Again, for examples, the hierarchy separator on the server is 113 presumed to be "/" throughout. None of these assumptions is required 114 nor recommended by this document. 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 118 "OPTIONAL" in this document are to be interpreted as described in BCP 119 14 RFC2119 [RFC2119] 8174 [RFC8174] when, and only when, they appear 120 in all capitals, as shown here. 122 Other capitalised words are IMAP4 [RFC3501] keywords or keywords from 123 this document. 125 2. Introduction and Overview 127 This document defines a couple of extension to the Internet Message 128 Access Protocol [RFC3501] for querying and manipulating 129 administrative limits on resource usage (quotas). 131 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 132 Some responses and response codes defined in this document are not 133 present in such servers (see Section 13 for more details), and 134 clients MUST NOT rely on their presence in the absence of any 135 capability beginning with "QUOTA=". 137 Any server compliant with this document MUST also return at least one 138 capability starting with "QUOTA=RES-" prefix, as described in 139 Section 3.1. 141 Any server compliant with this document that implements the SETQUOTA 142 command (see Section 4.1.3) MUST also return the "QUOTASET" 143 capability. 145 This document also reserves all other capabilities starting with 146 "QUOTA=" prefix for future IETF stream standard track or experimental 147 extensions to this document. 149 Quotas can be used to restrict clients for administrative reasons, 150 but the QUOTA extension can also be used to indicate system limits 151 and current usage levels to clients. 153 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 154 this has seen deployment in servers, it has seen little deployment in 155 clients. Since the meaning of the resources was left implementation- 156 dependant, it was impossible for a client implementation to determine 157 which resources were supported, and impossible to determine which 158 mailboxes were in a given quota root, without a priori knowledge of 159 the implementation. 161 3. Terms 163 3.1. Resource 165 A resource has a name, a formal definition. 167 3.1.1. Name 169 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. 170 These MUST be registered with IANA. Implementation specific 171 resources begin with "V-" . 173 Supported resource names MUST be advertised as a capability, by 174 prepending the resource name with "QUOTA=RES-". A server compliant 175 with this specification is not required to support all reported 176 resource types on all quota roots. 178 3.1.2. Definition 180 The resource definition or document containing it, while not visible 181 through the protocol, SHOULD be registered with IANA. 183 The usage of a resource MUST be represented as a 32 bit unsigned 184 integer. 0 indicates that the resource is exhausted. Usage integers 185 don't necessarily represent proportional use, so clients MUST NOT 186 compare available resource between two separate quota roots on the 187 same or different servers. 189 Limits will be specified as, and MUST be represented as, an integer. 190 0 indicates that any usage is prohibited. 192 Limits may be hard or soft - that is, an implementation MAY choose, 193 or be configured, to disallow any command if the limit on a resource 194 is or would be exceeded. 196 All resources which the server handles must be advertised in a 197 CAPABILITY constisting of the resource name 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 Each mailbox has zero or more implementation-defined named "quota 206 roots". Each quota root has zero or more resource limits (quotas). 207 All mailboxes that share the same named quota root share the resource 208 limits of the quota root. 210 Quota root names need not be mailbox names, nor is there any 211 relationship defined by this memo between a Quota root name and a 212 mailbox name. A quota root name is an astring, as defined in IMAP4 213 [RFC3501]. It SHOULD be treated as an opaque string by any clients. 215 Quota roots are used since not all implementations may be able to 216 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 217 hierarchies. 219 Not all resources may be limitable or calculatable for all quota 220 roots. Further, not all resources may support all limits - some 221 limits may be present in the underlying system. A server 222 implementation of this memo SHOULD advise the client of such inherent 223 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 224 advise the client of which resources are limitable for a particular 225 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 226 quota limit in an implementation dependant way, if the granularity of 227 the underlying system demands it. A client MUST be prepared for a 228 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 230 Implementation Notes: 231 This means that, for example under UNIX, a quota root may have a 232 MESSAGE (Section 5.2) quota always set due to the number of inodes 233 available on the filesystem, and similarly STORAGE (Section 5.1) may 234 be rounded to the nearest block and limited by free filesystem space. 236 4. Definitions 238 4.1. Commands 240 The following commands exist for manipulation and querying quotas. 242 4.1.1. GETQUOTA 244 Arguments: quota root 246 Responses: REQUIRED untagged responses: QUOTA 248 Result: OK - getquota completed 249 NO - getquota error: no such quota root, permission denied 250 BAD - command unknown or arguments invalid 252 The GETQUOTA command takes the name of a quota root and returns the 253 quota root's resource usage and limits in an untagged QUOTA response. 254 The client can try using any of the resource types returned in 255 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 256 prefix), however the server is not required to support any specific 257 resource type for any particular quota root. 259 Example: 261 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 262 [...] 263 C: G0001 GETQUOTA "!partition/sda4" 264 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 265 S: G0001 OK Getquota complete 267 4.1.2. GETQUOTAROOT 269 Arguments: mailbox name 271 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 273 Result: OK - getquotaroot completed 274 NO - getquotaroot error: permission denied 275 BAD - command unknown or arguments invalid 277 The GETQUOTAROOT command takes a mailbox name and returns the list of 278 quota roots for the mailbox in an untagged QUOTAROOT response. For 279 each listed quota root, it also returns the quota root's resource 280 usage and limits in an untagged QUOTA response. 282 Note that the mailbox name parameter doesn't have to reference an 283 existing mailbox. This can be handy in order to determine which 284 quotaroot would apply to a mailbox when it gets created. 286 Example: 288 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 289 [...] 290 [...] 291 C: G0002 GETQUOTAROOT INBOX 292 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 293 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 294 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 295 S: G0002 OK Getquotaroot complete 297 4.1.3. SETQUOTA 299 Arguments: quota root 301 list of resource limits 303 Responses: untagged responses: QUOTA 305 Result: OK - setquota completed 306 NO - setquota error: can't set that data 307 BAD - command unknown or arguments invalid 309 Note that unlike other command/responses/response codes defined in 310 this document, support for SETQUOTA command requires the server to 311 advertise "QUOTASET" capability. 313 The SETQUOTA command takes the name of a mailbox quota root and a 314 list of resource limits. The resource limits for the named quota 315 root are changed to be the specified limits. Any previous resource 316 limits for the named quota root are discarded. 318 If the named quota root did not previously exist, an implementation 319 may optionally create it and change the quota roots for any number of 320 existing mailboxes in an implementation-defined manner. 322 If the implementation chooses to change the quota roots for some 323 existing mailboxes such changes SHOULD be announced with untagged 324 QUOTA responses. 326 Example: 328 S: * CAPABILITY [...] QUOTA QUOTASET QUOTA=RES-STORAGE QUOTA=RES- 329 MESSAGE [...] 331 [...] 332 C: S0000 GETQUOTA "#user/alice" 333 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 334 S: S0000 OK Getquota completed 335 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 336 S: * QUOTA "#user/alice" (STORAGE 58 512) 338 // The server has rounded the STORAGE quota limit requested to the 339 nearest 512 blocks of 1024 octects, or else another client has 340 performed a near simultaneous SETQUOTA, using a limit of 512. 342 S: S0001 OK Rounded quota 343 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 344 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 346 // The server has not changed the quota, since this is a 347 filesystem limit, and cannot be changed. The QUOTA response here 348 is entirely optional. 350 S: S0002 NO Cannot change system limit 352 4.1.4. New STATUS attributes 354 DELETED and DELETED-STORAGE status data items allow to estimate the 355 amount of resource freed by an EXPUNGE on a mailbox. 357 DELETED status data item requests the server to return the number of 358 messages with \Deleted flag set. DELETED status data item is only 359 required to be implemented when the server advertises QUOTA=RES- 360 MESSAGE capability. 362 DELETED-STORAGE status data item requests the server to return the 363 amount of storage space that can be reclaimed by performing EXPUNGE 364 on the mailbox. The server SHOULD return the exact value, however it 365 is recognized that the server may have to do non-trivial amount of 366 work to calculate it. If the calculation of the exact value would 367 take a long time, the server MAY instead return the sum of 368 RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE 369 status data item is only required to be implemented when the server 370 advertises QUOTA=RES-STORAGE capability. 372 Example: 374 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE 375 [...] 376 [...] 377 C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) 378 S: * STATUS INBOX (MESSAGES 12 DELETED 4 DELETED-STORAGE 8) 379 // 12 messages, 4 of which would be deleted when an EXPUNGE 380 happens. 382 S: S0003 OK Status complete. 384 4.2. Responses 386 The following responses may be sent by the server. 388 4.2.1. QUOTA 390 Data: quota root name 391 list of resource names, usages, and limits 393 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 394 command. The first string is the name of the quota root for which 395 this quota applies. 397 The name is followed by a S-expression format list of the resource 398 usage and limits of the quota root. The list contains zero or more 399 triplets. Each triplet contains a resource name, the current usage 400 of the resource, and the resource limit. 402 Resources not named in the list are not limited in the quota root. 403 Thus, an empty list means there are no administrative resource limits 404 in the quota root. 406 Example: S: * QUOTA "" (STORAGE 10 512) 408 4.2.2. QUOTAROOT 410 Data: mailbox name 411 zero or more quota root names 413 This response occurs as a result of a GETQUOTAROOT command. The 414 first string is the mailbox and the remaining strings are the names 415 of the quota roots for the mailbox. 417 Example: 419 S: * QUOTAROOT INBOX "" 421 S: * QUOTAROOT comp.mail.mime 423 4.3. Response Codes 425 4.3.1. OVERQUOTA 427 OVERQUOTA response code SHOULD be returned in the tagged NO response 428 to an APPEND/COPY/MOVE when the addition of the message(s) puts the 429 target mailbox over any one of its quota limits. 431 Example: 433 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 434 S: + Ready for literal data 435 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 436 C: From: Fred Foobar 437 C: Subject: afternoon meeting 438 C: To: mooch@owatagu.siam.edu 439 C: Message-Id: 440 C: MIME-Version: 1.0 441 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 442 C: 443 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 444 C: 445 S: A003 NO [OVERQUOTA] APPEND Failed 447 The OVERQUOTA response code MAY also be returned in an untagged NO 448 response when a mailbox exceeds soft quota. Such responses have 2 449 forms. If it is followed by a tag, the tag refers to the command 450 that caused this (such as APPEND or COPY) and the OVERQUOTA response 451 code applies to the target mailbox specified by such command. If the 452 OVERQUOTA response code is not followed by the tag, this means that 453 an external event (e.g. LMTP delivery or APPEND/COPY in another IMAP 454 connection) caused this event and the event applies to the currently 455 selected mailbox. In particular, this means that such OVERQUOTA 456 response codes MUST NOT be returned if there is no mailbox selected 457 or if a mailbox other than the currently selected one exceeds soft 458 quota. 460 Example: 462 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 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 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: * NO [OVERQUOTA A003] Soft quota has been exceeded 475 S: A003 OK [APPENDUID 38505 3955] APPEND completed 477 5. Resource Type Definitions 479 The following resource types are defined in this memo. A server 480 supporting a resource type MUST advertise this as a CAPABILITY with a 481 name consisting of the resource name prefixed by "QUOTA=RES-". A 482 server MAY support mupltiple resource types, and MUST advertise all 483 resource types it supports. 485 5.1. STORAGE 487 The physical space estimate, in units of 1024 octets, of the 488 mailboxes governed by the quota root. This MAY not be the same as 489 the sum of the RFC822.SIZE of the messages. Some implementations MAY 490 include metadata sizes for the messages and mailboxes, other 491 implementations MAY store messages in such a way that the physical 492 space used is smaller, for example due to use of compression. 493 Additional messages might not increase the usage. Client MUST NOT 494 use the usage figure for anything other than informational purposes, 495 for example, they MUST NOT refuse to APPEND a message if the limit 496 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 497 message, but it MAY warn about such condition. 499 The usage figure may change as a result of performing actions not 500 associated with adding new messages to the mailbox, such as SEARCH, 501 since this may increase the amount of metadata included in the 502 calculations. 504 When the server supports this resource type, it MUST also support 505 DELETED-STORAGE status data item. 507 Support for this resource MUST be indicated by the server by 508 advertising the CAPABILITY "QUOTA=RES-STORAGE". 510 A resource named the same was also given as an example in RFC2087 511 [RFC2087]. This document provides a more precise definition. 513 5.2. MESSAGE 515 The number of messages stored within the mailboxes governed by the 516 quota root. This MUST be an exact number, however, clients MUST NOT 517 assume that a change in the usage indicates a change in the number of 518 messages available, since the quota root may include mailboxes the 519 client has no access to. 521 When the server supports this resource type, it MUST also support 522 DELETED status data item. 524 Support for this resource MUST be indicated by the server by 525 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 527 A resource named the same was also given as an example in RFC2087 528 [RFC2087]. This document provides a more precise definition. 530 5.3. MAILBOX 532 The number of mailboxes governed by the quota root. This MUST be an 533 exact number, however, clients MUST NOT assume that a change in the 534 usage indicates a change in the number of mailboxes, since the quota 535 root may include mailboxes the client has no access to. 537 Support for this resource MUST be indicated by the server by 538 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 540 5.4. ANNOTATION-STORAGE 542 [[CREF1: Bron to check whether this is a sensible description and 543 whether it is needed at all:]] The maximum size of all annotations 544 [RFC5257], in units of 1024 octets, associated with all messages in 545 the mailboxes governed by the quota root. 547 Support for this resource MUST be indicated by the server by 548 advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". 550 6. Interaction with IMAP ACL extension (RFC 4314) 552 This section lists [RFC4314] rights required to execute quota related 553 commands when both RFC 4314 and this document are implemented. 555 +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ 556 | Operations\Ri | l | r | s | w | i | c | x | t | e | a | Any | Non | 557 | ghts | | | | | | | | | | | | | 558 +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ 559 | GETQUOTA | | | | | | | | | | | | + | 560 | GETQUOTAROOT | | * | | | | | | | | | | * | 561 | SETQUOTA | | | | | | | | | | + | | | 562 +---------------+---+---+---+---+---+---+---+---+---+---+-----+-----+ 564 See Section 4 of RFC 4314 for conventions used in this table. 566 [[CREF2: The above table needs to be reviewed based on feedback from 567 existing and planned implementations.]] 569 7. Formal syntax 571 The following syntax specification uses the Augmented Backus-Naur 572 Form (ABNF) notation as specified in [ABNF]. 574 Non-terminals referenced but not defined below are as defined by 575 IMAP4 [RFC3501]. 577 Except as noted otherwise, all alphabetic characters are case- 578 insensitive. The use of upper or lower case characters to define 579 token strings is for editorial clarity only. Implementations MUST 580 accept these strings in a case-insensitive fashion. 582 getquota = "GETQUOTA" SP quota-root-name 584 getquotaroot = "GETQUOTAROOT" SP mailbox 586 quota-list = "(" quota-resource *(SP quota-resource) ")" 588 quota-resource = resource-name SP resource-usage SP resource- 589 limit 591 quota-response = "QUOTA" SP quota-root-name SP quota-list 593 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 595 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 597 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 598 ")" 600 setquota-resource = resource-name SP resource-limit 602 quota-root-name = astring 604 resource-limit = number64 606 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 607 "ANNOTATION-STORAGE" / resource-name-vnd / 608 resource-name-ext 610 resource-name-vnd = "V-" atom 611 ;; Vendor specific, must be registered with IANA. 612 ;; The "V-" prefix should be followed by a domain 613 name 614 ;; under vendor's control. 616 resource-name-ext = atom 617 ;; Not starting with V- and defined 618 ;; in a Standard Track or Experimental RFC 620 resource-names = "(" [resource-name *(SP resource-name)] ")" 622 resource-usage = number64 623 ;; must be less than corresponding resource-limit 625 capability-quota = capa-quota-res / "QUOTASET" 626 ;; One or more capa-quota-res must be returned. 627 ;; Also "QUOTASET" can optionally be returned. 629 capa-quota-res = "QUOTA=RES-" resource-name 631 status-att =/ "DELETED" / "DELETED-STORAGE" 632 ;; DELETED status data item MUST be supported 633 ;; when "QUOTA=RES-MESSAGE" capability is 634 ;; advertised. 635 ;; DELETED-STORAGE status data item MUST be 636 ;; supported when "QUOTA=RES-STORAGE" capability 637 ;; is advertised. 639 status-att-val =/ status-att-deleted / 640 status-att-deleted-storage 642 status-att-deleted =/ "DELETED" SP number 643 ;; DELETED status data item MUST be supported 644 ;; when "QUOTA=RES-MESSAGE" capability is 645 ;; advertised. 647 status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 648 ;; DELETED-STORAGE status data item MUST be 649 ;; supported when "QUOTA=RES-STORAGE" capability 650 ;; is advertised. 652 resp-text-code =/ "OVERQUOTA" [SP tag] 654 number64 = 1*DIGIT 655 ;; Unsigned 63-bit integer. 656 ;; (0 <= n <= 9,223,372,036,854,775,807) 658 8. Security Considerations 660 Implementors should be careful to make sure the implementation of 661 these commands does not violate the site's security policy. The 662 resource usage of other users is likely to be considered confidential 663 information and should not be divulged to unauthorized persons. 665 9. IANA Considerations 667 IMAP4 capabilities are registered by publishing a standards track or 668 IESG approved experimental RFC. The registry is currently located 669 at: 671 http://www.iana.org/assignments/imap4-capabilities 673 IANA is requested to update definition of the QUOTA extension to 674 point to this document. 676 IANA is also requested to create a new registry for IMAP quota 677 resource types. Registration policy for this registry is 678 "Specification Required". When registering a new quota resource 679 type, the registrant need to provide the following: Name of the quota 680 resource type, Author/Change Controller name and email address, short 681 description, extra (if any) required and optional IMAP commands/ 682 responses, and a reference to a specification that describes the 683 quota resource type in more details. 685 This document includes initial registrations for the following IMAP 686 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), 687 MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 688 details below. 690 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 691 capabilities registry and add a pointer to this document and to the 692 IMAP quota resource type registry established above. 694 IANA is requested to reserve all other capabilities starting with 695 "QUOTA=" prefix for future IETF stream standard track or experimental 696 extensions to this document. 698 9.1. Registrations of IMAP Quota Resource Types 700 Name of the quota resource type: STORAGE 702 Author: Alexey Melnikov 704 Change Controller: IESG 705 Description: The physical space estimate, in units of 1024 octets, 706 of the mailboxes governed by the quota root. 708 Extra required IMAP commands/responses: DELETED-STORAGE STATUS 709 request data item and response data item 711 Extra optional IMAP commands/responses: N/A 713 Reference: Section 5.1 of RFCXXXX 715 Name of the quota resource type: MESSAGE 717 Author: Alexey Melnikov 719 Change Controller: IESG 721 Description: The number of messages stored within the mailboxes 722 governed by the quota root. 724 Extra required IMAP commands/responses: DELETED STATUS request data 725 item and response data item 727 Extra optional IMAP commands/responses: N/A 729 Reference: Section 5.2 of RFCXXXX 731 Name of the quota resource type: MAILBOX 733 Author: Alexey Melnikov 735 Change Controller: IESG 737 Description: The number of mailboxes governed by the quota root. 739 Extra required IMAP commands/responses: N/A 741 Extra optional IMAP commands/responses: N/A 743 Reference: Section 5.3 of RFCXXXX 745 Name of the quota resource type: 747 Author: Alexey Melnikov 749 Change Controller: IESG 751 Description: The maximum size of all annotations [RFC5257], in units 752 of 1024 octets, associated with all messages in the mailboxes 753 governed by the quota root. [[CREF3: Recheck against the final 754 description of "ANNOTATION-STORAGE".]] 756 Extra required IMAP commands/responses: N/A 758 Extra optional IMAP commands/responses: N/A 760 Reference: Section 5.4 of RFCXXXX 762 10. Open Issues 764 '"OVERQUOTA" SP tag' form has syntactic issues, as "tag" allows for 765 "]", which is not allowed in response codes. Should we drop this 766 variant or change IMAP4rev2 to disallow "]" in tags? 768 11. Contributors 770 Dave Cridland wrote lots of text in an earlier draft that became the 771 basis for this document. 773 12. Acknowledgments 775 Editors of this document would like to thank the following people who 776 provided useful comments or participated in discussions that lead to 777 this update to RFC 2087: 778 John Myers, 779 Cyrus Daboo, 780 Lyndon Nerenberg 782 This document is a revision of RFC 2087. It borrows a lot of text 783 from RFC 2087. Thus work of the RFC 2087 author John Myers is 784 appreciated. 786 13. Changes since RFC 2087 788 This document is a revision of RFC 2087. It tries to clarify meaning 789 of different terms used by RFC 2087. It also provides more examples, 790 gives guidance on allowed server behaviour, defines IANA registry for 791 quota resource types and provides initial registrations for 3 of 792 them. 794 When compared with RFC 2087, this document defines two more commonly 795 used resource type, adds optional OVERQUOTA response code and defines 796 two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that 797 must be implemented. For extensibility quota usage and quota limits 798 are now 63 bit unsigned integers. 800 14. References 802 14.1. Normative References 804 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 805 Syntax Specifications: ABNF", RFC 5234, January 2008. 807 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 808 Requirement Levels", BCP 14, RFC 2119, 809 DOI 10.17487/RFC2119, March 1997, 810 . 812 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 813 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 814 . 816 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 817 RFC 4314, DOI 10.17487/RFC4314, December 2005, 818 . 820 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 821 Protocol - ANNOTATE Extension", RFC 5257, 822 DOI 10.17487/RFC5257, June 2008, 823 . 825 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 826 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 827 May 2017, . 829 14.2. Informative References 831 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 832 DOI 10.17487/RFC2087, January 1997, 833 . 835 Author's Address 837 Alexey Melnikov 838 Isode Limited 840 Email: alexey.melnikov@isode.com 841 URI: https://www.isode.com