| < draft-ietf-extra-quota-06.txt | draft-ietf-extra-quota-10.txt > | |||
|---|---|---|---|---|
| Network Working Group A. Melnikov | Network Working Group A. Melnikov | |||
| Internet-Draft Isode | Internet-Draft Isode | |||
| Obsoletes: 2087 (if approved) 27 August 2021 | Obsoletes: 2087 (if approved) 18 November 2021 | |||
| Intended status: Standards Track | Intended status: Standards Track | |||
| Expires: 28 February 2022 | Expires: 22 May 2022 | |||
| IMAP QUOTA Extension | IMAP QUOTA Extension | |||
| draft-ietf-extra-quota-06 | draft-ietf-extra-quota-10 | |||
| Abstract | Abstract | |||
| The QUOTA extension of the Internet Message Access Protocol (RFC | This document defines a QUOTA extension of the Internet Message | |||
| 3501/RFC 9051) permits administrative limits on resource usage | Access Protocol (RFC 3501/RFC 9051) that permits administrative | |||
| (quotas) to be manipulated through the IMAP protocol. | limits on resource usage (quotas) to be manipulated through the IMAP | |||
| protocol. | ||||
| This document obsoletes RFC 2087, but attempts to remain backwards | This document obsoletes RFC 2087, but attempts to remain backwards | |||
| compatible whenever possible. | compatible whenever possible. | |||
| Status of This Memo | Status of This Memo | |||
| This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
| provisions of BCP 78 and BCP 79. | provisions of BCP 78 and BCP 79. | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on 28 February 2022. | This Internet-Draft will expire on 22 May 2022. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2021 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents (https://trustee.ietf.org/ | Provisions Relating to IETF Documents (https://trustee.ietf.org/ | |||
| license-info) in effect on the date of publication of this document. | license-info) in effect on the date of publication of this document. | |||
| Please review these documents carefully, as they describe your rights | Please review these documents carefully, as they describe your rights | |||
| skipping to change at page 2, line 38 ¶ | skipping to change at page 2, line 38 ¶ | |||
| 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 | 1. Document Conventions . . . . . . . . . . . . . . . . . . . . 3 | |||
| 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 | 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 3 | |||
| 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1. Resource . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 | 3.1.1. Name . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 | 3.1.2. Definition . . . . . . . . . . . . . . . . . . . . . 4 | |||
| 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 | 3.2. Quota Root . . . . . . . . . . . . . . . . . . . . . . . 5 | |||
| 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1. Commands . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 | 4.1.1. GETQUOTA . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 6 | 4.1.2. GETQUOTAROOT . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 | 4.1.3. SETQUOTA . . . . . . . . . . . . . . . . . . . . . . 7 | |||
| 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 | 4.1.4. New STATUS attributes . . . . . . . . . . . . . . . . 9 | |||
| 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2. Responses . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 9 | 4.2.1. QUOTA . . . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 | 4.2.2. QUOTAROOT . . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 | 4.3. Response Codes . . . . . . . . . . . . . . . . . . . . . 10 | |||
| 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 10 | 4.3.1. OVERQUOTA . . . . . . . . . . . . . . . . . . . . . . 11 | |||
| 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 | 5. Resource Type Definitions . . . . . . . . . . . . . . . . . . 12 | |||
| 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.1. STORAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 | |||
| 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 12 | 5.2. MESSAGE . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 5.3. MAILBOX . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
| 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 | 5.4. ANNOTATION-STORAGE . . . . . . . . . . . . . . . . . . . 13 | |||
| 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 13 | 6. Interaction with IMAP ACL extension (RFC 4314) . . . . . . . 14 | |||
| 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 | 7. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 | |||
| 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 | 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 | |||
| 9.1. Changes/additions to the IMAP4 capabilities registry . . 16 | 9.1. Changes/additions to the IMAP4 capabilities registry . . 17 | |||
| 9.2. IMAP quota resource type registry . . . . . . . . . . . . 16 | 9.2. IMAP quota resource type registry . . . . . . . . . . . . 17 | |||
| 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 17 | 9.3. Registrations of IMAP Quota Resource Types . . . . . . . 18 | |||
| 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 | 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 | 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 19 | 12. Changes since RFC 2087 . . . . . . . . . . . . . . . . . . . 20 | |||
| 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 13.1. Normative References . . . . . . . . . . . . . . . . . . 19 | 13.1. Normative References . . . . . . . . . . . . . . . . . . 20 | |||
| 13.2. Informative References . . . . . . . . . . . . . . . . . 20 | 13.2. Informative References . . . . . . . . . . . . . . . . . 21 | |||
| Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
| 1. Document Conventions | 1. Document Conventions | |||
| In protocol examples, this document uses a prefix of "C: " to denote | In protocol examples, this document uses a prefix of "C: " to denote | |||
| lines sent by the client to the server, and "S: " for lines sent by | lines sent by the client to the server, and "S: " for lines sent by | |||
| the server to the client. Lines prefixed with "// " are comments | the server to the client. Lines prefixed with "// " are comments | |||
| explaining the previous protocol line. These prefixes and comments | explaining the previous protocol line. These prefixes and comments | |||
| are not part of the protocol. Lines without any of these prefixes | are not part of the protocol. Lines without any of these prefixes | |||
| are continuations of the previous line, and no line break is present | are continuations of the previous line, and no line break is present | |||
| in the protocol unless specifically mentioned. | in the protocol before such lines unless specifically mentioned. | |||
| Again, for examples, the hierarchy separator on the IMAP server is | ||||
| presumed to be "/" throughout. None of these assumptions is required | ||||
| nor recommended by this document. | ||||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in BCP | "OPTIONAL" in this document are to be interpreted as described in BCP | |||
| 14 [RFC2119] [RFC8174] when, and only when, they appear in all | 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| Other capitalised words are IMAP keywords [RFC3501][RFC9051] or | Other capitalised words are IMAP keywords [RFC3501][RFC9051] or | |||
| keywords from this document. | keywords from this document. | |||
| 2. Introduction and Overview | 2. Introduction and Overview | |||
| This document defines a couple of extension to the Internet Message | This document defines a couple of extensions to the Internet Message | |||
| Access Protocol [RFC3501] for querying and manipulating | Access Protocol [RFC3501] for querying and manipulating | |||
| administrative limits on resource usage (quotas). This extension is | administrative limits on resource usage (quotas). This extension is | |||
| compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. | compatible with both IMAP4rev1 [RFC3501] and IMAP4rev2 [RFC9051]. | |||
| The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. | The capability "QUOTA", denotes a RFC2087 [RFC2087] compliant server. | |||
| Some responses and response codes defined in this document are not | Some responses and response codes defined in this document are not | |||
| present in such servers (see Section 12 for more details), and | present in such servers (see Section 12 for more details), and | |||
| clients MUST NOT rely on their presence in the absence of any | clients MUST NOT rely on their presence in the absence of any | |||
| capability beginning with "QUOTA=". | capability beginning with "QUOTA=". | |||
| skipping to change at page 4, line 24 ¶ | skipping to change at page 4, line 20 ¶ | |||
| "QUOTA=" prefix for future IETF stream standard track, informational | "QUOTA=" prefix for future IETF stream standard track, informational | |||
| or experimental extensions to this document. | or experimental extensions to this document. | |||
| Quotas can be used to restrict clients for administrative reasons, | Quotas can be used to restrict clients for administrative reasons, | |||
| but the QUOTA extension can also be used to indicate system limits | but the QUOTA extension can also be used to indicate system limits | |||
| and current usage levels to clients. | and current usage levels to clients. | |||
| Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and | Although RFC2087 [RFC2087] specified an IMAP4 QUOTA extension, and | |||
| this has seen deployment in servers, it has seen little deployment in | this has seen deployment in servers, it has seen little deployment in | |||
| clients. Since the meaning of the resources was left implementation- | clients. Since the meaning of the resources was left implementation- | |||
| dependant, it was impossible for a client implementation to determine | dependent, it was impossible for a client implementation to determine | |||
| which resources were supported, and impossible to determine which | which resources were supported, and impossible to determine which | |||
| mailboxes were in a given quota root (see Section 3.2), without a | mailboxes were in a given quota root (see Section 3.2), without a | |||
| priori knowledge of the implementation. | priori knowledge of the implementation. | |||
| 3. Terms | 3. Terms | |||
| 3.1. Resource | 3.1. Resource | |||
| A resource has a name, a formal definition. | A resource has a name, a formal definition. | |||
| 3.1.1. Name | 3.1.1. Name | |||
| The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. | The resource name is an atom, as defined in IMAP4rev1 [RFC3501]. | |||
| These MUST be registered with IANA. Implementation specific | These MUST be registered with IANA. | |||
| resources begin with "V-" . | ||||
| Supported resource names MUST be advertised as a capability, by | Supported resource names MUST be advertised as a capability, by | |||
| prepending the resource name with "QUOTA=RES-". A server compliant | prepending the resource name with "QUOTA=RES-". A server compliant | |||
| with this specification is not required to support all reported | with this specification is not required to support all reported | |||
| resource types on all quota roots. | resource types on all quota roots. | |||
| 3.1.2. Definition | 3.1.2. Definition | |||
| The resource definition or document containing it, while not visible | The resource definition or document containing it, while not visible | |||
| through the protocol, SHOULD be registered with IANA. | through the protocol, SHOULD be registered with IANA. | |||
| skipping to change at page 5, line 28 ¶ | skipping to change at page 5, line 22 ¶ | |||
| All resources which the server handles MUST be advertised in a | All resources which the server handles MUST be advertised in a | |||
| CAPABILITY response/response code consisting of the resource name | CAPABILITY response/response code consisting of the resource name | |||
| prefixed by "QUOTA=RES-". | prefixed by "QUOTA=RES-". | |||
| The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX | The resources STORAGE (Section 5.1), MESSAGE (Section 5.2), MAILBOX | |||
| (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in | (Section 5.3) and ANNOTATION-STORAGE (Section 5.4) are defined in | |||
| this document. | this document. | |||
| 3.2. Quota Root | 3.2. Quota Root | |||
| This document introduces a concept of a "quota root", as resource | ||||
| limits can apply across multiple IMAP mailboxes. | ||||
| Each mailbox has zero or more implementation-defined named "quota | Each mailbox has zero or more implementation-defined named "quota | |||
| roots". Each quota root has zero or more resource limits (quotas). | roots". Each quota root has zero or more resource limits (quotas). | |||
| All mailboxes that share the same named quota root share the resource | All mailboxes that share the same named quota root share the resource | |||
| limits of the quota root. | limits of the quota root. | |||
| Quota root names need not be mailbox names, nor is there any | Quota root names need not be mailbox names, nor is there any | |||
| relationship defined by this document between a quota root name and a | relationship defined by this document between a quota root name and a | |||
| mailbox name. A quota root name is an astring, as defined in IMAP4 | mailbox name. A quota root name is an astring, as defined in IMAP4 | |||
| [RFC3501]. It SHOULD be treated as an opaque string by any clients. | [RFC3501]. It SHOULD be treated as an opaque string by any clients. | |||
| Quota roots are used since not all implementations may be able to | Quota roots are used since not all implementations may be able to | |||
| calculate usage, or apply quotas, on arbitary mailboxes or mailbox | calculate usage, or apply quotas, on arbitrary mailboxes or mailbox | |||
| hierarchies. | hierarchies. | |||
| Not all resources may be limitable or calculatable for all quota | Not all resources may be limitable or calculable for all quota roots. | |||
| roots. Further, not all resources may support all limits - some | Further, not all resources may support all limits - some limits may | |||
| limits may be present in the underlying system. A server | be present in the underlying system. A server implementation of this | |||
| implementation of this memo SHOULD advise the client of such inherent | memo SHOULD advise the client of such inherent limits, by generating | |||
| limits, by generating QUOTA (Section 4.2.1) responses and SHOULD | QUOTA (Section 4.2.1) responses, and SHOULD advise the client of | |||
| advise the client of which resources are limitable for a particular | which resources are limitable for a particular quota root. A | |||
| quota root. A SETQUOTA (Section 4.1.3) command MAY also round a | SETQUOTA (Section 4.1.3) command MAY also round a quota limit in an | |||
| quota limit in an implementation dependant way, if the granularity of | implementation-dependent way, if the granularity of the underlying | |||
| the underlying system demands it. A client MUST be prepared for a | system demands it. A client MUST be prepared for a SETQUOTA | |||
| SETQUOTA (Section 4.1.3) command to fail if a limit cannot be set. | (Section 4.1.3) command to fail if a limit cannot be set. | |||
| Implementation Notes: This means that, for example under UNIX, a | Implementation Notes: This means that, for example under UNIX, a | |||
| quota root may have a MESSAGE (Section 5.2) quota always set due to | quota root may have a MESSAGE (Section 5.2) quota always set due to | |||
| the number of inodes available on the filesystem, and similarly | the number of inodes available on the filesystem, and similarly | |||
| STORAGE (Section 5.1) may be rounded to the nearest block and limited | STORAGE (Section 5.1) may be rounded to the nearest block and limited | |||
| by free filesystem space. | by free filesystem space. | |||
| 4. Definitions | 4. Definitions | |||
| 4.1. Commands | 4.1. Commands | |||
| skipping to change at page 6, line 31 ¶ | skipping to change at page 6, line 31 ¶ | |||
| Responses: REQUIRED untagged responses: QUOTA | Responses: REQUIRED untagged responses: QUOTA | |||
| Result: OK - getquota completed | Result: OK - getquota completed | |||
| NO - getquota error: no such quota root, permission denied | NO - getquota error: no such quota root, permission denied | |||
| BAD - command unknown or arguments invalid | BAD - command unknown or arguments invalid | |||
| The GETQUOTA command takes the name of a quota root and returns the | The GETQUOTA command takes the name of a quota root and returns the | |||
| quota root's resource usage and limits in an untagged QUOTA response. | quota root's resource usage and limits in an untagged QUOTA response. | |||
| The client can try using any of the resource types returned in | (Names of quota roots applicable to a particular mailbox can be | |||
| CAPABILITY response (i.e. all capability items with "QUOTA=RES-" | discovered by issuing the GETQUOTAROOT command, see Section 4.1.2.) | |||
| prefix), however the server is not required to support any specific | Note that the server is not required to support any specific resource | |||
| resource type for any particular quota root. | type (as advertised in the CAPABILITY response, i.e. all capability | |||
| items with the "QUOTA=RES-" prefix) for any particular quota root. | ||||
| Example: | Example: | |||
| S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] | S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE [...] | |||
| [...] | [...] | |||
| C: G0001 GETQUOTA "!partition/sda4" | C: G0001 GETQUOTA "!partition/sda4" | |||
| S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) | S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) | |||
| skipping to change at page 7, line 47 ¶ | skipping to change at page 8, line 4 ¶ | |||
| 4.1.3. SETQUOTA | 4.1.3. SETQUOTA | |||
| Arguments: quota root | Arguments: quota root | |||
| list of resource limits | list of resource limits | |||
| Responses: untagged responses: QUOTA | Responses: untagged responses: QUOTA | |||
| Result: OK - setquota completed | Result: OK - setquota completed | |||
| NO - setquota error: can't set that data | NO - setquota error: can't set that data | |||
| BAD - command unknown or arguments invalid | BAD - command unknown or arguments invalid | |||
| Note that unlike other command/responses/response codes defined in | Note that unlike other command/responses/response codes defined in | |||
| this document, support for SETQUOTA command requires the server to | this document, support for SETQUOTA command requires the server to | |||
| advertise "QUOTASET" capability. | advertise "QUOTASET" capability. | |||
| The SETQUOTA command takes the name of a mailbox quota root and a | The SETQUOTA command takes the name of a mailbox quota root and a | |||
| list of resource limits. The resource limits for the named quota | list of resource limits. The resource limits for the named quota | |||
| root are changed to be the specified limits. Any previous resource | root are changed to be the specified limits. Any previous resource | |||
| limits for the named quota root are discarded. | limits for the named quota root are discarded, even resource limits | |||
| not explicitly listed in the SETQUOTA command. (For example, if the | ||||
| quota root had both STORAGE and MESSAGE limits assigned to the quota | ||||
| root before the SETQUOTA is called and the SETQUOTA only includes the | ||||
| STORAGE limit, then the MESSAGE limit is removed from the quota | ||||
| root.) | ||||
| If the named quota root did not previously exist, an implementation | If the named quota root did not previously exist, an implementation | |||
| may optionally create it and change the quota roots for any number of | may optionally create it and change the quota roots for any number of | |||
| existing mailboxes in an implementation-defined manner. | existing mailboxes in an implementation-defined manner. | |||
| If the implementation chooses to change the quota roots for some | If the implementation chooses to change the quota roots for some | |||
| existing mailboxes such changes SHOULD be announced with untagged | existing mailboxes such changes SHOULD be announced with untagged | |||
| QUOTA responses. | QUOTA responses. | |||
| Example: | Example: | |||
| skipping to change at page 8, line 44 ¶ | skipping to change at page 9, line 4 ¶ | |||
| C: S0001 SETQUOTA "#user/alice" (STORAGE 510) | C: S0001 SETQUOTA "#user/alice" (STORAGE 510) | |||
| S: * QUOTA "#user/alice" (STORAGE 58 512) | S: * QUOTA "#user/alice" (STORAGE 58 512) | |||
| // The server has rounded the STORAGE quota limit requested to the | // The server has rounded the STORAGE quota limit requested to the | |||
| nearest 512 blocks of 1024 octects, or else another client has | nearest 512 blocks of 1024 octects, or else another client has | |||
| performed a near simultaneous SETQUOTA, using a limit of 512. | performed a near simultaneous SETQUOTA, using a limit of 512. | |||
| S: S0001 OK Rounded quota | S: S0001 OK Rounded quota | |||
| C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) | C: S0002 SETQUOTA "!partition/sda4" (STORAGE 99999999) | |||
| S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) | S: * QUOTA "!partition/sda4" (STORAGE 104 10923847) | |||
| // The server has not changed the quota, since this is a | // The server has not changed the quota, since this is a | |||
| filesystem limit, and cannot be changed. The QUOTA response here | filesystem limit, and cannot be changed. The QUOTA response here | |||
| is entirely optional. | is entirely optional. | |||
| S: S0002 NO Cannot change system limit | S: S0002 NO Cannot change system limit | |||
| 4.1.4. New STATUS attributes | 4.1.4. New STATUS attributes | |||
| DELETED and DELETED-STORAGE status data items allow to estimate the | DELETED and DELETED-STORAGE status data items allow to estimate the | |||
| amount of resource freed by an EXPUNGE on a mailbox. | amount of resource freed by an EXPUNGE on a mailbox. | |||
| DELETED status data item requests the server to return the number of | The DELETED status data item requests the server to return the number | |||
| messages with \Deleted flag set. DELETED status data item is only | of messages with \Deleted flag set. The DELETED status data item is | |||
| required to be implemented when the server advertises QUOTA=RES- | only required to be implemented when the server advertises QUOTA=RES- | |||
| MESSAGE capability. | MESSAGE capability. | |||
| DELETED-STORAGE status data item requests the server to return the | The DELETED-STORAGE status data item requests the server to return | |||
| amount of storage space that can be reclaimed by performing EXPUNGE | the amount of storage space that can be reclaimed by performing | |||
| on the mailbox. The server SHOULD return the exact value, however it | EXPUNGE on the mailbox. The server SHOULD return the exact value, | |||
| is recognized that the server may have to do non-trivial amount of | however it is recognized that the server may have to do non-trivial | |||
| work to calculate it. If the calculation of the exact value would | amount of work to calculate it. If the calculation of the exact | |||
| take a long time, the server MAY instead return the sum of | value would take a long time, the server MAY instead return the sum | |||
| RFC822.SIZEs of messages with the \Deleted flag set. DELETED-STORAGE | of RFC822.SIZEs of messages with the \Deleted flag set. The DELETED- | |||
| status data item is only required to be implemented when the server | STORAGE status data item is only required to be implemented when the | |||
| advertises QUOTA=RES-STORAGE capability. | server advertises QUOTA=RES-STORAGE capability. | |||
| Example: | Example: | |||
| S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE | S: * CAPABILITY [...] QUOTA QUOTA=RES-STORAGE QUOTA=RES-MESSAGE | |||
| [...] | [...] | |||
| [...] | [...] | |||
| C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) | C: S0003 STATUS INBOX (MESSAGES DELETED DELETED-STORAGE) | |||
| skipping to change at page 10, line 5 ¶ | skipping to change at page 10, line 15 ¶ | |||
| 4.2. Responses | 4.2. Responses | |||
| The following responses may be sent by the server. | The following responses may be sent by the server. | |||
| 4.2.1. QUOTA | 4.2.1. QUOTA | |||
| Data: quota root name | Data: quota root name | |||
| list of resource names, usages, and limits | list of resource names, usages, and limits | |||
| This response occurs as a result of a GETQUOTA or GETQUOTAROOT | This response occurs as a result of a GETQUOTA, a GETQUOTAROOT or a | |||
| command. The first string is the name of the quota root for which | SETQUOTA command. The first string is the name of the quota root for | |||
| this quota applies. | which this quota applies. | |||
| The name is followed by a S-expression format list of the resource | The name is followed by a S-expression format list of the resource | |||
| usage and limits of the quota root. The list contains zero or more | usage and limits of the quota root. The list contains zero or more | |||
| triplets. Each triplet contains a resource name, the current usage | triplets. Each triplet contains a resource name, the current usage | |||
| of the resource, and the resource limit. | of the resource, and the resource limit. | |||
| Resources not named in the list are not limited in the quota root. | Resources not named in the list are not limited in the quota root. | |||
| Thus, an empty list means there are no administrative resource limits | Thus, an empty list means there are no administrative resource limits | |||
| in the quota root. | in the quota root. | |||
| skipping to change at page 10, line 30 ¶ | skipping to change at page 10, line 40 ¶ | |||
| 4.2.2. QUOTAROOT | 4.2.2. QUOTAROOT | |||
| Data: mailbox name | Data: mailbox name | |||
| zero or more quota root names | zero or more quota root names | |||
| This response occurs as a result of a GETQUOTAROOT command. The | This response occurs as a result of a GETQUOTAROOT command. The | |||
| first string is the mailbox and the remaining strings are the names | first string is the mailbox and the remaining strings are the names | |||
| of the quota roots for the mailbox. | of the quota roots for the mailbox. | |||
| Example: | Examples: | |||
| S: * QUOTAROOT INBOX "" | S: * QUOTAROOT INBOX "" | |||
| // The INBOX mailbox is covered by a single quota root with name "". | ||||
| S: * QUOTAROOT comp.mail.mime | S: * QUOTAROOT comp.mail.mime | |||
| 4.3. Response Codes | // The comp.mail.mime mailbox has no quota root associated with it, | |||
| but one can be created. | ||||
| 4.3. Response Codes | ||||
| 4.3.1. OVERQUOTA | 4.3.1. OVERQUOTA | |||
| OVERQUOTA response code SHOULD be returned in the tagged NO response | OVERQUOTA response code SHOULD be returned in the tagged NO response | |||
| to an APPEND/COPY/MOVE when the addition of the message(s) puts the | to an APPEND/COPY/MOVE when the addition of the message(s) puts the | |||
| target mailbox over any one of its quota limits. | target mailbox over any one of its quota limits. | |||
| Example 1: C: A003 APPEND saved-messages (\Seen) {326} | Example 1: C: A003 APPEND saved-messages (\Seen) {326} | |||
| S: + Ready for literal data | S: + Ready for literal data | |||
| C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) | C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST) | |||
| C: From: Fred Foobar <foobar@Blurdybloop.example> | C: From: Fred Foobar <foobar@Blurdybloop.example> | |||
| skipping to change at page 11, line 49 ¶ | skipping to change at page 12, line 20 ¶ | |||
| C: To: mooch@owatagu.siam.edu.example | C: To: mooch@owatagu.siam.edu.example | |||
| C: Message-Id: <B27397-0100000@Blurdybloop.example> | C: Message-Id: <B27397-0100000@Blurdybloop.example> | |||
| C: MIME-Version: 1.0 | C: MIME-Version: 1.0 | |||
| C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII | C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII | |||
| C: | C: | |||
| C: Hello Joe, do you think we can meet at 3:30 tomorrow? | C: Hello Joe, do you think we can meet at 3:30 tomorrow? | |||
| C: | C: | |||
| S: * NO [OVERQUOTA] Soft quota has been exceeded | S: * NO [OVERQUOTA] Soft quota has been exceeded | |||
| S: A003 OK [APPENDUID 38505 3955] APPEND completed | S: A003 OK [APPENDUID 38505 3955] APPEND completed | |||
| Example 3: C: A003 COPY 2:4 MEETING | Example 3: C: A004 COPY 2:4 MEETING | |||
| S: * NO [OVERQUOTA] Soft quota has been exceeded | S: * NO [OVERQUOTA] Soft quota has been exceeded | |||
| S: A003 OK [COPYUID 38505 304,319:320 3956:3958] COPY | S: A004 OK [COPYUID 38505 304,319:320 3956:3958] COPY | |||
| command completed | command completed | |||
| 5. Resource Type Definitions | 5. Resource Type Definitions | |||
| The following resource types are defined in this memo. A server | The following resource types are defined in this memo. A server | |||
| supporting a resource type MUST advertise this as a CAPABILITY with a | supporting a resource type MUST advertise this as a CAPABILITY with a | |||
| name consisting of the resource name prefixed by "QUOTA=RES-". A | name consisting of the resource name prefixed by "QUOTA=RES-". A | |||
| server MAY support mupltiple resource types, and MUST advertise all | server MAY support multiple resource types, and MUST advertise all | |||
| resource types it supports. | resource types it supports. | |||
| 5.1. STORAGE | 5.1. STORAGE | |||
| The physical space estimate, in units of 1024 octets, of the | The physical space estimate, in units of 1024 octets, of the | |||
| mailboxes governed by the quota root. This MAY not be the same as | 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 | the sum of the RFC822.SIZE of the messages. Some implementations MAY | |||
| include metadata sizes for the messages and mailboxes, other | include metadata sizes for the messages and mailboxes, other | |||
| implementations MAY store messages in such a way that the physical | implementations MAY store messages in such a way that the physical | |||
| space used is smaller, for example due to use of compression. | space used is smaller, for example due to use of compression. | |||
| skipping to change at page 12, line 32 ¶ | skipping to change at page 13, line 5 ¶ | |||
| use the usage figure for anything other than informational purposes, | use the usage figure for anything other than informational purposes, | |||
| for example, they MUST NOT refuse to APPEND a message if the limit | 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 | less the usage is smaller than the RFC822.SIZE divided by 1024 of the | |||
| message, but it MAY warn about such condition. | message, but it MAY warn about such condition. | |||
| The usage figure may change as a result of performing actions not | The usage figure may change as a result of performing actions not | |||
| associated with adding new messages to the mailbox, such as SEARCH, | associated with adding new messages to the mailbox, such as SEARCH, | |||
| since this may increase the amount of metadata included in the | since this may increase the amount of metadata included in the | |||
| calculations. | calculations. | |||
| When the server supports this resource type, it MUST also support | When the server supports this resource type, it MUST also support the | |||
| DELETED-STORAGE status data item. | DELETED-STORAGE status data item. | |||
| Support for this resource MUST be indicated by the server by | Support for this resource MUST be indicated by the server by | |||
| advertising the CAPABILITY "QUOTA=RES-STORAGE". | advertising the CAPABILITY "QUOTA=RES-STORAGE". | |||
| A resource named the same was also given as an example in RFC2087 | A resource named the same was also given as an example in RFC2087 | |||
| [RFC2087]. This document provides a more precise definition. | [RFC2087]. This document provides a more precise definition. | |||
| 5.2. MESSAGE | 5.2. MESSAGE | |||
| The number of messages stored within the mailboxes governed by the | The number of messages stored within the mailboxes governed by the | |||
| quota root. This MUST be an exact number, however, clients MUST NOT | quota root. This MUST be an exact number, however, clients MUST NOT | |||
| assume that a change in the usage indicates a change in the number of | assume that a change in the usage indicates a change in the number of | |||
| messages available, since the quota root may include mailboxes the | messages available, since the quota root may include mailboxes the | |||
| client has no access to. | client has no access to. | |||
| When the server supports this resource type, it MUST also support | When the server supports this resource type, it MUST also support the | |||
| DELETED status data item. | DELETED status data item. | |||
| Support for this resource MUST be indicated by the server by | Support for this resource MUST be indicated by the server by | |||
| advertising the CAPABILITY "QUOTA=RES-MESSAGE". | advertising the CAPABILITY "QUOTA=RES-MESSAGE". | |||
| A resource named the same was also given as an example in RFC2087 | A resource named the same was also given as an example in RFC2087 | |||
| [RFC2087]. This document provides a more precise definition. | [RFC2087]. This document provides a more precise definition. | |||
| 5.3. MAILBOX | 5.3. MAILBOX | |||
| skipping to change at page 13, line 49 ¶ | skipping to change at page 14, line 24 ¶ | |||
| +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | |||
| | GETQUOTAROOT | |*| | | | | | | | | | * | | | GETQUOTAROOT | |*| | | | | | | | | | * | | |||
| +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | |||
| | SETQUOTA | | | | | | | | | | + | | | | | SETQUOTA | | | | | | | | | | + | | | | |||
| +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | +-------------------+-+-+---+---+---+---+---+---+---+---+-----+-----+ | |||
| Table 1 | Table 1 | |||
| See Section 4 of RFC 4314 for conventions used in this table. | See Section 4 of RFC 4314 for conventions used in this table. | |||
| Legend: | ||||
| + - The right is required | ||||
| * - Only one of the rights marked with * is required | ||||
| "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is | ||||
| required | ||||
| "Non" - no rights required to perform the command | ||||
| Note that which permissions are needed in order to perform | ||||
| GETQUOTAROOT command depends on the quota resource type being | ||||
| requested. For example, a quota on number of messages (MESSAGE | ||||
| resource type) or total size of messages (STORAGE resource type) | ||||
| requires "r" right on the mailbox in question, since the quota | ||||
| involved would reveal information about the number (or total size) of | ||||
| messages in the mailbox. By comparison, the MAILBOX resource type | ||||
| doesn't require any right. | ||||
| 7. Formal syntax | 7. Formal syntax | |||
| The following syntax specification uses the Augmented Backus-Naur | The following syntax specification uses the Augmented Backus-Naur | |||
| Form (ABNF) notation as specified in [ABNF]. | Form (ABNF) notation as specified in [ABNF]. | |||
| Non-terminals referenced but not defined below are as defined by | Non-terminals referenced but not defined below are as defined by | |||
| IMAP4 [RFC3501]. | IMAP4 [RFC3501]. | |||
| Except as noted otherwise, all alphabetic characters are case- | Except as noted otherwise, all alphabetic characters are case- | |||
| insensitive. The use of upper or lower case characters to define | insensitive. The use of upper or lower case characters to define | |||
| skipping to change at page 14, line 38 ¶ | skipping to change at page 15, line 35 ¶ | |||
| ")" | ")" | |||
| setquota-resource = resource-name SP resource-limit | setquota-resource = resource-name SP resource-limit | |||
| quota-root-name = astring | quota-root-name = astring | |||
| resource-limit = number64 | resource-limit = number64 | |||
| resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / | resource-name = "STORAGE" / "MESSAGE" / "MAILBOX" / | |||
| "ANNOTATION-STORAGE" / resource-name-vnd / | "ANNOTATION-STORAGE" / resource-name-ext | |||
| resource-name-ext | ||||
| resource-name-vnd = "V-" atom | ||||
| ;; Vendor specific, must be registered with IANA. | ||||
| ;; The "V-" prefix should be followed by a domain | ||||
| name | ||||
| ;; under vendor's control. | ||||
| resource-name-ext = atom | resource-name-ext = atom | |||
| ;; Not starting with V- and defined | ||||
| ;; in a Standard Track or Experimental RFC | ||||
| resource-names = "(" [resource-name *(SP resource-name)] ")" | ;; Future resource registrations | |||
| resource-usage = number64 | resource-usage = number64 | |||
| ;; must be less than corresponding resource-limit | ;; must be less than corresponding resource-limit | |||
| capability-quota = capa-quota-res / "QUOTASET" | capability-quota = capa-quota-res / "QUOTASET" | |||
| ;; One or more capa-quota-res must be returned. | ;; One or more capa-quota-res must be returned. | |||
| ;; Also "QUOTASET" can optionally be returned. | ;; Also "QUOTASET" can optionally be returned. | |||
| skipping to change at page 15, line 21 ¶ | skipping to change at page 16, line 4 ¶ | |||
| ;; must be less than corresponding resource-limit | ;; must be less than corresponding resource-limit | |||
| capability-quota = capa-quota-res / "QUOTASET" | capability-quota = capa-quota-res / "QUOTASET" | |||
| ;; One or more capa-quota-res must be returned. | ;; One or more capa-quota-res must be returned. | |||
| ;; Also "QUOTASET" can optionally be returned. | ;; Also "QUOTASET" can optionally be returned. | |||
| capa-quota-res = "QUOTA=RES-" resource-name | capa-quota-res = "QUOTA=RES-" resource-name | |||
| status-att =/ "DELETED" / "DELETED-STORAGE" | status-att =/ "DELETED" / "DELETED-STORAGE" | |||
| ;; DELETED status data item MUST be supported | ;; DELETED status data item MUST be supported | |||
| ;; when "QUOTA=RES-MESSAGE" capability is | ;; when "QUOTA=RES-MESSAGE" capability is | |||
| ;; advertised. | ;; advertised. | |||
| ;; DELETED-STORAGE status data item MUST be | ;; DELETED-STORAGE status data item MUST be | |||
| ;; supported when "QUOTA=RES-STORAGE" capability | ;; supported when "QUOTA=RES-STORAGE" capability | |||
| ;; is advertised. | ;; is advertised. | |||
| status-att-val =/ status-att-deleted / | status-att-val =/ status-att-deleted / | |||
| status-att-deleted-storage | status-att-deleted-storage | |||
| status-att-deleted =/ "DELETED" SP number | status-att-deleted = "DELETED" SP number | |||
| ;; DELETED status data item MUST be supported | ;; DELETED status data item MUST be supported | |||
| ;; when "QUOTA=RES-MESSAGE" capability is | ;; when "QUOTA=RES-MESSAGE" capability is | |||
| ;; advertised. | ;; advertised. | |||
| status-att-deleted-storage =/ "DELETED-STORAGE" SP number64 | status-att-deleted-storage = "DELETED-STORAGE" SP number64 | |||
| ;; DELETED-STORAGE status data item MUST be | ;; DELETED-STORAGE status data item MUST be | |||
| ;; supported when "QUOTA=RES-STORAGE" capability | ;; supported when "QUOTA=RES-STORAGE" capability | |||
| ;; is advertised. | ;; is advertised. | |||
| resp-text-code =/ "OVERQUOTA" | resp-text-code =/ "OVERQUOTA" | |||
| number64 = <Defined in RFC 9051> | number64 = <Defined in RFC 9051> | |||
| 8. Security Considerations | 8. Security Considerations | |||
| Implementors should be careful to make sure the implementation of | Implementors should be careful to make sure the implementation of | |||
| these commands does not violate the site's security policy. The | these commands does not violate the site's security policy. The | |||
| resource usage of other users is likely to be considered confidential | resource usage of other users is likely to be considered confidential | |||
| information and should not be divulged to unauthorized persons. In | information and should not be divulged to unauthorized persons. In | |||
| particular, no quota information should be disclosed to anonymous | particular, no quota information should be disclosed to anonymous | |||
| users. | users. | |||
| As for any resource shared across users (for example a quota root | ||||
| attached to a set of shared mailboxes), a user that can consume or | ||||
| render unusable the resource can affect the resources available to | ||||
| the other users; this might occur, for example, by a user with | ||||
| permission to execute SETQUOTA setting an artificially small value. | ||||
| Note that computing resource usage might incur a heavy load on the | ||||
| server. Server implementers should consider implementation | ||||
| techniques that lower load on servers, such as caching of resource | ||||
| usage information or usage of less precise computations when under | ||||
| heavy load. | ||||
| 9. IANA Considerations | 9. IANA Considerations | |||
| 9.1. Changes/additions to the IMAP4 capabilities registry | 9.1. Changes/additions to the IMAP4 capabilities registry | |||
| IMAP4 capabilities are registered by publishing a standards track or | IMAP4 capabilities are registered by publishing a standards track or | |||
| IESG approved Informational or Experimental RFC. The registry is | IESG approved Informational or Experimental RFC. The registry is | |||
| currently located at: | currently located at: | |||
| http://www.iana.org/assignments/imap4-capabilities | https://www.iana.org/assignments/imap4-capabilities | |||
| IANA is requested to update definition of the QUOTA extension to | IANA is requested to update definition of the QUOTA extension to | |||
| point to this document. IANA is also requested to add the "QUOTASET" | point to this document. IANA is also requested to add the "QUOTASET" | |||
| capability to the IMAP4 capabilities registry, with this document as | capability to the IMAP4 capabilities registry, with this document as | |||
| the reference. | the reference. | |||
| IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 | IANA is requested to reserve the prefix "QUOTA=RES-" in the IMAP4 | |||
| capabilities registry and add a pointer to this document and to the | capabilities registry and add a pointer to this document and to the | |||
| IMAP quota resource type registry (see Section 9.2). | IMAP quota resource type registry (see Section 9.2). | |||
| IANA is requested to reserve all other capabilities starting with | IANA is requested to reserve all other capabilities starting with | |||
| "QUOTA=" prefix for future IETF stream standard track, informational | "QUOTA=" prefix for future IETF Stream extensions to this document. | |||
| or experimental extensions to this document. | ||||
| 9.2. IMAP quota resource type registry | 9.2. IMAP quota resource type registry | |||
| IANA is requested to create a new registry for IMAP quota resource | IANA is requested to create a new registry for IMAP quota resource | |||
| types. Registration policy for this registry is "Specification | types. Registration policy for this registry is "Specification | |||
| Required". When registering a new quota resource type, the | Required". When registering a new quota resource type, the | |||
| registrant need to provide the following: Name of the quota resource | registrant need to provide the following: Name of the quota resource | |||
| type, Author/Change Controller name and email address, short | type, Author/Change Controller name and email address, short | |||
| description, extra (if any) required and optional IMAP commands/ | description, extra (if any) required and optional IMAP commands/ | |||
| responses, and a reference to a specification that describes the | responses, and a reference to a specification that describes the | |||
| skipping to change at page 18, line 10 ¶ | skipping to change at page 19, line 4 ¶ | |||
| governed by the quota root. | governed by the quota root. | |||
| Extra required IMAP commands/responses: DELETED STATUS request data | Extra required IMAP commands/responses: DELETED STATUS request data | |||
| item and response data item | item and response data item | |||
| Extra optional IMAP commands/responses: N/A | Extra optional IMAP commands/responses: N/A | |||
| Reference: Section 5.2 of RFCXXXX | Reference: Section 5.2 of RFCXXXX | |||
| Name of the quota resource type: MAILBOX | Name of the quota resource type: MAILBOX | |||
| Author: Alexey Melnikov <alexey.melnikov@isode.com> | Author: Alexey Melnikov <alexey.melnikov@isode.com> | |||
| Change Controller: IESG <iesg@ietf.org> | Change Controller: IESG <iesg@ietf.org> | |||
| Description: The number of mailboxes governed by the quota root. | Description: The number of mailboxes governed by the quota root. | |||
| Extra required IMAP commands/responses: N/A | Extra required IMAP commands/responses: N/A | |||
| Extra optional IMAP commands/responses: N/A | Extra optional IMAP commands/responses: N/A | |||
| Reference: Section 5.3 of RFCXXXX | Reference: Section 5.3 of RFCXXXX | |||
| Name of the quota resource type: | Name of the quota resource type: ANNOTATION-STORAGE | |||
| Author: Alexey Melnikov <alexey.melnikov@isode.com> | Author: Alexey Melnikov <alexey.melnikov@isode.com> | |||
| Change Controller: IESG <iesg@ietf.org> | Change Controller: IESG <iesg@ietf.org> | |||
| Description: The maximum size of all annotations [RFC5257], in units | Description: The maximum size of all annotations [RFC5257], in units | |||
| of 1024 octets, associated with all messages in the mailboxes | of 1024 octets, associated with all messages in the mailboxes | |||
| governed by the quota root. | governed by the quota root. | |||
| Extra required IMAP commands/responses: N/A | Extra required IMAP commands/responses: N/A | |||
| skipping to change at page 18, line 46 ¶ | skipping to change at page 19, line 39 ¶ | |||
| Reference: Section 5.4 of RFCXXXX | Reference: Section 5.4 of RFCXXXX | |||
| 10. Contributors | 10. Contributors | |||
| Dave Cridland wrote lots of text in an earlier draft that became the | Dave Cridland wrote lots of text in an earlier draft that became the | |||
| basis for this document. | basis for this document. | |||
| 11. Acknowledgments | 11. Acknowledgments | |||
| Editors of this document would like to thank the following people who | Editor of this document would like to thank the following people who | |||
| provided useful comments or participated in discussions that lead to | provided useful comments or participated in discussions that lead to | |||
| this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg | this update to RFC 2087: John Myers, Cyrus Daboo, Lyndon Nerenberg, | |||
| Benjamin Kaduk, Roman Danyliw, Eric Vyncke. | ||||
| This document is a revision of RFC 2087. It borrows a lot of text | This document is a revision of RFC 2087. It borrows a lot of text | |||
| from RFC 2087. Thus work of the RFC 2087 author John Myers is | from RFC 2087. Thus work of the RFC 2087 author John Myers is | |||
| appreciated. | appreciated. | |||
| 12. Changes since RFC 2087 | 12. Changes since RFC 2087 | |||
| This document is a revision of RFC 2087. It tries to clarify meaning | This document is a revision of RFC 2087. It tries to clarify the | |||
| of different terms used by RFC 2087. It also provides more examples, | meaning of different terms used by RFC 2087. It also provides more | |||
| gives guidance on allowed server behaviour, defines IANA registry for | examples, gives guidance on allowed server behaviour, defines IANA | |||
| quota resource types and provides initial registrations for 3 of | registry for quota resource types and provides initial registrations | |||
| them. | for 4 of them. | |||
| When compared with RFC 2087, this document defines two more commonly | When compared with RFC 2087, this document defines two more commonly | |||
| used resource type, adds optional OVERQUOTA response code and defines | used resource type, adds optional OVERQUOTA response code and defines | |||
| two extra STATUS data items ("DELETED" and "DELETED-STORAGE") that | two extra STATUS data items ("DELETED" and "DELETED-STORAGE"). The | |||
| must be implemented. For extensibility quota usage and quota limits | DELETED STATUS data item must be implemented if the QUOTA=RES-MESSAGE | |||
| are now 63 bit unsigned integers. | capability is advertised. The DELETED-STORAGE STATUS data item must | |||
| be implemented if the QUOTA=RES-STORAGE capability is advertised. | ||||
| For extensibility quota usage and quota limits are now 63 bit | ||||
| unsigned integers. | ||||
| 13. References | 13. References | |||
| 13.1. Normative References | 13.1. Normative References | |||
| [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for | [ABNF] Crocker, D., Ed. and P. Overell, Ed., "Augmented BNF for | |||
| Syntax Specifications: ABNF", RFC 5234, January 2008, | Syntax Specifications: ABNF", RFC 5234, January 2008, | |||
| <ftp://ftp.isi.edu/in-notes/rfc5234.txt>. | <https://www.rfc-editor.org/info/rfc5234>. | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
| 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
| <https://www.rfc-editor.org/info/rfc3501>. | <https://www.rfc-editor.org/info/rfc3501>. | |||
| End of changes. 52 change blocks. | ||||
| 109 lines changed or deleted | 136 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||