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

[Benoit Tellier <[e-mail]>]

|Hi,
|

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

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

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

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