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

[Benjamin Kaduk <[e-mail]>]

On Wed, Jan 09, 2019 at 11:42:01PM -0800, Ned Freed wrote:
> > 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?
> 
> 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.

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

> 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.
> 
> >                          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.)
> 
> 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

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

> 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 

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

> > 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?
> 
> 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.

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)

> >  (This requirement may also be a candidate for an
> > Updates: relationship with 5228.)
> 
> We didn't do that with RFC 5231. I'm not sure this is the time to start.
> 
> > Section 3.1.2
> 
> > Perhaps note that implementations are permitted but not required to create
> > the mailbox (if needed) without this extension.
> 
> As previously discussed in the EKR comment thread, this definitely needs to be
> sorted out.
> 
> > 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).
> 
> But the same could be said about that document updating the behavior of this
> one.

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.

> > 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.)
> 
> 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.

> > 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?
> 
> 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.

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