idnits 2.17.1 draft-ietf-imapext-acl-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 (2024-04-25) 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) 2024 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 0) being 61 lines 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. ** There are 3 instances of too long lines in the document, the longest one being 62 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([IMAP4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 282: '... MUST accept these strings in a case...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (May 2000) is 8746 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: 'UTF-8' is defined on line 321, 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) ** Obsolete normative reference: RFC 2279 (ref. 'UTF-8') (Obsoleted by RFC 3629) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Myers 3 Internet Draft Netscape Communications 4 Document: draft-ietf-imapext-acl-00.txt May 2000 6 IMAP4 ACL extension 8 Status of this Memo 10 This document is an Internet Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its Areas, and its Working Groups. Note that 15 other groups may also distribute working documents as Internet 16 Drafts. Internet Drafts are draft documents valid for a maximum of 17 six months. Internet Drafts may be updated, replaced, or obsoleted 18 by other documents at any time. It is not appropriate to use 19 Internet Drafts as reference material or to cite them other than as 20 ``work in progress''. 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 29 munnari.oz.au. 31 A revised version of this draft document will be submitted to the RFC 32 editor as a Proposed Standard for the Internet Community. Discussion 33 and suggestions for improvement are requested. Distribution of this 34 draft is unlimited. 36 Internet DRAFT ACL May 23, 2000 38 1. Abstract 40 The ACL extension of the Internet Message Access Protocol [IMAP4] 41 permits access control lists to be manipulated through the IMAP 42 protocol. 44 2. Conventions Used in this Document 46 In examples, "C:" and "S:" indicate lines sent by the client and 47 server respectively. 49 3. Introduction and Overview 51 The ACL extension is present in any IMAP4 implementation which 52 returns "ACL" as one of the supported capabilities to the CAPABILITY 53 command. 55 An access control list is a set of pairs. 57 Identifier is a UTF-8 string. The identifier "anyone" is reserved to 58 refer to the universal identity (all authentications, including 59 anonymous). All user name strings accepted by the LOGIN or 60 AUTHENTICATE commands to authenticate to the IMAP server are reserved 61 as identifiers for the corresponding user. Identifiers starting with 62 a dash ("-") are reserved for "negative rights", described below. 63 Identifiers starting with a dollar sign ("$") are reserved for 64 groups. All other identifier strings are interpreted in an 65 implementation-defined manner. 67 Rights is a string listing a (possibly empty) set of alphanumeric 68 characters, each character listing a set of operations which is being 69 controlled. Letters are reserved for ``standard'' rights, listed 70 below. The set of standard rights may only be extended by a 71 standards-track document. Digits are reserved for implementation or 72 site defined rights. The currently defined standard rights are: 74 l - lookup (mailbox is visible to LIST/LSUB commands) 75 r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, 76 SEARCH, COPY from mailbox) 77 s - keep seen/unseen information across sessions (STORE \SEEN flag) 78 w - write (STORE flags other than \SEEN and \DELETED) 79 i - insert (perform APPEND, COPY into mailbox) 80 p - post (send mail to submission address for mailbox, 81 not enforced by IMAP4 itself) 82 c - create and delete mailbox (CREATE new sub-mailboxes in any 83 implementation-defined hierarchy, RENAME or DELETE mailbox) 84 d - delete messages (STORE \DELETED flag, perform EXPUNGE) 85 a - administer (perform SETACL) 87 Internet DRAFT ACL May 23, 2000 89 An implementation may tie rights together or may force rights to 90 always or never be granted to particular identifiers. For example, 91 in an implementation that uses unix mode bits, the rights "wisd" are 92 tied, the "a" right is always granted to the owner of a mailbox and 93 is never granted to another user. If rights are tied in an 94 implementation, the implementation must be conservative in granting 95 rights in response to SETACL commands--unless all rights in a tied 96 set are specified, none of that set should be included in the ACL 97 entry for that identifier. A client may discover the set of rights 98 which may be granted to a given identifier in the ACL for a given 99 mailbox by using the LISTRIGHTS command. 101 When an identifier in an ACL starts with a dash ("-"), that indicates 102 that associated rights are to be removed from the identifier that is 103 prefixed by the dash. This is referred to as a "negative right". For 104 example, if the identifier "-fred" is granted the "w" right, that 105 indicates that the "w" right is to be removed from users matching the 106 identifier "fred". Server implementations are not required to 107 support having identifiers which start with a dash in ACLs. 109 It is possible for multiple identifiers in an access control list to 110 apply to a given user (or other authentication identity). For 111 example, an ACL may include rights to be granted to the identifier 112 matching the user, one or more implementation-defined identifiers 113 matching groups which include the user, and/or the identifier 114 "anyone". These rights are combined by taking the union of the 115 rights granted to the applicable identifiers and then removing the 116 union of the negative rights applying to the applicable identifiers. 118 A client may determine the set of rights granted to the logged-in 119 user for a given mailbox by using the MYRIGHTS command. 121 Internet DRAFT ACL May 23, 2000 123 4. Commands 125 4.1. SETACL 127 Arguments: mailbox name 128 authentication identifier 129 access right modification 131 Data: no specific data for this command 133 Result: OK - setacl completed 134 NO - setacl failure: can't set acl 135 BAD - command unknown or arguments invalid 137 The SETACL command changes the access control list on the 138 specified mailbox so that the specified identifier is granted 139 permissions as specified in the third argument. 141 The third argument is a string containing an optional plus ("+") 142 or minus ("-") prefix, followed by zero or more rights characters. 143 If the string starts with a plus, the following rights are added 144 to any existing rights for the identifier. If the string starts 145 with a minus, the following rights are removed from any existing 146 rights for the identifier. If the string does not start with a 147 plus or minus, the rights replace any existing rights for the 148 identifier. 150 4.2. DELETEACL 152 Arguments: mailbox name 153 authentication identifier 155 Data: no specific data for this command 157 Result: OK - deleteacl completed 158 NO - deleteacl failure: can't delete acl 159 BAD - command unknown or arguments invalid 161 The DELETEACL command removes any pair for the 162 specified identifier from the access control list for the 163 specified mailbox. 165 Internet DRAFT ACL May 23, 2000 167 4.3. GETACL 169 Arguments: mailbox name 171 Data: untagged responses: ACL 173 Result: OK - getacl completed 174 NO - getacl failure: can't get acl 175 BAD - command unknown or arguments invalid 177 The GETACL command returns the access control list for mailbox in 178 an untagged ACL reply. 180 Example: C: A002 GETACL INBOX 181 S: * ACL INBOX Fred rwipslda 182 S: A002 OK Getacl complete 184 4.4. LISTRIGHTS 186 Arguments: mailbox name 187 authentication identifier 189 Data: untagged responses: LISTRIGHTS 191 Result: OK - listrights completed 192 NO - listrights failure: can't get rights list 193 BAD - command unknown or arguments invalid 195 The LISTRIGHTS command takes a mailbox name and an identifier and 196 returns information about what rights may be granted to the 197 identifier in the ACL for the mailbox. 199 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 200 S: * LISTRIGHTS ~/Mail/saved smith la r swicd 201 S: a001 OK Listrights completed 203 C: a005 LISTRIGHTS archive.imap anyone 204 S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a 205 0 1 2 3 4 5 6 7 8 9 206 S: a005 OK Listrights completed 208 Internet DRAFT ACL May 23, 2000 210 4.5. MYRIGHTS 212 Arguments: mailbox name 214 Data: untagged responses: MYRIGHTS 216 Result: OK - myrights completed 217 NO - myrights failure: can't get rights 218 BAD - command unknown or arguments invalid 220 The MYRIGHTS command returns the set of rights that the user has 221 to mailbox in an untagged MYRIGHTS reply. 223 Example: C: A003 MYRIGHTS INBOX 224 S: * MYRIGHTS INBOX rwipslda 225 S: A003 OK Myrights complete 227 5. Responses 229 5.1. ACL 231 Data: mailbox name 232 zero or more identifier rights pairs 234 The ACL response occurs as a result of a GETACL command. The 235 first string is the mailbox name for which this ACL applies. This 236 is followed by zero or more pairs of strings, each pair contains 237 the identifier for which the entry applies followed by the set of 238 rights that the identifier has. 240 5.2. LISTRIGHTS 242 Data: mailbox name 243 identifier 244 required rights 245 list of optional rights 247 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 248 command. The first two strings are the mailbox name and 249 identifier for which this rights list applies. Following the 250 identifier is a string containing the (possibly empty) set of 251 rights the identifier will always be granted in the mailbox. 253 Internet DRAFT ACL May 23, 2000 255 Following this are zero or more strings each containing a set of 256 rights the identifier may be granted in the mailbox. Rights 257 mentioned in the same string are tied together--either all must be 258 granted to the identifier in the mailbox or none may be granted. 260 The same right may not be listed more than once in the LISTRIGHTS 261 command. 263 5.3. MYRIGHTS 265 Data: mailbox name 266 rights 268 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 269 The first string is the mailbox name for which these rights apply. 270 The second string is the set of rights that the client has. 272 6. Formal Syntax 274 The following syntax specification uses the augmented Backus-Naur 275 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 276 Non-terminals referenced but not defined below are as defined by 277 [IMAP4]. 279 Except as noted otherwise, all alphabetic characters are 280 case-insensitive. The use of upper or lower case characters to 281 define token strings is for editorial clarity only. Implementations 282 MUST accept these strings in a case-insensitive fashion. 284 acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE rights) 286 deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier 288 getacl ::= "GETACL" SPACE mailbox 290 identifier ::= astring 291 ;; UTF-8 293 listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 295 listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 296 SPACE rights *(SPACE rights) 298 mod_rights ::= astring 299 ;; +rights to add, -rights to remove 301 Internet DRAFT ACL May 23, 2000 303 ;; rights to replace 305 myrights ::= "MYRIGHTS" SPACE mailbox 307 myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights 309 rights ::= astring 311 setacl ::= "SETACL" SPACE mailbox SPACE identifier SPACE mod_rights 313 7. References 315 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 316 RFC 1730, University of Washington, December 1994. 318 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 319 Messages", STD 11, RFC 822. 321 [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISP 10646", 322 RFC 2279. 324 8. Security Considerations 326 An implementation must make sure the ACL commands themselves do not 327 give information about mailboxes with appropriately restricted ACL's. 328 For example, a GETACL command on a mailbox for which the user has 329 insufficient rights should not admit the mailbox exists, much less 330 return the mailbox's ACL. 332 9. Author's Address 334 John G. Myers 335 Carnegie-Mellon University 336 5000 Forbes Ave. 337 Pittsburgh PA, 15213-3890 339 Email: jgm+@cmu.edu 341 Appendix A. Changes since RFC 2086 343 1. Changed the charset of "identifier" from US-ASCII to UTF-8 345 2. Specified that identifiers starting with a dollar sign ("$") are 346 reserved for groups 348 3. Specified that mailbox deletion is controled by the "c" right. 350 Internet DRAFT ACL May 23, 2000 352 4. Required servers to implement "union of rights minus union of 353 negative rights" for evaluating ACLs. 355 Internet DRAFT ACL May 23, 2000 357 TTTTaaaabbbblllleeee ooooffff CCCCoooonnnntttteeeennnnttttssss 359 Status of this Memo ............................................... i 360 1. Abstract ..................................................... 2 361 2. Conventions Used in this Document ............................ 2 362 3. Introduction and Overview .................................... 2 363 4. Commands ..................................................... 4 364 4.1. SETACL ....................................................... 4 365 4.2. DELETEACL .................................................... 4 366 4.3. GETACL ....................................................... 4 367 4.4. LISTRIGHTS ................................................... 5 368 4.5. MYRIGHTS ..................................................... 5 369 5. Responses .................................................... 6 370 5.1. ACL .......................................................... 6 371 5.2. LISTRIGHTS ................................................... 6 372 5.3. MYRIGHTS ..................................................... 7 373 6. Formal Syntax ................................................ 7 374 7. References ................................................... 8 375 8. Security Considerations ...................................... 8 376 9. Author's Address ............................................. 8 377 Appendix A. Changes since RFC 2086 ................................ 8