[Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt

Alexey Melnikov <alexey.melnikov@isode.com> Tue, 16 October 2018 16:36 UTC

Return-Path: <alexey.melnikov@isode.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 80743130DEE for <extra@ietfa.amsl.com>; Tue, 16 Oct 2018 09:36:03 -0700 (PDT)
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=isode.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 9cyMOE6HJ_PH for <extra@ietfa.amsl.com>; Tue, 16 Oct 2018 09:36:01 -0700 (PDT)
Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 3782F130DFD for <extra@ietf.org>; Tue, 16 Oct 2018 09:36:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1539707760; d=isode.com; s=june2016; i=@isode.com; bh=a9E1YJdHiYkhFT9uZVc/B6PzPIAMnUMH7Xb5OMao2UI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=TpRIf2G3X68t/+f2tGEKHlND/YBT9nA7zShLiwGSYQc2jH8eM78/8yqO8GnmJismHbQXM7 XHf3RR9m7MkFchtGLILhAFhCOcMYJnDxDU35BCd9MEw3EUSjLUsXCZkQCgZjw80DFZwA5V lqnzx43lm8n4N87QsK+laZEVn86HRFI=;
Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by statler.isode.com (submission channel) via TCP with ESMTPSA id <W8YTbwAG7cIQ@statler.isode.com>; Tue, 16 Oct 2018 17:36:00 +0100
To: extra <extra@ietf.org>
From: Alexey Melnikov <alexey.melnikov@isode.com>
Message-ID: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com>
Date: Tue, 16 Oct 2018 17:35:21 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/Lh_3l7tYYCyP-CS8v9Om_7mG9SE>
Subject: [Extra] AD review of draft-ietf-extra-sieve-fcc-06.txt
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: Tue, 16 Oct 2018 16:36:04 -0000

Hi,

The document is generally fine and contains enough details to implement, 
but I found a few minor issues:


3.  Tagged Argument ":fcc"

    For convenience, the "FCC" syntax element is defined here using ABNF
    [RFC5234] so that it can be augmented by other extensions.

Actually, you are not using ABNF, you are using Sieve syntax.

    FCC = ":fcc" <mailbox: string>

Later in the same section:

    If the specified mailbox doesn't exist, the
    implementation MAY treat it as an error, create the mailbox, or file
    the message into an implementation-defined mailbox.

Allowing for either an error or filing into different mailboxes is going
to make scripts non portable, considering that there is no way to test
in a Sieve script which exact behaviour is supported.

Also, why is it Ok to have all these different choices, which will 
potentially

confuse users? I would like to either have a way to test for different 
behaviour

or have some explanation in the document why all of the choices are 
acceptable.


In 3.1:

    o  Subject: The Subject header field is OPTIONAL and MAY be generated
       as follows: The subject is set to the characters "Fcc: " followed
       by the subject of the message being processed by the Sieve
       interpreter.

Please make it clear that subject encodings used by RFC 2231 are Ok to 
be used,
so if an implementation does prefix matching, this is done after decoding.

In 3.2:

    Vacation auto-reply messages are MIME-compliant and MAY

This is not an implementation choice and is not a compliance statement,
so use of RFC 2119 MAY is not appropriate here. So please use either
"may" or "can" here.

There is similar text in Section 3.3.

    be filed into
    the target mailbox without modification.

In 3.3.1:

    Example:

    require ["enotify", "fcc"];

    if notify_method_capability "xmpp:" "Fcc" "yes" {


Is "fcc" case insensitive? (I didn't check).


        notify :fcc "INBOX.Sent"
               :message "You got mail"
               "xmpp:ken@example.com?message;subject=SIEVE";
    } else {
        notify :fcc "INBOX.Sent"
               :message "You got mail!"
               "mailto:ken@example.com";
    }

In 3.5:

3.5.  Interaction with Fileinto Extensions

    The "fcc" extension can be used with some tagged arguments defined in
    extensions to the "fileinto" action.

This got me initially very confused and I was confused till section 3.5.4,
until I saw the example. I thought you were defining use of :fcc with 
"fileinto",
but you are actually allowing use of some "fileinto" tagged arguments 
together
with ":fcc" in other actions. So maybe rephrase this like this:

    This document defines how some tagged arguments defined in
    extensions to the "fileinto" action can be used together with ":fcc"
    used in other actions.

Or something like that.

    The sections below describe its
    interaction with currently defined extensions.  Tagged arguments in
    future extensions to the "fileinto" command should describe their
    interaction with ":fcc", if any.

In 3.5.1:

    FCC =/ [":flags" <list-of-flags: string-list>]

I think use of "=/" is wrong here. You are not defining another 
alternative to
":fcc", you are allowing some tags to be used together with it.

I suggest you either define a separate production from FCC or you just use
Sieve syntax:

    ":flags" <list-of-flags: string-list>

  and describe the rest in text.

(Similar issue in 3.5.2 and 3.5.3)

Best Regards,

Alexey