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

["Chris Newman" <[e-mail]>]

On 4 Apr 2017, at 7:00, Alexey Melnikov wrote:
> 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 general principle, I'm opposed to gratuitous changes between IMAP 
and JMAP (or Submit and JMAP). So a message has to have flags/keywords 
as a property and $Forwarded is a keyword no different from other 
keywords in how it is accessed.

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

+1. IMAP flags/keywords are easy to access and searchable via IMAP. Same 
should be true via JMAP.

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

I'm supportive of including flag setting logic for $Forwarded, $MDNSent 
and \Answered in JMAP to the extent JMAP provides forward, MDN and reply 
functionality. Our JMAP-equivalent IMAP/Submit proxy has flag setting 
logic for $MDNSent and \Answered. The omission of support for $Forwarded 
is likely because it was defined later than the other two.

		- Chris

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


> _______________________________________________
> Jmap mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/jmap