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

Stuart Brandt <stujenerin@aol.com> Wed, 24 October 2018 11:48 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 5D7AC130E70 for <extra@ietfa.amsl.com>; Wed, 24 Oct 2018 04:48:27 -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=unavailable 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 qKKLCyeDVNmz for <extra@ietfa.amsl.com>; Wed, 24 Oct 2018 04:48:24 -0700 (PDT)
Received: from sonic306-2.consmr.mail.bf2.yahoo.com (sonic306-2.consmr.mail.bf2.yahoo.com [74.6.132.41]) (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 5682C130E6D for <extra@ietf.org>; Wed, 24 Oct 2018 04:48:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1540381703; bh=zvIE2BsSzPxGJeVXf1NfXycjFNM5c53B5dj8SQ2pNs0=; h=Date:From:To:Subject:References:In-Reply-To:From:Subject; b=MSjrnRXKYeXYaSt427W2xdSpKlpQYg2uF+COVCTNw6ph9NiSL8uFnq5MUdDlfj9jOUAHavQkUPVNPamP7UUUQ3pOsH9wRbmiVc/ToPIKS9TF+Os7iLIxr5M06k1L9NESNoKHBL7aXYBpnkCq3FEocPDHSKZHKIC8v+MQMjAHZQLDwjvxvEnQHj4zjSZdPIhtludtR9sJ6i0hiu1S2Jc1kRcGf3HsKL2tlEse9TXse2CmCx3g8ZPIWU8p6S8nVZJsv2GcuJ7amRd+cm3tDMQJq9QMoOr0kdcKpDjWEmt9qQXYjJ8baBbX9Ekq5Ng+bc2bIbJDNcUeo0dp1rthyriOLw==
X-YMail-OSG: OA1EdX0VM1nkrWwFkz5_16ZHUg2av1NEFe0ZzZEX6I4CghW0R91JPmPlHMHRVH. TWi6O5SxKw_TsK6a50fbXLBVD1qPtmk0KaCvmDcnTQwAfD4vv8p3bMrYiZ77e8dYtjkiRpS6ezEs MerN6a9xrkcxmQT72YDWLH8RH7.9NKrUgUhIH8idXJRsuQQUxmPmfWvNKLm_pRUeZu7TGqeh6Sfp jZD2OFBxn6kQtxwx3qAFQRadvpC_nQjie36z2TWZfBCqKu0dd40i3pIwA38A8PD26ELjVRnh3KB9 ZT1ZPKi54E3EoL3TrYBlHs5g8MFIGCv54fzEB5tO0blat80cusjwMZNCosdYTSzMi.wiVx1iNMEG yDmfn13V6.VGcDgvsBVryjXm.XYvJUjj2yCLeIOhV2gaPuagn_3hlLwTZJ_SuQXCn5x5fmOs8o6F JA6PoYlFqp19vIejXdvY6JFT_iusk4ZxREFPV7QbmQe1z_Yu1T2xT1yqoWdTVYRuIaNwf0srE5LN wCB.xfFxt8JCsA8zWmp_4.LlCQ86R4hly1VQoSxn.Zra0MNY933Pzhk.CEG1LQnWg1BaltUZdMti PhWrJ6kaXbhE.tyJuzXiy3SKiSYomF4TFaCQjqd7s.SY5At42ctZa58GQFTMyOzrpbp6DKc1N5ki .Mled7AMVDSalQ7AfnAeNvhgdxnxS3SlSn9..8m6ZyTfjbnTnrO7UeinaU6Pl_DcwgrOzIni5Rsv qYPVhrBFN4LmYT4PpU8bMgrFw058P77NwsyiR3DuquqQqUejXjhYvySzBoQFCs18xOzQDWuHT_b7 j.VY2vRLOWpz7ZwwVCM.e9GAn684eqbMCP9CNejv27H2IXsLfNWwvvz.FhrBzpTMQ47jTzhrC2R7 E5u2xxSNx4xKCfzoMqcRy8Lrfv3NPq35bkOmgJEAKWQyLy6ep8e1UcXBs67kfV.rWn.2SDy30nf_ ujcILrs3Yg743fnwt8.z8Q_O0cC873D5Ph95BYn30O2zXcrnV8Rn6s2FZntDXuSymmKNEia6O_DT wwn6.MH0nHnNZfHUONd.6TYc6enYNn9bJ
Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.bf2.yahoo.com with HTTP; Wed, 24 Oct 2018 11:48:23 +0000
Received: from pool-70-106-226-126.clppva.fios.verizon.net (EHLO [192.168.1.13]) ([70.106.226.126]) by smtp431.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 59fcd78cf6ca1f9947f642daaa2c926d; Wed, 24 Oct 2018 11:48:17 +0000 (UTC)
Message-ID: <5BD05BE3.9060202@aol.com>
Date: Wed, 24 Oct 2018 07:47:47 -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: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
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: <154035359808.31373.16459164548875812554.idtracker@ietfa.amsl.com>
In-Reply-To: <154035359808.31373.16459164548875812554.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/VZ5ZeqLKxifnTnz6eOpq-dz9GR0>
Subject: Re: [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
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 11:48:27 -0000

Thanks, Spencer. This same question was raised elsewhere, so I will try 
to bring more clarity to it.

- Stuart

On 10/23/2018 11:59 PM, Spencer Dawkins wrote:
> 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:
> https://datatracker.ietf.org/doc/draft-ietf-extra-imap-replace/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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
> non-starter?
>
>