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 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 BCC5C130EA9 for <extra@ietfa.amsl.com>; Tue, 23 Oct 2018 20:14:14 -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 KU-fzLNz7yVl for <extra@ietfa.amsl.com>; Tue, 23 Oct 2018 20:14:12 -0700 (PDT)
Received: from sonic311-15.consmr.mail.bf2.yahoo.com (sonic311-15.consmr.mail.bf2.yahoo.com [74.6.131.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 3367F130E4C for <extra@ietf.org>; Tue, 23 Oct 2018 20:14:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540350844; bh=/mETTQC4xBnB6Z2Pe5c58EpZsxfa5qvJue7oKBLnK94=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=o97zXrFfjyyvDuLiuPEJz3cdT+2GiaM4gRdTkDV15oAJo0KOpu057OpW03zS1XSSxlBmyRepH19FioPbavR5dPfUJgfi/bw9kAf57F+rgNGByuRMSYr0Y/FjPjLVeW9T1V4osOrwKq0y2mN6Fk6J658yQXOrqe+Ydkb031tQiDYoSbItGVkjyXfYM9YQRTAyluKr9lFQ97rPKu0ufbuEl31rpZdkgDHXwTNl9ZlNvT4esl2oM3vtoJsNebfKbeY7F22OrxTS9tjjTdHIF4FZ9oxut/iEifg05zYZM20PgmyXWsDVUYeNpYtlEmRaH0kL8hl4kS3qv7OI1I35pS/izw==
X-YMail-OSG: _y7yBaUVM1ldvHOWq.68NpqanlVv4XE2wZ034zlCm0T_ajIbbbqW1e.MYJMYhFU laRNnGz0wPLgwleyoGJmdIB7f5XJq2FXRfNt31jlyyFvmPxI9zn9JbyaFMb9hIeBvsk.YKoK9iUS Ck62VQzlRGFpa0SdkpzUg7mz7h3l2f9_kp0.765Tx1x0nJSw4R0KTLFgMfmbqATe._8dfRad3zXb _OIXgGmeeCuQvakENkvxZoDk6Yr6ofEajP8lTGFvB9NqtD8bi_Tgy0eY1gfI2aIpNZ6ukCGlmM8X pc6v3MRq1llU0wf7wbOnUf5IcCW7buA6Aa7ySw_lKYpmBajtG5bZY7IQEVHJuSDhejlgZ.cjsb2v MSxlX949MLrrSZO0gdT6icsBE1jjMkS1gryDOO3TGFyZRU19u.9.kGcQAmVCDCxap0tXSK68D5JI 8qTmhWtkhj9y.ygeN1j9aIBLdaGutHjHA5.gceVwHKb8ZuyJOf9n4eft6EzJWIK1Tnbt.V79q_LS xmTgckJBXoFdXR2JMYaPH8syywCI8eZz.w6vNdRUCzS.NkxVt06TvBNBlq.afxjppQSNunlGsy5w us3SkwmhQZUnrlY6v4VBe5IBcReGoFBT7r.B.HmA3H49yzUqP87rIy4Q2VEz7IzVB8hkZ.J90TKH euJKVd86DqclI4xKeP5k_GGxjkeNGzi8MQ_mSryXGcgJQXCEiKbjg6V1jez525S85zWeS1hCaG21 tEut4ekt4EUocjLdI7sgjl67Omm0ljqDHls1IwhaoVJuOa3KKz0XQCOlO1Fax1DWg7vjXyquGiLK OTNzRWNbki4YdcysqRogZpbEDX30Xk62HFf86xscUZMHtwK7f6InAQAW_XGb7nbYKTH2ImkBZ1I4 lOjxPD1cHa0XW81Mem0KsVJYBKCp.VQmmCNz0YrQ.vJ6gd3vPsIyicS4Ock_MdB6ZWSgm5TmpoOw wx_j2roCGzMInoNrpd_YuLmfGiMhAZFVhCT67edkCI1GXryFlh42Wd_yfttsiqFx.sy4JfJ73rGQ kU9fjHJjoJqcCIWi_wjuhpZR5Mb9RS3d7Rik-
Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 03:14:04 +0000
Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID dd79a59f3c67d5141154f53f212e9aa6; Wed, 24 Oct 2018 03:14:01 +0000 (UTC)
Message-ID: <5BCFE35D.5020703@aol.com>
Date: Tue, 23 Oct 2018 23:13:33 -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> <5BCFD689.3040004@aol.com> <20181024022358.GQ45914@kduck.kaduk.org>
In-Reply-To: <20181024022358.GQ45914@kduck.kaduk.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-v5HAy9AJDYGY4zwrvX7X0ODLjY>
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 03:14:16 -0000

On 10/23/2018 10:23 PM, Benjamin Kaduk wrote:
> On Tue, Oct 23, 2018 at 10:18:49PM -0400, Stuart Brandt wrote:
>> 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.
>
> I probably should have made it clear: I also prefer to not forge such new
> ground in this specification.  But does it make sense to make a nod to this
> reality in the document and note that this restriction is also applied to
> UID REPLACE for consistency?

Makes sense. Would the nod be more helpful when discussing state impacts 
(section 3.5) or when discussing UID REPLACE syntax (section 3.3)?

>
> Thanks,
>
> Benjamin
>