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

[Bron Gondwana <[e-mail]>]

On Sun, 25 Mar 2018, at 06:50, Ned Freed wrote:
>> Hi Ned,
> 
> 
>> On 03/24/2018 10:43 AM, Ned Freed wrote:
>>>> 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.)
> 
>> 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.
> 
> 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.

I'd like to get back to this and come up with a syntax that everyone is
happy with and progress this document.
Ken - do you have any good ideas?  It seems that we might need some text
duplication to add options to each of the extended commands, but that's
still going to only be a couple of places.
Cheers,

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]