[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.
- [Jmap] message copying and moving Josef 'Jeff' Sipek
- Re: [Jmap] message copying and moving Ted Lemon
- Re: [Jmap] message copying and moving अजय डाटा (Ajay DATA)
- Re: [Jmap] message copying and moving Neil Jenkins
- Re: [Jmap] message copying and moving Josef 'Jeff' Sipek
- Re: [Jmap] message copying and moving Neil Jenkins
- Re: [Jmap] message copying and moving J.B. Nicholson
- Re: [Jmap] message copying and moving Neil Jenkins
- Re: [Jmap] message copying and moving Ted Lemon