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

[pb at p-b.me]

Good morning,

Thank-you for your detailed reply.

On 2015-04-03 13:25, Jeroen van Meeuwen (Kolab Systems) wrote:

> ...before you start, I would encourage you outline the problem
> space...

Essentially, I am looking to migrate a base of users away from GMail
who are heavy users of GMail's `label' system. The functionality these
users rely on can be characterised as follows:

1) The ability to categorise conversations, marking them with
`labels'/`tags'/`flags'/`keywords' (I will use the generic term
`tags'). This can be simplified to being able to categorise individual
messages.

2) It should be possible to arbitrarily define new tags. There should
be no limit on the number of available, defined tags.

3) It should be possible to apply 0 - n tags to a given message, where
1 < n < N. N should be large but can be finite (e.g. for GMail
N = 27). For example, one conversation might have the following tags
applied: [NotMyProblem, BossRelated, ProjectAlpha, External,
LongTerm].

4) The application of tags should not prevent messages from appearing
within the user's Inbox, nor should they prevent the user from filing
messages adorned with tags into other folders.

5) It should be possible to automatically, programmatically assign
tags to received messages based on properties of that message.

6) It should be possible to search for messages bearing a given tag.

7) It should be possible to define a colour associated with each tag
used to represent it.

8) It should be possible to interact with the given labels across
different clients: labels should be tightly bound to the objects to
which they apply.

9) It would be good if this could be extended to other groupware
objects in addition to messages.

The problem with the Kolab implementation at present is that it does
not exhibit characteristic #5 or, using current clients, #8 (although
granted, this is a function of the available mobile clients rather than
the implementation).

> "tagging" incoming email... might functionally not be too much
> different from filtering inbound messages in to a folder

This wouldn't exhibit characteristic #3 or #4, however, my proposed
solution is a combination of IMAP permanent flags and configuration
objects, thus:

     1) A user creates a new tag. A configuration object is created as at
     present, with the addition of a field which defines an IMAP FLAG to
     which the tag relates. For example, the `configurationtype-fields'
     element could be updated as follows:

         configurationtype-fields = {
             ...
             element imapFlag { #String } ?
         }

     The value of `imapFlag' would initially be set to the same as the
     `name' element.

     2) A user applies the tag to a message. An IMAP
     STORE command is generated, thus:

     C: STORE 4 +FLAGS (Tag:Politics)
     S: * 4 FETCH (FLAGS (\Seen Tag:Politics Tag:NotMyProblem))
     S: OK STORE completed

     The name of the IMAP flag used is <"Tag:%s", imapFlag>.

     3) The interface is updated to include the Politics tag, whose
     colour and display properties are obtained from the previously 
stored
     configuration object.

Regarding the issues you raised with IMAP FLAGs:

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

The configuration object would store information for all tags about
which Kolab cares. Other clients could continue to store other
information in other IMAP flags.

In the case where we encounter a message with a flag matching the
pattern /Tag:(.+)/ for which a configuration object does not exist,
simply create a new configuration object containing the observed name.
It isn't necessary to iteratively index to find every tag in the inbox:
we maintain our own `index' in the configuration objects.

> [an IMAP flag] cannot simply be updated (from \Foo to \Bar)

Simply change the tag's `name' field without changing the `imapFlag'
field. Alternatively, fetch the entire set of UIDs with the old flag,
create the new flag, STORE <UIDset> +FLAGS <new flag>,
STORE <UIDset> -FLAGS <old flag>.

> some of what you might want to tag likely resides in read-only
> folders

> [an IMAP FLAG] is always related only to one single object

For us and our users, the former isn't the case (for us the correct
semantic would be that the users with write-permission could set flags
visible to all), although the existing `members' field could still
cater for this. Although this would make the set of members of a given
tag disjoint (consisting of the union of the set of messages tagged
using IMAP FLAGS and the set of members in that field), so long as it
was well-defined as to which type of object went where it wouldn't be
a problem.

> Furthermore, the number of flags allowed is limited.

I can't find any mention of this in the specification [1].
Dovecot seems to allow an unlimited number [2].

How does this sound as a solution?

Kind regards,

Peter Bridgman

[1] http://tools.ietf.org/html/rfc2060.html#section-2.3.2
[2] http://wiki.dovecot.org/MailboxFormat/Maildir#IMAP_keywords