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

[Alexey Melnikov <[e-mail]>]

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