Re: [Extra] Proposed update to draft-ietf-extra-imap-replace-02

"Chris Newman" <chris.newman@oracle.com> Thu, 25 October 2018 22:57 UTC

Return-Path: <chris.newman@oracle.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 8F7A5130DBE for <extra@ietfa.amsl.com>; Thu, 25 Oct 2018 15:57:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level:
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=oracle.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 eDNH0YbaCB00 for <extra@ietfa.amsl.com>; Thu, 25 Oct 2018 15:57:15 -0700 (PDT)
Received: from userp2130.oracle.com (userp2130.oracle.com [156.151.31.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFA8127B92 for <extra@ietf.org>; Thu, 25 Oct 2018 15:57:15 -0700 (PDT)
Received: from pps.filterd (userp2130.oracle.com [127.0.0.1]) by userp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w9PMsSYw010902; Thu, 25 Oct 2018 22:57:13 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : in-reply-to : references : mime-version : content-type; s=corp-2018-07-02; bh=T+a+Add7YRbshN0uuzmFYr2U+KJENBM3o+ymR5OD/Aw=; b=eQDNaIiicwZ3zVEi0ujhN4akpUdIyqCn9ZxNcysO/LL/ht+lJxpr9DxjLY1Hkria8fOP tTvEBVOES5z/FwgIUWH9ZU8pTHTgSQUR1/gbKrIwJ1CANJ3NwqgJyRPpCccBD97DgvWz kqsM2dqpcDzYcl5vvKkfBwhAA/jwz+bNmNk77ieIyrl7C5qSNHAnCL18eIXrqCfOVxhX 1wCMRbJB53Q6E1WtAPenaDa1LuMjx1x4ogP+rUqGie9FyMHe1t9nCZJFoPJ7Ki7211dW zOcn+QdxTuhtMVRilnLdDz0+bQNRzGsPEOY1XQm808RgdyINYufTcXKGnhdSkrhl8f/j 4g==
Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp2130.oracle.com with ESMTP id 2n7usumccx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 22:57:12 +0000
Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by aserv0022.oracle.com (8.14.4/8.14.4) with ESMTP id w9PMv7Od020976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Oct 2018 22:57:07 GMT
Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w9PMv6Uf011507; Thu, 25 Oct 2018 22:57:06 GMT
Received: from [10.159.255.166] (/10.159.255.166) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 25 Oct 2018 15:57:06 -0700
From: "Chris Newman" <chris.newman@oracle.com>
To: "Stuart Brandt" <stujenerin=40aol.com@dmarc.ietf.org>
Cc: extra@ietf.org
Date: Thu, 25 Oct 2018 15:56:59 -0700
X-Mailer: MailMate (1.12r5523)
Message-ID: <D3EC266D-4731-4622-A049-600A567E7FD5@oracle.com>
In-Reply-To: <5BD11CB4.5080909@aol.com>
References: <5BD11CB4.5080909@aol.com>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=9057 signatures=668683
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=470 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1810250189
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/e5kfpnDC3Zq97n6kal32ejD6Wo0>
Subject: Re: [Extra] Proposed update to draft-ietf-extra-imap-replace-02
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: Thu, 25 Oct 2018 22:57:17 -0000

On 24 Oct 2018, at 18:30, Stuart Brandt wrote:
> B) Lack of clarity in final paragraph of the section 2
>
> Current...
>    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.
>
> Proposed...
>    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.  Server
>    developers are encouraged to implement REPLACE as an atomic 
> operation
>    to simplify error handling, minimize operational concerns, and 
> reduce
>    potential security problems.  For systems where this is not 
> possible,
>    communication with the requesting client must ensure no confusion 
> of
>    message store state.  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.

This is a good improvement. I consider it important to avoid an atomic 
behavior requirement to increase chances of implementation, but the new 
wording does a better job of stating the technical goal.

		- Chris