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

[Benjamin Kaduk <[e-mail]>]

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?