idnits 2.17.00 (12 Aug 2021) /tmp/idnits58533/draft-myers-imap-quota-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2022-05-14) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 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. ** The abstract seems to contain references ([IMAP4]), 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 document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 182: '...al clarity only. Implementations MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 103 has weird spacing: '...etquota error...' -- 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 (December 1995) is 9647 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) == Unused Reference: 'RFC-822' is defined on line 211, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 13 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Myers 2 Internet Draft Carnegie Mellon 3 Document: draft-myers-imap-quota-00.txt December 1995 5 IMAP4 QUOTA extension 7 Status of this Memo 9 This document is an Internet Draft. Internet Drafts are working 10 documents of the Internet Engineering Task Force (IETF), its Areas, 11 and its Working Groups. Note that other groups may also distribute 12 working documents as Internet Drafts. 14 Internet Drafts are draft documents valid for a maximum of six 15 months. Internet Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet 17 Drafts as reference material or to cite them other than as a 18 ``working draft'' or ``work in progress''. 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 23 munnari.oz.au. 25 A revised version of this draft document will be submitted to the RFC 26 editor as a Proposed Standard for the Internet Community. Discussion 27 and suggestions for improvement are requested. This document will 28 expire before April 1996. Distribution of this draft is unlimited. 30 Internet DRAFT QUOTA December 14, 1995 32 1. Abstract 34 The QUOTA extension of the Internet Message Access Protocol [IMAP4] 35 permits administrative limits on resource usage (quotas) to be 36 manipulated through the IMAP protocol. 38 2. Conventions Used in this Document 40 In examples, "C:" and "S:" indicate lines sent by the client and 41 server respectively. 43 3. Introduction and Overview 45 The QUOTA extension is present in any IMAP4 implementation which 46 returns "QUOTA" as one of the supported capabilities to the 47 CAPABILITY command. 49 An IMAP4 server which supports the QUOTA capability may support 50 limits on any number of resources. Each resource has an atom name 51 and an implementation-defined interpretation which evaluates to an 52 integer. Examples of such resources are: 54 Name Interpretation 56 STORAGE Sum of messages' RFC822.SIZE, in units of 1024 octets 57 MESSAGE Number of messages 59 Each mailbox has zero or more implementation-defined named "quota 60 roots". Each quota root has zero or more resource limits. All 61 mailboxes that share the same named quota root share the resource 62 limits of the quota root. 64 Quota root names do not necessarily have to match the names of 65 existing mailboxes. 67 Internet DRAFT QUOTA December 14, 1995 69 4. Commands 71 4.1. SETQUOTA Command 73 Arguments: quota root 74 list of resource limits 76 Data: untagged responses: QUOTA 78 Result: OK - setquota completed 79 NO - setquota error: can't set that data 80 BAD - command unknown or arguments invalid 82 The SETQUOTA command takes the name of a mailbox quota root and a 83 list of resource limits. The resource limits for the named quota 84 root are changed to be the specified limits. Any previous 85 resource limits for the named quota root are discarded. 87 If the named quota root did not previously exist, an 88 implementation may optionally create it and change the quota roots 89 for any number of existing mailboxes in an implementation-defined 90 manner. 92 Example: C: A001 SETQUOTA "" (STORAGE 512) 93 S: * QUOTA "" (STORAGE 10 512) 94 S: A001 OK Setquota completed 96 4.2. GETQUOTA Command 98 Arguments: quota root 100 Data: untagged responses: QUOTA 102 Result: OK - getquota completed 103 NO - getquota error: no such quota root, permission 104 denied 105 BAD - command unknown or arguments invalid 107 The GETQUOTA command takes the name of a quota root and returns 108 the quota root's resource usage and limits in an untagged QUOTA 109 response. 111 Example: C: A003 GETQUOTA "" 112 S: * QUOTA "" (STORAGE 10 512) 113 S: A003 OK Getquota completed 115 Internet DRAFT QUOTA December 14, 1995 117 4.3. GETQUOTAROOT Command 119 Arguments: mailbox name 121 Data: untagged responses: QUOTAROOT, QUOTA 123 Result: OK - getquota completed 124 NO - getquota error: no such mailbox, permission denied 125 BAD - command unknown or arguments invalid 127 The GETQUOTAROOT command takes the name of a mailbox and returns the 128 list of quota roots for the mailbox in an untagged QUOTAROOT 129 response. For each listed quota root, it also returns the quota 130 root's resource usage and limits in an untagged QUOTA response. 132 Example: C: A003 GETQUOTAROOT INBOX 133 S: * QUOTAROOT INBOX "" 134 S: * QUOTA "" (STORAGE 10 512) 135 S: A003 OK Getquota completed 137 5. Responses 139 5.1. QUOTA Response 141 Data: quota root name 142 list of resource names, usages, and limits 144 This response occurs as a result of a GETQUOTA or GETQUOTAROOT 145 command. The first string is the name of the quota root for which 146 this quota applies. 148 The name is followed by a S-expression format list of the resource 149 usage and limits of the quota root. The list contains zero or 150 more triplets. Each triplet conatins a resource name, the current 151 usage of the resource, and the resource limit. 153 Resources not named in the list are not limited in the quota root. 154 Thus, an empty list means there are no administrative resource 155 limits in the quota root. 157 Example: S: * QUOTA "" (STORAGE 10 512) 159 Internet DRAFT QUOTA December 14, 1995 161 5.2. QUOTAROOT Response 163 Data: mailbox name 164 zero or more quota root names 166 This response occurs as a result of a GETQUOTAROOT command. The 167 first string is the mailbox and the remaining strings are the 168 names of the quota roots for the mailbox. 170 Example: S: * QUOTAROOT INBOX "" 171 S: * QUOTAROOT comp.mail.mime 173 6. Formal syntax 175 The following syntax specification uses the augmented Backus-Naur 176 Form (BNF) notation as specified in RFC 822 with one exception; the 177 delimiter used with the "#" construct is a single space (SP) and not 178 one or more commas. 180 Except as noted otherwise, all alphabetic characters are case- 181 insensitive. The use of upper or lower case characters to define 182 token strings is for editorial clarity only. Implementations MUST 183 accept these strings in a case-insensitive fashion. 185 getquota ::= "GETQUOTA" SP astring 187 getquotaroot ::= "GETQUOTAROOT" SP astring 189 quota_list ::= "(" #quota_resource ")" 191 quota_resource ::= atom SP number SP number 193 quota_response ::= "QUOTA" SP astring SP quota_list 195 quotaroot_response 196 ::= "QUOTAROOT" SP astring *(SP astring) 198 setquota ::= "SETQUOTA" SP astring SP setquota_list 200 setquota_list ::= "(" 0#setquota_resource ")" 202 setquota_resource ::= atom SP number 204 7. References 206 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 207 RFC 1730, University of Washington, December 1994. 209 Internet DRAFT QUOTA December 14, 1995 211 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 212 Messages", STD 11, RFC 822. 214 8. Security Considerations 216 Implementors should be careful to make sure the implementation of 217 these commands does not violate the site's security policy. The 218 resource usage of other users is likely to be considered confidential 219 information and should not be divulged to unauthorized persons. 221 9. Author's Address 223 John G. Myers 224 Carnegie-Mellon University 225 5000 Forbes Ave. 226 Pittsburgh PA, 15213-3890 228 Email: jgm+@cmu.edu 230 Internet DRAFT QUOTA December 14, 1995 232 Table of Contents 234 Status of this Memo ............................................... i 235 1. Abstract ..................................................... 2 236 2. Conventions Used in this Document ............................ 2 237 3. Introduction and Overview .................................... 2 238 4. Commands ..................................................... 3 239 4.1. SETQUOTA Command ............................................. 3 240 4.2. GETQUOTA Command ............................................. 3 241 4.3. GETQUOTAROOT Command ......................................... 4 242 5. Responses .................................................... 4 243 5.1. QUOTA Response ............................................... 4 244 5.2. QUOTAROOT Response ........................................... 4 245 6. Formal syntax ................................................ 5 246 7. References ................................................... 5 247 8. Security Considerations ...................................... 6 248 9. Author's Address ............................................. 6