Tag Configuration object draft

[Thomas Brüderli]

Aleksander Machniak wrote:
> On 04/10/2014 06:48 PM, Thomas Brüderli wrote:
>> What about using the full IMAP path with the message UID as the primary
>> identifier with a fallback information (e.g. Message-ID) for a
>> hit-and-miss scenario? Although the Message-ID can't be assumed to be
>> absolutely unique, it still denotes an identifier for a message or set
>> of "related" messages. Possibly append it with the Date header of the
>> message, which at least would solve the forwarded-but-no-new-message-id
>> case and still is searchable via IMAP.
>>
>> If the final message identifier is restricted to be a string, an URL
>> comes to mind:
>>
>> imap://[<namespace>/]<folder>/<subfolder>/<message-uid>#<message-id>;<message-date>
> 
> I don't know, there's too much to change when you move a message/folder.

With the fall-back after #, references don't necessarily need to be
updated on move and should still remain working.

> Now, new idea comes. Generate unique message identifiers (based on set
> of message headers, size, etc. or use some general method of UUID
> genertion) and store them in message annotations using ANNOTATE
> extension (RFC5257). This identifier/annotation will be generated only
> once. Maybe we could even extend cyrus to generate them automatically.
> 
> Then we could use these identifiers as message references. Searching
> should be simple.

If Cyrus will support section 4.8. "ANNOTATION Criterion in SEARCH" of
the RFC, yes.

But I'd still suggest to use a fall-back with
<message-id>;<message-date> just in case some clients do things that
would destroy the message annotation. Think of a Thunderbird extension
that removes attachments and therefor appends a new message in IMAP.

~Thomas