idnits 2.17.1 draft-melnikov-imapext-quota-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 667. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 678. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 685. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 691. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 RFC 3978 Section 5.4 Copyright Line does not match the current year -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The physical space estimate, in units of 1024 octets, of the mailboxes governed by the quota root. This MAY not be the same as the sum of the RFC822.SIZE of the messages. Some implementations MAY include metadata sizes for the messages and mailboxes, other implementations MAY store messages in such a way that the physical space used is smaller. Additional messages MAY NOT increase the usage. Client MUST NOT use the usage figure for anything other than informational purposes, for example, they MUST NOT refuse to APPEND a message if the limit less the usage is smaller than the RFC822.SIZE divided by 1024 of the message, but it MAY warn about such condition. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 15, 2006) is 6432 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 442, 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: 5 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft 4 Intended status: Standards Track A. Melnikov 5 Expires: March 19, 2007 Isode 6 September 15, 2006 8 IMAP QUOTA Extension 9 draft-melnikov-imapext-quota-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 19, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The QUOTA extension of the Internet Message Access Protocol (RFC 43 3501) permits administrative limits on resource usage (quotas) to be 44 manipulated through the IMAP protocol. 46 This memo obsoletes RFC 2087, but attempts to remain backwards 47 compatible whenever possible. 49 Table of Contents 51 1. Document Conventions . . . . . . . . . . . . . . . . . . . . . 3 52 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 53 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . . 4 57 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . . 5 58 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . . 5 61 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . . 6 62 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 8 64 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 8 65 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 8 66 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 9 67 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . . 9 68 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 9 69 5. Resource Definitions . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 11 72 5.3. MAILBOXES . . . . . . . . . . . . . . . . . . . . . . . . 11 73 6. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 12 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 77 10. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . . 14 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 11.1. Normative References . . . . . . . . . . . . . . . . . . . 14 80 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Intellectual Property and Copyright Statements . . . . . . . . . . 16 84 1. Document Conventions 86 In protocol examples, this document uses a prefix of "C: " to denote 87 lines sent by the client to the server, and "S: " for lines sent by 88 the server to the client. Lines prefixed with "// " are comments 89 explaining the previous protocol line. These prefixes and comments 90 are not part of the protocol. Lines without any of these prefixes 91 are continuations of the previous line, and no line break is present 92 in the protocol unless specifically mentioned. 94 Again, for examples, the hierarchy separator on the server is 95 presumed to be "/" throughout. None of these assumptions is required 96 nor recommended by this memo. 98 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 99 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 100 document are to be interpreted as described in RFC2119 [RFC2119]. 102 Other capitalised words are IMAP4 [RFC3501] keywords or keywords from 103 this document. 105 2. Introduction and Overview 107 The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. 108 Some commands and responses defined in this document are not present 109 in such servers, and clients MUST NOT rely on their presence in the 110 absence of any capability beginning with "QUOTA=". 112 Any server compliant with this document MUST also return at least one 113 capability starting with "QUOTA=RES-" prefix, as described in 114 Section 3.1. 116 This document also reserves all other capabilities starting with 117 "QUOTA=" prefix to future standard track or experimental extensions 118 to this document. 120 Quotas can be used to restrict clients for administrative reasons, 121 but the QUOTA extension can also be used to indicate system limits 122 and current usage levels to clients. 124 Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and 125 this has seen deployment in servers, it has seen little deployment in 126 clients. Since the meaning of the resources was left implementation- 127 dependant, it was impossible for a client implementation to determine 128 which resources were supported, and impossible to determine which 129 mailboxes were in a given quota root, without a priori knowledge of 130 the implementation. 132 3. Terms 134 3.1. Resource 136 A resource has a name, a formal definition. 138 3.1.1. Name 140 [[anchor5: Fix IANA considerations section.]] 142 The resource name is an atom, as defined in IMAP4 [RFC3501]. These 143 MUST be registered with IANA, or begin with "X-", which indicates an 144 experimental resource. Implementation specific resources MUST be 145 registered with IANA, and begin with "V-". 147 Supported resource names MUST be advertised as a capability, by 148 prepending the resource name with "QUOTA=RES-". Server is not 149 required to support all reported resource types on all quota roots. 151 3.1.2. Definition 153 The resource definition or document containing it, while not visible 154 through the protocol, SHOULD be registered with IANA. 156 The usage of a resource MUST be represented as a 32 bit unsigned 157 integer. 0 indicates no usage of a resource. Usage integers MUST NOT 158 represent proportional use, such that a client can compare available 159 resource between two separate quota roots or servers with reasonable 160 accuracy. 162 Limits will be specified as, and MUST be represented as, an integer. 163 0 indicates that any usage is prohibited. 165 Limits may be hard or soft - that is, an implementation MAY choose, 166 or be configured, to disallow any command if the limit on a resource 167 is or would be exceeded. 169 All resources which the server handles must be advertised in a 170 CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". 171 For compatability with RFC2087 [RFC2087], a client which discovers 172 resources available on the server which are not advertised through 173 this mechanism MUST treat the resource as if it were completely 174 opaque, and without any meaning. 176 The resources STORAGE (Section 5.1), MESSAGE (Section 5.2) and 177 MAILBOXES (Section 5.3) are defined in this memo. 179 3.2. Quota Root 181 Each mailbox has zero or more implementation-defined named "quota 182 roots". Each quota root has zero or more resource limits (quotas). 183 All mailboxes that share the same named quota root share the resource 184 limits of the quota root. 186 Quota root names need not be mailbox names, nor is there any 187 relationship defined by this memo between a Quota root name and a 188 mailbox name. A quota root name is an astring, as defined in IMAP4 189 [RFC3501]. It MUST be treated as an opaque string by any clients 190 which do not have a priori knowledge of the server implementation. 192 Quota roots are used since not all implementations may be able to 193 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 194 hierarchies. 196 Not all resources may be limitable or calculatable for all quota 197 roots. Further, not all resources may support all limits - some 198 limits may be present in the underlying system. A server 199 implementation of this memo SHOULD advise the client of such inherent 200 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 201 advise the client of which resources are limitable for a particular 202 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 203 quota limit in an implementation dependant way, if the granularity of 204 the underlying system demands it. A client MUST be prepared for a 205 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 207 Implementation Notes: 208 This means that, for example under UNIX, a quota root may have a 209 MESSAGE (Section 5.2) quota always set due to the number of inodes 210 available on the filesystem, and similarly STORAGE (Section 5.1) may 211 be rounded to the nearest block and limited by free filesystem space. 213 4. Definitions 215 4.1. Commands 217 The following commands exist for manipulation and querying quotas. 219 4.1.1. GETQUOTA 221 Arguments: quota root 222 Responses: REQUIRED untagged responses: QUOTA 224 Result: OK - getquota completed 225 NO - getquota error: no such quota root, permission denied 226 BAD - command unknown or arguments invalid 228 The GETQUOTA command takes the name of a quota root and returns the 229 quota root's resource usage and limits in an untagged QUOTA response. 230 The client can try using any of the resource types returned in 231 CAPABILITY response (i.e. all capability items with "QUOTA=RES-" 232 prefix), however the server is not required to support any specific 233 resource type for any particular quota root. 235 Example: 237 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 238 [...] 239 C: G0001 GETQUOTA "!partition/sda4" 240 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 241 S: G0001 OK Getquota complete 243 4.1.2. GETQUOTAROOT 245 Arguments: mailbox name 247 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 249 Result: OK - getquotaroot completed 250 NO - getquotaroot error: no such mailbox, permission denied 251 BAD - command unknown or arguments invalid 253 The GETQUOTAROOT command takes the name of a mailbox and returns the 254 list of quota roots for the mailbox in an untagged QUOTAROOT 255 response. For each listed quota root, it also returns the quota 256 root's resource usage and limits in an untagged QUOTA response. 258 [[anchor10: Need to clarify that the mailbox name doesn't have to 259 reference an existing mailbox. This can be handy in order to 260 determine which quotaroot would apply to a mailbox when it gets 261 created.]] 263 Example: 265 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 266 [...] 267 [...] 268 C: G0002 GETQUOTAROOT INBOX 269 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 270 S: * QUOTA "#user/alice" (MESSAGE 42 1000) 271 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 272 S: G0002 OK Getquotaroot complete 274 4.1.3. SETQUOTA 276 Arguments: quota root 278 list of resource limits 280 Responses: untagged responses: QUOTA 282 Result: OK - setquota completed 283 NO - setquota error: can't set that data 284 BAD - command unknown or arguments invalid 286 The SETQUOTA command takes the name of a mailbox quota root and a 287 list of resource limits. The resource limits for the named quota 288 root are changed to be the specified limits. Any previous resource 289 limits for the named quota root are discarded. 291 If the named quota root did not previously exist, an implementation 292 may optionally create it and change the quota roots for any number of 293 existing mailboxes in an implementation-defined manner. 295 [[anchor11: Should the server be sending untagged QUOTA responses for 296 all side effect changes? It can, but only if the client has told the 297 server that it supports QUOTA.]] 299 Example: 301 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE 302 [...] 303 [...] 304 C: S0000 GETQUOTA "#user/alice" 305 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGE 42 1000) 306 S: S0000 OK Getquota completed 307 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 308 S: * QUOTA "#user/alice" (STORAGE 58 512) 310 // The server has rounded the STORAGE quota limit requested to the 311 nearest 512 blocks of 1024 octects, or else another client has 312 performed a near simultaneous SETQUOTA, using a limit of 512. 314 S: S0001 OK Rounded quota 315 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 316 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 317 // The server has not changed the quota, since this is a 318 filesystem limit, and cannot be changed. The QUOTA response here 319 is entirely optional. 321 S: S0002 NO Cannot change system limit 323 4.1.4. New STATUS attributes 325 DELETED-MESSAGES and DELETED-STORAGE status data items allow to 326 estimate the amount of resource freed by an EXPUNGE on a mailbox. 328 DELETED-MESSAGES status data item requests the server to return the 329 number of messages with \Deleted flag set. 331 DELETED-STORAGE status data item requests the server to return the 332 amount of storage space that can be reclaimed by performing EXPUNGE 333 on the mailbox. The server SHOULD return the exact value, however it 334 is recognized that the server may have to do non-trivial amount of 335 work to calculate it. If the calculation of the exact value would 336 take a long time, the server MAY instead return the sum of 337 RFC822.SIZEs of messages with the \Deleted flag set. 339 Example: 341 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGE 342 [...] 343 [...] 344 C: S0003 STATUS INBOX (MESSAGES DELETED-MESSAGES DELETED-STORAGE) 345 S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE 346 8) 348 // 12 messages, 4 of which would be deleted when an EXPUNGE 349 happens. 351 S: S0003 OK Status complete. 353 4.2. Responses 355 The following responses may be sent by the server. 357 4.2.1. QUOTA 359 Data: quota root name 360 list of resource names, usages, and limits 362 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 363 command. The first string is the name of the quota root for which 364 this quota applies. 366 The name is followed by a S-expression format list of the resource 367 usage and limits of the quota root. The list contains zero or more 368 triplets. Each triplet contains a resource name, the current usage 369 of the resource, and the resource limit. 371 Resources not named in the list are not limited in the quota root. 372 Thus, an empty list means there are no administrative resource limits 373 in the quota root. 375 Example: S: * QUOTA "" (STORAGE 10 512) 377 4.2.2. QUOTAROOT 379 Data: mailbox name 380 zero or more quota root names 382 This response occurs as a result of a GETQUOTAROOT command. The 383 first string is the mailbox and the remaining strings are the names 384 of the quota roots for the mailbox. 386 Example: 388 S: * QUOTAROOT INBOX "" 390 S: * QUOTAROOT comp.mail.mime 392 4.3. Response Codes 394 4.3.1. OVERQUOTA 396 OVERQUOTA response code SHOULD be returned in the tagged NO response 397 to an APPEND/COPY when the addition of the message(s) puts mailbox 398 over any one of its quota limits. 400 Example: 402 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 403 S: + Ready for literal data 404 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 405 C: From: Fred Foobar 406 C: Subject: afternoon meeting 407 C: To: mooch@owatagu.siam.edu 408 C: Message-Id: 409 C: MIME-Version: 1.0 410 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 411 C: 412 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 413 C: 415 S: A003 NO [OVERQUOTA] APPEND Failed 417 The OVERQUOTA response code MAY also be returned in an untagged NO 418 response when the currently selected mailbox exceeds soft quota. 419 [[anchor14: What about per-user quotas when no mailbox is selected?]] 420 The response code MUST be followed by the tag of the command that 421 caused this (such as APPEND or COPY). The tag MUST be omitted if an 422 external event (e.g. LMTP delivery or APPEND/COPY in another IMAP 423 connection) caused this event. 425 [[anchor15: Should the exceeded quota resource type be added as a 426 parameter?]] 428 Example: 430 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 431 S: + Ready for literal data 432 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 433 C: From: Fred Foobar 434 C: Subject: afternoon meeting 435 C: To: mooch@owatagu.siam.edu 436 C: Message-Id: 437 C: MIME-Version: 1.0 438 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 439 C: 440 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 441 C: 442 S: * NO [OVERQUOTA A003] Soft quota has been exceeded 443 S: A003 OK [APPENDUID 38505 3955] APPEND completed 445 5. Resource Definitions 447 The following resources are defined in this memo. A server 448 supporting a resource MUST advertise this as a CAPABILITY with a name 449 consisting of the resource name prefixed by "QUOTA=RES-". A server 450 MAY support mupltiple resource types, and MUST advertise all 451 resources it supports. 453 5.1. STORAGE 455 The physical space estimate, in units of 1024 octets, of the 456 mailboxes governed by the quota root. This MAY not be the same as 457 the sum of the RFC822.SIZE of the messages. Some implementations MAY 458 include metadata sizes for the messages and mailboxes, other 459 implementations MAY store messages in such a way that the physical 460 space used is smaller. Additional messages MAY NOT increase the 461 usage. Client MUST NOT use the usage figure for anything other than 462 informational purposes, for example, they MUST NOT refuse to APPEND a 463 message if the limit less the usage is smaller than the RFC822.SIZE 464 divided by 1024 of the message, but it MAY warn about such condition. 466 The usage figure may change as a result of performing actions not 467 associated with adding new messages to the mailbox, such as SEARCH, 468 since this may increase the amount of metadata included in the 469 calculations. 471 Support for this resource MUST be indicated by the server by 472 advertising the CAPABILITY "QUOTA=RES-STORAGE". 474 A resource named the same was also given as an example in RFC2087 475 [RFC2087], clients conformant to this specification connecting to 476 servers which do not advertise "QUOTA=RES-STORAGE", yet allow a 477 resource named STORAGE, MUST NOT assume that it is the same resource. 478 [[anchor17: ?]] 480 5.2. MESSAGE 482 The number of messages stored within the mailboxes governed by the 483 quota root. This MUST be an exact number, however, clients MUST NOT 484 assume that a change in the usage indicates a change in the number of 485 messages available, since the quota root may include mailboxes the 486 client has no access to. 488 Support for this resource MUST be indicated by the server by 489 advertising the CAPABILITY "QUOTA=RES-MESSAGE". 491 A resource named the same was also given as an example in RFC2087 492 [RFC2087], clients conformant to this specification connecting to 493 servers which do not advertise "QUOTA=RES-MESSAGE", yet allow a 494 resource named MESSAGE, MUST NOT assume that it is the same resource. 496 5.3. MAILBOXES 498 [[anchor18: Rename to "MAILBOX", for consistency with STORAGE/ 499 MESSAGE?]] 501 The number of mailboxes governed by the quota root. This MUST be an 502 exact number, however, clients MUST NOT assume that a change in the 503 usage indicates a change in the number of mailboxes, since the quota 504 root may include mailboxes the client has no access to. 506 Support for this resource MUST be indicated by the server by 507 advertising the CAPABILITY "QUOTA=RES-MAILBOXES". 509 6. Formal syntax 511 The following syntax specification uses the Augmented Backus-Naur 512 Form (ABNF) notation as specified in [ABNF]. 514 Non-terminals referenced but not defined below are as defined by 515 IMAP4 [RFC3501]. 517 Except as noted otherwise, all alphabetic characters are case- 518 insensitive. The use of upper or lower case characters to define 519 token strings is for editorial clarity only. Implementations MUST 520 accept these strings in a case-insensitive fashion. 522 getquota = "GETQUOTA" SP quota-root-name 524 getquotaroot = "GETQUOTAROOT" SP mailbox 526 quota-list = "(" quota-resource *(SP quota-resource) ")" 528 quota-resource = resource-name SP resource-usage SP resource- 529 limit 531 quota-response = "QUOTA" SP quota-root-name SP quota-list 533 quotaroot-response = "QUOTAROOT" SP mailbox *(SP quota-root-name) 535 setquota = "SETQUOTA" SP quota-root-name SP setquota-list 537 setquota-list = "(" [setquota-resource *(SP setquota-resource)] 538 ")" 540 setquota-resource = resource-name SP resource-limit 542 quota-root-name = astring 544 resource-limit = number 546 resource-name = "STORAGE" | "MESSAGE" | "MAILBOXES" | 547 resource-name-priv | resource-name-vnd | 548 resource-name-ext 550 resource-name-priv = "X-" atom 551 ;; Private use 553 resource-name-vnd = "V-" atom 554 ;; Vendor specific, must be registered with IANA 556 resource-name-ext = atom 557 ;; Not starting with either X- or V- and defined 558 ;; in a Standard Track or Experimental RFC 560 resource-names = "(" [resource-name *(SP resource-name)] ")" 562 resource-usage = number 563 ;; must be less than corresponding resource-limit 565 capability-quota = capa-quota-res 567 capa-quota-res = "QUOTA=RES-" resource-name 569 status-att =/ "DELETED-MESSAGES" | "DELETED-STORAGE" 571 [[anchor20: Should this be optional unless the 572 server implements MESSAGE/STORAGE?]] 574 resp-text-code =/ "OVERQUOTA" [SP tag] 576 7. Security Considerations 578 Implementors should be careful to make sure the implementation of 579 these commands does not violate the site's security policy. The 580 resource usage of other users is likely to be considered confidential 581 information and should not be divulged to unauthorized persons. 583 8. IANA Considerations 585 IMAP4 capabilities are registered by publishing a standards track or 586 IESG approved experimental RFC. The registry is currently located 587 at: 589 http://www.iana.org/assignments/imap4-capabilities 591 IANA is requested to update definition of the QUOTA extension to 592 point to this document. 594 [[anchor23: Define registry for "QUOTA=RES-" and add initial 595 registrations.]] 597 9. Acknowledgments 599 Authors of this document would like to thank the following people who 600 provided useful comments or participated in discussions that lead to 601 this update to RFC 2087: 602 John Myers, 603 Cyrus Daboo, 604 Lyndon Nerenberg 606 This document is a revision of RFC 2087. It borrows a lot of text 607 from RFC 2087. Thus work of the RFC 2087 author John Myers is 608 appreciated. 610 10. Changes since RFC 2087 612 This document is a revision of RFC 2087. It tries to clarify meaning 613 of different terms used by RFC 2087. It also provides more examples, 614 gives guidance on allowed server behaviour, defines IANA registry for 615 quota resource types and provides initial registrations for 3 of 616 them. 618 When compared with RFC 2087, this document defines one more commonly 619 used resource type, adds optional OVERQUOTA response code and defines 620 two extra STATUS data items ("DELETED-MESSAGES" and "DELETED- 621 STORAGE") 623 11. References 625 11.1. Normative References 627 [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for 628 Syntax Specifications: ABNF", RFC 4234, October 2005. 630 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 631 Requirement Levels", BCP 14, RFC 2119, March 1997. 633 [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 634 4rev1", RFC 3501, March 2003. 636 11.2. Informative References 638 [RFC2087] Myers, J., "IMAP4 QUOTA extension", RFC 2087, 639 January 1997. 641 Authors' Addresses 643 Dave A. Cridland 645 Email: dave@cridland.net 647 Alexey Melnikov 648 Isode Limited 650 Email: alexey.melnikov@isode.com 651 URI: http://www.isode.com 653 Full Copyright Statement 655 Copyright (C) The Internet Society (2006). 657 This document is subject to the rights, licenses and restrictions 658 contained in BCP 78, and except as set forth therein, the authors 659 retain all their rights. 661 This document and the information contained herein are provided on an 662 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 663 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 664 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 665 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 666 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 667 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 669 Intellectual Property 671 The IETF takes no position regarding the validity or scope of any 672 Intellectual Property Rights or other rights that might be claimed to 673 pertain to the implementation or use of the technology described in 674 this document or the extent to which any license under such rights 675 might or might not be available; nor does it represent that it has 676 made any independent effort to identify any such rights. Information 677 on the procedures with respect to rights in RFC documents can be 678 found in BCP 78 and BCP 79. 680 Copies of IPR disclosures made to the IETF Secretariat and any 681 assurances of licenses to be made available, or the result of an 682 attempt made to obtain a general license or permission for the use of 683 such proprietary rights by implementers or users of this 684 specification can be obtained from the IETF on-line IPR repository at 685 http://www.ietf.org/ipr. 687 The IETF invites any interested party to bring to its attention any 688 copyrights, patents or patent applications, or other proprietary 689 rights that may cover technology that may be required to implement 690 this standard. Please address the information to the IETF at 691 ietf-ipr@ietf.org. 693 Acknowledgment 695 Funding for the RFC Editor function is provided by the IETF 696 Administrative Support Activity (IASA).