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

["Chris Newman" <[e-mail]>]

On 9 Apr 2017, at 17:08, Neil Jhaveri wrote:
> I seem to be on the minority side here, but I personally do see the 
> appeal in **isForwarded** being a first-class property. This is a core 
> part of many modern client UI's showing a list of messages. If I had 
> never used IMAP before, it would definitely seem weird and incongruent 
> to me that answered is a property, but forwarded is a keyword, and it 
> would probably cause some momentary confusion trying to figure out how 
> to know if a message was forwarded or not.

System flags and keywords have largely identical syntax and behavior in 
the IMAP data model and are all searchable.

So the fact that JMAP is introducing a special data model for system 
flags that's different from the syntax for keywords seems odd to me. Why 
can't JMAP treat all flags/keywords as peers in the data model; the way 
IMAP does?

The only significant difference between flags and keywords in the IMAP 
base spec is that servers are not required to support keywords. One of 
the design flaws in IMAP is it's too permissive of server variations 
that make it harder to write clients. When the majority of deployed IMAP 
servers support a feature (providing support for a minimum number of 
extensible keywords being an example), I'm supportive of making JMAP 
require that feature. So adding a clause that requires JMAP servers to 
support at least X extensible keywords (maybe X=32 or X=64) is a change 
I would support.

> If there does end up being more support for this, I could see an 
> argument for drawing a line in the sand on the most important 
> keywords, and maybe upgrading $Junk/$NotJunk and $Phishing into 
> first-class properties too. Other keywords like $SubmitPending and 
> $Submitted seem to have their use cases handled quite differently in 
> JMAP with the Outbox concept, so could be left alone in a raw keywords 
> property.

 From my viewpoint, differences between the IMAP data model and JMAP 
data model are added complexity to the email infrastructure unless 
there's a justification for making a change. So I'd prefer to leave the 
line between system flags and registered keywords where it is unless 
there's a compelling reason to change it. Otherwise we have to modify 
the keyword registry to distinguish ones that are treated differently in 
JMAP from IMAP.

> I think it’s a stylistic question, though, and not a functional one. 
> Consensus so far seems to be against this, and I think either way is 
> probably fine, but I do personally support the more OOP-like 
> first-class property, where it makes sense and is cleaner to the 
> newcomer.

The extensibility of a data model is one of the most important parts of 
a protocol's design. I consider JMAP severely deficient if its 
extensibility model for flags/keywords is inferior to the one in IMAP. I 
also consider JMAP deficient if it can't largely share the extension 
registries for IMAP keywords/metadata/annotations and the extension 
registry for the SMTP Submission protocol.

		- Chris