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

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 09 Jan 2019 16:04:18 -0800

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?

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Jan 2019 23:42:01 -0800 (PST)

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

Unfortunately Sieve extensions have a tendency to create new requirements
that subsequent extensions have to address. For example, the relational
extension specified in RFC 5231 adds additional match types that
subsequent extensions that specify new tests have to deal with. 

While I realize this is not ideal, I don't think it's reasonable to have to
update the base specification every time this happens.

Specking as an implementor the great thing about Sieve is that the syntax never
changes so you never have to tweak your parser. This is a huge win.

The less great thing is that any time something like this is added have to
check every place the semantic comes up and make sure you've handled all the
cases, meaning it's an O(N*M) sort of deal. The fact that N and M are small and
will remain so is what makes it manageable.

> MAY options for fileinto.)

A previous response of mine mentioned a similar issue in the special use
extension. On consideration, I think the use of compliance language here is
incorrect in regards to syntax since the Sieve implementation has no control
over what people put in their scripts, and until a script is evaluated there's
no way to be sure the syntactic requirements of the underlying store (which may
or may not be an IMAP store) are met.

Semantics of a syntactically valid mailbox name are another matter. They really
do need to match whatever it is that fileinto does or we have a mess on our
hands. (FWIW, in our implementation there's no way it could work any other way
since the use of :fcc results 

> interaction with :fcc?

Maybe "need to" rather than "should"? This isn't really a place where
compliance language should be used either since we're talking about
something future extension specifications need to do.

>  (This requirement may also be a candidate for an

We didn't do that with RFC 5231. I'm not sure this is the time to start.

> the mailbox (if needed) without this extension.

As previously discussed in the EKR comment thread, this definitely needs to be
sorted out.

> I-D (vs. specifying the behavior in question in that document).

But the same could be said about that document updating the behavior of this
one.

> (Same for the notify action in Section 6.)

FCC is defined in section 3.2.

> readers as to what was defined at the time of this writing?

As noted previously, we had it and took it out based on review comments. I
don't especially care if we do or not, but we need to pick an approach and
stick to it.

				Ned

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 10 Jan 2019 12:46:21 -0600

> update the base specification every time this happens.

Okay.  It sounds like there's a good culture already present here and not
much to gain from an Updates relationship.

> incorrect in regards to syntax since the Sieve implementation has no control

I saw that other response, and agree that we should probably rethink our
compliance language for these cases.

> since the use of :fcc results 

(looks like this got cut off, but was just a side note anyway)

> something future extension specifications need to do.

I agree that we can't use compliance language here, and given the
discussion above wouldn't make a big deal about this case either way (but
"need to" is fine by me)

> But the same could be said about that document updating the behavior of this

I was thinking more that the two documents would advance together, with
cyclical normative dependencies.  So each just describes both the bits used
from and used by the other, and presents it as "how things are".  IIRC this
is mostly up to the sponsoring AD, though.

> FCC is defined in section 3.2.

I think I wasn't sure how tightly bound the formal grammar and Usage
statements were with each other -- the rest of the Usage statement didn't
look like formal grammar on first glance.  But there's plenty of ways I
could have been wrong about that, so thanks for clarifying.

> don't especially care if we do or not, but we need to pick an approach and

For my part, I'm happy just having heard that there was previous
discussion, and won't pick a horse in the race.

Thanks,

Benjamin