Re: [Jmap] Adding the Message::isForwarded property

["Adrien de Croy" <[e-mail]>]

Is there no equivalent to set?  E.g. a sorted container whose keys are 
also the values?

Saves the meaningless value issue.

Adrien

------ Original Message ------
From: "Neil Jenkins" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Sent: 5/04/2017 5:36:45 PM
Subject: Re: [Jmap] Adding the Message::isForwarded property

>The existing isFoo properties on the Message object correspond to IMAP 
>system flags, so I think they are OK to be special, but since we know 
>we need generic access to IMAP user flags I agree we should just do 
>that and use the IANA registry rather than adding a special isForwarded 
>flag.
>
>My suggestion would be to add a keywords property to the Message 
>object, which corresponds to the list of IMAP user flags. There is a 
>question of what type this should be. An array is one option, but this 
>has two downsides:
>The server must sort it to ensure a consistent representation is 
>returned (probably just by ASCII code point, and for compatibility with 
>IMAP the flags will have to be ASCII). This then leads to the question 
>of whether the server accepts an unsorted array from the client when 
>updating it (probably yes, but then it's returning something that's 
>semantically different at the JSON layer to what was set, to represent 
>something semantically the same at the application layer).
>It's much harder to define patch semantics for an array. In CalConnect 
><https://www.calconnect.org/>, we've been working on a new JSON 
>representation for event data, and there are often many "complex" 
>properties on the event (e.g. set of alarms). Over time we've moved to 
>having everything as a map with an id as the key, rather than an array, 
>so that we can more easily patch event objects.
>So I would advocate for making the keywords property type Object, with 
>the keywords as the keys, each mapping to a Boolean true as the value. 
>This avoids the above two issues, although at the expense of having an 
>irrelevant "value" in the map for each keyword.
>
>To enable searching I would add the following properties to the 
>MessageList FilterCondition:
>hasKeyword: `String|null`
>notKeyword: `String|null`
>
>With regards to the special server behaviour for the $Forwarded 
>keyword, I think we can define this without adding a 
>forwardingMessageId property. We can just define that the server should 
>look for the X-Forwarded-Message-Id header on the message, and then 
>search for message(s) with this RFC5322 message id, and add the 
>$Forwarded keyword to any it finds.
>
>The current inReplyToMessageId property on the Message object is 
>actually problematic, because it's meant to be the JMAP message id, 
>which can change if the original message is delivered and/or deleted 
>after the reply is fetched, but the property is meant to be immutable.
>
>I think we can actually just drop the inReplyToMessageId property 
>altogether. Instead, clients can simply set the In-Reply-To and 
>References headers directly, and the server can use the In-Reply-To 
>header to search for the message(s) to set as replied, just like with 
>$Forwarded.
>
>Neil.