Subject: [Extra] draft-ietf-extra-sieve-fcc

From: Ken Murchison <[email-masked]>
Date: Sat, 24 Mar 2018 08:40:00 -0400

At the EXTRA session this week, Alexey questioned whether the way I 
integrated fileinto tagged arguments with :fcc was legal.  It turns out 
that Alexey is correct, and the current implementation breaks a SHOULD 
NOT in Section 2.6.2 of RFC5228:

"Tagged arguments SHOULD NOT take tagged arguments as arguments."

So, assuming we want to continue to allow options like :flags and 
:special-use to be used with :fcc (and I think we should if possible), 
we need to find another way to do this.

Do we allow options like :flags to float anywhere in the command and 
simply ignore them if :fcc isn't included? E.g.

vacation :days 7 :specialuse "\\Sent" :create :fcc "INBOX.Sent" :flags 
["\\Seen"] :from "[email-masked]" "Gone Fishin'";

This seems messy and somewhat illogical to me. We can't use a block to 
encapsulate the fileinto options, as that is also prohibited by RFC5228.

One other idea that comes to mind is to have :fcc accept a variable name 
as its argument into which a copy of the generated message will be 
stored.  We then extend fileinto to accept the variable name as the 
message to be filed.

Thoughts?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC:

---

From: Ned Freed <[email-masked]>
Date: Sat, 24 Mar 2018 07:43:20 -0700 (PDT)

> we need to find another way to do this.

I missed the fact that you had made FCC-OPTIONS a positional parameter
inside of :fcc. While I can certainly implement this, I agree that it's
a bad idea. And more to the point, unnecessary since there are no
cases where one of these arguments has a different meaning outside
of this context. (And if there were such cases... ick.)

> simply ignore them if :fcc isn't included? E.g.

Or better still, require :fcc to be present in order to use :flags or
whatever.

> encapsulate the fileinto options, as that is also prohibited by RFC5228.

I'm sorry, but I fail to see anything messy or illogical about this.

> stored.  We then extend fileinto to accept the variable name as the

Double ick. I really don't like abusing variables and/or fileinto this way, to
the point where the chances I'd ever implement this are essentially zero.

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Sat, 24 Mar 2018 12:17:27 -0400

Hi Ned,

> of this context. (And if there were such cases... ick.)

I only did that so that the parser would know ahead of time to expect 
the fileinto options.  Instead, the parser will have to expect those 
options to occur anywhere, possibly prior to parsing :fcc, and validate 
the command at the end.

> Or better still, require :fcc to be present in order to use :flags or

Right.  And if they are used without :fcc, its a parse error.

I will make the necessary changes and post a new draft.

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Stan Kalisch <[email-masked]>
Date: Sat, 24 Mar 2018 13:03:14 -0400

Hi,

> the point where the chances I'd ever implement this are essentially zero.

+1, particularly WRT variables being employed in this manner in this or any other context.

Thanks,
Stan

---

From: Ned Freed <[email-masked]>
Date: Sat, 24 Mar 2018 13:50:55 -0700 (PDT)

> options to occur anywhere, possibly prior to parsing :fcc, and validate

Does this really differ from the present situation?

For example, in the case of the imap4flags extension, you have to parse the
entire parameter list in order to determine whether or not there are one or two
positional parameters at the end, and if there are two check to make sure the
variables extension is enabled.

There are also many nonpositional parameters that are mutually exclusive so you
have to check and make sure only one is specified.

There's also at least one existing case where one nonpositional precludes the
use of another: :list and :comparator.

				Ned