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

[Alexey Melnikov <[e-mail]>]

Hi Neil,


On 05/04/2017 06:36, Neil Jenkins wrote:
> 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:
>
>  1. 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).
>  2. 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.
>

Sorting seems sensible to me.
> 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.
That would be fine.

> To enable searching I would add the following properties to the 
> MessageList FilterCondition:
>
>   * hasKeyword: `String|null`
>   * notKeyword: `String|null`
>
Ok.

> 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.
Is X-Forwarded-Message-Id registered and which implementations are known 
to add it?

> 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.
>
>
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap