idnits 2.17.1 draft-ietf-extra-quota-01.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 (June 15, 2020) is 1373 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 461, but not defined == Unused Reference: 'RFC4314' is defined on line 742, but no explicit reference was found in the text ** 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 (~~), 6 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 June 15, 2020 5 Expires: December 17, 2020 7 IMAP QUOTA Extension 8 draft-ietf-extra-quota-01 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 December 17, 2020. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . 8 79 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 81 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 9 82 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9 83 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 92 9.1. Registrations of IMAP Quota Resource Types . . . . . . . 14 93 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 94 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 95 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 16 96 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 97 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 98 13.2. Informative References . . . . . . . . . . . . . . . . . 17 99 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 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 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 [RFC2119] 8174 [RFC8174] when, and only when, they appear 119 in all capitals, as shown here. 121 Other capitalised words are IMAP4 [RFC3501] keywords or keywords from 122 this document. 124 2. Introduction and Overview 126 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 127 Some commands and responses defined in this document are not present 128 in such servers, and clients MUST NOT rely on their presence in the 129 absence of any capability beginning with "QUOTA=". 131 Any server compliant with this document MUST also return at least one 132 capability starting with "QUOTA=RES-" prefix, as described in 133 Section 3.1. 135 This document also reserves all other capabilities starting with 136 "QUOTA=" prefix to future standard track or experimental extensions 137 to this document. 139 Quotas can be used to restrict clients for administrative reasons, 140 but the QUOTA extension can also be used to indicate system limits 141 and current usage levels to clients. 143 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 144 this has seen deployment in servers, it has seen little deployment in 145 clients. Since the meaning of the resources was left implementation- 146 dependant, it was impossible for a client implementation to determine 147 which resources were supported, and impossible to determine which 148 mailboxes were in a given quota root, without a priori knowledge of 149 the implementation. 151 3. Terms 153 3.1. Resource 155 A resource has a name, a formal definition. 157 3.1.1. Name 159 The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. 160 These MUST be registered with IANA. Implementation specific 161 resources begin with "V-" . 163 Supported resource names MUST be advertised as a capability, by 164 prepending the resource name with "QUOTA=RES-". A server compliant 165 with this specification is not required to support all reported 166 resource types on all quota roots. 168 3.1.2. Definition 170 The resource definition or document containing it, while not visible 171 through the protocol, SHOULD be registered with IANA. 173 The usage of a resource MUST be represented as a 32 bit unsigned 174 integer. 0 indicates that the resource is exhausted. Usage integers 175 don't necessarily represent proportional use, so clients MUST NOT 176 compare available resource between two separate quota roots on the 177 same or different servers. 179 Limits will be specified as, and MUST be represented as, an integer. 180 0 indicates that any usage is prohibited. 182 Limits may be hard or soft - that is, an implementation MAY choose, 183 or be configured, to disallow any command if the limit on a resource 184 is or would be exceeded. 186 All resources which the server handles must be advertised in a 187 CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". 188 For compatability with RFC2087 [RFC2087], a client which discovers 189 resources available on the server which are not advertised through 190 this mechanism MUST treat them as if they were completely opaque, and 191 without any meaning. 193 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2) and 194 MAILBOX (Section 5.3) are defined in this document. 196 3.2. Quota Root 198 Each mailbox has zero or more implementation-defined named "quota 199 roots". Each quota root has zero or more resource limits (quotas). 200 All mailboxes that share the same named quota root share the resource 201 limits of the quota root. 203 Quota root names need not be mailbox names, nor is there any 204 relationship defined by this memo between a Quota root name and a 205 mailbox name. A quota root name is an astring, as defined in IMAP4 206 [RFC3501]. It SHOULD be treated as an opaque string by any clients. 208 Quota roots are used since not all implementations may be able to 209 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 210 hierarchies. 212 Not all resources may be limitable or calculatable for all quota 213 roots. Further, not all resources may support all limits - some 214 limits may be present in the underlying system. A server 215 implementation of this memo SHOULD advise the client of such inherent 216 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 217 advise the client of which resources are limitable for a particular 218 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 219 quota limit in an implementation dependant way, if the granularity of 220 the underlying system demands it. A client MUST be prepared for a 221 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 223 Implementation Notes: 224 This means that, for example under UNIX, a quota root may have a 225 MESSAGE (Section 5.2) quota always set due to the number of inodes 226 available on the filesystem, and similarly STORAGE (Section 5.1) may 227 be rounded to the nearest block and limited by free filesystem space. 229 4. Definitions 231 4.1. Commands 233 The following commands exist for manipulation and querying quotas. 235 4.1.1. GETQUOTA 237 Arguments: quota root 239 Responses: REQUIRED untagged responses: QUOTA 241 Result: OK - getquota completed 242 NO - getquota error: no such quota root, permission denied 243 BAD - command unknown or arguments invalid 245 The GETQUOTA command takes the name of a quota root and returns the 246 quota root's resource usage and limits in an untagged QUOTA response. 247 The client can try using any of the resource types returned in 248 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 249 prefix), however the server is not required to support any specific 250 resource type for any particular quota root. 252 Example: 254 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 255 [...] 256 C: G0001 GETQUOTA "!partition/sda4" 257 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 258 S: G0001 OK Getquota complete 260 4.1.2. GETQUOTAROOT 262 Arguments: mailbox name 264 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 266 Result: OK - getquotaroot completed 267 NO - getquotaroot error: no such mailbox, permission denied 268 BAD - command unknown or arguments invalid 270 The GETQUOTAROOT command takes a mailbox name and returns the list of 271 quota roots for the mailbox in an untagged QUOTAROOT response. For 272 each listed quota root, it also returns the quota root's resource 273 usage and limits in an untagged QUOTA response. 275 Note that the mailbox name parameter doesn't have to reference an 276 existing mailbox. This can be handy in order to determine which 277 quotaroot would apply to a mailbox when it gets created. 279 Example: 281 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 282 [...] 284 [...] 285 C: G0002 GETQUOTAROOT INBOX 286 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 287 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 288 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 289 S: G0002 OK Getquotaroot complete 291 4.1.3. SETQUOTA 293 Arguments: quota root 295 list of resource limits 297 Responses: untagged responses: QUOTA 299 Result: OK - setquota completed 300 NO - setquota error: can't set that data 301 BAD - command unknown or arguments invalid 303 The SETQUOTA command takes the name of a mailbox quota root and a 304 list of resource limits. The resource limits for the named quota 305 root are changed to be the specified limits. Any previous resource 306 limits for the named quota root are discarded. 308 If the named quota root did not previously exist, an implementation 309 may optionally create it and change the quota roots for any number of 310 existing mailboxes in an implementation-defined manner. 312 If the implementation chooses to change the quota roots for some 313 existing mailboxes such changes SHOULD be announced with untagged 314 QUOTA responses. 316 Example: 318 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 319 [...] 320 [...] 321 C: S0000 GETQUOTA "#user/alice" 322 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 323 S: S0000 OK Getquota completed 324 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 325 S: * QUOTA "#user/alice" (STORAGE 58 512) 327 // The server has rounded the STORAGE quota limit requested to the 328 nearest 512 blocks of 1024 octects, or else another client has 329 performed a near simultaneous SETQUOTA, using a limit of 512. 331 S: S0001 OK Rounded quota 332 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 333 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 335 // The server has not changed the quota, since this is a 336 filesystem limit, and cannot be changed. The QUOTA response here 337 is entirely optional. 339 S: S0002 NO Cannot change system limit 341 4.1.4. New STATUS attributes 343 DELETED-MESSAGES and DELETED-STORAGE status data items allow to 344 estimate the amount of resource freed by an EXPUNGE on a mailbox. 346 DELETED-MESSAGES status data item requests the server to return the 347 number of messages with \Deleted flag set. 349 DELETED-STORAGE status data item requests the server to return the 350 amount of storage space that can be reclaimed by performing EXPUNGE 351 on the mailbox. The server SHOULD return the exact value, however it 352 is recognized that the server may have to do non-trivial amount of 353 work to calculate it. If the calculation of the exact value would 354 take a long time, the server MAY instead return the sum of 355 RFC822.SIZEs of messages with the \Deleted flag set. 357 Example: 359 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE 360 [...] 361 [...] 362 C: S0003 STATUS INBOX (MESSAGES DELETED-MESSAGES DELETED-STORAGE) 363 S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE 364 8) 366 // 12 messages, 4 of which would be deleted when an EXPUNGE 367 happens. 369 S: S0003 OK Status complete. 371 4.2. Responses 373 The following responses may be sent by the server. 375 4.2.1. QUOTA 377 Data: quota root name 378 list of resource names, usages, and limits 380 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 381 command. The first string is the name of the quota root for which 382 this quota applies. 384 The name is followed by a S-expression format list of the resource 385 usage and limits of the quota root. The list contains zero or more 386 triplets. Each triplet contains a resource name, the current usage 387 of the resource, and the resource limit. 389 Resources not named in the list are not limited in the quota root. 390 Thus, an empty list means there are no administrative resource limits 391 in the quota root. 393 Example: S: * QUOTA "" (STORAGE 10 512) 395 4.2.2. QUOTAROOT 397 Data: mailbox name 398 zero or more quota root names 400 This response occurs as a result of a GETQUOTAROOT command. The 401 first string is the mailbox and the remaining strings are the names 402 of the quota roots for the mailbox. 404 Example: 406 S: * QUOTAROOT INBOX "" 408 S: * QUOTAROOT comp.mail.mime 410 4.3. Response Codes 412 4.3.1. OVERQUOTA 414 OVERQUOTA response code SHOULD be returned in the tagged NO response 415 to an APPEND/COPY/MOVE when the addition of the message(s) puts the 416 target mailbox over any one of its quota limits. 418 Example: 420 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 421 S: + Ready for literal data 422 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 423 C: From: Fred Foobar 424 C: Subject: afternoon meeting 425 C: To: mooch@owatagu.siam.edu 426 C: Message-Id: 427 C: MIME-Version: 1.0 428 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 429 C: 430 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 431 C: 432 S: A003 NO [OVERQUOTA] APPEND Failed 434 The OVERQUOTA response code MAY also be returned in an untagged NO 435 response when a mailbox exceeds soft quota. Such responses have 2 436 forms. If it is followed by a tag, the tag refers to the command 437 that caused this (such as APPEND or COPY) and the OVERQUOTA response 438 code applies to the target mailbox specified by such command. If the 439 OVERQUOTA response code is not followed by the tag, this means that 440 an external event (e.g. LMTP delivery or APPEND/COPY in another IMAP 441 connection) caused this event and the event applies to the currently 442 selected mailbox. In particular, this means that such OVERQUOTA 443 response codes MUST NOT be returned if there is no mailbox selected 444 or if a mailbox other than the currently selected one exceeds soft 445 quota. 447 Example: 449 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 450 S: + Ready for literal data 451 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 452 C: From: Fred Foobar 453 C: Subject: afternoon meeting 454 C: To: mooch@owatagu.siam.edu 455 C: Message-Id: 456 C: MIME-Version: 1.0 457 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 458 C: 459 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 460 C: 461 S: * NO [OVERQUOTA A003] Soft quota has been exceeded 462 S: A003 OK [APPENDUID 38505 3955] APPEND completed 464 5. Resource Type Definitions 466 The following resource types are defined in this memo. A server 467 supporting a resource type MUST advertise this as a CAPABILITY with a 468 name consisting of the resource name prefixed by "QUOTA=RES-". A 469 server MAY support mupltiple resource types, and MUST advertise all 470 resource types it supports. 472 5.1. STORAGE 474 The physical space estimate, in units of 1024 octets, of the 475 mailboxes governed by the quota root. This MAY not be the same as 476 the sum of the RFC822.SIZE of the messages. Some implementations MAY 477 include metadata sizes for the messages and mailboxes, other 478 implementations MAY store messages in such a way that the physical 479 space used is smaller, for example due to use of compression. 480 Additional messages might not increase the usage. Client MUST NOT 481 use the usage figure for anything other than informational purposes, 482 for example, they MUST NOT refuse to APPEND a message if the limit 483 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 484 message, but it MAY warn about such condition. 486 The usage figure may change as a result of performing actions not 487 associated with adding new messages to the mailbox, such as SEARCH, 488 since this may increase the amount of metadata included in the 489 calculations. 491 Support for this resource MUST be indicated by the server by 492 advertising the CAPABILITY "QUOTA=RES-STORAGE". 494 A resource named the same was also given as an example in RFC2087 495 [RFC2087]. In absence of information to the contrary, clients 496 conformant to this specification connecting to servers which do not 497 advertise "QUOTA=RES-STORAGE", yet allow a resource named STORAGE, 498 MUST NOT assume that it is the same resource. [[CREF1: Is the above 499 restriction useful and will it be obeyed? If the answer is "no", 500 delete it.]] 502 5.2. MESSAGE 504 The number of messages stored within the mailboxes governed by the 505 quota root. This MUST be an exact number, however, clients MUST NOT 506 assume that a change in the usage indicates a change in the number of 507 messages available, since the quota root may include mailboxes the 508 client has no access to. 510 Support for this resource MUST be indicated by the server by 511 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 513 A resource named the same was also given as an example in RFC2087 514 [RFC2087], clients conformant to this specification connecting to 515 servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a 516 resource named MESSAGE, MUST NOT assume that it is the same resource. 517 [[CREF2: As above.]] 519 5.3. MAILBOX 521 The number of mailboxes governed by the quota root. This MUST be an 522 exact number, however, clients MUST NOT assume that a change in the 523 usage indicates a change in the number of mailboxes, since the quota 524 root may include mailboxes the client has no access to. 526 Support for this resource MUST be indicated by the server by 527 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 529 5.4. ANNOTATION-STORAGE 531 [[CREF3: Bron to check whether this is a sensible description and 532 whether it is needed at all:]] The maximum size of all annotations 533 [RFC5257], in units of 1024 octets, associated with all messages in 534 the mailboxes governed by the quota root. 536 Support for this resource MUST be indicated by the server by 537 advertising the CAPABILITY "QUOTA=RES-ANNOTATION-STORAGE". 539 6. Interaction with IMAP ACL extension (RFC 4314) 541 [[CREF4: TBD]] 543 7. Formal syntax 545 The following syntax specification uses the Augmented Backus-Naur 546 Form (ABNF) notation as specified in [ABNF]. 548 Non-terminals referenced but not defined below are as defined by 549 IMAP4 [RFC3501]. 551 Except as noted otherwise, all alphabetic characters are case- 552 insensitive. The use of upper or lower case characters to define 553 token strings is for editorial clarity only. Implementations MUST 554 accept these strings in a case-insensitive fashion. 556 getquota = "GETQUOTA" SP quota-root-name 558 getquotaroot = "GETQUOTAROOT" SP mailbox 560 quota-list = "(" quota-resource *(SP quota-resource) ")" 562 quota-resource = resource-name SP resource-usage SP resource- 563 limit 565 quota-response = "QUOTA" SP quota-root-name SP quota-list 566 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 568 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 570 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 571 ")" 573 setquota-resource = resource-name SP resource-limit 575 quota-root-name = astring 577 resource-limit = number 579 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 580 resource-name-vnd / 581 resource-name-ext 583 resource-name-vnd = "V-" atom 584 ;; Vendor specific, must be registered with IANA. 585 ;; The "V-" prefix should be followed by a domain 586 name 587 ;; under vendor's control. 589 resource-name-ext = atom 590 ;; Not starting with V- and defined 591 ;; in a Standard Track or Experimental RFC 593 resource-names = "(" [resource-name *(SP resource-name)] ")" 595 resource-usage = number 596 ;; must be less than corresponding resource-limit 598 capability-quota = capa-quota-res 600 capa-quota-res = "QUOTA=RES-" resource-name 602 status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE" 604 [[CREF5: Should the above be optional unless the 605 server implements MESSAGE/STORAGE? Also sync 606 this with IMAP4rev2.]] 608 resp-text-code =/ "OVERQUOTA" [SP tag] 610 8. Security Considerations 612 Implementors should be careful to make sure the implementation of 613 these commands does not violate the site's security policy. The 614 resource usage of other users is likely to be considered confidential 615 information and should not be divulged to unauthorized persons. 617 9. IANA Considerations 619 IMAP4 capabilities are registered by publishing a standards track or 620 IESG approved experimental RFC. The registry is currently located 621 at: 623 http://www.iana.org/assignments/imap4-capabilities 625 IANA is requested to update definition of the QUOTA extension to 626 point to this document. 628 IANA is also requested to create a new registry for IMAP quota 629 resource types. Registration policy for this registry is 630 "Specification Required". When registering a new quota resource 631 type, the registrant need to provide the following: Name of the quota 632 resource type, Author/Change Controller name and email address, short 633 description and a reference to a specification that describes the 634 quota resource type in more details. 636 This document includes initial registrations for the following IMAP 637 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2), 638 MAILBOX (Section 5.3) and "ANNOTATION-STORAGE" (Section 5.4). See 639 details below. 641 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 642 capabilities registry and add a pointer to this document and to the 643 IMAP quote resource type registry established above. 645 IANA is requested to reserve all other capabilities starting with 646 "QUOTA=" prefix for future standard track or experimental extensions 647 to this document. 649 9.1. Registrations of IMAP Quota Resource Types 651 Name of the quota resource type: STORAGE 653 Author: Alexey Melnikov 655 Change Controller: IESG 656 Description: The physical space estimate, in units of 1024 octets, 657 of the mailboxes governed by the quota root. 659 Reference: Section 5.1 of RFCXXXX 661 Name of the quota resource type: MESSAGE 663 Author: Alexey Melnikov 665 Change Controller: IESG 667 Description: The number of messages stored within the mailboxes 668 governed by the quota root. 670 Reference: Section 5.2 of RFCXXXX 672 Name of the quota resource type: MAILBOX 674 Author: Alexey Melnikov 676 Change Controller: IESG 678 Description: The number of mailboxes governed by the quota root. 680 Reference: Section 5.3 of RFCXXXX 682 Name of the quota resource type: 684 Author: Alexey Melnikov 686 Change Controller: IESG 688 Description: The maximum size of all annotations [RFC5257], in units 689 of 1024 octets, associated with all messages in the mailboxes 690 governed by the quota root. [[CREF6: Recheck against the final 691 description of "ANNOTATION-STORAGE".]] 693 Reference: Section 5.4 of RFCXXXX 695 10. Contributors 697 Dave Cridland wrote lots of text in an earlier draft that became the 698 basis for this document. 700 11. Acknowledgments 702 Editors of this document would like to thank the following people who 703 provided useful comments or participated in discussions that lead to 704 this update to RFC 2087: 705 John Myers, 706 Cyrus Daboo, 707 Lyndon Nerenberg 709 This document is a revision of RFC 2087. It borrows a lot of text 710 from RFC 2087. Thus work of the RFC 2087 author John Myers is 711 appreciated. 713 12. Changes since RFC 2087 715 This document is a revision of RFC 2087. It tries to clarify meaning 716 of different terms used by RFC 2087. It also provides more examples, 717 gives guidance on allowed server behaviour, defines IANA registry for 718 quota resource types and provides initial registrations for 3 of 719 them. 721 When compared with RFC 2087, this document defines one more commonly 722 used resource type, adds optional OVERQUOTA response code and defines 723 two extra STATUS data items ("DELETED-MESSAGES" and "DELETED- 724 STORAGE") 726 13. References 728 13.1. Normative References 730 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 731 Syntax Specifications: ABNF", RFC 5234, January 2008. 733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, 735 DOI 10.17487/RFC2119, March 1997, 736 . 738 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 739 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 740 . 742 [RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension", 743 RFC 4314, DOI 10.17487/RFC4314, December 2005, 744 . 746 [RFC5257] Daboo, C. and R. Gellens, "Internet Message Access 747 Protocol - ANNOTATE Extension", RFC 5257, 748 DOI 10.17487/RFC5257, June 2008, 749 . 751 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 752 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 753 May 2017, . 755 13.2. Informative References 757 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 758 DOI 10.17487/RFC2087, January 1997, 759 . 761 Author's Address 763 Alexey Melnikov 764 Isode Limited 766 Email: alexey.melnikov@isode.com 767 URI: https://www.isode.com