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

Ned Freed <ned.freed@mrochek.com> Sat, 24 March 2018 21:11 UTC

Return-Path: <ned.freed@mrochek.com>
X-Original-To: extra@ietfa.amsl.com
Delivered-To: extra@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E870126BF7 for <extra@ietfa.amsl.com>; Sat, 24 Mar 2018 14:11:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mrochek.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45yU-cbqa3Cq for <extra@ietfa.amsl.com>; Sat, 24 Mar 2018 14:11:06 -0700 (PDT)
Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 496DC1204DA for <extra@ietf.org>; Sat, 24 Mar 2018 14:11:06 -0700 (PDT)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QQIOF20OAO00HC1B@mauve.mrochek.com> for extra@ietf.org; Sat, 24 Mar 2018 14:05:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1521925559; bh=YOvuKACobdkIaK48vkq4i6ikUPCLsCWAl0GAQVXqqxw=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=I+pw9ftGlmFOHPCagZNUIZA6c05QpLWV8lhdBxp/ArBF5QSIZ4Y9i6r4J4SxgEQmD 4IW8kDRWuJTyqA0y4C4NxYj4Eo/NE4N/PEPHqmXxoP5/WJ3DTECcs7LJwWpwITzvUF 5eiPfMLcRfJwhlmWgm0JScEwBUSXM1ygbs3+lAos=
MIME-version: 1.0
Content-transfer-encoding: 8bit
Content-type: TEXT/PLAIN; charset="utf-8"; format="flowed"
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QQ1J13T4YO00CZTT@mauve.mrochek.com>; Sat, 24 Mar 2018 14:05:54 -0700 (PDT)
Cc: Ned Freed <ned.freed@mrochek.com>, extra@ietf.org
Message-id: <01QQIOEYKZAG00CZTT@mauve.mrochek.com>
Date: Sat, 24 Mar 2018 13:50:55 -0700
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sat, 24 Mar 2018 12:17:27 -0400" <f6d8794b-d3dc-7496-9f64-3717127deb66@fastmail.com>
References: <0de6594d-2b11-aede-7c98-0e05a585f97d@fastmail.com> <01QQIBC8Y8B600CZTT@mauve.mrochek.com> <f6d8794b-d3dc-7496-9f64-3717127deb66@fastmail.com>
To: Ken Murchison <murch@fastmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/-qkBFO1rGlhRgljqHJYfpi3VfTU>
Subject: Re: [Extra] draft-ietf-extra-sieve-fcc
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 24 Mar 2018 21:11:07 -0000

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

				Ned