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

Stuart Brandt <stujenerin@aol.com> Wed, 24 October 2018 02:19 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 3A689130E8B for <extra@ietfa.amsl.com>; Tue, 23 Oct 2018 19:19:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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] 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 K1eLlUckrTtU for <extra@ietfa.amsl.com>; Tue, 23 Oct 2018 19:19:22 -0700 (PDT)
Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 24E12130F2F for <extra@ietf.org>; Tue, 23 Oct 2018 19:19:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540347560; bh=z6513lr0/2pJe8Ub5DQ3OyodgC6UNOaPxUwVIxWP/zc=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=m5ZpKFf6Gf83CO/21Ej12Lpc4ScDAaxhONxKEpyYjfk8uUextduPB6f23bAegMOjy/joA3aFqF6qV4eNq+MMc7aI29LjgUmNUJsfBbcuWDfugIwScnDKU3ll2fXPuUmLwXGcX11lpYwvR4uW2JAjbfjIR3dihpi3B+kOYwn+QETpT6MKxeWRqiYB+uG617OipKMjtYMSK/0TFfJ11Ny+1Z0qhsIbrLEvKEs69YTq1iQFZZg9g//yBAliSgJ2NZ07Rlf/XAU8HK21o0DdZQKTr02dVaLW+yVuqx/6eqqxQvElSLq/DYdUJqeZHSXoKCepT+gSBLUGtd6wb0oJTxPGnw==
X-YMail-OSG: OqoqSqUVM1mhK61Q3p_I5yLPnkmUgRcQUfU_WuM.pexYMzfT_dRfSAR4HtPA0U4 LG0fJv1f7o_03SxGJFMSOjt5UNR9qV.JZRvnEplXHagF5.T8vQXsH6HpEpedCxiPJIgGJBSueyhF DoiuRcp_xxDcOKnNAqe7E2BAE8dB20pNgTTXPjDcm8N.BI6hqMRC3K1hJzf0F1vOSHbyVOeuQEqB YOfAov_HpLOjA0RhTtlWoysVAPc5oVmHcO.teEvcD9PEqS2ZwDGv67BBd2W3Tw3tTAIeqBC6Flv2 EqWyNECyqtGZdVhawN1.TDGi2C3l9mZZAXudYCPC8ArkcKaV5AYSU0wfzHAzqhIdsWz1ePx6V9UN SaGS.cX9zYDSqHV8mrMMnB6Mq1Y1jRvH9g38ycUaFvn4muQvyb_RH7r_8x3bibk3ElZQ0QAbQskA JrrY_xBQdgn9tCf5SmOOgOKLsjJbFfVDWpM3xvuEUObJ.Pwo0DJCuVbY.R6vYJoSYXYjw8zz360G S39x1Vvp136Twvhf762cyO4FyW0KvqeIs_9I1kQ1V9MX_wg5mgiNyIYSS5n3nSb31Mmj8Gag3Iqa sYvYgWqaXpMjL2sD69KPEYln3q4V5Q7umxVhA_eC20jO2KCYpn4Dh_TSDY72VivabOUIl_ykBebo hKZrapRlY0cEl2hG1QFpOygHc4ipLu17psL0ciAadJvxXCYe5vZQQt7BHnHJQInl24dtbpCbXitR wkn_Ov57A9Y.UUYDIyGhyLXdp4.0OCbP3O9zfv92pScLDhHSlT_JIuw.0rXri7nWFd9dnetDoRmH 8j5u.YvJRZyP6RDRB2w.56sABS2WMm.OjYHvEA2I1oTo.MhBOX7EGXQoVmrPvF2BNWR4iWLeyR_a kovzRccW4WRqp80k_9JFusaHBOk.3asBgbffjyrZ3HoET5ruGeQcMLO7ufIr3pml8x9ZiL4min0O xB.R124qOZiQNvG42PZ5XoRDe2Gs79iM9_SgYbA2yUwWB8BnMbR0OoktRdbP06Ofwjo340Pvu50. 3aNsiT81TJk5M1xn04qSbwDvYyQoq
Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 02:19:20 +0000
Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp418.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID fe367cb2a89ff9f909d84b2c5b598024; Wed, 24 Oct 2018 02:19:17 +0000 (UTC)
Message-ID: <5BCFD689.3040004@aol.com>
Date: Tue, 23 Oct 2018 22:18:49 -0400
From: Stuart Brandt <stujenerin@aol.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Benjamin Kaduk <kaduk@mit.edu>
CC: The IESG <iesg@ietf.org>, draft-ietf-extra-imap-replace@ietf.org, Bron Gondwana <brong@fastmailteam.com>, extra-chairs@ietf.org, extra@ietf.org
References: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com>
In-Reply-To: <154032941464.31269.3192588777781367014.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/8pp__ojVwU4Ezm3wm6DwQjlDZYg>
Subject: Re: [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
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, 24 Oct 2018 02:19:32 -0000

Thanks for the feedback. Comments inline.

On 10/23/2018 5:16 PM, Benjamin Kaduk wrote:
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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?

The syntax of REPLACE identifies the source message's Mailbox by means 
of the currently selected Mailbox, thus requiring Selected state.

An optional source-mailbox parameter could be added to the syntax just 
for the UID REPLACE case, but other UID command variants such as those 
discussed in RFC3501 section 6.4.8 chose not to introduce UID specific 
syntax for specifying source-mailbox in order to support actions from 
Authenticated state alone. I'd prefer not to forge new ground in that 
area with this particular specification.

>
> 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).
>
>