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

[Alexey Melnikov <[e-mail]>]

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]
>> https://www.ietf.org/mailman/listinfo/jmap
>
> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap