MBOX-Line: From mrc+uw at panda.com  Mon Nov  9 20:47:54 2009
To: imap-protocol@u.washington.edu
From: Mark Crispin <mrc+uw@panda.com>
Date: Fri Jun  8 12:34:42 2018
Subject: [Imap-protocol] "k" right in IMAP ACLs
Message-ID: <alpine.OSX.2.00.0911092020290.72789@hsinghsing.panda.com>

RFC 4314 is silent on many important details of the "k" right.  For 
example:

[1] If a mailbox is top-level in the hierarchy (co-equal with INBOX),
     where is the "k" right to be found?

[2] What if the parent name doesn't have an ACL?  For example, consider
     a hierarchical namespace in which the heirarchy delimiter is simply
     a character in the name.  Thus, a CREATE of a/b/c/d in no way
     necessitates that a, a/b, and/or a/b/c exist; these are not only
     \NoSelect names, they simply do not exist in any physical sense.  Is
     it supposed to search up the hierarchy, first trying a/b/c, then
     a/b, then a, and finally the who-knows-where location of top-level
     ACL in order to determine if there is a "k" right?

I assume that the purpose of the "k" right is to allow a designated 
administrator to create new mailboxes in a non-user shared location. 
However, this lack of specificity of where the necessary ACL is to be 
found for top-level names is a weakness.

Oh yeah, and what other rights are valid for the place that holds the ACL 
used to determine create of top-level mailboxes?  Is it just "a" and "k"?

Last but not least...

What do clients that implement IMAP ACL expect from the "k" right?

-- Mark --

http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.

