[Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-replace-02: (with COMMENT)

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Wed, 24 October 2018 03:59 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: extra@ietf.org
Delivered-To: extra@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 174A8130DE0; Tue, 23 Oct 2018 20:59:58 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, brong@fastmailteam.com, extra@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154035359808.31373.16459164548875812554.idtracker@ietfa.amsl.com>
Date: Tue, 23 Oct 2018 20:59:58 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/nXVbPENmd1a6a4MgZBGUOW6d1Y0>
Subject: [Extra] Spencer Dawkins' No Objection on draft-ietf-extra-imap-replace-02: (with COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
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, 24 Oct 2018 03:59:58 -0000

Spencer Dawkins has entered the following ballot position for
draft-ietf-extra-imap-replace-02: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


I'm curious about one point -

   In its simplest form, the REPLACE command is a single-command
   encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a
   message, except that it avoids any of the quota implications or
   intermediate states associated with the 3 command sequence.  In
   handling a REPLACE command, a server MUST NOT generate a response
   code for the STORE +flags \DELETED portion of the sequence.
   Additionally, servers supporting the REPLACE command MUST NOT infer
   any inheritance of content, flags, or annotations from the message
   being replaced.  Finally, the replaced and replacing messages SHOULD
   NOT be present in the mailbox at the same time.

I can imagine that having the replaced and replacing messages present at the
same time is better than having the replaced message deleted and the replacing
message not stored due to quota limits when pipelining APPEND, STORE, EXPUNGE,
but is SHOULD the right level of requirement language here? Is MUST just a