[Jmap] Adding the Message::isForwarded property

Benoit Tellier <btellier@linagora.com> Mon, 03 April 2017 09:13 UTC

Return-Path: <btellier@linagora.com>
X-Original-To: jmap@ietfa.amsl.com
Delivered-To: jmap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC71129590 for <jmap@ietfa.amsl.com>; Mon, 3 Apr 2017 02:13:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.108
X-Spam-Level:
X-Spam-Status: No, score=-1.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8AgF1I_SKwv for <jmap@ietfa.amsl.com>; Mon, 3 Apr 2017 02:13:37 -0700 (PDT)
Received: from alderaan.linagora.com (unknown [109.197.180.137]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 935B91295EA for <jmap@ietf.org>; Mon, 3 Apr 2017 02:13:36 -0700 (PDT)
Received: from [10.11.114.151] (unknown [1.55.245.97]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by alderaan.linagora.com (Postfix) with ESMTPSA id 592773EEA for <jmap@ietf.org>; Mon, 3 Apr 2017 11:13:32 +0200 (CEST)
To: jmap@ietf.org
References: <148716911729.17277.15371202023742081890.idtracker@ietfa.amsl.com> <b7ec34d3-3aaf-82af-3663-5b0966c83ff0@dcrocker.net>
From: Benoit Tellier <btellier@linagora.com>
Message-ID: <b5753f7f-92f9-50dd-42f0-ce0de7360e08@linagora.com>
Date: Mon, 03 Apr 2017 16:13:24 +0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <b7ec34d3-3aaf-82af-3663-5b0966c83ff0@dcrocker.net>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/gwwJS3tOgvuVOGblvXNvIdvR4Cw>
Subject: [Jmap] Adding the Message::isForwarded property
X-BeenThere: jmap@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: JSON Message Access Protocol <jmap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jmap>, <mailto:jmap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jmap/>
List-Post: <mailto:jmap@ietf.org>
List-Help: <mailto:jmap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jmap>, <mailto:jmap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 03 Apr 2017 09:13:40 -0000

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