Martin Konold wrote:
Hi,
KONSEC (www.konsec.com) is working on implementing support for METADATA in
Cyrus IMAPd.
Most of the work is done by Levin Fritz <[EMAIL PROTECTED]> and I am
supervising the work.
A first step is the development of the LIST-EXTENDED capability.
http://www.ietf.org/internet-drafts/draft-ietf-imapext-list-extensions-17.txt
As I said before, the beginnings of this extension is already in the code.
The LIST-EXTENDED capability is the prerequisite for the most recent METADATA
extension as described in
http://www.ietf.org/internet-drafts/draft-daboo-imap-annotatemore-09.txt
Ken: You mentioned that you want to limit what the client is allowed to store
in the annotations using something like a white list and ACLs.
What is the basic idea behind this?
Why do you want to limit the client to only allow it to store a limited number
and types of annotations?
After all the plain folder ACLs already govern the access and provided that
the space used is accounted for in the quota calculation I am wondering about
the rational?
Do you want to go beyond/extend draft-daboo-imap-annotatemore-09.txt?
What about the implications of run-time parsing an external file?
As an underlying principal, I think it is reasonable for an admin to
have control over what a client can store on the server.
I suppose that if the annotations stored by the client are only used by
the client (config options, etc), then I don't have any objection to
using just the mailboxes ACL.
If however, we're talking about tagging a mailbox so that the server
treats the mailbox differently (calendar data, etc), then I think we
want to tighten up the access.
I'd like to hear other opinions on this topic.
--
Kenneth Murchison
Systems Programmer
Project Cyrus Developer/Maintainer
Carnegie Mellon University
