Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-replace-02

Stuart Brandt <> Wed, 24 October 2018 03:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AB0EF130DE0 for <>; Tue, 23 Oct 2018 20:39:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id llyBuJtNsRgO for <>; Tue, 23 Oct 2018 20:39:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7651E12D4F2 for <>; Tue, 23 Oct 2018 20:39:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=a2048; t=1540352343; bh=PBUM9SmMdetQa0cD2WOqh7aFHM/4d+1hCzwtp9Ih748=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=tlqVZq8vXn18HRTqZExuTt3i+Bkp7yLU36N+rshsiLimphGER9bguPihzrE28j9PpKf/62PiDd1359fH6itVyyfq8WutY/3YQTU4/3ivLhd1v5tE5tbc5CvIPaCN1fwRLH3SOWZu99hu/LeAvDipO0/La1kCdsapfy5+C+nS1agPz4W9EIX25OZfQv3gSKphXASgnpR87/Y7PpD6BqFLerIWg6DZyCV0bAqLjBMOsJrCDpsoYJq2ksCJg/0V9izIqP2Ka8h5ILdSWnuuz4x3iPnh0kH9vvKoa6jY0CnuqAm3A9TRHQrgJHwQF7M9MOWh+3t0vrNeJ4okOUoWIfGkXw==
X-YMail-OSG: BdiETN0VM1lB2YRtM9ChCignkiKqGC.bKtqtMiLfdlsrpl0gO_9LROY4bPJddbx _uVDkcylvkx0FK7nEZTC5QB8jtI2FQs1Q1tw7Y7IGNzZXPvZEYvc3Hv_BO3ycxt3E6Xl.4giRF.S w4s2R.IpR_q07DX9T3W3PmHivruSaDiyQxPgqJbOoryEVMox7iKMcN1hFGXICwg796FwPQLCx0gB vehpFJMqVPxUrfGt.onB5mBV6nouWOQOmRA12JaMoyRJGJvuETzqhP55K8qV_5GYqGrwAxyUb1qr h1JRs1AcyqvVhIMdr7kfVrMJX_f.QNuyPWcw.vGcO2wqQkkD9fDQ7ChI1HZ3DT733_XsDoPfnbuF ufiinwrPz8IVfcjf9_pP51PA_wJ66bgYJtF_XWw2d0kncp19I4DbZgYe6sTCEvt3HCXEpVLufk2N 1i5PLMq68UjlZdL6LI2FLl7l0X3eKBBK5w_OV1OoFPhVIfciGb4dbbkSgBqEip3on3ZhImcM5hAb Z49GWc8Nxzio0igr6I1Bs0fHqvxrk8hqDieB5oaEuBwkMdOhQI7YYuSQHBRh4haS04QMrKDEex4F 0LxOeFkW29M9fnnLPRjCn2dysg9SkpnBGyT9AlbgpDQAcjQd0IAzdiGcnE.OTcIQkm2lJTs.klJg HPir2vmoMKr7J45Gm_FckH2LBhHDsXO.NXqmpD5MlgJa8vsDU81R1ZMMx_yQknfGvdmuaC6i.2V8 dMFkKxfY1V5KYvLTCZtV82_boWXrGQghRznDz1RinKgCuwDOvjtuWHfN6HWRwHl4RJ8CWMPSsi8x JYSyw0ZDciz4y3LXvUIQSIoGreQ68ZBrWxZ6ZvYI82PgqDJFXIQeg_PweBvXMwOarW1RFOgfMtyf gaIZ82sOl3I.lczKixM.wSqXjLoEyQlK6hLiLHpLTPXZ5M39CSttBNz6C5nYfbMpWNNvPGTHwg.o SXAQr7Qq3z1UmlbdEj2PuIos8hM8Lj90dbPH42wxtLqN4E7GySryOjGvnJhLQYZVwzS1HqYXtDSY k9.jCXgrnPePUV5HjnJ.8v39KQnOLvbIAqw--
Received: from by with HTTP; Wed, 24 Oct 2018 03:39:03 +0000
Received: from (EHLO []) ([]) by (Oath Hermes SMTP Server) with ESMTPA ID 05381467c50ccf1b0593ea224e4f2087; Wed, 24 Oct 2018 03:28:59 +0000 (UTC)
Message-ID: <>
Date: Tue, 23 Oct 2018 23:28:31 -0400
From: Stuart Brandt <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Scott Bradner <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Extra] Opsdir last call review of draft-ietf-extra-imap-replace-02
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Oct 2018 03:39:05 -0000

Thanks, Scott. Comments inline

On 10/20/2018 8:12 PM, Scott Bradner wrote:
> Reviewer: Scott Bradner
> Review result: Has Nits
> This is an OPS-DIR review of IMAP REPLACE Extension
> (draft-ietf-extra-imap-replace-02)
> imo - this proposal causes negative ops issues - i.e. it fixes potentially bad
> ops situations where the state of a message repository is not determinable due
> to the failure of one of a chain of commands. so it reduces potential ops issues
> that said, it seems to me that section 3.4 could more clearly state that no
> changes are to be made to the repository unless all changes are made - i.e.,
> 'all or nothing' - the information is there but it is a bit convoluted and the
> use of a clear simple statement would help

We had discussed this back around IETF93 and some server implementors 
indicated issues with an atomic guarantee. While I personally think it's 
much more valuable with such a guarantee, the wording for when to send 
the untagged EXPUNGE and the suppression of intermediate state responses 
was intended to cover the not-always-all-or-nothing nature.

> _______________________________________________
> Extra mailing list