Tag Configuration object draft

[Thomas Brüderli]

Aleksander Machniak wrote:
> On 02/25/2014 08:32 PM, Christian Mollekopf wrote:
>> Here's a draft for the Tag configuration object:
> 
> As this is already implemented (as Relations in libkolabxml) we have to
> agree on the last implementation considerations:
> 
> 1. Tag type value. As for now we have two types of relations: tags (e.g.
> email tags) and generic relations (between two or more
> objects/messages). Off-line we discussed and it looks that it will be
> the best to use "tag" and "generic" labels in relationType field.
> 
> 2. Member URIs.
> 2.1. Kolab objects can be referenced by "urn:uuid:<UUID>" (RFC4122).
> 2.2. Email messages need to be specified as IMAP URIs with additional
> data to use as a fallback search when message specified by folder/UID
> does not exist. So, we have RFC5092 to consider. However, our use-case
> here is different. I propose:
> 
> imap:///<path>/<uid>#<message-id>;<date>
> 
> where <path> is "user/<username>[/folder]" or "shared[/folder]", <uid>
> is message IMAP UID, <message-id> and <date> are values of these headers.
> 
> Note that we use "imap:///" prefix because we don't need host/auth info
> here.
> 
> Considerations/Feedback needed:
> 
> - I decided to not use UIDVALIDITY in URI, what do you think?

Seems OK to me. Whenever one retrieves a referenced message with
path/uid, a cross-check against the message-id header could be done in
order to make sure we got the right message (in case of an UIDVALIDITY
change).

> - Still, I'm not sure if we should use message date header as is or e.g.
> converted to unix timestamp.

I propose to use whatever format can be easily used to perform IMAP
searches. According to RFC 1730 that would be something like "1-Feb-2013
14:00 +0000".

> - maybe what we do after # we should change to a search string, e.g.
> "imap:///<path>/<uid>?<search>", where <search> is e.g.
> HEADER%20MESSAGE-ID...%20HEADER%20DATE...?

Named parameters might be a better choice regarding possible later
changes. But I'd not add the rather redundant "HEADER " prefix to these
parameters.

~Thomas