[Kolab-devel] IMAP Flags for E-mail Tags?

[Jeroen van Meeuwen (Kolab Systems)]

On 2015-04-02 09:46, pb at p-b.me wrote:
> Good morning,
> 
> Firstly, my apologies if this has previously been discussed or is
> answered in documentation: I have searched through what is publicly
> available but couldn't find anything conclusive.
> 
> I notice that e-mail (and in fact general groupware-item) tagging is
> implemented via `tag configuration objects' which store both
> meta-data and membership-data for each defined tag. I was wondering
> if there was a reason why this route was selected instead of
> utilising the `FLAGS' / keywords functionality provided by IMAP4r1
> to store the tag membership data?
> 

While IMAP flags indeed exist, and are available today, and they can 
also already be used as such.

However an IMAP flag does not contain colour coding for the UI, IMAP 
flags cannot easily be indexed (a UI will need to iterate over all 
folders to find all flags, and only then compose the related UI 
elements), cannot simply be updated (from \Foo to \Bar), always exist 
only in a shared fashion (provided the 'w' right, one could write these 
flags but some of what you might want to tag likely resides in read-only 
folders), and is always related only to one single object. Furthermore, 
the number of flags allowed is limited.

What we were looking for with tags included addressing these 
constraints, in that with the configuration objects we can establish a 
relation between items throughout the mail spool -- using IMAP URIs, a 
relationship object can in fact also relate to search results, include 
colour coding, need not index them through iterations, can simply be 
updated, and need no extra rights (other than the configuration folder 
already in the personal namespace). Furthermore, a level of 
"consistency" was desired, so that no mess of \Foo:33bb88 and 
\Foo:4400ff or something like that would start existing.

The relationship objects (you've found indeed are configuration objects) 
are, in this case, of a type "tag" (displayed as such in the UI). The 
same mechanism could however be applied to establish a relation of 
"project" (in the future, you might be able to select a limited view on 
all of your information to concentrate on working on a project).

This way, we believe we have found a way to implement the needed 
functionality, without rendering actual IMAP flags both limited in their 
functionality outside of Kolab (such as doing nonsense such as 
\Foo:33bb88) and Kolab's use of them completely Kolab-specific or 
otherwise incompatible with an implementation on top of actual genuine 
IMAP flags.

> My reasons for asking are twofold:
> 
> 1) Flags/keywords can trivially be applied to incoming mail messages 
> via
> Sieve rules using the Imap4Flags Extension to Sieve (RFC5232) (which is
> supported by Cyrus), whereas this does not presently appear to be so
> for Kolab tags;
> 

The purpose of the tags as currently implemented did not include a 
requirement to be able to tag incoming email through Sieve, indeed.

> Following from this, as someone interested in contributing to the
> project in order to have these features available, would there be
> architectural problems in introducing this? If so, are there ways
> that the same effects could be achieved using the configuration
> objects (namely, auto-application of tags to incoming mail, and
> access to tags in a native app on a mobile [Android] device)?
> If not, in which areas of the codebase would I need to start looking?
> 

I could see several separate options, but you might just want to 
consider implementing a view on Flags in the various UIs (perhaps in a 
way that is supplemental to the current real estate spent on Tags).

However before you start, I would encourage you outline the problem 
space, rather than just the desired solution. After all, while the 
imap4flags sieve extension indeed addresses a problem of "tagging" 
incoming email, it might functionally not be too much different from 
filtering inbound messages in to a folder (and perhaps applying a tag to 
a member url containing all items in that folder).

Kind regards,

Jeroen van Meeuwen

-- 
Systems Architect, Kolab Systems AG

e: vanmeeuwen at kolabsys.com
m: +41 79 951 9003
w: https://kolabsystems.com

pgp: 9342 BF08