idnits 2.17.1 draft-cridland-imap-quota-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 15 instances of lines with control characters in the document. ** The abstract seems to contain references ([2], [4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 == Line 501 has weird spacing: '...ate, in units...' -- 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. -- 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 (August 20, 2002) is 7919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2234 (ref. '1') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2060 (ref. '2') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2086 (ref. '3') (Obsoleted by RFC 4314) ** Obsolete normative reference: RFC 2087 (ref. '4') (Obsoleted by RFC 9208) Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Cridland 3 Internet-Draft Clues 4 Expires: February 18, 2003 A. Melnikov 5 ACI 6 August 20, 2002 8 IMAP4rev1 QUOTA Extension 9 draft-cridland-imap-quota-00 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at http:// 27 www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on February 18, 2003. 34 Copyright Notice 36 Copyright (C) The Internet Society (2002). All Rights Reserved. 38 Abstract 40 The QUOTA extension of the Internet Message Access Protocol IMAP4 [2] 41 permits administrative limits on resource usage (quotas) to be 42 manipulated through the IMAP protocol. 44 This memo replaces RFC2087 [4], but attempts to remain backwards 45 compatible whenever possible. 47 1. Document Conventions 49 In protocol examples, this document uses a prefix of "C: " to denote 50 lines sent by the client to the server, and "S: " for lines sent by 51 the server to the client. Lines prefixed with "// " are comments 52 explaining the previous protocol line. These prefixes and comments 53 are not part of the protocol. Lines without any of these prefixes 54 are continuations of the previous line, and no line break is present 55 in the protocol unless specifically mentioned. 57 Again, for examples, the hierarchy separator on the server is 58 presumed to be "/" throughout. None of these assumptions is required 59 nor recommended by this memo. 61 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 62 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 63 document are to be interpreted as described in RFC2119 [5]. 65 Other capitalised words are IMAP4 [2] keywords or keywords from this 66 document. 68 2. Introduction and Overview 70 The QUOTA extension is present in any IMAP4rev1 server which 71 advertises any CAPABILITY beginning with "QUOTA=". 73 The capability "QUOTA", with no "=", denotes a RFC2087 [4] compliant 74 server. Some commands and responses are not present in such servers, 75 and clients MUST NOT rely on their presence in the absence of any 76 capability beginning "QUOTA=". 78 Quotas can be used to restrict clients for administrative reasons, 79 but the QUOTA extension can also be used to indicate system limits 80 and current usage levels to clients. 82 Although RFC2087 [4] specified an IMAP4 QUOTA extension, and this has 83 seen deployment in servers, it has seen little deployment in clients. 84 Since the meaning of the resources was left implementation-dependant, 85 it was impossible for a client implementation to determine which 86 resources were supported, and impossible to determine which mailboxes 87 were in a given quota root, without a priori knowledge of the 88 implementation. 90 3. Terms 92 3.1 Resource 94 A resource has a name, a formal definition. 96 3.1.1 Name 98 The resource name is an atom, as defined in IMAP4 [2]. These MUST be 99 registered with IANA, or begin with "X-", which indicates an 100 experimental resource. Implementation specific resources MUST be 101 registered with IANA, and begin with "V-". 103 Supported resource names MUST be advertised as a capability, by 104 prepending the resource name with "QUOTA=RES-". Server is not 105 required to support all reported resource types on all quota roots. 107 3.1.2 Definition 109 The resource definition or document containing it, while not visible 110 through the protocol, SHOULD be registered with IANA. 112 The usage of a resource MUST be represented as a 32 bit unsigned 113 integer. 0 indicates no usage of a resource. Usage integers MUST 114 NOT represent proportional use, such that a client can compare 115 available resource between two separate quota roots or servers with 116 reasonable accuracy. 118 Limits will be specified as, and MUST be represented as, an integer. 119 0 indicates that any usage is prohibited. 121 Limits may be hard or soft - that is, an implementation MAY choose, 122 or be configured, to disallow any command if the limit on a resource 123 is or would be exceeded. 125 All resources which the server handles must be advertised in a 126 CAPABILITY constisting of the resource name prefixed by "QUOTA=RES-". 127 For compatability with RFC2087 [4], a client which discovers 128 resources available on the server which are not advertised through 129 this mechanism MUST treat the resource as if it were completely 130 opaque, and without any meaning. 132 The resources STORAGE (Section 5.1), MESSAGES (Section 5.2) and 133 MAILBOXES (Section 5.3) are defined in this memo. 135 3.2 Quota Root 137 Each mailbox has zero or more implementation-defined named "quota 138 roots". Each quota root has zero or more resource limits (quotas). 139 All mailboxes that share the same named quota root share the resource 140 limits of the quota root. 142 Quota root names need not be mailbox names, nor is there any 143 relationship defined by this memo between a Quota root name and a 144 mailbox name. A quota root name is an astring, as defined in IMAP4 145 [2]. It MUST be treated as an opaque string by any clients which do 146 not have a priori knowledge of the server implementation. 148 Quota roots are used since not all implementations may be able to 149 calculate usage, or apply quotas, on arbitary mailboxes or mailbox 150 hierarchies. A client might be able to determine how a quota root 151 relates to the mailboxes it governs by looking at any mapping which 152 MAY be given in a QUOTAMAP (Section 4.2.3) response. 154 Not all resources may be limitable or calculatable for all quota 155 roots. Further, not all resources may support all limits - some 156 limits may be present in the underlying system. A server 157 implementation of this memo SHOULD advise the client of such inherent 158 limits, by generating QUOTA (Section 4.2.1) responses and SHOULD 159 advise the client of which resources are limitable for a particular 160 quota root. A SETQUOTA (Section 4.1.3) command MAY also round a 161 quota limit in an implementation dependant way, if the granularity of 162 the underlying system demands it. A client MUST be prepared for a 163 SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. 165 Implementation Notes 167 This means that, for example under UNIX, a quota root may have a 168 MESSAGES (Section 5.2) quota always set due to the number of inodes 169 available on the filesystem, and similarly STORAGE (Section 5.1) may 170 be rounded to the nearest block and limited by free filesystem space. 172 4. Definitions 174 4.1 Commands 176 The following commands exist for manipulation and querying quotas. 178 4.1.1 GETQUOTA 180 Arguments: quota root 182 Responses: REQUIRED untagged responses: QUOTA 183 OPTIONAL untagged response: SUPPORTEDQUOTARES 185 Result: OK - getquota completed 186 NO - getquota error: no such quota root, permission denied 187 BAD - command unknown or arguments invalid 189 The GETQUOTA command takes the name of a quota root and returns the 190 quota root's resource usage and limits in an untagged QUOTA response. 191 GETQUOTA command MAY also return an untagged SUPPORTEDQUOTARES 192 response that lists all resource types that can be set on the quota 193 root. If the SUPPORTEDQUOTARES response is not returned by the 194 server, this means that all resource types returned in CAPABILITY 195 response (i.e. all capability items with "QUOTA=RES-" prefix) are 196 applicable to the quota root. 198 Example: 200 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] 201 [...] 202 C: G0001 GETQUOTA "!partition/sda4" 203 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 204 S: * SUPPORTEDQUOTARES "!partition/sda4" STORAGE 205 S: G0001 OK Getquota complete 207 4.1.2 GETQUOTAROOT 209 Arguments: mailbox name 211 Responses: REQUIRED untagged responses: QUOTAROOT, QUOTA 213 OPTIONAL untagged responses: QUOTAMAP 215 Result: OK - getquotaroot completed 216 NO - getquotaroot error: no such mailbox, permission denied 217 BAD - command unknown or arguments invalid 219 The GETQUOTAROOT command takes the name of a mailbox and returns the 220 list of quota roots for the mailbox in an untagged QUOTAROOT 221 response. For each listed quota root, it also returns the quota 222 root's resource usage and limits in an untagged QUOTA response and 223 MAY return an untagged QUOTAMAP response that describes a 224 relationship between the quota root and the mailbox (mapping). 226 //Should we remove some information from QUOTAMAP as it is already 227 returned in QUOTAROOT? 229 Example: 231 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGES 232 [...] 233 [...] 234 C: G0002 GETQUOTAROOT INBOX 235 S: * QUOTAROOT INBOX "#user/alice" "!partition/sda4" 236 S: * QUOTAMAP "#user/alice" INBOX (USER) 237 S: * QUOTAMAP "!partition/sda4" INBOX () 238 S: * QUOTA "#user/alice" (MESSAGES 42 1000) 239 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 240 S: G0002 OK Getquotaroot complete 242 4.1.3 SETQUOTA 244 Arguments: quota root 246 list of resource limits 248 Responses: untagged responses: QUOTA 250 Result: OK - setquota completed 251 NO - setquota error: can't set that data 252 BAD - command unknown or arguments invalid 254 The SETQUOTA command takes the name of a mailbox quota root and a 255 list of resource limits. The resource limits for the named quota 256 root are changed to be the specified limits. Any previous resource 257 limits for the named quota root are discarded. 259 If the named quota root did not previously exist, an implementation 260 may optionally create it and change the quota roots for any number of 261 existing mailboxes in an implementation-defined manner. 263 // Should we be sending untagged QUOTA responses for all side effect 264 changes? 265 // Quota root name must uniquely identifier mapping [if any] 266 (different mapping must have non overlapping namespaces) 268 Example: 270 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGES 271 [...] 272 [...] 273 C: S0000 GETQUOTA "#user/alice" 274 S: * QUOTA "#user/alice" (STORAGE 54 111 MESSAGES 42 1000) 275 S: S0000 OK Getquota completed 276 C: S0001 SETQUOTA "#user/alice" (STORAGE 510) 277 S: * QUOTA "#user/alice" (STORAGE 58 512) 279 // The server has rounded the STORAGE quota limit requested to the 280 nearest 512 blocks of 1024 octects, or else another client has 281 performed a near simultaneous SETQUOTA, using a limit of 512. 283 S: S0001 OK Rounded quota 284 C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) 285 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 287 // The server has not changed the quota, since this is a 288 filesystem limit, and cannot be changed. The QUOTA response here 289 is entirely optional. 291 S: S0002 NO Cannot change system limit 293 4.1.4 DELQUOTA 295 Arguments: quota root 297 resource name 299 Responses: no specific responses for this command 301 Result: OK - delquota completed 302 NO - delquota error: can't delete that data 303 BAD - command unknown or arguments invalid 305 The DELQUOTA command takes the name of a mailbox quota root and a 306 resource name. The resource limit associated with the resource name 307 is removed (or reset to the underlying system limit), or other 308 resources associated with the same quote root are unaffected. (This 309 command is different from "SETQUOTA ( 310 0)", because the latter discards all resources associated with the 311 quota root). 313 An implementation may optionally change the quota roots for any 314 number of existing mailboxes in an implementation-defined manner. 316 // Should we be sending untagged QUOTA responses for all side effect 317 changes? 319 Example: 321 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGES 322 [...] 323 [...] 324 C: S0001 DELQUOTA "#user/alice" STORAGE 325 S: * QUOTA "#user/alice" (MESSAGES 42 1000) 326 S: S0001 OK STORAGE limit removed. 327 C: S0002 DELQUOTA "!partition/sda4" STORAGE 328 S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) 330 // The server has not changed the quota, since this is a 331 filesystem limit, and cannot be changed. The QUOTA response here 332 is entirely optional. 334 S: S0002 NO Cannot remove system limit 336 4.1.5 LISTQUOTA 338 Arguments: quota root 340 OPTIONAL untagged responses: QUOTAMAP 342 Result: OK - listquota completed 343 NO - listquota error: no such quota root, permission denied 344 BAD - command unknown or arguments invalid 346 The LISTQUOTA command takes the name of a quota root and returns 347 QUOTAMAP responses for all mailboxes accessible to the user that are 348 governed by this quota root 350 //Client should be prepared to receive a lot of traffic, because this 351 might be equivalent to performing 353 Example: 355 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGES 356 [...] 357 [...] 358 C: L0001 LISTQUOTA "#user/alice" 359 S: * QUOTAMAP "#user/alice" INBOX (USER) 360 S: * QUOTAMAP "#user/alice" "Drafts" (USER) 361 S: * QUOTAMAP "#user/alice" "Work/Meetings" (USER) 362 S: * QUOTAMAP "#user/alice" "Work/Projects" (USER) 363 S: L0001 OK 365 4.1.6 STATUS attribute RECOVERABLE 367 DELETED-MESSAGES and DELETED-STORAGE status data items allow to 368 estimate the amount of resource freed by an EXPUNGE on a mailbox. 370 DELETED-MESSAGES status data item requests the server to return the 371 number of messages with \Deleted flag set. 373 //DELETED-STORAGE - Is it the sum of RFC822.SIZEs or "How match we 374 can recover" (depending on messages with \Deleted flag it may be 375 different) 377 Example: 379 S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA-RES-MESSAGES 380 [...] 381 [...] 382 C: S0003 STATUS INBOX (MESSAGES DELETED-MESSAGES DELETED-STORAGE) 383 S: * STATUS INBOX (MESSAGES 12 DELETED-MESSAGES 4 DELETED-STORAGE 384 8) 386 // 12 messages, 4 of which would be deleted when an EXPUNGE 387 happens. 389 S: S0003 OK Status complete. 391 4.2 Responses 393 The following responses may be sent by the server. 395 4.2.1 QUOTA 397 Data: quota root name 398 list of resource names, usages, and limits 400 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 401 command. The first string is the name of the quota root for which 402 this quota applies. 404 The name is followed by a S-expression format list of the resource 405 usage and limits of the quota root. The list contains zero or more 406 triplets. Each triplet contains a resource name, the current usage 407 of the resource, and the resource limit. 409 Resources not named in the list are not limited in the quota root. 410 Thus, an empty list means there are no administrative resource limits 411 in the quota root. 413 Example: S: * QUOTA "" (STORAGE 10 512): 415 4.2.2 QUOTAROOT 417 Data: mailbox name 418 zero or more quota root names 420 This response occurs as a result of a GETQUOTAROOT command. The 421 first string is the mailbox and the remaining strings are the names 422 of the quota roots for the mailbox. 424 Example: 426 S: * QUOTAROOT INBOX "" 428 S: * QUOTAROOT comp.mail.mime 430 4.2.3 QUOTAMAP 432 Data: quota root name 433 mailbox name 434 OPTIONAL mapping name 436 This response occurs as a result of a GETQUOTAROOT or LISTQUOTA 437 command. It defines the relationship (mapping) between the quota 438 root and the mailbox. 440 4.2.4 SUPPORTEDQUOTARES 442 Data: quota root name 443 zero or more resource names 445 SUPPORTEDQUOTARES response occurs as a result of GETQUOTA command. 446 It lists all resource types that can be set on the quota root. If 447 the list of resources is missing (not empty!) this means that the 448 server can't list supported resources and the client must try 449 SETQUOTA. Note that SUPPORTEDQUOTARES with no resource name is 450 different from the absent SUPPORTEDQUOTARES response. If the 451 SUPPORTEDQUOTARES response is not returned by the server, this means 452 that all resource types returned in CAPABILITY response (i.e. all 453 capability items with "QUOTA=RES-" prefix) are applicable to the 454 quota root. 456 4.3 Response Codes 458 4.3.1 OVERQUOTA 460 OVERQUOTA response code is returned in NO tagged response to an 461 APPEND/COPY when the addition of the message(s) puts mailbox over any 462 one of its quota limits. 464 Example: 466 S: C: A003 APPEND Drafts (\Seen $MDNSent) {310} 467 S: + Ready for literal data 468 C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) 469 C: From: Fred Foobar 470 C: Subject: afternoon meeting 471 C: To: mooch@owatagu.siam.edu 472 C: Message-Id: 473 C: MIME-Version: 1.0 474 C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII 475 C: 476 C: Hello Joe, do you think we can meet at 3:30 tomorrow? 477 C: 478 S: A003 NO [OVERQUOTA] APPEND Failed 480 4.4 Interaction with the ACL and ACL2 extensions 482 Both the ACL [3] and ACL2 extensions define access control lists, and 483 specific permissions which are required for certain actions. 485 // But how do they interact? Presumably, QUOTAMAP responses 486 containing mailboxes which cannot be LISTed shouldn't be generated. 487 Quota Roots which govern no mailboxes to which the client has write 488 access should also, presumably, be hidden from the client's view? 489 Administration rights to set quotas? 491 5. Resource Definitions 493 The following resources are defined in this memo. A server 494 supporting a resource MUST advertise this as a CAPABILITY with a name 495 consisting of the resource name prefixed by "QUOTA=RES-". A server 496 MAY support mupltiple resource types, and MUST advertise all 497 resources it supports. 499 5.1 STORAGE 501 The physical space estimate, in units of 1024 octets, of the 502 mailboxes governed by the quota root. This MAY not be the same as 503 the sum of the RFC822.SIZE of the messages. Some implementations MAY 504 include metadata sizes for the messages and mailboxes, other 505 implementations MAY store messages in such a way that the physical 506 space used is smaller. Additional messages MAY NOT increase the 507 usage. Client MUST NOT use the usage figure for anything other than 508 informational purposes, for example, they MUST NOT refuse to APPEND a 509 message if the limit less the usage is smaller than the RFC822.SIZE 510 divided by 1024 of the message. 512 The usage figure may change as a result of performing actions not 513 associated with adding new messages to the mailbox, such as SEARCH, 514 since this may increase the amount of metadata included in the 515 calculations. 517 Support for this resource MUST be indicated by the server by 518 advertising the CAPABILITY "QUOTA=RES-STORAGE". 520 A resource named the same was also given as an example in RFC2087 521 [4], clients conformant to this specification connecting to servers 522 which do not advertise "QUOTA=RES-STORAGE", yet allow a resource 523 named STORAGE, MUST NOT assume that it is the same resource. 525 5.2 MESSAGES 527 The number of messages stored within the mailboxes governed by the 528 quota root. This MUST be an exact number, however, clients MUST NOT 529 assume that a change in the usage indicates a change in the number of 530 messages available, since the quota root may include mailboxes the 531 client has no access to. 533 Support for this resource MUST be indicated by the server by 534 advertising the CAPABILITY "QUOTA=RES-MESSAGES". 536 A resource named the same was also given as an example in RFC2087 537 [4], clients conformant to this specification connecting to servers 538 which do not advertise "QUOTA=RES-MESSAGES", yet allow a resource 539 named MESSAGES, MUST NOT assume that it is the same resource. 541 5.3 MAILBOXES 543 The number of mailboxes governed by the quota root. This MUST be an 544 exact number, however, clients MUST NOT assume that a change in the 545 usage indicates a change in the number of mailboxes, since the quota 546 root may include mailboxes the client has no access to. 548 Support for this resource MUST be indicated by the server by 549 advertising the CAPABILITY "QUOTA=RES-MAILBOXES". 551 6. Quota Root Relationship Definitions 553 Where a specific quota root relationship, or mapping, is given in a 554 QUOTAMAP response, a client MAY make certain assumptions about which 555 Quota Root, and therefore which Quota, will govern an existing or 556 newly created mailbox, without having to use LISTQUOTAROOT after 557 creation. 559 Implementations MAY provide no mapping information at all, either for 560 security reasons or because the mapping actually used does not fit 561 one of the defined mappings. 563 Relationship names are atoms, as defined in IMAP4 [2], and must be 564 registered at IANA. Relationships which are implementation specific 565 are of limited use for interoperability, however they MUST be 566 registered and prefixed with "V-", along with the meaning of any 567 parameters they list. 569 The mapping applicable to a particular quota root and mailbox is 570 given in the QUOTAMAP (Section 4.2.3) response. 572 6.1 HIER 574 The quota root in question applies to all inferior mailboxes of the 575 named mailbox, and a newly created inferior mailbox will be governed 576 by the same quota root. 578 6.2 SINGLE 580 The quota root in question applies only to the named mailbox, and to 581 no other. This is mutually exclusive with HIER mappings. 583 6.3 USER 585 The quota root in question applies to all mailboxes owned by the same 586 user. The definition of ownership is implementation dependant. 588 // Do we restrict this to the currently logged in user? 590 6.4 DOMAIN 592 The quota root in question applies to all mailboxes in the current 593 domain on at least this server. If the server doesn't support 594 multiple domains, GLOBAL MUST be used instead. 596 6.5 GLOBAL 598 The quota root in question applies to all mailboxes on at least this 599 server. 601 7. Formal syntax 603 The following syntax specification uses the Augmented Backus-Naur 604 Form (ABNF) notation as specified in ABNF [1]. 606 Non-terminals referenced but not defined below are as defined by 607 IMAP4 [2]. 609 Except as noted otherwise, all alphabetic characters are case- 610 insensitive. The use of upper or lower case characters to define 611 token strings is for editorial clarity only. Implementations MUST 612 accept these strings in a case-insensitive fashion. 614 getquota = "GETQUOTA" SP quota_root_name 616 getquotaroot = "GETQUOTAROOT" SP mailbox 618 quota_list = "(" quota_resource *(SP quota_resource) ")" 620 quota_resource = resource_name SP resource_usage SP 621 resource_limit 623 quota_response = "QUOTA" SP quota_root_name SP quota_list 625 quotaroot_response = "QUOTAROOT" SP mailbox *(SP quota_root_name) 627 setquota = "SETQUOTA" SP quota_root_name SP setquota_list 629 setquota_list = "(" [setquota_resource *(SP setquota_resource)] 630 ")" 632 setquota_resource = resource_name SP resource_limit 634 quota_root_name = astring 636 resource_limit = number 638 resource_name = "STORAGE" | "MESSAGES" | "MAILBOXES" | 639 resource_name_priv | resource_name_vnd | resource_name_ext 641 resource_name_priv = "X-" atom 642 ;; Private use 644 resource_name_vnd = "V-" atom 645 ;; Vendor specific, must be registered with IANA 647 resource_name_ext = atom 648 ;; Not starting with either X- or V- and defined 649 ;; in a Standard Track or Experimental RFC 651 resource_names = "(" [resource_name *(SP resource_name)] ")" 653 resource_usage = number 654 ;; must be less than corresponding resource_limit 656 quotamap_response = "QUOTAMAP" SP quota_root_name SP mailbox SP "(" 657 [mapping] ")" 659 suppres_response = "SUPPORTEDQUOTARES" SP quota_root_name [SP 660 resource_names] 662 mapping = "HIER" | "SINGLE" | "USER" | "DOMAIN" | 663 "GLOBAL" | mapping_vendor | mapping_ext 665 mapping_vendor = "V-" atom 666 ;; Vendor specific, must be registered with IANA 668 mapping_ext = atom 669 ;; Must be defined by an Experimental or a Standard Track RFC 671 delquota = "DELQUOTA" SP quota_root_name SP resource_name 673 capability_quota = capa_quota_res | capa_quota_mapping 675 capa_quota_res = "QUOTA=RES-" resource_name 677 capa_quota_mapping? 679 listquota = "LISTQUOTA" SP quota_root_name 681 status-att =/ "DELETED-MESSAGES" | "DELETED-STORAGE" 683 //Should this be optional unless the server implements MESSAGES/ 684 STORAGE? 686 resp-text-code =/ "OVERQUOTA" 688 References 690 [1] Crocker, D. and P. Overell, "Augmented BNF for Syntax 691 Specifications: ABNF", RFC 2234, November 1997. 693 [2] Crispin, M., "Internet Message Access Protocol - Version 4rev1", 694 RFC 2060, December 1996. 696 [3] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997. 698 [4] Myers, J., "IMAP4 QUOTA extension", RFC 2087, January 1997. 700 [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement 701 Levels", BCP 14, RFC 2119, March 1997. 703 Authors' Addresses 705 Dave A. Cridland 706 Clues Ltd 708 EMail: dave.cridland@clues.ltd.uk 709 URI: http://www.clues.ltd.uk/ 711 Alexey Melnikov 712 ACI WorldWide / MessagingDirect 714 EMail: mel@messagingdirect.com 715 URI: http://orthanc.ab.ca/mel/ 717 Full Copyright Statement 719 Copyright (C) The Internet Society (2002). All Rights Reserved. 721 This document and translations of it may be copied and furnished to 722 others, and derivative works that comment on or otherwise explain it 723 or assist in its implementation may be prepared, copied, published 724 and distributed, in whole or in part, without restriction of any 725 kind, provided that the above copyright notice and this paragraph are 726 included on all such copies and derivative works. However, this 727 document itself may not be modified in any way, such as by removing 728 the copyright notice or references to the Internet Society or other 729 Internet organizations, except as needed for the purpose of 730 developing Internet standards in which case the procedures for 731 copyrights defined in the Internet Standards process must be 732 followed, or as required to translate it into languages other than 733 English. 735 The limited permissions granted above are perpetual and will not be 736 revoked by the Internet Society or its successors or assigns. 738 This document and the information contained herein is provided on an 739 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 740 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 741 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 742 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 743 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 745 Acknowledgement 747 Funding for the RFC Editor function is currently provided by the 748 Internet Society.