Hi,
KONSEC (www.konsec.com) is working on implementing support for METADATA in
Cyrus IMAPd.
Most of the work is done by Levin Fritz <levin.fritz at konsec.com> 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
"The LIST command is extended by amending the syntax to allow options
and multiple patterns to be specified. The list of options replaces
the several commands that are currently used to mix and match the
information requested. The new syntax is backward- compatible, with
no ambiguity: the new syntax is being used if one of the following
conditions is true:
1. if the first word after the command name begins with a
parenthesis ("LIST selection options");
2. if the second word after the command name begins with a
parenthesis ("multiple mailbox patterns");
3. if the LIST command has more than 2 parameters ("LIST return
options");
Otherwise the original syntax is used."
[...]
".. defines an IMAP4 extension that is identified by the
capability string "LIST-EXTENDED". The LIST-EXTENDED extension makes
the following changes to the IMAP4 protocol, which are described in
more detail in Section 3 and Section 4:
a. defines new syntax for LIST command options.
b. extends LIST to allow for multiple mailbox patterns.
c. adds LIST command selection options: SUBSCRIBED, REMOTE and
RECURSIVEMATCH.
d. adds LIST command return options: SUBSCRIBED and CHILDREN.
e. adds new mailbox attributes: "\NonExistent", "\Subscribed",
"\Remote", "\HasChildren" and "\HasNoChildren".
f. adds CHILDINFO extended data item."
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
"The METADATA extension to the Internet Message Access Protocol
permits clients and servers to maintain "annotations" or "meta data"
on IMAP servers. It is possible to have annotations on a per-mailbox
basis or on the server as a whole. For example, this would allow
comments about the purpose of a particular mailbox to be "attached"
to that mailbox, or a "message of the day" containing server status
information to be made available to anyone logging in to the server."
We plan to interpret the "per mailbox" as per folder like everywhere else in
Cyrus IMAPd.
Proper support for METADATA is required for a clean implementation of
annotations as required by Kolab and other IMAP based solutions. See also:
https://bugzilla.andrew.cmu.edu/show_bug.cgi?id=2458
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?
Regards,
-- martin
--
http://www.erfrakon.com/
Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker