[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-replace-02: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Tue, 23 October 2018 21:16 UTC

Return-Path: <kaduk@mit.edu>
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 9E9F6130DE8; Tue, 23 Oct 2018 14:16:54 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
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: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com>
Date: Tue, 23 Oct 2018 14:16:54 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/bizeF4IEs4TMp1NOm3lQ1s91Rbw>
Subject: [Extra] Benjamin Kaduk's 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: Tue, 23 Oct 2018 21:16:55 -0000

Benjamin Kaduk 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:


Section 1

(RFC 8174 provides an updated version of the BCP 14 boilerplate that can be
used instead of the RFC 2119 boilerplate.)

Section 3.5

   Unlike the APPEND command which is valid in the authenticated state,
   the REPLACE and UID REPLACE commands MUST only be valid in the
   selected state.  This difference from APPEND is necessary since
   REPLACE operates on message sequence numbers.

The stated justification applies only to REPLACE.  What is the
justification for disallowing UID REPLACE from the authenticated state?

Section 4.3

   (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS
   specification means that the client first receives an EXPUNGE for a
   message and afterwards APPENDUID for the new message.  [...]

nit: This comma is either spurious or missing a partner (if "as described
in the UIDPLUS specification" is supposed to be a parenthetical).