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

[Ned Freed <[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?

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.

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

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

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

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

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

				Ned