imap annotations was: KONSEC work on Cyrus IMAPd

[Sven Mueller]

Martin Konold wrote on 07/09/2006 22:18:
> I think we need three kinds of annotations. Each kind has different purposes 
> and different quota accounting rules and different ACL sets are required.
> 
> 1. server annotations
> - only system administration can control server annotation
> - not necessarily set via imap but e.g. configuration files
> - typically only root can write and everyone can read the server annotations
> - no quoata or content limitations/restrictions are required as contents is ro 
> for imap users anyway

What would you think should be stored in such annotations? I currently
can't think of any use of such read-only annotations.

> 2. system annotations for folders
> - stuff like controlling annotions for server side feature like the above 
> mentioned quatter and cyr_expire services.
> - space required shall not be accounted for when calculating the quoata for an 
> users mailbox/account
> - possible contents is strictly defined at compile time
> - Access control is not determined by the folders ACLs

Hmm, why should the possible contents be strictly defined at compile
time? I would imagine that it would be useful for sys-admins to define
possible system annotations for folders in imapd.conf (or an associated
config file). For example I could imagine that I implemented variable
spam/ham folders for Users using annotations instead of using predefined
folder names. I admit I never used annotations before (mostly because
Thundebird doesn't allow access to annotations), but this discussion got
me thinking. However, part of this would require that I am able to define:
1) additional annotation types with possible values
2) who is allowed to modify/create which of those
On the one hand it would be nice to allow/disallow modification of
folder system annotations through normal ACLs, on the other hand, it
would also be nice to have control over annotations in an even finer
grain (i.e. allow modification of some system annotations while
disallowing others), which I can't imagine how this could be controlled
via the normal ACL system.

> 3. user annotations for folders
> - generic meta data useful for some applications. This includes stuff required 
> for special purpose servers like Kolab (e.g. folder-type, freebusy relevance 
> etc.) and more generic information like folder creation timedate.
> - namespace is predefined and allows for arbitrary local extensions within a 
> subtree
> - space used shall be considered for calculating the quota
> - possible contents is arbitrary and subject to the same ACLs like the folder 
> itself

This looks good.

In general, I would certainly welcome more options with annotations.

regards,
Sven