Re: [Extra] Implementation questions regarding IMAP REPLACE

Stuart Brandt <stujenerin@aol.com> Wed, 14 November 2018 03:14 UTC

Return-Path: <stujenerin@aol.com>
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 13662127148 for <extra@ietfa.amsl.com>; Tue, 13 Nov 2018 19:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.com
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 qxPbgQREYYL8 for <extra@ietfa.amsl.com>; Tue, 13 Nov 2018 19:14:48 -0800 (PST)
Received: from sonic308-4.consmr.mail.bf2.yahoo.com (sonic308-4.consmr.mail.bf2.yahoo.com [74.6.130.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0BEA130ED7 for <extra@ietf.org>; Tue, 13 Nov 2018 19:14:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1542165282; bh=UZN2l2bpexcXvo+omCqwdHpaRijYHU1rgr5UWHImxkY=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=azUINkKCtqJhcezNLWxUHWNky8D1MZlQ0aNl9MJp91akiU7zPlgP3WIejYwFrVDC1mZi17kIOnQJ+kdsmtXizSo4vvSjcK+kZVJasF3tPEWaLBFYqk6NErxC3ndSoKUZ3pIZb8qn87mSWgtWvCd+mfJ8ia4/mrkuxHEJHtKk5APToyreu1Smsr1s66hw1Yg9u8OnByNGYnyG4sV43esnMabg9mg5uT5G8OaezO7E3o174z9cO2/ZX7Sttz0Ua6oz7QY+oJFczA4e3rlCUu2EHHO74M9XXn6rJ625oc8yHgJ0RKU1pighjHZBVTnAkE3QmYWM+f16Cf9KoUQ6Tl1j0Q==
X-YMail-OSG: LA3.LGQVM1kQDCqwARC8iEurwufWXDiXMYZRb10w_zznMmkBnpYIYbVVk8ko93a Kk.RN3ZzfrksQyxn8CEwN5zduk6IDOON9BXa0yzJWgk6QjnlXxHr.rniF.zSueaXggAOlgaBYkd1 0L3_lXni9CoKZjB5bVeKNYrWhI0vsu..9PCKgfIsHGlrAo_ioAcJkJy8Ucm8y5.tPXNMehMsbaaz 7NUkjaXULfymny5kZLeMkJ_59nLU_bHPlcTnh7RU5a7kU5rg4e5QUxqjzpz2quFtKh1hR7XHsuhd fkCK4zn5tNXMITv7DW71oC.dPimaz_j9fhCMlQH239RVlaTPKKmYAi.y9NcnBGSVWmP9D6AM1rM4 KOpgSvUdziEkpMg8QU5Q7ITbpvgy8inYr1ZcsBicwAournLq0ITRZG9ynU.D93MYzIarpQL4HOpB ljQ1WIkfLxkGSBpqCDyw5J1iHkkOJ.HeD_SU5MPdjoLjN0XIwRk6mpwnnioDiWlnC2FCJBYKvp6A g0JjLnA2apN2hFUsvS4ft6jhpm9InihIIr9STaIgenCp5iliRMYf7r.1Mblc_r4iWE6QM78SgS8Q Wcn01rTuo5rmvM9OHQVv47MvoaYKO08z5c4X8UuUdPQjTiUUW.E1TXF_2_Yzt72EsxsWF8izLUuR 8Y7CuQ1IjvRbyCkXWDY6d6dMYYTtDZvBhxC19KFVbUdP_65CHWGUPIeuj9LGgV2I0raLTtg0ckJq bI_Rz9IKdIqUv0tqxa_hPn68.GV51PkXcy1aY6g8.N.gUbUzChbrVEtJu5wQ_khPcCQdcs_5lph2 osMdST8wFPMtPtDmPjelSXvGj5ctqVD_68VsbFBRSvIzwgMDPDqGKeNThmP2NSQ8j5X0qiBy5KOp 6PiHESInmICbGp0V3WPpB6kg_nhMLmsjdMcvmy4RO2UiUurpcI9eIAh2FJsOEDniltIwoyb.xUUe 1aCRJ82zRtDWKz8o3xXhw40HsLfXnNqicp2NW1jBcxNK846LE0mzLlda70D5ayDwm6wumHnDaDZg zrkDlCeqWm_USQg--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic308.consmr.mail.bf2.yahoo.com with HTTP; Wed, 14 Nov 2018 03:14:42 +0000
Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp406.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fe4192eb452ec1a6c83a1a1b6fdc1776 for <extra@ietf.org>; Wed, 14 Nov 2018 03:14:39 +0000 (UTC)
To: extra@ietf.org
References: <ec55d6ba-351c-e6c7-85ca-6abbd42b350a@dovecot.fi>
From: Stuart Brandt <stujenerin@aol.com>
Message-ID: <5BEB9304.1070207@aol.com>
Date: Tue, 13 Nov 2018 22:14:12 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <ec55d6ba-351c-e6c7-85ca-6abbd42b350a@dovecot.fi>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/XxSIPVcTwWShzGn02NOa_QCUjBA>
Subject: Re: [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: Wed, 14 Nov 2018 03:14:50 -0000

Stephan -

Thanks for the input...comments inline:

On 11/13/2018 6:10 PM, Stephan Bosch wrote:
> 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?

Likely, yes.

>
> 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?

The intention is that it would fail and fail quickly -- prior to upload 
of the replacing data. Continuing with the Append can be problematic in 
a multi-client/session scenario and can lead to re-introduction of a 
Draft that was already sent or creation of a draft that appears newer 
than the one that replaced the referenced message. Additionally, it's 
important that a client actually *know* when it's not in sync with the 
present mail store, something that's downright dangerous when dealing 
with sequence numbers.

>
> Regards,
>
> Stephan.
>
>
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra
>