[Extra] Adam Roach's Yes on draft-ietf-extra-sieve-fcc-08: (with COMMENT)
Adam Roach <adam@nostrum.com> Wed, 09 January 2019 23:17 UTC
Return-Path: <adam@nostrum.com>
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 79301131181; Wed, 9 Jan 2019 15:17:24 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-extra-sieve-fcc@ietf.org, Jiankang Yao <yaojk@cnnic.cn>, extra-chairs@ietf.org, yaojk@cnnic.cn, extra@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154707584442.5000.13501401246628029757.idtracker@ietfa.amsl.com>
Date: Wed, 09 Jan 2019 15:17:24 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/DWGRwB02skejfOA_Bh_89hLta-Q>
Subject: [Extra] Adam Roach's Yes on draft-ietf-extra-sieve-fcc-08: (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: Wed, 09 Jan 2019 23:17:27 -0000
Adam Roach has entered the following ballot position for draft-ietf-extra-sieve-fcc-08: Yes 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-sieve-fcc/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the work everyone did on this document. The mechanism seems quite useful. I have some minor suggestions that you may want to consider incorporating. I support Ben's discuss. --------------------------------------------------------------------------- §1: > This extension defines a new optional tagged argument ":fcc" to > action commands which generate additional messages to allow a copy of Nit: "...commands that generate..." --------------------------------------------------------------------------- §3: > alters the behavior of action commands which generate additional Nit: "...commands that generate..." --------------------------------------------------------------------------- §3.2: > FCC = ":fcc" string *FCC-OPTS > ; per Section 2.6.2 of RFC5228, > ; the tagged arguments in FCC may appear in any order This threw me for a bit of a loop when I got to the example in section 5, and I had to go carefully read RFC 5228 to figure out what was going on. I think this would be much clearer and more accurate if the rule were described as: > FCC = *FCC-OPTS ":fcc" string *FCC-OPTS --------------------------------------------------------------------------- General: I'm a little concerned about the fact that this extension is generating a new message and attempting to store it into a potentially quota-controlled user folder. This would seem to be a run-time error, about which RFC 5228 says: > When an error happens, implementations MUST notify the user that an > error occurred and which actions (if any) were taken, and do an > implicit keep. This probably isn't the right behavior for FCC. I think a sentence or two of guidance about what happens when an FCC action would put the destination mailbox over quota are in order, particularly since they'll be different than the guidance in the base SIEVE spec. I might just be confused here -- corrections to any incorrect notions I've expressed would be appreciated.