Re: [Jmap] Draft messages - mutability

"Chris Newman" <chris.newman@oracle.com> Tue, 25 April 2017 02:18 UTC

Return-Path: <chris.newman@oracle.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 BF6A6131991 for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 19:18:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.202
X-Spam-Level:
X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham 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 ASeH53IHFH-7 for <jmap@ietfa.amsl.com>; Mon, 24 Apr 2017 19:18:16 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BAE12785F for <jmap@ietf.org>; Mon, 24 Apr 2017 19:18:16 -0700 (PDT)
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3P2ID8h001566 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:18:13 GMT
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3P2ICAn000911 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 25 Apr 2017 02:18:13 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3P2IC9b014105; Tue, 25 Apr 2017 02:18:12 GMT
Received: from [10.145.239.181] (/10.145.239.181) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 24 Apr 2017 19:18:12 -0700
From: Chris Newman <chris.newman@oracle.com>
To: Neil Jenkins <neilj@fastmail.com>
Cc: Bron Gondwana <brong@fastmail.fm>, jmap@ietf.org
Date: Mon, 24 Apr 2017 19:18:10 -0700
Message-ID: <BFB51221-4FD4-4546-B628-595CF76B7F66@oracle.com>
In-Reply-To: <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com>
References: <1492998899.3316920.953769616.254C9CBD@webmail.messagingengine.com> <EDDD6045-ECAD-4EAB-AC11-842A9CB2E1CA@oracle.com> <1493084134.2830550.955039432.5403CAFB@webmail.messagingengine.com>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
X-Source-IP: aserv0022.oracle.com [141.146.126.234]
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/IH56eTrvZLHZ0yyBwxY8XiZzm7s>
Subject: Re: [Jmap] Draft messages - mutability
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: Tue, 25 Apr 2017 02:18:18 -0000

On 24 Apr 2017, at 18:35, Neil Jenkins wrote:
> On Tue, 25 Apr 2017, at 11:02 AM, Chris Newman wrote:
>> I see a lot of cost and no benefit to making a draft a different
>> datatype from a message.
>
> I don't see any benefit to making it a different data type. However,
> what we currently have is that, like IMAP, a message is immutable 
> except
> for flags/mailboxes. This is a pain for client authors trying to keep
> track of a single draft as it is saved through multiple revisions
> (especially when the user has multiple clients). One possible solution
> to this is to simply say any message with the \Draft flag set is fully
> mutable (while keeping the same id). I think we would also want the
> server to enforce that a message cannot be changed from/to draft state
> after creation. If it starts a draft it stays a draft, or vice versa.

Why is it important to keep the same ID when modifying a draft? The 
approach draft-brandt-imap-replace uses is to include the new ID in the 
response to the modification operation. The replace model seems a good 
way to preserve the immutable property (which is very helpful for quick 
synchronization) while providing the client an interface that looks just 
like editing an existing message.

		- Chris