Re: [Jmap] message copying and moving

"J.B. Nicholson" <jbn@forestfield.org> Fri, 11 August 2017 05:27 UTC

Return-Path: <jbn@forestfield.org>
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 BBFFA1323BE for <jmap@ietfa.amsl.com>; Thu, 10 Aug 2017 22:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=forestfield.org
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 aH3-YHLITnwl for <jmap@ietfa.amsl.com>; Thu, 10 Aug 2017 22:27:05 -0700 (PDT)
Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCA1131CF2 for <jmap@ietf.org>; Thu, 10 Aug 2017 22:27:05 -0700 (PDT)
Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 81DBEA004B16 for <jmap@ietf.org>; Thu, 10 Aug 2017 22:27:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=forestfield.org; h=subject :to:references:from:reply-to:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s= forestfield.org; bh=IiZSVOxCoOfKNut1TTnGQUZI/CE=; b=H6hEO1sj5J6A rEYBOmWexVwfZVQVVqZVQcP7P3e7Cbj3VzXNOy3AOW92g/0Dwu/LtQxNLrHakbFX XPZRl4GgCWy4mmX15EifXoCeT7q8/Ja15f3QTALcWqc8QOQ+JVYBCkQq6D0MMhaG FTH13Pl+RtCOSGfL3I5HUtdP4iKK7sA=
Received: from [10.15.0.8] (unknown [173.44.37.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: jbn@forestfield.org) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 3C676A004B13 for <jmap@ietf.org>; Thu, 10 Aug 2017 22:27:04 -0700 (PDT)
To: jmap@ietf.org
References: <20170731134452.GB1402@meili> <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com>
From: "J.B. Nicholson" <jbn@forestfield.org>
Reply-To: jmap@ietf.org
Message-ID: <d4237a83-193a-44ae-da43-3c8ef89309e3@forestfield.org>
Date: Fri, 11 Aug 2017 00:27:03 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <27EB9EDE-A81C-4640-9F02-F76850002221@fugue.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/z4tvEr4KqKJOX5K1qElDK4vT48s>
Subject: Re: [Jmap] message copying and moving
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: Fri, 11 Aug 2017 05:27:07 -0000

Ted Lemon wrote:
> I think this is right, and is the right way to document it.   Default
> behavior on the client should be link—it's unlikely that the user ever
> wants a copy when a link is possible.   The only use case for copy is
> when the mail client is showing two mail stores on separate servers, or
> in the rare case where the user _wants_ two copies that are treated
> differently.   (I'm curious if there is general agreement on this or if
> folks think I'm crazy, though!)
I could be misreading or misunderstanding what you've written but I think I 
don't agree because I can't remember the last time I used an MUA that let 
me choose to link an email via the MUA's UI.

I also cannot recall when I would have wanted a link as a default choice 
while, say, dragging and dropping an email from one folder to another. I 
would think the default behavior on GUI MUAs would be moving or copying 
with the other option available via holding down a dead key.

I also think moving and copying are far more straightforward and familiar 
actions to non-technical users.

Hence, I think linking functionality is interesting but unlikely to be used 
much in practice. Therefore I believe copying and moving should be clear in 
the protocol.

I do understand the attraction for mail server implementers and sysadmins 
to want to use linking as much as possible to save storage space.