doc: Add RFC documents

1 files changed, 1515 insertions, 0 deletions

diff --git a/doc/rfc/rfc4314.txt b/doc/rfc/rfc4314.txt
new file mode 100644
index 0000000..e73a56f
--- /dev/null
+++ b/doc/rfc/rfc4314.txt
@@ -0,0 +1,1515 @@
+
+
+
+
+
+
+Network Working Group                                        A. Melnikov
+Request for Comments: 4314                                    Isode Ltd.
+Obsoletes: 2086                                            December 2005
+Category: Standards Track
+
+
+               IMAP4 Access Control List (ACL) Extension
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2005).
+
+Abstract
+
+   The Access Control List (ACL) extension (RFC 2086) of the Internet
+   Message Access Protocol (IMAP) permits mailbox access control lists
+   to be retrieved and manipulated through the IMAP protocol.
+
+   This document is a revision of RFC 2086.  It defines several new
+   access control rights and clarifies which rights are required for
+   different IMAP commands.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 1]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Table of Contents
+
+   1. Introduction and Overview .......................................3
+      1.1. Conventions Used in This Document ..........................3
+   2. Access Control ..................................................3
+      2.1. Standard Rights ............................................5
+           2.1.1. Obsolete Rights .....................................5
+      2.2. Rights Defined in RFC 2086 .................................8
+   3. Access control management commands and responses ................8
+      3.1. SETACL Command .............................................8
+      3.2. DELETEACL Command ..........................................9
+      3.3. GETACL Command ............................................10
+      3.4. LISTRIGHTS Command ........................................10
+      3.5. MYRIGHTS Command ..........................................11
+      3.6. ACL Response ..............................................11
+      3.7. LISTRIGHTS Response .......................................12
+      3.8. MYRIGHTS Response .........................................12
+   4. Rights Required to Perform Different IMAP4rev1 Commands ........12
+   5. Other Considerations ...........................................17
+      5.1. Additional Requirements and Implementation Notes ..........17
+           5.1.1. Servers ............................................17
+           5.1.2. Clients ............................................18
+      5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
+           Response Codes ............................................19
+   6. Security Considerations ........................................20
+   7. Formal Syntax ..................................................21
+   8. IANA Considerations ............................................22
+   9. Internationalization Considerations ............................22
+   Appendix A. Changes since RFC 2086 ................................23
+   Appendix B. Compatibility with RFC 2086 ...........................24
+   Appendix C. Known Deficiencies ....................................24
+   Appendix D. Acknowledgements ......................................25
+   Normative References ..............................................25
+   Informative References ............................................25
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 2]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+1.  Introduction and Overview
+
+   The ACL (Access Control List) extension of the Internet Message
+   Access Protocol [IMAP4] permits mailbox access control lists to be
+   retrieved and manipulated through the IMAP protocol.
+
+   This document is a revision of RFC 2086 [RFC2086].  It tries to
+   clarify different ambiguities in RFC 2086, in particular, the use of
+   UTF-8 [UTF-8] in access identifiers, which rights are required for
+   different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes
+   are related to ACL.
+
+1.1.  Conventions Used in This Document
+
+   In examples, "C:" and "S:" indicate lines sent by the client and
+   server respectively.
+
+   In all examples "/" character is used as hierarchy separator.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [KEYWORDS].
+
+   The phrase "ACL server" is just a shortcut for saying "IMAP server
+   that supports ACL extension as defined in this document".
+
+2.  Access Control
+
+   The ACL extension is present in any IMAP4 implementation that returns
+   "ACL" as one of the supported capabilities to the CAPABILITY command.
+
+   A server implementation conformant to this document MUST also return
+   rights (see below) not defined in Section 2.2 in the "RIGHTS="
+   capability.
+
+   An access control list is a set of <access identifier,rights> pairs.
+   An ACL applies to a mailbox name.
+
+   Access identifier (or just "identifier") is a UTF-8 [UTF-8] string.
+   The identifier "anyone" is reserved to refer to the universal
+   identity (all authentications, including anonymous).  All user name
+   strings accepted by the LOGIN or AUTHENTICATE commands to
+   authenticate to the IMAP server are reserved as identifiers for the
+   corresponding users.  Identifiers starting with a dash ("-") are
+   reserved for "negative rights", described below.  All other
+   identifier strings are interpreted in an implementation-defined
+   manner.
+
+
+
+
+Melnikov                    Standards Track                     [Page 3]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Rights is a string listing a (possibly empty) set of alphanumeric
+   characters, each character listing a set of operations that is being
+   controlled.  Lowercase letters are reserved for "standard" rights,
+   listed in Section 2.1.  (Note that for compatibility with deployed
+   clients and servers uppercase rights are not allowed.)  The set of
+   standard rights can only be extended by a standards-track document.
+   Digits are reserved for implementation- or site-defined rights.
+
+   An implementation MAY tie rights together or MAY force rights to
+   always or never be granted to particular identifiers.  For example,
+   in an implementation that uses UNIX mode bits, the rights "swite" are
+   tied, the "a" right is always granted to the owner of a mailbox and
+   is never granted to another user.  If rights are tied in an
+   implementation, the implementation must be conservative in granting
+   rights in response to SETACL commands--unless all rights in a tied
+   set are specified, none of that set should be included in the ACL
+   entry for that identifier.  A client can discover the set of rights
+   that may be granted to a given identifier in the ACL for a given
+   mailbox name by using the LISTRIGHTS command.
+
+   It is possible for multiple identifiers in an access control list to
+   apply to a given user.  For example, an ACL may include rights to be
+   granted to the identifier matching the user, one or more
+   implementation-defined identifiers matching groups that include the
+   user, and/or the identifier "anyone".  How these rights are combined
+   to determine the user's access is implementation defined.  An
+   implementation may choose, for example, to use the union of the
+   rights granted to the applicable identifiers.  An implementation may
+   instead choose, for example, to use only those rights granted to the
+   most specific identifier present in the ACL.  A client can determine
+   the set of rights granted to the logged-in user for a given mailbox
+   name by using the MYRIGHTS command.
+
+   When an identifier in an ACL starts with a dash ("-"), that indicates
+   that associated rights are to be removed from the identifier prefixed
+   by the dash.  This is referred to as a "negative right".  This
+   differs from DELETEACL in that a negative right is added to the ACL
+   and is a part of the calculation of the rights.
+
+   Let's assume that an identifier "fred" refers to a user with login
+   "fred".  If the identifier "-fred" is granted the "w" right, that
+   indicates that the "w" right is to be removed from users matching the
+   identifier "fred", even though the user "fred" might have the "w"
+   right as a consequence of some other identifier in the ACL.  A
+   DELETEACL of "fred" simply deletes the identifier "fred" from the
+   ACL; it does not affect any rights that the user "fred" may get from
+   another entry in the ACL, in particular it doesn't affect rights
+   granted to the identifier "-fred".
+
+
+
+Melnikov                    Standards Track                     [Page 4]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Server implementations are not required to support "negative right"
+   identifiers.
+
+2.1.  Standard Rights
+
+   The currently defined standard rights are (note that the list below
+   doesn't list all commands that use a particular right):
+
+   l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
+       mailbox)
+   r - read (SELECT the mailbox, perform STATUS)
+   s - keep seen/unseen information across sessions (set or clear
+       \SEEN flag via STORE, also set \SEEN during APPEND/COPY/
+       FETCH BODY[...])
+   w - write (set or clear flags other than \SEEN and \DELETED via
+       STORE, also set them during APPEND/COPY)
+   i - insert (perform APPEND, COPY into mailbox)
+   p - post (send mail to submission address for mailbox,
+       not enforced by IMAP4 itself)
+   k - create mailboxes (CREATE new sub-mailboxes in any
+       implementation-defined hierarchy, parent mailbox for the new
+       mailbox name in RENAME)
+   x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
+   t - delete messages (set or clear \DELETED flag via STORE, set
+       \DELETED flag during APPEND/COPY)
+   e - perform EXPUNGE and expunge as a part of CLOSE
+   a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)
+
+2.1.1.  Obsolete Rights
+
+   Due to ambiguity in RFC 2086, some existing RFC 2086 server
+   implementations use the "c" right to control the DELETE command.
+   Others chose to use the "d" right to control the DELETE command.  For
+   the former group, let's define the "create" right as union of the "k"
+   and "x" rights, and the "delete" right as union of the "e" and "t"
+   rights.  For the latter group, let's define the "create" rights as a
+   synonym to the "k" right, and the "delete" right as union of the "e",
+   "t", and "x" rights.
+
+   For compatibility with RFC 2086, this section defines two virtual
+   rights "d" and "c".
+
+   If a client includes the "d" right in a rights list, then it MUST be
+   treated as if the client had included every member of the "delete"
+   right.  (It is not an error for a client to specify both the "d"
+   right and one or more members of the "delete" right, but the effect
+   is no different than if just the "d" right or all members of the
+   "delete" right had been specified.)
+
+
+
+Melnikov                    Standards Track                     [Page 5]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   When any of the "delete" member rights is set in a list of rights,
+   the server MUST also include the "d" right when returning the list in
+   a MYRIGHTS or ACL response.  This is to enable older clients
+   conforming to RFC 2086 to work with newer servers. (*)
+
+   Example:    C: A001 SeTacl INBOX/Drafts David lrswida
+               S: A001 OK Setacl complete
+
+   The client has specified the "d" right in the SETACL command above
+   and it expands to "et" on the server:
+
+               C: A002 getacl INBOX/Drafts
+               S: * ACL INBOX Fred rwipslxcetda David lrswideta
+               S: A002 OK Getacl complete
+
+   If the identifier specified in the LISTRIGHTS command can be granted
+   any of the "delete" member rights on a mailbox, then the server MUST
+   include the "d" right in the corresponding LISTRIGHTS response. (*)
+   If the member rights aren't tied to non-member rights, then the "d"
+   right is returned by itself in the LISTRIGHTS response.  If any of
+   the member rights needs to be tied to one (or more) non-member right,
+   then the "d" right and all of the member rights need to be tied to
+   the same non-member right(s) (**).
+
+   If a client includes the "c" right in a rights list, then it MUST be
+   treated as if the client had included every member of the "create"
+   right.  (It is not an error for a client to specify both the "c"
+   right and one or more members of the "create" right, but the effect
+   is no different than if just the "c" right or all members of the
+   "create" right had been specified.)
+
+   When any of the "create" member rights is set in a list of rights,
+   the server MUST also include the "c" right when returning the list in
+   a MYRIGHTS or ACL response.  This is to enable older clients
+   conforming to RFC 2086 to work with newer servers. (*)
+
+   Example:    C: A003 Setacl INBOX/Drafts Byron lrswikda
+               S: A001 OK Setacl complete
+               C: A002 getAcl INBOX/Drafts
+               S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
+               S: A002 OK Getacl complete
+
+   The client has specified the "d" right in the SETACL command above
+   and it expands to "et" on the server: As the client has specified the
+   "k" right (which is a member of the "c" right), the server also
+   returns the "c" right.
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 6]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   If the identifier specified in the LISTRIGHTS command can be granted
+   any of the "create" member rights on a mailbox, then the server MUST
+   include the "c" right in the corresponding LISTRIGHTS response. (*)
+   If the member rights aren't tied to non-member rights, then the "c"
+   right is returned by itself in the LISTRIGHTS response.  If any of
+   the member rights needs to be tied to one (or more) non-member right,
+   then the "c" right and all of the member rights need to be tied to
+   the same non-member right(s) (**).
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k x t
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k x t c d
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k xte
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k xte c d
+
+   Example: The server that ties the rights as follows:
+
+               lr s w i p k x te
+
+            and c=k
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr s w i p k c x te d
+
+   Example: The server that ties the rights as follows:
+
+               lr swte i p k x
+
+            and c=kx
+
+
+
+
+Melnikov                    Standards Track                     [Page 7]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+            will return:
+
+               S: * LISTRIGHTS archive/imap anyone ""
+                  lr swted i p k x c
+
+   (*)  Clients conforming to this document MUST ignore the virtual "d"
+        and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
+
+   (**) The IMAPEXT Working Group has debated this issue in great length
+        and after reviewing existing ACL implementations concluded that
+        this is a reasonable restriction.
+
+2.2.  Rights Defined in RFC 2086
+
+   The "RIGHTS=" capability MUST NOT include any of the rights defined
+   in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the
+   digits ("0" .. "9").
+
+3.  Access control management commands and responses
+
+   Servers, when processing a command that has an identifier as a
+   parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands),
+   SHOULD first prepare the received identifier using "SASLprep" profile
+   [SASLprep] of the "stringprep" algorithm [Stringprep].  If the
+   preparation of the identifier fails or results in an empty string,
+   the server MUST refuse to perform the command with a BAD response.
+   Note that Section 6 recommends additional identifier's verification
+   steps.
+
+3.1.  SETACL Command
+
+   Arguments:  mailbox name
+               identifier
+               access right modification
+
+   Data:       no specific data for this command
+
+   Result:     OK - setacl completed
+               NO - setacl failure: can't set acl
+               BAD - arguments invalid
+
+   The SETACL command changes the access control list on the specified
+   mailbox so that the specified identifier is granted permissions as
+   specified in the third argument.
+
+   The third argument is a string containing an optional plus ("+") or
+   minus ("-") prefix, followed by zero or more rights characters.  If
+   the string starts with a plus, the following rights are added to any
+
+
+
+Melnikov                    Standards Track                     [Page 8]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   existing rights for the identifier.  If the string starts with a
+   minus, the following rights are removed from any existing rights for
+   the identifier.  If the string does not start with a plus or minus,
+   the rights replace any existing rights for the identifier.
+
+   Note that an unrecognized right MUST cause the command to return the
+   BAD response.  In particular, the server MUST NOT silently ignore
+   unrecognized rights.
+
+   Example:    C: A001 GETACL INBOX/Drafts
+               S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
+               S: A001 OK Getacl complete
+               C: A002 SETACL INBOX/Drafts Chris +cda
+               S: A002 OK Setacl complete
+               C: A003 GETACL INBOX/Drafts
+               S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
+               S: A003 OK Getacl complete
+
+
+               C: A035 SETACL INBOX/Drafts John lrQswicda
+               S: A035 BAD Uppercase rights are not allowed
+
+
+               C: A036 SETACL INBOX/Drafts John lrqswicda
+               S: A036 BAD The q right is not supported
+
+3.2.  DELETEACL Command
+
+   Arguments:  mailbox name
+               identifier
+
+   Data:       no specific data for this command
+
+   Result:     OK - deleteacl completed
+               NO - deleteacl failure: can't delete acl
+              BAD - arguments invalid
+
+   The DELETEACL command removes any <identifier,rights> pair for the
+   specified identifier from the access control list for the specified
+   mailbox.
+
+   Example:    C: B001 getacl INBOX
+               S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
+               S: B001 OK Getacl complete
+               C: B002 DeleteAcl INBOX Fred
+               S: B002 OK Deleteacl complete
+
+
+
+
+
+Melnikov                    Standards Track                     [Page 9]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+               C: B003 GETACL INBOX
+               S: * ACL INBOX -Fred wetd $team w
+               S: B003 OK Getacl complete
+
+3.3.  GETACL Command
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: ACL
+
+   Result:     OK - getacl completed
+               NO - getacl failure: can't get acl
+              BAD - arguments invalid
+
+   The GETACL command returns the access control list for mailbox in an
+   untagged ACL response.
+
+   Some implementations MAY permit multiple forms of an identifier to
+   reference the same IMAP account.  Usually, such implementations will
+   have a canonical form that is stored internally.  An ACL response
+   caused by a GETACL command MAY include a canonicalized form of the
+   identifier that might be different from the one used in the
+   corresponding SETACL command.
+
+   Example:    C: A002 GETACL INBOX
+               S: * ACL INBOX Fred rwipsldexta
+               S: A002 OK Getacl complete
+
+3.4.  LISTRIGHTS Command
+
+   Arguments:  mailbox name
+               identifier
+
+   Data:       untagged responses: LISTRIGHTS
+
+   Result:     OK - listrights completed
+               NO - listrights failure: can't get rights list
+               BAD - arguments invalid
+
+   The LISTRIGHTS command takes a mailbox name and an identifier and
+   returns information about what rights can be granted to the
+   identifier in the ACL for the mailbox.
+
+   Some implementations MAY permit multiple forms of an identifier to
+   reference the same IMAP account.  Usually, such implementations will
+   have a canonical form that is stored internally.  A LISTRIGHTS
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 10]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   response caused by a LISTRIGHTS command MUST always return the same
+   form of an identifier as specified by the client.  This is to allow
+   the client to correlate the response with the command.
+
+   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
+               S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
+               S: a001 OK Listrights completed
+
+   Example:    C: a005 listrights archive/imap anyone
+               S: * LISTRIGHTS archive.imap anyone ""
+                  l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9
+               S: a005 Listrights successful
+
+3.5.  MYRIGHTS Command
+
+   Arguments:  mailbox name
+
+   Data:       untagged responses: MYRIGHTS
+
+   Result:     OK - myrights completed
+               NO - myrights failure: can't get rights
+               BAD - arguments invalid
+
+   The MYRIGHTS command returns the set of rights that the user has to
+   mailbox in an untagged MYRIGHTS reply.
+
+   Example:    C: A003 MYRIGHTS INBOX
+               S: * MYRIGHTS INBOX rwiptsldaex
+               S: A003 OK Myrights complete
+
+3.6.  ACL Response
+
+   Data:       mailbox name
+               zero or more identifier rights pairs
+
+   The ACL response occurs as a result of a GETACL command.  The first
+   string is the mailbox name for which this ACL applies.  This is
+   followed by zero or more pairs of strings; each pair contains the
+   identifier for which the entry applies followed by the set of rights
+   that the identifier has.
+
+   Section 2.1.1 details additional server requirements related to
+   handling of the virtual "d" and "c" rights.
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 11]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+3.7.  LISTRIGHTS Response
+
+   Data:       mailbox name
+               identifier
+               required rights
+               list of optional rights
+
+   The LISTRIGHTS response occurs as a result of a LISTRIGHTS command.
+   The first two strings are the mailbox name and identifier for which
+   this rights list applies.  Following the identifier is a string
+   containing the (possibly empty) set of rights the identifier will
+   always be granted in the mailbox.
+
+   Following this are zero or more strings each containing a set of
+   rights the identifier can be granted in the mailbox.  Rights
+   mentioned in the same string are tied together.  The server MUST
+   either grant all tied rights to the identifier in the mailbox or
+   grant none.  Section 2.1.1 details additional server requirements
+   related to handling of the virtual "d" and "c" rights.
+
+   The same right MUST NOT be listed more than once in the LISTRIGHTS
+   command.
+
+3.8.  MYRIGHTS Response
+
+   Data:       mailbox name
+               rights
+
+   The MYRIGHTS response occurs as a result of a MYRIGHTS command.  The
+   first string is the mailbox name for which these rights apply.  The
+   second string is the set of rights that the client has.
+
+   Section 2.1.1 details additional server requirements related to
+   handling of the virtual "d" and "c" rights.
+
+4.  Rights Required to Perform Different IMAP4rev1 Commands
+
+   Before executing a command, an ACL-compliant server MUST check which
+   rights are required to perform it.  This section groups command by
+   functions they perform and list the rights required.  It also gives
+   the detailed description of any special processing required.
+
+   For the purpose of this section the UID counterpart of a command is
+   considered to be the same command, e.g., both UID COPY and COPY
+   commands require the same set of rights.
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 12]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   The table below summarizes different rights or their combinations
+   that are required in order to perform different IMAP operations.  As
+   it is not always possible to express complex right checking and
+   interactions, the description after the table should be used as the
+   primary reference.
+
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+   |Operations\Rights  | l | r | s | w | i | k | x | t | e | a |Any|Non|
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+   |                  commands in authenticated state                  |
+   +-------------------------------------------------------------------+
+   |      LIST         | + |   |   |   |   |   |   |   |   |   |   |   |
+   |   SUBSCRIBE       | * |   |   |   |   |   |   |   |   |   |   | * |
+   |  UNSUBSCRIBE      |   |   |   |   |   |   |   |   |   |   |   | + |
+   |      LSUB         | * |   |   |   |   |   |   |   |   |   |   | * |
+   |CREATE (for parent)|   |   |   |   |   | + |   |   |   |   |   |   |
+   |     DELETE        |   | ? |   |   |   |   | + | ? | ? |   |   |   |
+   |     RENAME        |   |   |   |   |   | + | + |   |   |   |   |   |
+   |  SELECT/EXAMINE   |   | + |   |   |   |   |   |   |   |   |   |   |
+   |      STATUS       |   | + |   |   |   |   |   |   |   |   |   |   |
+   |  SETACL/DELETEACL |   |   |   |   |   |   |   |   |   | + |   |   |
+   | GETACL/LISTRIGHTS |   |   |   |   |   |   |   |   |   | + |   |   |
+   |     MYRIGHTS      |   |   |   |   |   |   |   |   |   |   | + |   |
+   |      APPEND       |   |   | ? | ? | + |   |   | ? |   |   |   |   |
+   +-------------------------------------------------------------------+
+   |                     commands in selected state                    |
+   +-------------------------------------------------------------------+
+   |       COPY        |   |   | ? | ? | + |   |   | ? |   |   |   |   |
+   |     EXPUNGE       |   |   |   |   |   |   |   |   | + |   |   |   |
+   |      CLOSE        |   |   |   |   |   |   |   |   | ? |   |   |   |
+   |      FETCH        |   |   | ? |   |   |   |   |   |   |   |   |   |
+   |   STORE flags     |   |   | ? | ? |   |   |   | ? |   |   |   |   |
+   +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+
+   Note: for all commands in the selected state, the "r" is implied,
+   because it is required to SELECT/EXAMINE a mailbox.  Servers are not
+   required to check presence of the "r" right once a mailbox is
+   successfully selected.
+
+   Legend:
+    +     - The right is required
+    *     - Only one of the rights marked with * is required
+            (see description below)
+    ?     - The right is OPTIONAL (see description below)
+    "Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
+            required
+    "Non" - No rights required to perform the command
+
+
+
+
+Melnikov                    Standards Track                    [Page 13]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Listing and subscribing/unsubscribing mailboxes:
+      LIST - "l" right is required.  However, unlike other commands
+      (e.g., SELECT) the server MUST NOT return a NO response if it
+      can't list a mailbox.
+      Note that if the user has "l" right to a mailbox "A/B", but not to
+      its parent mailbox "A", the LIST command should behave as if the
+      mailbox "A" doesn't exist, for example:
+
+               C: A777 LIST "" *
+               S: * LIST (\NoInferiors) "/" "A/B"
+               S: * LIST () "/" "C"
+               S: * LIST (\NoInferiors) "/" "C/D"
+               S: A777 OK LIST completed
+
+
+      SUBSCRIBE - "l" right is required only if the server checks for
+      mailbox existence when performing SUBSCRIBE.
+
+      UNSUBSCRIBE - no rights required to perform this operation.
+
+      LSUB - "l" right is required only if the server checks for mailbox
+      existence when performing SUBSCRIBE.  However, unlike other
+      commands (e.g., SELECT) the server MUST NOT return a NO response
+      if it can't list a subscribed mailbox.
+
+   Mailbox management:
+      CREATE - "k" right on a nearest existing parent mailbox.  When a
+      new mailbox is created, it SHOULD inherit the ACL from the parent
+      mailbox (if one exists) in the defined hierarchy.
+
+      DELETE - "x" right on the mailbox.  Note that some servers don't
+      allow to delete a non-empty mailbox.  If this is the case, the
+      user would also need "r", "e", and "t" rights, in order to open
+      the mailbox and empty it.
+
+      The DELETE command MUST delete the ACL associated with the deleted
+      mailbox.
+
+      RENAME - Moving a mailbox from one parent to another requires the
+      "x" right on the mailbox itself and the "k" right for the new
+      parent.  For example, if the user wants to rename the mailbox
+      named "A/B/C" to "D/E", the user must have the "x" right for the
+      mailbox "A/B/C" and the "k" right for the mailbox "D".
+      The RENAME command SHOULD NOT change the ACLs on the renamed
+      mailbox and submailboxes.
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 14]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Copying or appending messages:
+      Before performing a COPY/APPEND command, the server MUST check if
+      the user has "i" right for the target mailbox.  If the user
+      doesn't have "i" right, the operation fails.  Otherwise for each
+      copied/appended message the server MUST check if the user has
+         "t" right - when the message has \Deleted flag set
+         "s" right - when the message has \Seen flag set
+         "w" right - for all other message flags.
+      Only when the user has a particular right are the corresponding
+      flags stored for the newly created message.  The server MUST NOT
+      fail a COPY/APPEND if the user has no rights to set a particular
+      flag.
+
+   Example:    C: A003 MYRIGHTS TargetMailbox
+               S: * MYRIGHTS TargetMailbox rwis
+               S: A003 OK Myrights complete
+
+               C: A004 FETCH 1:3 (FLAGS)
+               S: * 1 FETCH (FLAGS (\Draft \Deleted)
+               S: * 2 FETCH (FLAGS (\Answered)
+               S: * 3 FETCH (FLAGS ($Forwarded \Seen)
+               S: A004 OK Fetch Completed
+
+               C: A005 COPY 1:3 TargetMailbox
+               S: A005 OK Copy completed
+
+               C: A006 SELECT TargetMailbox
+                  ...
+               S: A006 Select Completed
+
+      Let's assume that the copied messages received message numbers
+      77:79.
+
+               C: A007 FETCH 77:79 (FLAGS)
+               S: * 77 FETCH (FLAGS (\Draft))
+               S: * 78 FETCH (FLAGS (\Answered))
+               S: * 79 FETCH (FLAGS ($Forwarded \Seen))
+               S: A007 OK Fetch Completed
+
+      \Deleted flag was lost on COPY, as the user has no "t" right in
+      the target mailbox.
+      If the MYRIGHTS command with the tag A003 would have returned:
+
+               S: * MYRIGHTS TargetMailbox rsti
+
+      the response from the FETCH with the tag A007 would have been:
+
+               C: A007 FETCH 77:79 (FLAGS)
+
+
+
+Melnikov                    Standards Track                    [Page 15]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+               S: * 77 FETCH (FLAGS (\Deleted))
+               S: * 78 FETCH (FLAGS ())
+               S: * 79 FETCH (FLAGS (\Seen))
+               S: A007 OK Fetch Completed
+
+      In the latter case, \Answered, $Forwarded, and \Draft flags were
+      lost on COPY, as the user has no "w" right in the target mailbox.
+
+   Expunging the selected mailbox:
+      EXPUNGE - "e" right on the selected mailbox.
+
+      CLOSE - "e" right on the selected mailbox.  If the server is
+      unable to expunge the mailbox because the user doesn't have the
+      "e" right, the server MUST ignore the expunge request, close the
+      mailbox, and return the tagged OK response.
+
+   Fetch information about a mailbox and its messages:
+      SELECT/EXAMINE/STATUS - "r" right on the mailbox.
+
+      FETCH - A FETCH request that implies setting \Seen flag MUST NOT
+      set it, if the current user doesn't have "s" right.
+
+   Changing flags:
+      STORE - the server MUST check if the user has
+         "t" right - when the user modifies \Deleted flag
+         "s" right - when the user modifies \Seen flag
+         "w" right - for all other message flags.
+      STORE operation SHOULD NOT fail if the user has rights to modify
+      at least one flag specified in the STORE, as the tagged NO
+      response to a STORE command is not handled very well by deployed
+      clients.
+
+   Changing ACLs:
+      SETACL/DELETEACL - "a" right on the mailbox.
+
+   Reading ACLs:
+      GETACL - "a" right on the mailbox.
+
+      MYRIGHTS - any of the following rights is required to perform the
+      operation: "l", "r", "i", "k", "x", "a".
+
+      LISTRIGHTS - "a" right on the mailbox.
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 16]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+5.  Other Considerations
+
+5.1.  Additional Requirements and Implementation Notes
+
+5.1.1.  Servers
+
+   This document defines an additional capability that is used to
+   announce the list of extra rights (excluding the ones defined in RFC
+   2086) supported by the server.  The set of rights MUST include "t",
+   "e", "x", and "k".  Note that the extra rights can appear in any
+   order.
+
+   Example:    C: 1 capability
+               S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
+                  ACL RIGHTS=texk
+               S: 1 OK completed
+
+   Any server implementing an ACL extension MUST accurately reflect the
+   current user's rights in FLAGS and PERMANENTFLAGS responses.
+
+   Example:    C: A142 SELECT INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
+               S: A142 OK [READ-WRITE] SELECT completed
+               C: A143 MYRIGHTS INBOX
+               S: * MYRIGHTS INBOX lrwis
+               S: A143 OK completed
+
+   Note that in order to get better performance the client MAY pipeline
+   SELECT and MYRIGHTS commands:
+
+               C: A142 SELECT INBOX
+               C: A143 MYRIGHTS INBOX
+               S: * 172 EXISTS
+               S: * 1 RECENT
+               S: * OK [UNSEEN 12] Message 12 is first unseen
+               S: * OK [UIDVALIDITY 3857529045] UIDs valid
+               S: * OK [UIDNEXT 4392] Predicted next UID
+               S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
+               S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
+               S: A142 OK [READ-WRITE] SELECT completed
+               S: * MYRIGHTS INBOX lrwis
+               S: A143 OK completed
+
+
+
+Melnikov                    Standards Track                    [Page 17]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   Servers MAY cache the rights a user has on a mailbox when the mailbox
+   is selected, so that if a client's rights on a mailbox are changed
+   with SETACL or DELETEACL, commands specific to the selected state
+   (e.g., STORE, EXPUNGE) might not reflect the changed rights until the
+   mailbox is re-selected.  If the server checks the rights on each
+   command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if
+   they have changed.  If such server detects that the user no longer
+   has read access to the mailbox, it MAY send an untagged BYE response
+   and close connection.  It MAY also refuse to execute all commands
+   specific to the selected state until the mailbox is closed; however,
+   server implementors should note that most clients don't handle NO
+   responses very well.
+
+   An ACL server MAY modify one or more ACLs for one or more identifiers
+   as a side effect of modifying the ACL specified in a
+   SETACL/DELETEACL.  If the server does that, it MUST send untagged ACL
+   response(s) to notify the client about the changes made.
+
+   An ACL server implementation MUST treat received ACL modification
+   commands as a possible ambiguity with respect to subsequent commands
+   affected by the ACL, as described in Section 5.5 of [IMAP4].  Hence a
+   pipeline SETACL + MYRIGHTS is an ambiguity with respect to the
+   server, meaning that the server must execute the SETACL command to
+   completion before the MYRIGHTS.  However, clients are permitted to
+   send such a pipeline.
+
+5.1.2.  Clients
+
+   The following requirement is put on clients in order to allow for
+   future extensibility.  A client implementation that allows a user to
+   read and update ACLs MUST preserve unrecognized rights that it
+   doesn't allow the user to change.  That is, if the client
+
+   1) can read ACLs
+    and
+   2) can update ACLs
+    but
+   3) doesn't allow the user to change the rights the client doesn't
+   recognize, then it MUST preserve unrecognized rights.
+
+   Otherwise the client could risk unintentionally removing permissions
+   it doesn't understand.
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 18]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+5.2.  Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
+
+   A particular ACL server implementation MAY allow "shared multiuser
+   access" to some mailboxes.  "Shared multiuser access" to a mailbox
+   means that multiple different users are able to access the same
+   mailbox, if they have proper access rights.  "Shared multiuser
+   access" to the mailbox doesn't mean that the ACL for the mailbox is
+   currently set to allow access by multiple users.  Let's denote a
+   "shared multiuser write access" as a "shared multiuser access" when a
+   user can be granted flag modification rights (any of "w", "s", or
+   "t").
+
+   Section 4 describes which rights are required for modifying different
+   flags.
+
+   If the ACL server implements some flags as shared for a mailbox
+   (i.e., the ACL for the mailbox MAY be set up so that changes to those
+   flags are visible to another user), let's call the set of rights
+   associated with these flags (as described in Section 4) for that
+   mailbox collectively as "shared flag rights".  Note that the "shared
+   flag rights" set MAY be different for different mailboxes.
+
+   If the server doesn't support "shared multiuser write access" to a
+   mailbox or doesn't implement shared flags on the mailbox, "shared
+   flag rights" for the mailbox is defined to be the empty set.
+
+   Example 1: Mailbox "banan" allows "shared multiuser write access" and
+              implements flags \Deleted, \Answered, and $MDNSent as
+              shared flags. "Shared flag rights" for the mailbox "banan"
+              is a set containing flags "t" (because system flag
+              \Deleted requires "t" right) and "w" (because both
+              \Answered and $MDNSent require "w" right).
+
+   Example 2: Mailbox "apple" allows "shared multiuser write access" and
+              implements \Seen system flag as shared flag. "Shared flag
+              rights" for the mailbox "apple" contains "s" right
+              because system flag \Seen requires "s" right.
+
+   Example 3: Mailbox "pear" allows "shared multiuser write access" and
+              implements flags \Seen, \Draft as shared flags. "Shared
+              flag rights" for the mailbox "apple" is a set containing
+              flags "s" (because system flag \Seen requires "s" right)
+              and "w" (because system flag \Draft requires "w" right).
+
+   The server MUST include a READ-ONLY response code in the tagged OK
+   response to a SELECT command if none of the following rights is
+   granted to the current user:
+
+
+
+
+Melnikov                    Standards Track                    [Page 19]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+    "i", "e", and "shared flag rights"(***).
+
+   The server SHOULD include a READ-WRITE response code in the tagged OK
+   response if at least one of the "i", "e", or "shared flag
+   rights"(***) is granted to the current user.
+
+   (***) Note that a future extension to this document can extend the
+   list of rights that causes the server to return the READ-WRITE
+   response code.
+
+   Example 1 (continued): The user that has "lrs" rights for the mailbox
+                          "banan".  The server returns READ-ONLY
+                          response code on SELECT, as none of "iewt"
+                          rights is granted to the user.
+
+   Example 2 (continued): The user that has "rit" rights for the mailbox
+                          "apple".  The server returns READ-WRITE
+                          response code on SELECT, as the user has "i"
+                          right.
+
+   Example 3 (continued): The user that has "rset" rights for the
+                          mailbox "pear".  The server returns READ-WRITE
+                          response code on SELECT, as the user has "e"
+                          and "s" rights.
+
+6.  Security Considerations
+
+   An implementation MUST make sure the ACL commands themselves do not
+   give information about mailboxes with appropriately restricted ACLs.
+   For example, when a user agent executes a GETACL command on a mailbox
+   that the user has no permission to LIST, the server would respond to
+   that request with the same error that would be used if the mailbox
+   did not exist, thus revealing no existence information, much less the
+   mailbox's ACL.
+
+   IMAP clients implementing ACL that are able to modify ACLs SHOULD
+   warn a user that wants to give full access (or even just the "a"
+   right) to the special identifier "anyone".
+
+   This document relies on [SASLprep] to describe steps required to
+   perform identifier canonicalization (preparation).  The preparation
+   algorithm in SASLprep was specifically designed such that its output
+   is canonical, and it is well-formed.  However, due to an anomaly
+   [PR29] in the specification of Unicode normalization, canonical
+   equivalence is not guaranteed for a select few character sequences.
+   Identifiers prepared with SASLprep can be stored and returned by an
+   ACL server.  The anomaly affects ACL manipulation and evaluation of
+   identifiers containing the selected character sequences.  These
+
+
+
+Melnikov                    Standards Track                    [Page 20]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   sequences, however, do not appear in well-formed text.  In order to
+   address this problem, an ACL server MAY reject identifiers containing
+   sequences described in [PR29] by sending the tagged BAD response.
+   This is in addition to the requirement to reject identifiers that
+   fail SASLprep preparation as described in Section 3.
+
+   Other security considerations described in [IMAP4] are relevant to
+   this document.  In particular, ACL information is sent in the clear
+   over the network unless confidentiality protection is negotiated.
+
+   This can be accomplished either by the use of STARTTLS, negotiated
+   privacy protection in the AUTHENTICATE command, or some other
+   protection mechanism.
+
+7.  Formal Syntax
+
+   Formal syntax is defined using ABNF [ABNF], extending the ABNF rules
+   in Section 9 of [IMAP4].  Elements not defined here can be found in
+   [ABNF] and [IMAP4].
+
+   Except as noted otherwise, all alphabetic characters are case
+   insensitive.  The use of uppercase or lowercase characters to define
+   token strings is for editorial clarity only.  Implementations MUST
+   accept these strings in a case-insensitive fashion.
+
+   LOWER-ALPHA     =  %x61-7A   ;; a-z
+
+   acl-data        = "ACL" SP mailbox *(SP identifier SP
+                       rights)
+
+   capability      =/ rights-capa
+                       ;;capability is defined in [IMAP4]
+
+   command-auth    =/ setacl / deleteacl / getacl /
+                       listrights / myrights
+                       ;;command-auth is defined in [IMAP4]
+
+   deleteacl       = "DELETEACL" SP mailbox SP identifier
+
+   getacl          = "GETACL" SP mailbox
+
+   identifier      = astring
+
+   listrights      = "LISTRIGHTS" SP mailbox SP identifier
+
+   listrights-data = "LISTRIGHTS" SP mailbox SP identifier
+                           SP rights *(SP rights)
+
+
+
+
+Melnikov                    Standards Track                    [Page 21]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   mailbox-data    =/ acl-data / listrights-data / myrights-data
+                       ;;mailbox-data is defined in [IMAP4]
+
+   mod-rights      = astring
+                       ;; +rights to add, -rights to remove
+                       ;; rights to replace
+
+   myrights        = "MYRIGHTS" SP mailbox
+
+   myrights-data   = "MYRIGHTS" SP mailbox SP rights
+
+   new-rights      = 1*LOWER-ALPHA
+                       ;; MUST include "t", "e", "x", and "k".
+                       ;; MUST NOT include standard rights listed
+                       ;; in section 2.2
+
+   rights          = astring
+                       ;; only lowercase ASCII letters and digits
+                       ;; are allowed.
+
+   rights-capa     = "RIGHTS=" new-rights
+                       ;; RIGHTS=... capability
+
+   setacl          = "SETACL" SP mailbox SP identifier
+                       SP mod-rights
+
+8.  IANA Considerations
+
+   IMAP4 capabilities are registered by publishing a standards-track or
+   IESG-approved experimental RFC.  The registry is currently located
+   at:
+
+      http://www.iana.org/assignments/imap4-capabilities
+
+   This document defines the RIGHTS= IMAP capability.  IANA has added
+   this capability to the registry.
+
+9.  Internationalization Considerations
+
+   Section 3 states requirements on servers regarding
+   internationalization of identifiers.
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 22]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Appendix A.  Changes since RFC 2086
+
+   1.   Changed the charset of "identifier" from US-ASCII to UTF-8.
+   2.   Specified that mailbox deletion is controlled by the "x" right
+        and EXPUNGE is controlled by the "e" right.
+   3.   Added the "t" right that controls STORE \Deleted.  Redefined the
+        "d" right to be a macro for "e", "t", and possibly "x".
+   4.   Added the "k" right that controls CREATE.  Redefined the "c"
+        right to be a macro for "k" and possibly "x".
+   5.   Specified that the "a" right also controls DELETEACL.
+   6.   Specified that the "r" right also controls STATUS.
+   7.   Removed the requirement to check the "r" right for CHECK, SEARCH
+        and FETCH, as this is required for SELECT/EXAMINE to be
+        successful.
+   8.   LISTRIGHTS requires the "a" right on the mailbox (same as
+        SETACL).
+   9.   Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
+   10.  Specified that the "w" right controls setting flags other than
+        \Seen and \Deleted on APPEND.  Also specified that the "s" right
+        controls the \Seen flag and that the "t" right controls the
+        \Deleted flag.
+   11.  Specified that SUBSCRIBE is NOT allowed with the "r" right.
+   12.  Specified that the "l" right controls SUBSCRIBE.
+   13.  GETACL is NOT allowed with the "r" right, even though there are
+        several implementations that allows that.  If a user only has
+        "r" right, GETACL can disclose information about identifiers
+        existing on the mail system.
+   14.  Clarified that RENAME requires the "k" right for the new parent
+        and the "x" right for the old name.
+   15.  Added new section that describes which rights are required
+        and/or checked when performing various IMAP commands.
+   16.  Added mail client security considerations when dealing with
+        special identifier "anyone".
+   17.  Clarified that negative rights are not the same as DELETEACL.
+   18.  Added "Compatibility with RFC 2086" section.
+   19.  Added section about mapping of ACL rights to READ-WRITE and
+        READ-ONLY response codes.
+   20.  Changed BNF to ABNF.
+   21.  Added "Implementation Notes" section.
+   22.  Updated "References" section.
+   23.  Added more examples.
+   24.  Clarified when the virtual "c" and "d" rights are returned in
+        ACL, MYRIGHTS, and LISTRIGHTS responses.
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 23]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Appendix B.  Compatibility with RFC 2086
+
+   This non-normative section gives guidelines as to how an existing RFC
+   2086 server implementation may be updated to comply with this
+   document.
+
+   This document splits the "d" right into several new different rights:
+   "t", "e", and possibly "x" (see Section 2.1.1 for more details).  The
+   "d" right remains for backward-compatibility, but it is a virtual
+   right.  There are two approaches for RFC 2086 server implementors to
+   handle the "d" right and the new rights that have replaced it:
+
+   a.  Tie "t", "e" (and possibly "x) together - almost no changes.
+   b.  Implement separate "x", "t" and "e".  Return the "d" right in a
+       MYRIGHTS response or an ACL response containing ACL information
+       when any of the "t", "e" (and "x") is granted.
+
+   In a similar manner this document splits the "c" right into several
+   new different rights: "k" and possibly "x" (see Section 2.1.1 for
+   more details).  The "c" right remains for backwards-compatibility but
+   it is a virtual right.  Again, RFC 2086 server implementors can
+   choose to tie rights or to implement separate rights, as described
+   above.
+
+   Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see
+   other changes required.  Server implementors should check which
+   rights are required to invoke different IMAP4 commands as described
+   in Section 4.
+
+Appendix C.  Known Deficiencies
+
+   This specification has some known deficiencies including:
+
+   1.  This is inadequate to provide complete read-write access to
+       mailboxes protected by Unix-style rights bits because there is no
+       equivalent to "chown" and "chgrp" commands nor is there a good
+       way to discover such limitations are present.
+   2.  Because this extension leaves the specific semantics of how
+       rights are combined by the server as implementation defined, the
+       ability to build a user-friendly interface is limited.
+   3.  Users, groups, and special identifiers (e.g., anyone) exist in
+       the same namespace.
+
+   The work-in-progress "ACL2" extension is intended to redesign this
+   extension to address these deficiencies without the constraint of
+   backward-compatibility and may eventually supercede this facility.
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 24]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+   However, RFC 2086 is deployed in multiple implementations so this
+   intermediate step, which fixes the straightforward deficiencies in a
+   backward-compatible fashion, is considered worthwhile.
+
+Appendix D.  Acknowledgements
+
+   This document is a revision of RFC 2086 written by John G. Myers.
+
+   Editor appreciates comments received from Mark Crispin, Chris Newman,
+   Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole,
+   Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie
+   Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon
+   Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants
+   of the IMAPEXT working group.
+
+Normative References
+
+   [KEYWORDS]   Bradner, S., "Key words for use in RFCs to Indicate
+                Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [ABNF]       Crocker, D. and P. Overell, "Augmented BNF for Syntax
+                Specifications: ABNF", RFC 4234, October 2005.
+
+   [IMAP4]      Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
+                4rev1", RFC 3501, March 2003.
+
+   [UTF-8]      Yergeau, F., "UTF-8, a transformation format of ISO
+                10646", STD 63, RFC 3629, November 2003.
+
+   [Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
+                Internationalized Strings ("stringprep")", RFC 3454,
+                December 2002.
+
+   [SASLprep]   Zeilenga, K., "SASLprep: Stringprep Profile for User
+                Names and Passwords", RFC 4013, February 2005.
+
+Informative References
+
+   [RFC2086]    Myers, J., "IMAP4 ACL extension", RFC 2086,
+                January 1997.
+
+   [PR29]       "Public Review Issue #29: Normalization Issue",
+                February 2004,
+                <http://www.unicode.org/review/pr-29.html>.
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 25]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Author's Address
+
+   Alexey Melnikov
+   Isode Ltd.
+   5 Castle Business Village
+   36 Station Road
+   Hampton, Middlesex  TW12 2BX
+   GB
+
+   EMail: alexey.melnikov@isode.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 26]
+
+RFC 4314                        IMAP ACL                   December 2005
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2005).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+Melnikov                    Standards Track                    [Page 27]
+