[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Thu, 10 January 2019 00:04 UTC

Return-Path: <kaduk@mit.edu>
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 5B53B12DF71; Wed, 9 Jan 2019 16:04:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk <kaduk@mit.edu>
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: <154707865829.4946.2773236088316133086.idtracker@ietfa.amsl.com>
Date: Wed, 09 Jan 2019 16:04:18 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/K-Or_r_fQN-dJXrr-dc4chHO1v0>
Subject: [Extra] Benjamin Kaduk's No Objection 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: Thu, 10 Jan 2019 00:04:19 -0000

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-sieve-fcc-08: 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-sieve-fcc/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I support Ben's Discuss.  I also have some other comments.

Section 1

   Each action that generates additional messages will need to specify
   how it interfacts with :fcc.  [...]

Do we need to Update: 5228 so that authors of such future actions are aware
of this requirement?

                         The syntax and semantics of the mailbox
   argument MUST match those of the mailbox argument to the "fileinto"
   action specified in Section 4.1 of [RFC5228].  If the specified
   mailbox doesn't exist, the implementation MUST file the message into
   the user's main mailbox (e.g.  IMAP "INBOX").

It's unclear that the "syntax and semantics MUST match" needs the 2119
MUST; it could just be "are defined to match".  (Except they don't, since
we add on the extra condition that a nonexistant mailbox name be delivered
to the no-longer-implementation-defined INBOX folder instead of the other
MAY options for fileinto.)

Section 3.1

                  Tagged arguments in future extensions to the
   "fileinto" action should describe their interaction with ":fcc", if
   any.

This is not a very strong statement.  What would an implementor be expected
to do upon encountering such future extensions that do not describe
interaction with :fcc?  (This requirement may also be a candidate for an
Updates: relationship with 5228.)

Section 3.1.2

Perhaps note that implementations are permitted but not required to create
the mailbox (if needed) without this extension.

Section 3.1.3

It's a bit odd to update the behavior of another document that's still an
I-D (vs. specifying the behavior in question in that document).

Section 5

   Usage:   vacation [FCC]
                     [":days" number | ":seconds" number]
                     [":subject" string]
                     [":from" string]
                     [":addresses" string-list]
                     [":mime"]
                     [":handle" string]
                     <reason: string>

This is presumably just my having skimmed RFC 5228 too quickly, but why is
this [FCC] instead of [":fcc" string]" or similar?
(Same for the notify action in Section 6.)

Section 7

Do we want to have a list of currently defined actions that are not
compatible with the "fcc" extension, to avoid any confusion by future
readers as to what was defined at the time of this writing?