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

[Neil Jhaveri <[e-mail]>]

On Apr 4, 2017, at 7:32 AM, Benoit Tellier <[e-mail]<mailto:[e-mail]>> wrote:


Hi Alexey,

Thanks for your answer.

Le 04/04/2017 à 21:00, Alexey Melnikov a écrit :

Hi Benoit,

On 04/04/2017 11:08, Benoit Tellier wrote:

Hi,

Thanks for your answers. How do you plan to access such registered keyword, if it is not made somehow a message property?

It has to be a message properly. For example "keywords" which contains an array of other IMAP keywords as strings. I have other applications that need to access to other keywords, some of which are listed on <https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml><https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml>
I agree that a **keyword** property is cool.

However, I would go a bit further. Rather than creating a message property having a special meaning for the Forwarded feature, I would make it a top-level message property. That is why I proposed to add a **isForwarded** message property.

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.

I also see the dilemma of having to play catch-up with every new registered keyword becoming a supplemental property.

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.

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.

As a JMAP user I would like this to be very easily accessible from the Message object, and also it to be searchable.

Agreed.


In the case of $Forwarded I think it needs to be consistent with the reply feature, for automatically marked as forwarded, and for threads.

I wouldn't mind having some extra logic for forwarded messages, if the group can agree on that.

Best Regards,
Alexey


Cheers,

Benoit Tellier

Le 04/04/2017 à 00:43, Alexey Melnikov a écrit :
On 03/04/2017 18:10, Chris Newman wrote:

IMAP $Forwarded is a registered keyword and thus a fully supported part of IMAP:

https://www.iana.org/assignments/imap-keywords/imap-keywords.xhtml#imap-keywords-1

There's no need for JMAP to define all these registered keywords; it only needs to reference the registry.
Agreed. And at the Chicago face-to-face meeting I've raised the issue of lack of generic access to IMAP keywords in JMAP. I believe there was room agreement to fix it in a generic way.


        = Chris

On 3 Apr 2017, at 2:13, Benoit Tellier wrote:

Hello,

At Linagora, we tend to consider **forward** information as important
for the email we care about.

Today, it is not part of the RFC-3501 spec, and many IMAP
implementations handle it with the de-facto standard $Forwarded flag.

This implicit standard is a bad thing, and we truly would like the JMAP
mail protocol to do this right. To be right, it should be explicit.

We then propose this pull request:

It reproduces the behavior of **answered** feature:

 - Adds a **isForwarded** message property
 - Adds a mechanism for automatically marking messages as forwarded upon
sending emails
 - Clarifies interactions between isForwarded and threads
 - Makes isForwarded searchable

Does this proposal make sense to you?

Best regards,

Benoit Tellier
-----------------------------
Software engineer at Linagora
PMC on Apache JAMES


Le 01/04/2017 à 06:23, Dave Crocker a écrit :
G'day,

The working group meeting discussion about a static message, dynamic
annotation, etc., resonated with a variety of similar discussions I've
been around over the years (dating back to the mid-1970.)

A simpler version equates the constructs of message and document, as
two views of the same thing.  (Ie, Document with attributes; Message
with a body.)

The essence is to consider the nature and relationship of the objects,
possibly permitting different semantics for the same set of objects,
according to different applications or roles.

That is, there can be a variety of constituent objects that are
associated and can be viewed according to different semantics (or
views)...  So a message, a document, a calendar entry, a series of
comments, etc.  Each object has associated processing rules (eg,
static vs. editable vs. executable; constrained choice of values;
organization into folders or other schemas...)

An environment like this can  be powerful and very appealing. The
challenge tends to be staying practical:  With no effort at all it
devolves into an abstract computer science exercise.  Some of that is
an efficiency issue(*) but I think it's mostly about the human
manageability for design and operations.

Based on both the years of commercial use and the public commentary
about the performance, I've no doubt the fastmail system does not
suffer these downsides.  But it's a potential that this re-casting
through the IETF could easily suffer.

I'm posting this note partly because I think it would exciting to
produce specs that permit a degree of flexibility that such an
approach permits, but also wanted to cite the dangers.

At the moment, I'm guessing there needs to be a small number of basic
object types and a small number of 'relationship' types that define
the association between objects.  These could then be combined into
higher-order, formal organizations/semantics the define an application
semantic (mail, calendar, whatever.)


d/

(*) A system I did in 1977 has a little bit of this and the extremely
pure design produced impressively horrible performance.


_______________________________________________
Jmap mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jmap

_______________________________________________
Jmap mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jmap




_______________________________________________
Jmap mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/jmap