[Jmap] message copying and moving

Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi> Mon, 31 July 2017 13:44 UTC

Return-Path: <jeff.sipek@dovecot.fi>
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 D083B128C9C for <jmap@ietfa.amsl.com>; Mon, 31 Jul 2017 06:44:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 vZfsm_9dgqpR for <jmap@ietfa.amsl.com>; Mon, 31 Jul 2017 06:44:55 -0700 (PDT)
Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id A5AEB1275FD for <jmap@ietf.org>; Mon, 31 Jul 2017 06:44:55 -0700 (PDT)
Received: from meili (officewifi.dovecot.fi [193.209.119.110]) by mail.dovecot.fi (Postfix) with ESMTPSA id 7BDC12B3DD1 for <jmap@ietf.org>; Mon, 31 Jul 2017 16:45:29 +0300 (EEST)
Date: Mon, 31 Jul 2017 16:44:53 +0300
From: Josef 'Jeff' Sipek <jeff.sipek@dovecot.fi>
To: jmap@ietf.org
Message-ID: <20170731134452.GB1402@meili>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.8.3 (2017-05-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/jmap/fISODCaWBhK0M-idShLT-aaLHng>
Subject: [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: Mon, 31 Jul 2017 13:44:57 -0000

There appear to be three different ways in jmap mail to "copy" an email from
one mailbox to another.  That is, duplicating a message but leaving the
original in place (like COPY in IMAP).  They are:

1. setMessages on an existing message's messageId with destination
   mailbox's mailboxId added to mailboxIds
2. importMessages with blobId referencing an existing message's blobId
3. copyMessages with fromAccountId == toAccountId

Based on my reading of the draft, the semantics of these are:

The first method creates a "hardlink" copy - any keyword changes will be
shared by all the copies of the message.

The second method creates a total duplicate of the message and its metadata.
The new copy has a new messageId.  Changes to keywords are not propagated to
other copies.  (The headers and body may be shared by the copies if the
server supports some form of transparent deduplication.)

The third method appears to work similarly to the second.  That is, a new
messageId is created and the new duplicate is *not* "linked" to the original.


When it comes to moving mails from one mailbox to another (like MOVE or
COPY+EXPUNGE in IMAP) the situation is equally complex.  The options are:

1. setMessages on an existing message's messageId with destination
   mailbox's mailboxId replacing the source mailbox's mailboxId in
   mailboxIds
2. importMessages with blobId referencing an existing message's blobId,
   followed by a setMessages on the original message but removing the
   source mailbox's mailboxId from mailboxIds
3. copyMessages with fromAccountId == toAccountId, followed by setMessages
   on the original message but removing the source mailbox's mailboxId from
   mailboxIds

The first method preserves the "links" between the source message and any
other "hardlinks" it may have had.

The second method creates a totally independent copy (much like IMAP COPY +
EXPUNGE).  (The headers and body may be shared with other copies if the
server supports some sort of transparent deduplication.)

The third method has same semantics as the second.


This brings up a number of questions:

The description of copyMessages (jmap mail section 5.5) is confusing.
Instead of describing what the call does, it talks about one potential use
(namely, moving emails between accounts).  Am I understanding the
copyMessages semantics correctly?  Or is it more like IMAP MOVE rather than
COPY?

Is there a limit to how many mailboxes a message may belong to?  I can't
seem to find anything that talks about it.  If the server implements a
limit, what would be the appropriate error to return from setMessages?  What
should a client do when it encounters this error?  Should it try to fall
back to copyMessages?

Does it make sense to allow copyMessages with fromAccountId equal to
toAccountId?

My inclination is to say that there should be only one way to copy emails.
At the same time, I see a reason for both "hardlink" and "copy" flavors of
copying to exist and the server supporting whatever is feasible given the
storage format it uses.  Sadly, that leads to added complexity in the
client.

Thanks,

Jeff.