[Extra] Implementation questions regarding IMAP REPLACE

Stephan Bosch <stephan.bosch@dovecot.fi> Tue, 13 November 2018 23:11 UTC

Return-Path: <stephan.bosch@dovecot.fi>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58035130DF5 for <extra@ietfa.amsl.com>; Tue, 13 Nov 2018 15:11:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 46HFp370HSY5 for <extra@ietfa.amsl.com>; Tue, 13 Nov 2018 15:11:00 -0800 (PST)
Received: from mail.dovecot.fi (wursti.dovecot.fi [94.237.32.243]) by ietfa.amsl.com (Postfix) with ESMTP id 7A701130DEE for <extra@ietf.org>; Tue, 13 Nov 2018 15:11:00 -0800 (PST)
Received: from [10.168.3.2] (klara.student.utwente.nl [130.89.162.218]) by mail.dovecot.fi (Postfix) with ESMTPSA id D885D2B3C92 for <extra@ietf.org>; Wed, 14 Nov 2018 01:10:57 +0200 (EET)
To: extra@ietf.org
From: Stephan Bosch <stephan.bosch@dovecot.fi>
Message-ID: <ec55d6ba-351c-e6c7-85ca-6abbd42b350a@dovecot.fi>
Date: Wed, 14 Nov 2018 00:10:55 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EFD33831B692D7C216C0A137"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/9SjZzC01axnSbKpkPHyvG1qInPM>
Subject: [Extra] Implementation questions regarding IMAP REPLACE
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Nov 2018 23:11:02 -0000

Hi,

I've been evaluating a bit what effort an implementation of IMAP REPLACE 
would require at our end. I got two remarks/questions now:

1) The MOVE capability has some overlap with this one and that document 
states the following:

    The server may send EXPUNGE (or VANISHED) responses before the tagged
    response, so the client cannot safely send more commands with message
    sequence number arguments while the server is processing MOVE or UID
    MOVE.

    Both MOVE and UID MOVE can be pipelined with other commands, but care
    has to be taken.  Both commands modify sequence numbers and also
    allow unrelated EXPUNGE responses.  The renumbering of other messages
    in the source mailbox following any EXPUNGE response can be
    surprising and makes it unsafe to pipeline any command that relies on
    message sequence numbers after a MOVE or UID MOVE.  Similarly, MOVE
    cannot be pipelined with a command that might cause message
    renumbering.  See[RFC3501], Section 5.5 <https://tools.ietf.org/html/rfc3501#section-5.5>;, for more information about
    ambiguities as well as handling requirements for both clients and
    servers.

I'd say similar considerations apply to REPLACE, don't they?

2) What happens when the replaced message does not exist at all (no such 
seqnum/UID). Will the whole command fail or will it assume that the 
replaced message is already expunged and continue as a normal APPEND?

Regards,

Stephan.