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

[Neil Jenkins <[e-mail]>]

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[1], 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.


Links:

  1. https://www.calconnect.org/