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

[Ned Freed <[e-mail]>]

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

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

> Do we allow options like :flags to float anywhere in the command and
> 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.

> vacation :days 7 :specialuse "\\Sent" :create :fcc "INBOX.Sent" :flags
> ["\\Seen"] :from "[e-mail]" "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.

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

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

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