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
