c and d rights in GETACL responses

[Bron Gondwana]

On Tue, Aug 03, 2010 at 07:12:25PM +0200, Jan Schneider wrote:
> Hi,
> 
> I'm not sure if this isn't rather a question for the IMAPEXT mailing  
> list, but I'm starting here because I only noticed it on Cyrus so far.
> 
> I wondering what the correct behavior of servers and clients should be  
> regarding the mapping of d and c ACL rights to RFC 4314 rights.
> Cyrus as of version 2.3.11 only returns d and c rights in GETACL  
> responses if these have been set with a pre-4314 version of Cyrus. It  
> does not expand these rights to the corresponding kxte rights.

It just returns whatever's stored in the mailboxes.db.  I can't think of
any good reason not to auto-upgrade the ACL whenever you parse it and hit
the old characters.

> This  
> behavior probably isn't wrong,

It probably isn't right either.  We should return a consistent set of
characters - either one or the other.

> at least I can't find anything in the  
> RFC about how to do it correctly. And that's exactly the problem when  
> developing a client. If I display the current rights to the user, I  
> display the kxte matrix because Cyrus implements 4314, but it doesn't  
> return kxte rights in GETACL responses, only the legacy dc rights. I  
> can't map those to kxte in the client either because I don't if the  
> server maps c to kx or k, etc. Well, I might know because it's Cyrus,  
> but I don't know from the IMAP conversation.

You make a compelling case!

> I would have expected that the IMAP server automatically expands the  
> (old) cd rights to kxte in GETACL responses because it's doing the  
> same internally when enforcing the rights, I guess. With the current  
> situation, the user doesn't know anything about create/delete rights  
> when using the client, because the kxte rights are never set because  
> of this behavior.
> 
> Is this a bug, an ambiguity of RFC 4314 or should I deal with this  
> differently in the client?

"yes" ;)

I think we should fix Cyrus.  Better than clients working around our
weirdness.

Bron.