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

From: Eric Rescorla <[email-masked]>
Date: Sun, 06 Jan 2019 14:12:58 -0800

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

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?

---

From: Ned Freed <[email-masked]>
Date: Wed, 09 Jan 2019 07:21:53 -0800 (PST)

> 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

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.

> 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

---

From: Ken Murchison <[email-masked]>
Date: Wed, 9 Jan 2019 11:19:22 -0500

Hi Ned,

> those of fileinto, which I see as a least astonishment principle violation.

I agree, and I had originally used the RFC 5228 text.  The current text 
was a result of a comment during AD review, which I have asked him to 
review/reconsider.  My intent is to revert to the 5228 text unless there 
is pushback, in which case I will have to note the semantic difference 
as you suggest.

> and there may be other stuff as well.

Well, there is [e]reject, but we decided to remove the section stating 
that :fcc is incompatible.  We can certainly add it back in.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC