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

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

Hi

one thing that has bugged me for a long time about IMAP is its basic 
verbosity.

We protocol log IMAP here, and the IMAP logs are a lot bigger than any 
others even though a lot less work is done.

Even trimming the completely redundant \ from the start of a flag 
keyword would save a bunch of space and transfer bandwidth.

Are we going to make any effort to make the JMAP more efficient or will 
it be equally or even more bloated?

Will there be a requirement for compression support?

I don't know why we would stick with the same keywords for the flags as 
IMAP uses.  I wonder if any IMAP implementors are storing these flags in 
textual format anyway.  We certainly aren't.

Regards

Adrien


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

>The initial JMAP design was only interested in the system flags, so 
>having the separate properties made sense. But given we want to add 
>full support for custom IMAP flags (and reuse the IANA registry), I 
>think having the system ones in a different format is going to end up 
>causing pain down the line. We could make properties for the keywords 
>currently in the IANA registry, but this would clearly cause headaches 
>as more are standardised down the line. So I agree we should change to 
>just a single "keywords" property, and reuse the keyword names from 
>IMAP.
>
>This means we would remove the "isUnread", "isFlagged", "isAnswered" 
>and "isDraft" properties from the Message object and introduce a single 
>"keywords" property (with respectively "\Seen" (flipped meaning), 
>"\Flagged", "\Answered" and "\Draft" keywords, as per IMAP).
>
>The main downside is I think is this is slightly less accessible for 
>newcomers who haven't been exposed to IMAP, but this is probably 
>outweighed by the benefits already discussed.
>
>Do we have consensus on this? The last few messages all seem to be in 
>favour of making this change. If so, I'm happy to update the spec and 
>call this issue closed.
>
>In terms of representation, do we agree on an Object type, with the 
>keywords as the keys (and a boolean `true` as the value (as discussed 
>in a previous email in this thread)?
>
>Neil.