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

[Benoit Tellier <[e-mail]>]

Link to the pull request: https://github.com/jmapio/jmap/pull/58


Le 03/04/2017 à 16:13, Benoit Tellier a écrit :
> 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]
> https://www.ietf.org/mailman/listinfo/jmap