idnits 2.17.1 draft-ietf-extra-quota-00.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 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 17, 2019) is 1324 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 453, but not defined ** Obsolete normative reference: RFC 4234 (ref. 'ABNF') (Obsoleted by RFC 5234) ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) -- Obsolete informational reference (is this intentional?): RFC 2087 (Obsoleted by RFC 9208) Summary: 2 errors (**), 0 flaws (~~), 4 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 17, 2019 5 Expires: December 19, 2019 7 IMAP QUOTA Extension 8 draft-ietf-extra-quota-00 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 19, 2019. 36 Copyright Notice 38 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 86 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 6. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 11 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 89 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 90 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 91 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 92 11. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 14 93 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 94 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 95 12.2. Informative References . . . . . . . . . . . . . . . . . 15 97 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 99 1. Document Conventions 101 In protocol examples, this document uses a prefix of "C: " to denote 102 lines sent by the client to the server, and "S: " for lines sent by 103 the server to the client. Lines prefixed with "// " are comments 104 explaining the previous protocol line. These prefixes and comments 105 are not part of the protocol. Lines without any of these prefixes 106 are continuations of the previous line, and no line break is present 107 in the protocol unless specifically mentioned. 109 Again, for examples, the hierarchy separator on the server is 110 presumed to be "/" throughout. None of these assumptions is required 111 nor recommended by this document. 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC2119 [RFC2119]. 117 Other capitalised words are IMAP4 [RFC3501] keywords or keywords from 118 this document. 120 2. Introduction and Overview 122 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 123 Some commands and responses defined in this document are not present 124 in such servers, and clients MUST NOT rely on their presence in the 125 absence of any capability beginning with "QUOTA=". 127 Any server compliant with this document MUST also return at least one 128 capability starting with "QUOTA=RES-" prefix, as described in 129 Section 3.1. 131 This document also reserves all other capabilities starting with 132 "QUOTA=" prefix to future standard track or experimental extensions 133 to this document. 135 Quotas can be used to restrict clients for administrative reasons, 136 but the QUOTA extension can also be used to indicate system limits 137 and current usage levels to clients. 139 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 140 this has seen deployment in servers, it has seen little deployment in 141 clients. Since the meaning of the resources was left implementation- 142 dependant, it was impossible for a client implementation to determine 143 which resources were supported, and impossible to determine which 144 mailboxes were in a given quota root, without a priori knowledge of 145 the implementation. 147 3. Terms 149 3.1. Resource 151 A resource has a name, a formal definition. 153 3.1.1. Name 155 [[CREF1: Fix IANA considerations section.]] 157 The resource name is an atom, as defined in IMAP4 [RFC3501]. These 158 MUST be registered with IANA. Implementation specific resources 159 begin with "V-" . 161 Supported resource names MUST be advertised as a capability, by 162 prepending the resource name with "QUOTA=RES-". A server compliant 163 with this specification is not required to support all reported 164 resource types on all quota roots. 166 3.1.2. Definition 168 The resource definition or document containing it, while not visible 169 through the protocol, SHOULD be registered with IANA. 171 The usage of a resource MUST be represented as a 32 bit unsigned 172 integer. 0 indicates that the resource is exhausted. Usage integers 173 don't necessarily represent proportional use, so clients MUST NOT 174 compare available resource between two separate quota roots on the 175 same or different servers. 177 Limits will be specified as, and MUST be represented as, an integer. 178 0 indicates that any usage is prohibited. 180 Limits may be hard or soft - that is, an implementation MAY choose, 181 or be configured, to disallow any command if the limit on a resource 182 is or would be exceeded. 184 All resources which the server handles must be advertised in a 185 CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". 186 For compatability with RFC2087 [RFC2087], a client which discovers 187 resources available on the server which are not advertised through 188 this mechanism MUST treat them as if they were completely opaque, and 189 without any meaning. 191 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2) and 192 MAILBOX (Section 5.3) are defined in this document. 194 3.2. Quota Root 196 Each mailbox has zero or more implementation-defined named "quota 197 roots". Each quota root has zero or more resource limits (quotas). 198 All mailboxes that share the same named quota root share the resource 199 limits of the quota root. 201 Quota root names need not be mailbox names, nor is there any 202 relationship defined by this memo between a Quota root name and a 203 mailbox name. A quota root name is an astring, as defined in IMAP4 204 [RFC3501]. It SHOULD be treated as an opaque string by any clients. 206 Quota roots are used since not all implementations may be able to 207 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 208 hierarchies. 210 Not all resources may be limitable or calculatable for all quota 211 roots. Further, not all resources may support all limits - some 212 limits may be present in the underlying system. A server 213 implementation of this memo SHOULD advise the client of such inherent 214 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 215 advise the client of which resources are limitable for a particular 216 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 217 quota limit in an implementation dependant way, if the granularity of 218 the underlying system demands it. A client MUST be prepared for a 219 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 221 Implementation Notes: 222 This means that, for example under UNIX, a quota root may have a 223 MESSAGE (Section 5.2) quota always set due to the number of inodes 224 available on the filesystem, and similarly STORAGE (Section 5.1) may 225 be rounded to the nearest block and limited by free filesystem space. 227 4. Definitions 229 4.1. Commands 231 The following commands exist for manipulation and querying quotas. 233 4.1.1. GETQUOTA 235 Arguments: quota root 237 Responses: REQUIRED untagged responses: QUOTA 238 Result: OK - getquota completed 239 NO - getquota error: no such quota root, permission denied 240 BAD - command unknown or arguments invalid 242 The GETQUOTA command takes the name of a quota root and returns the 243 quota root's resource usage and limits in an untagged QUOTA response. 244 The client can try using any of the resource types returned in 245 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 246 prefix), however the server is not required to support any specific 247 resource type for any particular quota root. 249 Example: 251 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 252 [...] 253 C: G0001 GETQUOTA "!partition/sda4" 254 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 255 S: G0001 OK Getquota complete 257 4.1.2. GETQUOTAROOT 259 Arguments: mailbox name 261 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 263 Result: OK - getquotaroot completed 264 NO - getquotaroot error: no such mailbox, permission denied 265 BAD - command unknown or arguments invalid 267 The GETQUOTAROOT command takes the name of a mailbox and returns the 268 list of quota roots for the mailbox in an untagged QUOTAROOT 269 response. For each listed quota root, it also returns the quota 270 root's resource usage and limits in an untagged QUOTA response. 272 [[CREF2: Need to clarify that the mailbox name doesn't have to 273 reference an existing mailbox. This can be handy in order to 274 determine which quotaroot would apply to a mailbox when it gets 275 created.]] 277 Example: 279 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 280 [...] 281 [...] 282 C: G0002 GETQUOTAROOT INBOX 283 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 284 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 285 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 286 S: G0002 OK Getquotaroot complete 288 4.1.3. SETQUOTA 290 Arguments: quota root 292 list of resource limits 294 Responses: untagged responses: QUOTA 296 Result: OK - setquota completed 297 NO - setquota error: can't set that data 298 BAD - command unknown or arguments invalid 300 The SETQUOTA command takes the name of a mailbox quota root and a 301 list of resource limits. The resource limits for the named quota 302 root are changed to be the specified limits. Any previous resource 303 limits for the named quota root are discarded. 305 If the named quota root did not previously exist, an implementation 306 may optionally create it and change the quota roots for any number of 307 existing mailboxes in an implementation-defined manner. 309 [[CREF3: Should the server be sending untagged QUOTA responses for 310 all side effect changes?]] 312 Example: 314 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 315 [...] 316 [...] 317 C: S0000 GETQUOTA "#user/alice" 318 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 319 S: S0000 OK Getquota completed 320 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 321 S: * QUOTA "#user/alice" (STORAGE 58 512) 323 // The server has rounded the STORAGE quota limit requested to the 324 nearest 512 blocks of 1024 octects, or else another client has 325 performed a near simultaneous SETQUOTA, using a limit of 512. 327 S: S0001 OK Rounded quota 328 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 329 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 331 // The server has not changed the quota, since this is a 332 filesystem limit, and cannot be changed. The QUOTA response here 333 is entirely optional. 335 S: S0002 NO Cannot change system limit 337 4.1.4. New STATUS attributes 339 DELETED-MESSAGES and DELETED-STORAGE status data items allow to 340 estimate the amount of resource freed by an EXPUNGE on a mailbox. 342 DELETED-MESSAGES status data item requests the server to return the 343 number of messages with \Deleted flag set. 345 DELETED-STORAGE status data item requests the server to return the 346 amount of storage space that can be reclaimed by performing EXPUNGE 347 on the mailbox. The server SHOULD return the exact value, however it 348 is recognized that the server may have to do non-trivial amount of 349 work to calculate it. If the calculation of the exact value would 350 take a long time, the server MAY instead return the sum of 351 RFC822.SIZEs of messages with the \Deleted flag set. 353 Example: 355 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE 356 [...] 357 [...] 358 C: S0003 STATUS INBOX (MESSAGES DELETED-MESSAGES DELETED-STORAGE) 359 S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE 360 8) 362 // 12 messages, 4 of which would be deleted when an EXPUNGE 363 happens. 365 S: S0003 OK Status complete. 367 4.2. Responses 369 The following responses may be sent by the server. 371 4.2.1. QUOTA 373 Data: quota root name 374 list of resource names, usages, and limits 376 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 377 command. The first string is the name of the quota root for which 378 this quota applies. 380 The name is followed by a S-expression format list of the resource 381 usage and limits of the quota root. The list contains zero or more 382 triplets. Each triplet contains a resource name, the current usage 383 of the resource, and the resource limit. 385 Resources not named in the list are not limited in the quota root. 386 Thus, an empty list means there are no administrative resource limits 387 in the quota root. 389 Example: S: * QUOTA "" (STORAGE 10 512) 391 4.2.2. QUOTAROOT 393 Data: mailbox name 394 zero or more quota root names 396 This response occurs as a result of a GETQUOTAROOT command. The 397 first string is the mailbox and the remaining strings are the names 398 of the quota roots for the mailbox. 400 Example: 402 S: * QUOTAROOT INBOX "" 404 S: * QUOTAROOT comp.mail.mime 406 4.3. Response Codes 408 4.3.1. OVERQUOTA 410 OVERQUOTA response code SHOULD be returned in the tagged NO response 411 to an APPEND/COPY when the addition of the message(s) puts mailbox 412 over any one of its quota limits. 414 Example: 416 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 417 S: + Ready for literal data 418 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 419 C: From: Fred Foobar 420 C: Subject: afternoon meeting 421 C: To: mooch@owatagu.siam.edu 422 C: Message-Id: 423 C: MIME-Version: 1.0 424 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 425 C: 426 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 427 C: 428 S: A003 NO [OVERQUOTA] APPEND Failed 430 The OVERQUOTA response code MAY also be returned in an untagged NO 431 response when the currently selected mailbox exceeds soft quota. 432 [[CREF4: What about per-user quotas when no mailbox is selected or 433 when the destination mailbox (different from the currently selected 434 one) is affected?]] The response code MUST be followed by the tag of 435 the command that caused this (such as APPEND or COPY). The tag MUST 436 be omitted if an external event (e.g. LMTP delivery or APPEND/COPY 437 in another IMAP connection) caused this event. 439 Example: 441 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 442 S: + Ready for literal data 443 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 444 C: From: Fred Foobar 445 C: Subject: afternoon meeting 446 C: To: mooch@owatagu.siam.edu 447 C: Message-Id: 448 C: MIME-Version: 1.0 449 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 450 C: 451 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 452 C: 453 S: * NO [OVERQUOTA A003] Soft quota has been exceeded 454 S: A003 OK [APPENDUID 38505 3955] APPEND completed 456 5. Resource Type Definitions 458 The following resource types are defined in this memo. A server 459 supporting a resource type MUST advertise this as a CAPABILITY with a 460 name consisting of the resource name prefixed by "QUOTA=RES-". A 461 server MAY support mupltiple resource types, and MUST advertise all 462 resource types it supports. 464 5.1. STORAGE 466 The physical space estimate, in units of 1024 octets, of the 467 mailboxes governed by the quota root. This MAY not be the same as 468 the sum of the RFC822.SIZE of the messages. Some implementations MAY 469 include metadata sizes for the messages and mailboxes, other 470 implementations MAY store messages in such a way that the physical 471 space used is smaller, for example due to use of compression. 472 Additional messages might not increase the usage. Client MUST NOT 473 use the usage figure for anything other than informational purposes, 474 for example, they MUST NOT refuse to APPEND a message if the limit 475 less the usage is smaller than the RFC822.SIZE divided by 1024 of the 476 message, but it MAY warn about such condition. 478 The usage figure may change as a result of performing actions not 479 associated with adding new messages to the mailbox, such as SEARCH, 480 since this may increase the amount of metadata included in the 481 calculations. 483 Support for this resource MUST be indicated by the server by 484 advertising the CAPABILITY "QUOTA=RES-STORAGE". 486 A resource named the same was also given as an example in RFC2087 487 [RFC2087], clients conformant to this specification connecting to 488 servers which do not advertise "QUOTA=RES-STORAGE", yet allow a 489 resource named STORAGE, MUST NOT assume that it is the same resource. 490 [[CREF5: ?]] 492 5.2. MESSAGE 494 The number of messages stored within the mailboxes governed by the 495 quota root. This MUST be an exact number, however, clients MUST NOT 496 assume that a change in the usage indicates a change in the number of 497 messages available, since the quota root may include mailboxes the 498 client has no access to. 500 Support for this resource MUST be indicated by the server by 501 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 503 A resource named the same was also given as an example in RFC2087 504 [RFC2087], clients conformant to this specification connecting to 505 servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a 506 resource named MESSAGE, MUST NOT assume that it is the same resource. 508 5.3. MAILBOX 510 The number of mailboxes governed by the quota root. This MUST be an 511 exact number, however, clients MUST NOT assume that a change in the 512 usage indicates a change in the number of mailboxes, since the quota 513 root may include mailboxes the client has no access to. 515 Support for this resource MUST be indicated by the server by 516 advertising the CAPABILITY "QUOTA=RES-MAILBOX". 518 6. Formal syntax 520 The following syntax specification uses the Augmented Backus-Naur 521 Form (ABNF) notation as specified in [ABNF]. 523 Non-terminals referenced but not defined below are as defined by 524 IMAP4 [RFC3501]. 526 Except as noted otherwise, all alphabetic characters are case- 527 insensitive. The use of upper or lower case characters to define 528 token strings is for editorial clarity only. Implementations MUST 529 accept these strings in a case-insensitive fashion. 531 getquota = "GETQUOTA" SP quota-root-name 533 getquotaroot = "GETQUOTAROOT" SP mailbox 535 quota-list = "(" quota-resource *(SP quota-resource) ")" 537 quota-resource = resource-name SP resource-usage SP resource- 538 limit 540 quota-response = "QUOTA" SP quota-root-name SP quota-list 542 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 544 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 546 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 547 ")" 549 setquota-resource = resource-name SP resource-limit 551 quota-root-name = astring 553 resource-limit = number 555 resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / 556 resource-name-vnd / 557 resource-name-ext 559 resource-name-vnd = "V-" atom 560 ;; Vendor specific, must be registered with IANA. 561 ;; The "V-" prefix should be followed by a domain 562 name 563 ;; under vendor's control. 565 resource-name-ext = atom 566 ;; Not starting with V- and defined 567 ;; in a Standard Track or Experimental RFC 569 resource-names = "(" [resource-name *(SP resource-name)] ")" 571 resource-usage = number 572 ;; must be less than corresponding resource-limit 574 capability-quota = capa-quota-res 576 capa-quota-res = "QUOTA=RES-" resource-name 578 status-att =/ "DELETED-MESSAGES" / "DELETED-STORAGE" 580 [[CREF6: Should this be optional unless the 581 server implements MESSAGE/STORAGE?]] 583 resp-text-code =/ "OVERQUOTA" [SP tag] 585 7. Security Considerations 587 Implementors should be careful to make sure the implementation of 588 these commands does not violate the site's security policy. The 589 resource usage of other users is likely to be considered confidential 590 information and should not be divulged to unauthorized persons. 592 8. IANA Considerations 594 IMAP4 capabilities are registered by publishing a standards track or 595 IESG approved experimental RFC. The registry is currently located 596 at: 598 http://www.iana.org/assignments/imap4-capabilities 600 IANA is requested to update definition of the QUOTA extension to 601 point to this document. 603 IANA is also requested to create a new registry for IMAP quota 604 resource types. Registration policy for this registry is 605 "Specification Required". When registering a new quota resource 606 type, the registrant need to provide the following: Name of the quota 607 resource type, Author/Change Controller name and email address, short 608 description and a reference to the specification. 610 This document includes initial registrations for the following IMAP 611 quota resource type: STORAGE (Section 5.1), MESSAGE (Section 5.2) and 612 MAILBOX (Section 5.3). 614 IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 615 capabilities registry and add a pointer to this document and to the 616 IMAP quote resource type registry established above. 618 IANA is requested to reserve all other capabilities starting with 619 "QUOTA=" prefix to future standard track or experimental extensions 620 to this document. 622 9. Contributors 624 Dave Cridland wrote lots of text in an earlier draft that became the 625 base for this document. 627 10. Acknowledgments 629 Editors of this document would like to thank the following people who 630 provided useful comments or participated in discussions that lead to 631 this update to RFC 2087: 632 John Myers, 633 Cyrus Daboo, 634 Lyndon Nerenberg 636 This document is a revision of RFC 2087. It borrows a lot of text 637 from RFC 2087. Thus work of the RFC 2087 author John Myers is 638 appreciated. 640 11. Changes since RFC 2087 642 This document is a revision of RFC 2087. It tries to clarify meaning 643 of different terms used by RFC 2087. It also provides more examples, 644 gives guidance on allowed server behaviour, defines IANA registry for 645 quota resource types and provides initial registrations for 3 of 646 them. 648 When compared with RFC 2087, this document defines one more commonly 649 used resource type, adds optional OVERQUOTA response code and defines 650 two extra STATUS data items ("DELETED-MESSAGES" and "DELETED- 651 STORAGE") 653 12. References 655 12.1. Normative References 657 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 658 Syntax Specifications: ABNF", RFC 4234, October 2005. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, 662 DOI 10.17487/RFC2119, March 1997, 663 . 665 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 666 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 667 . 669 12.2. Informative References 671 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 672 DOI 10.17487/RFC2087, January 1997, 673 . 675 Author's Address 677 Alexey Melnikov 678 Isode Limited 680 Email: alexey.melnikov@isode.com 681 URI: https://www.isode.com