idnits 2.17.1 draft-melnikov-acl-rights-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 177. -- Found old boilerplate from RFC 3978, Section 5.5 on line 213. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 1) being 234 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** There are 36 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 2004) is 7071 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: 'ABNF' is defined on line 144, but no explicit reference was found in the text == Unused Reference: 'IMAP4' is defined on line 148, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2234 (ref. 'ABNF') (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 3501 (ref. 'IMAP4') (Obsoleted by RFC 9051) -- No information found for draft-ietf-imapext-2086upd-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'ACL' -- No information found for draft-ietf-lemonade-urlauth-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'URLAUTH' -- No information found for draft-ietf-lemonade-catenate-XX - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'CATENATE' Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IMAPEXT Working Group A. Melnikov 2 Internet Draft Isode Ltd. 3 Document: draft-melnikov-acl-rights-00.txt December 2004 4 Updates: 2086 5 Expires: June 2005 7 IMAP4 ACL extension - 8 list of rights for various IMAP commands 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, or 14 will be disclosed, and any of which I become aware will be disclosed, 15 in accordance with RFC 3668. 17 Internet Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its Areas, and its Working Groups. Note that 19 other groups may also distribute working documents as Internet 20 Drafts. Internet Drafts are draft documents valid for a maximum of 21 six months. Internet Drafts may be updated, replaced, or obsoleted 22 by other documents at any time. It is not appropriate to use 23 Internet Drafts as reference material or to cite them other than as 24 ``work in progress''. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 33 munnari.oz.au. 35 A revised version of this draft document will be submitted to the RFC 36 editor as a Proposed Standard for the Internet Community. Discussion 37 and suggestions for improvement are requested. Distribution of this 38 draft is unlimited. 40 Abstract 42 This document lists Access Control rights (RFC 2086) required for 43 various IMAP extensions. 45 1. Conventions Used in this Document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in RFC 2119 [KEYWORDS]. 51 2. Rights required to perform different IMAP commands 53 Before executing a command an ACL compliant server must check which rights 54 are required to perform it. This section groups command by functions 55 they perform and list the rights required. It also gives the detailed 56 description of any special processing required. 58 For the purpose of this section the UID counterpart of a command is 59 considered to be the same command, e.g. both UID COPY and COPY commands 60 require the same set of rights. 62 The tables listed in subsections of this section summarize different rights 63 or their combinations that are required in order to perform different IMAP 64 operations. As it is not always possible to express complex right checking 65 and interactions, the description after the table should be used as the 66 primary reference. 68 All tables use the following legend: 69 + - The right is required 70 * - Only one of the rights marked with * is required (see description below) 71 ? - The right is optional (see description below) 72 "Any" - at least one of the "l", "r", "i", "c", "x", "a" rights is 73 required 74 "None" - No rights required to perform the command 76 2.1. Servers that also implement URLAUTH extension 78 Servers that implement both [ACL] and the URLAUTH [URLAUTH] extensions MUST 79 use the following table to check if the client is allowed to perform a 80 particular IMAP command described in the URLAUTH document. 82 The table uses the conventions defined in section 2. 84 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 85 | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | 86 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 87 | RESETKEY | | + | | | | | | | | | | | 88 | GENURLAUTH | | + | | | | | | | | | | | 89 | URLFETCH | | | | | | | | | | | | + | 90 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 92 RESETKEY - "r" right is required for each mailbox affected by the command. 93 In particular the RESETKEY MUST NOT reset keys on mailboxes that 94 can't be SELECT/EXAMINEd by the current user. 96 GENURLAUTH - "r" right is required for each mailbox referenced in the URL(s) 97 specified as parameter(s) to the GENURLAUTH command. 99 URLFETCH - no rights required to perform this operation. 101 2.2. Servers that also implement CATENATE extension 103 Servers that implement both [ACL] and the [CATENATE] extensions MUST 104 use the following table to check if the client is allowed to perform a 105 particular IMAP command described in the CATENATE document. 107 The table uses the conventions defined in section 2. 109 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 110 | Operations\Rights | l | r | s | w | i | c | x | t | e | a | Any | None | 111 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 112 | CATENATE | | | ? | ? | + | | | ? | | | | | 113 +---------------------+---+---+---+---+---+---+---+---+---+---+-----+------+ 115 CATENATE command obey the same set of access control rules as the APPEND 116 command. The rules are summarized in this section. 118 Before performing a CATENATE command the server MUST check if the 119 user has the "i" right for the target mailbox. If the user doesn't have the 120 "i" right, the operation fails. Otherwise for each catenated message 121 the server MUST check if the user has 122 "t" right - when the message has \Deleted flag set 123 "s" right - when the message has \Seen flag set 124 "w" right for all other message flags. 125 Only when the user has a particular right the corresponding flags are 126 stored for the newly created message. The server MUST NOT fail 127 a CATENATE if the user has no rights to set a particular flag. 129 3. Security Considerations 131 <> 133 4. IANA Considerations 135 This document doesn't have any IANA considerations. 137 5. References 139 5.1. Normative References 141 [KEYWORDS] Bradner, "Key words for use in RFCs to Indicate 142 Requirement Levels", RFC 2119, Harvard University, March 1997. 144 [ABNF] Crocker, Overell, "Augmented BNF for Syntax Specifications: 145 ABNF", RFC 2234, Internet Mail Consortium, Demon Internet Ltd, 146 November 1997. 148 [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 149 4rev1", RFC 3501, University of Washington, March 2003. 151 [ACL] Melnikov, A., "IMAP4 ACL extension", work in progress, 152 draft-ietf-imapext-2086upd-XX.txt. 154 [URLAUTH] Crispin, M., "Internet Message Access Protocol (IMAP) - 155 URLAUTH Extension", work in progress, draft-ietf-lemonade-urlauth-XX.txt 157 [CATENATE] Resnick, P., "Internet Message Access Protocol (IMAP) 158 CATENATE Extension", work in progress, draft-ietf-lemonade-catenate-XX.txt 160 6. Acknowledgment 162 Editor appreciates comments received from Mark Crispin and other 163 participants of the IMAPEXT working group. 165 7. Editor's Address 167 Alexey Melnikov 168 email: alexey.melnikov@isode.com 170 Isode Limited 172 8. IPR Disclosure Acknowledgement 174 By submitting this Internet-Draft, I certify that any applicable 175 patent or other IPR claims of which I am aware have been disclosed, 176 and any of which I become aware will be disclosed, in accordance with 177 RFC 3668. 179 9. Intellectual Property Statement 181 The IETF takes no position regarding the validity or scope of any 182 intellectual property or other rights that might be claimed to 183 pertain to the implementation or use of the technology described in 184 this document or the extent to which any license under such rights 185 might or might not be available; neither does it represent that it 186 has made any effort to identify any such rights. Information on the 187 IETF's procedures with respect to rights in standards-track and 188 standards-related documentation can be found in BCP-11. Copies of 189 claims of rights made available for publication and any assurances of 190 licenses to be made available, or the result of an attempt made to 191 obtain a general license or permission for the use of such 192 proprietary rights by implementors or users of this specification can 193 be obtained from the IETF Secretariat. 195 The IETF invites any interested party to bring to its attention any 196 copyrights, patents or patent applications, or other proprietary 197 rights which may cover technology that may be required to practice 198 this standard. Please address the information to the IETF Executive 199 Director. 201 10. Full Copyright Statement 203 Copyright (C) The Internet Society (2004). This document is subject 204 to the rights, licenses and restrictions contained in BCP 78 and 205 except as set forth therein, the authors retain all their rights. 207 This document and the information contained herein are provided on an 208 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 209 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 210 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 211 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 212 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 213 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 215 Acknowledgement 217 Funding for the RFC Editor function is currently provided by the 218 Internet Society.