Tag Configuration object draft

[Jeroen van Meeuwen (Kolab Systems)]

On 2014-02-26 09:43, Thomas Jarosch wrote:
> On Wednesday, 26. February 2014 09:22:05 Aleksander Machniak wrote:
>> On 02/26/2014 09:08 AM, Thomas Brüderli wrote:
>> >> * member: A UID of a member of the tag.
>> >
>> > For tagging email messages, I suppose the member { #UID } element will
>> > hold the according Message-ID header value, right?
>> 
>> I see a possible issue here, but for not so common scenario I suppose.
>> 
>> 1. Add tag to a message.
>> 2. Copy the message to other folder (it will be copied with the tag
>> assignment, because Message-ID doesn't change, that's good).
>> 3. Remove tag from the copied message - tag will be also removed from
>> the original message, which might be not what all users expect.
>> 
>> Because in some cases this might be an acceptable behaviour and 
>> because
>> copying messages is not very common action we can ignore this problem.
>> But do not forget about this "limitation".
> 
> ...or think about MS Outlook clients that sometimes don't
> issue a new message-ID when forwarding a message.
> 
> -> message-IDs are not reliable for "uniqueness".
> 

This is reputed to be true indeed, and has messed with duplicate 
delivery suppression quite a bit as well as it messes with / will mess 
with conversations in general.

However, should message $x (already received) be tagged, and a copy of 
message $x be forwarded to the same recipient, and with the same 
Message-ID [1], becoming message $y, the duplicate appearing as having 
been tagged is not a completely insurmountable side-effect, and 
otherwise barely relevant unless your boss forwards you a message that 
you had tagged as "IGNORE".

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.

To address the "tag this unique copy of the message", perhaps a folder 
ID could be included, though I admit I'm seeing a lot of processing 
overhead occur just to prevent a tag from being removed off of multiple 
copies of a message. I suppose it is not unfair to simply acknowledge 
that either you are, or you are not interested in a message (or any copy 
thereof), and modifications to your level of interest go both ways.

Kind regards,

Jeroen van Meeuwen

[1] Directly in against RFC 822, section 4.6.1, and although 2822 is a 
bit more ambiguously formulated, it continues to emphasize the 
Message-ID uniqueness for every particular version of a particular 
message (section 3.6.4). The fact Microsoft elects / has elected to 
ignore the possibility of using Resent-* headers can really only be held 
against Microsoft.

-- 
Systems Architect, Kolab Systems AG

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

pgp: 9342 BF08