idnits 2.17.1 draft-myers-imap-acl-02.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. ** 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 278: '... 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 (June 1996) is 10176 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 1730 (ref. 'IMAP4') (Obsoleted by RFC 2060, RFC 2061) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) Summary: 14 errors (**), 0 flaws (~~), 1 warning (==), 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-acl-02.txt June 1996 5 IMAP4 ACL 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 December 1996. Distribution of this draft is 29 unlimited. 31 Internet DRAFT ACL June 3, 1996 33 1. Abstract 35 The ACL extension of the Internet Message Access Protocol [IMAP4] 36 permits access control lists to be manipulated through the IMAP 37 protocol. 39 2. Conventions Used in this Document 41 In examples, "C:" and "S:" indicate lines sent by the client and 42 server respectively. 44 3. Introduction and Overview 46 The ACL extension is present in any IMAP4 implementation which 47 returns "ACL" as one of the supported capabilities to the CAPABILITY 48 command. 50 An access control list is a set of pairs. 52 Identifier is a US-ASCII string. The identifier anyone is reserved 53 to refer to the universal identity (all authentications, including 54 anonymous). All user name strings accepted by the LOGIN or 55 AUTHENTICATE commands to authenticate to the IMAP server are reserved 56 as identifiers to refer to the corresponding user. All other 57 identifier strings have implementation-defined semantics. 59 Possible variations of identifier interpretation include, but are not 60 limited to: 62 * Named groups of users, presumably managed by some 63 authorization service. 65 * A prefix to the identifier specifying an "authentication 66 type". 68 As an example, an implementation may control posting to a group 69 based on the contents of the From: header: 71 from$user p 73 * Whether the union of rights for matching identifiers are granted 74 to a user or whether the rights for the most specific matching 75 identifier is granted. 77 As an example, for a mailbox with the following ACL: 79 user lrsa 80 group-user-is-in lrsw 82 Internet DRAFT ACL June 3, 1996 84 One implementation may grant the user 'lrswa' rights, another 85 may only grant the user 'lrsa' rights. 87 * A prefix to an identifier name specifying the listed rights 88 are to be removed from users who match the prefixed identifier. 90 As an example, for a mailbox with the following ACL: 92 group-user-is-in lrsw 93 -user w 95 An implementation may grant the user 'lrs' rights. 97 Rights is a string listing a (possibly empty) set of alphanumeric 98 characters, each character listing a set of operations which is being 99 controlled. Letters are reserved for ``standard'' rights, listed 100 below. Digits are reserved for implementation or site defined 101 rights. The standard rights are: 103 l - lookup (mailbox is visible to LIST/LSUB commands) 104 r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL, 105 SEARCH, COPY from mailbox) 106 s - keep seen/unseen information across sessions (STORE \SEEN flag) 107 w - write (STORE flags other than \SEEN and \DELETED) 108 i - insert (perform APPEND, COPY into mailbox) 109 p - post (send mail to submission address for mailbox, 110 not enforced by IMAP4 itself) 111 c - create (CREATE new sub-mailboxes in any implementation-defined 112 hierarchy) 113 d - delete (STORE \DELETED flag, perform EXPUNGE) 114 a - administer (perform SETACL) 116 An implementation may tie rights together or may force rights to 117 always or never be granted. For example, in an implementation that 118 uses unix mode bits, the rights "wisd" are tied, the "a" right is 119 always granted to the owner and is never granted to another user. If 120 rights are tied in an implementation, it should be conservative in 121 granting rights in response to SETACL commands--unless all rights in 122 a tied set are specified, none should be used. 124 Internet DRAFT ACL June 3, 1996 126 4. Commands 128 4.1. SETACL 130 Arguments: mailbox name 131 authentication identifier 132 access rights 134 Data: no specific data for this command 136 Result: OK - setacl completed 137 NO - setacl failure: can't set acl 138 BAD - command unknown or arguments invalid 140 The SETACL command changes the access control list on the 141 specified mailbox so that the specified identifier is granted the 142 permissions enumerated in rights. 144 4.2. DELETEACL 146 Arguments: mailbox name 147 authentication identifier 149 Data: no specific data for this command 151 Result: OK - deleteacl completed 152 NO - deleteacl failure: can't delete acl 153 BAD - command unknown or arguments invalid 155 The DELETEACL command removes any portion of the access control 156 list for mailbox for the specified identifier. 158 4.3. GETACL 160 Arguments: mailbox name 162 Data: untagged responses: ACL 164 Result: OK - getacl completed 165 NO - getacl failure: can't get acl 166 BAD - command unknown or arguments invalid 168 The GETACL command returns the access control list for mailbox in 170 Internet DRAFT ACL June 3, 1996 172 an untagged ACL reply. 174 Example: C: A002 GETACL INBOX 175 S: * ACL INBOX Fred rwipslda 176 S: A002 OK Getacl complete 178 4.4. LISTRIGHTS 180 Arguments: mailbox name 181 authentication identifier 183 Data: untagged responses: LISTRIGHTS 185 Result: OK - listrights completed 186 NO - listrights failure: can't get rights list 187 BAD - command unknown or arguments invalid 189 Example: C: a001 LISTRIGHTS ~/Mail/saved smith 190 S: * LISTRIGHTS ~/Mail/saved smith la r swicd 191 S: a001 OK Listrights completed 193 C: a005 LISTRIGHTS archive.imap anyone 194 S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a 0 1 195 2 3 4 5 6 7 8 9 196 S: a005 OK Listrights completed 198 The LISTRIGHTS command takes a mailbox name and an identifier and 199 returns information about what rights may be granted to the 201 4.5. MYRIGHTS 203 Arguments: mailbox name 205 Data: untagged responses: MYRIGHTS 207 Result: OK - myrights completed 208 NO - myrights failure: can't get rights 209 BAD - command unknown or arguments invalid 211 The MYRIGHTS command returns the set of rights that the user has 212 to mailbox in an untagged MYRIGHTS reply. 214 Example: C: A003 MYRIGHTS INBOX 215 S: * MYRIGHTS INBOX rwipslda 217 Internet DRAFT ACL June 3, 1996 219 S: A003 OK Myrights complete 221 5. Responses 223 5.1. ACL 225 Data: mailbox name 226 zero or more identifier rights pairs 228 The ACL response occurs as a result of a GETACL command. The 229 first string is the mailbox name for which this ACL entry applies. 230 This is followed by zero or more pairs of strings, each pair 231 contains the identifier for which the entry applies followed by 232 the set of rights that the identifier has. 234 5.2. LISTRIGHTS 236 Data: mailbox name 237 identifier 238 required rights 239 list of optional rights 241 The LISTRIGHTS response occurs as a result of a LISTRIGHTS 242 command. The first two strings are the mailbox name and 243 identifier for which this rights list applies. Following the 244 identifier is a string containing the (possibly empty) set of 245 rights the identifier will always be granted in the mailbox. 247 Following this are zero or more strings each containing a set of 248 rights the identifier may be granted in the mailbox. Rights 249 mentioned in the same string are tied together--either all must be 250 granted to the identifier in the mailbox or none may be granted. 252 The same right may not be listed more than once in the LISTRIGHTS 253 command. 255 5.3. MYRIGHTS 257 Data: mailbox name 258 rights 260 The MYRIGHTS response occurs as a result of a MYRIGHTS command. 261 The first string is the mailbox name for which this ACL entry 263 Internet DRAFT ACL June 3, 1996 265 applies. The second string is the set of rights that the client 266 has. 268 6. Formal Syntax 270 The following syntax specification uses the augmented Backus-Naur 271 Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4]. 272 Non-terminals referenced but not defined below are as defined by 273 [IMAP4]. 275 Except as noted otherwise, all alphabetic characters are 276 case-insensitive. The use of upper or lower case characters to 277 define token strings is for editorial clarity only. Implementations 278 MUST accept these strings in a case-insensitive fashion. 280 acl_data ::= "ACL" SPACE mailbox *(SPACE identifier SPACE rights) 282 deleteacl ::= "DELETEACL" SPACE mailbox SPACE identifier 284 getacl ::= "GETACL" SPACE mailbox 286 identifier ::= astring 288 listrights ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 290 listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier 291 SPACE rights *(SPACE rights) 293 myrights ::= "MYRIGHTS" SPACE mailbox 295 myrights_data ::= "MYRIGHTS" SPACE mailbox SPACE rights 297 rights ::= astring 299 setacl ::= "SETACL" SPACE mailbox SPACE identifier SPACE rights 301 7. References 303 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4", 304 RFC 1730, University of Washington, December 1994. 306 [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text 307 Messages", STD 11, RFC 822. 309 Internet DRAFT ACL June 3, 1996 311 8. Security Considerations 313 An implementation must make sure the ACL commands themselves do not 314 give information about mailboxes with appropriately restricted ACL's. 315 For example, a GETACL command on a mailbox for which the user has 316 insufficient rights should not admit the mailbox exists, much less 317 return the mailbox's ACL. 319 9. Author's Address 321 John G. Myers 322 Carnegie-Mellon University 323 5000 Forbes Ave. 324 Pittsburgh PA, 15213-3890 326 Email: jgm+@cmu.edu 328 Internet DRAFT ACL June 3, 1996 330 Table of Contents 332 Status of this Memo ............................................... i 333 1. Abstract ..................................................... 2 334 2. Conventions Used in this Document ............................ 2 335 3. Introduction and Overview .................................... 2 336 4. Commands ..................................................... 4 337 4.1. SETACL ....................................................... 4 338 4.2. DELETEACL .................................................... 4 339 4.3. GETACL ....................................................... 4 340 4.4. LISTRIGHTS ................................................... 5 341 4.5. MYRIGHTS ..................................................... 5 342 5. Responses .................................................... 6 343 5.1. ACL .......................................................... 6 344 5.2. LISTRIGHTS ................................................... 6 345 5.3. MYRIGHTS ..................................................... 6 346 6. Formal Syntax ................................................ 7 347 7. References ................................................... 7 348 8. Security Considerations ...................................... 8 349 9. Author's Address ............................................. 8