Tag Configuration object draft

Jeroen van Meeuwen (Kolab Systems) vanmeeuwen at kolabsys.com
Thu Feb 27 13:47:45 CET 2014


On 2014-02-27 13:38, Thomas Jarosch wrote:
>> That said, the way that duplicate delivery suppression has resolved 
>> the
>> issue is by matching more headers than just the one Message-ID. 
>> Perhaps
>> it is not unreasonable to at least allow the storage format used to
>> include such additional headers as well, solely in an attempt to
>> uniquely identify the message.
> 
> may be some unorthodox request and it came up earlier:
> Can't the tagging be stored in the headers of the individual message?
> 
> Then it's really unique to that specific message. It also won't have
> any problems if you copy the message to another folder and
> untag the copy only.
> 
> Some kind of "X-Kolab-Message-Tag" header. An "external" message tag 
> needs
> always to be synchronized to the current mail folder content and I 
> think
> its annoying for the user if the tag gets lost somehow.
> 

The problem here is that messages are immutable, for we have no 
"REPLACE" but only "APPEND", as well as the model in which "tagging", 
which is just one implementation of the suggested format object, results 
in creating a particular view:

   - Select tag,

   - *search* all folders for messages with the corresponding header.

The proposed format object definition can at least allow for hint(s) on 
where the message was when tagged originally 
(/vendor/cmu/cyrus-imapd/uniqueid in Cyrus IMAP 2.5, or 
/vendor/kolab/uniqueid for Cyrus IMAP 2.4), as well as the content type 
of the object that had been tagged, so that a hit-or-miss can narrow 
subsequent searches it may need to perform.

FYI, the current idea is based on a feature in Cyrus IMAP 2.5 called 
XCONVERSATIONS -- a cross-folder database of message IDs and message's 
References: headers -- and (we think) gets us closer to more generically 
drawing relationships between items -- one of which purposes is a tag, 
other purposes include "project views" and/or "knowledge base" "types" 
of relations.

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +44 74 2516 3817
w: http://www.kolabsys.com

pgp: 9342 BF08


More information about the format mailing list