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

Ned Freed <ned.freed@mrochek.com> Wed, 09 January 2019 16:00 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 F2E26128CF2; Wed, 9 Jan 2019 08:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 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] 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 05duxunc0Ifu; Wed, 9 Jan 2019 08:00:57 -0800 (PST)
Received: from mauve.mrochek.com (mauve.mrochek.com [66.218.59.24]) (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 D3151130E95; Wed, 9 Jan 2019 08:00:56 -0800 (PST)
Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1SUAKH3R400DVRD@mauve.mrochek.com>; Wed, 9 Jan 2019 07:55:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mrochek.com; s=201712; t=1547049348; bh=hpeh2FO9GleYzHvckC41IG9o3RznHqmF4LOvhByvfkM=; h=Cc:Date:From:Subject:In-reply-to:References:To:From; b=hiSpObGUkxFbhoM9Db1RyGx7l8zSZ6euVesJhKJ9RJfoI035bLHZU2lIWBFBPFIqH ifwfUnlsMHCmqx4iSm/zq/2P7qHACyTnqS3CiheFDBtm6SC28CZA3iQfw74NoHqVpF 2Nav15lPwRfXppIqUEuWDD1iMxPjjlFrbcS/Y7PQ=
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-type: TEXT/PLAIN; CHARSET=us-ascii
Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01R1N39ADWKW00004L@mauve.mrochek.com>; Wed, 9 Jan 2019 07:55:42 -0800 (PST)
Cc: The IESG <iesg@ietf.org>, extra@ietf.org, Jiankang Yao <yaojk@cnnic.cn>, draft-ietf-extra-sieve-fcc@ietf.org, extra-chairs@ietf.org
Message-id: <01R1SUAHNJJC00004L@mauve.mrochek.com>
Date: Wed, 09 Jan 2019 07:21:53 -0800 (PST)
From: Ned Freed <ned.freed@mrochek.com>
In-reply-to: "Your message dated Sun, 06 Jan 2019 14:12:58 -0800" <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com>
References: <154681277828.16929.18247897769470424327.idtracker@ietfa.amsl.com>
To: Eric Rescorla <ekr@rtfm.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/ZPCje9_IeVRUKZwrePYgK7Ow39s>
Subject: Re: [Extra] Eric Rescorla's No Objection on draft-ietf-extra-sieve-fcc-08: (with COMMENT)
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 09 Jan 2019 16:00:59 -0000

> 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 think you meant 3.1.2 (mailbox extension), not 3.1.1 (imap4flags).

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

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.

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

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