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

[Benoit Tellier <[e-mail]>]

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>|
|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.
|
>>
>> |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
>>>
>>
>