imap annotations was: KONSEC work on Cyrus IMAPd

[Martin Konold]

Am Montag, 11. September 2006 10:09 schrieb Sven Mueller:

Hi Sven,

> > 1. server annotations

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

Think about simple stuff like "message of today", name of the actual physical 
imap server or statistical metadata like available space, used resources. I 
can also imagine hints for mobile clients on how to interact with this server 
in the most efficient/cost saving manner.

Server annotations are defined in the Internet-Draft 
draft-daboo-imap-annotatemore-09.

> > 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?

With possible contents I meant not the actual data but the syntax and the 
semantic of the data. Doing this at compile time is more efficient that doing 
it at startup 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.

Describing the contents or purpose of a folder is a primary goal of imap 
annotations.

> I admit I never used annotations before (mostly because 
> Thundebird doesn't allow access to annotations)

The Kolab clients KDE Kontact, Toltec Connector and KONSEC Konnektor support 
annotations. Actually adding support for annotations to clients is rather 
simple and straight forward.

> 1) additional annotation types with possible values

There is a defined procedure how additional annotation types are added. Please 
check with the URL above. It describes how it works including how to deal 
with IANA.

> 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.

The internet draft answers your questions partly. Please come back and then we 
can discuss the ACL question. Please be aware of the fact that the current 
implementation of ACLs in cyrus imapd is not uptodate to the lastes ACL2 
developments.

I am for many reasons very interested in ACL2 support. Is anyone working on 
this already?

> > 3. user annotations for folders

> This looks good.

IMHO 3. is the most important from a functionality point of view.

Regards,
-- martin

-- 
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker