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

[Ned Freed <[e-mail]>]

> Eric Rescorla 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:
> ----------------------------------------------------------------------

> Rich version of this review at:
> https://mozphab-ietf.devsvcdev.mozaws.net/D3898

> IMPORTANT
> S 3.
> >      copy of the generated message into the mailbox provided in the
> >      subsequent argument.  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").

> This seems to sort of conflict with S 3.1.1.

I think you meant 3.1.2 (mailbox extension), not 3.1.1 (imap4flags).

> I assume that the logic
> is: if (!exists && :create) { try_to_create() }; if (!exists) {
> file_in_inbox()} else { file_in_fcc_mailbox()}, but this text isn't
> celar.

Actually, there's a more serious conflict here. RFC 5228 section 4.1 has this
to say in regards to the semantics of the mailbox argument to fileinto:

   If the specified mailbox doesn't exist, the
   implementation MAY treat it as an error, create the mailbox, or
   deliver the message to an implementation-defined mailbox.  If the
   implementation uses a different encoding scheme than UTF-8 for
   mailbox names, it SHOULD reencode the mailbox name from UTF-8 to its
   encoding scheme.  For example, the Internet Message Access Protocol
   [IMAP] uses modified UTF-7, such that a mailbox argument of "odds &
   ends" would appear in IMAP as "odds &- ends".

If the semantics MUST match this, as the document currently says, then you
can't then require fallback to INBOX if the specified mailbox doesn't already
exist, since only one of several possible behaviors.

Nor does :create in RFC 5490 actually change this. All the mailbox
extension does is provide a means to say "create the mailbox". It doesn't
change the behavior when :create isn't specified, meaning implementations
are allowed to treat :create as a no-op. (The reason for this, incidentally,
is that requiring :create for a create operation would potentially invalidate
existing sieves.)

Or, to put this another way, RFC 5228 says this is also valid:

  if (!exists) { try_to_create() };
  if (!exists) { file_in_inbox()} else { file_in_fcc_mailbox()}

as well as several other possibilities.

I think the correct way to resolve this is to make the text match RFC 5228
semantics. The alternative is to note that the semantics here aren't
those of fileinto, which I see as a least astonishment principle violation.

> COMMENTS
> S 1.
> >
> >      The capability string associated with this extension is "fcc".
> >
> >      Each action that generates additional messages will need to specify
> >      how it interfacts with :fcc.  This document specifies the interaction
> >      of :fcc with the Vacation [RFC5230] and Notify [RFC5435] extensions.

> Are these the only such actions?

They are the only standardized ones. There are probably implementations
of the old notify draft out there:

  https://datatracker.ietf.org/doc/html/draft-martin-sieve-notify

and there may be other stuff as well.

				Ned