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

["HANSEN, TONY L" <[e-mail]>]

I support everything that Chris says here.

	Tony Hansen

On 4/10/17, 7:38 PM, "Jmap on behalf of Chris Newman" <[e-mail] on behalf of [e-mail]> wrote:

    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