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