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

Ken Murchison <murch@fastmail.com> Fri, 09 November 2018 16:54 UTC

Return-Path: <murch@fastmail.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 4917F12EB11 for <extra@ietfa.amsl.com>; Fri, 9 Nov 2018 08:54:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.com header.b=ahOZwBEH; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=wJziNQ6u
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 u2VKjZtO0qLb for <extra@ietfa.amsl.com>; Fri, 9 Nov 2018 08:54:43 -0800 (PST)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FEE6128766 for <extra@ietf.org>; Fri, 9 Nov 2018 08:54:43 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 451D2221D0; Fri, 9 Nov 2018 11:54:42 -0500 (EST)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 09 Nov 2018 11:54:42 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.com; h= subject:to:references:from:message-id:date:mime-version :in-reply-to:content-type; s=fm1; bh=2d8e7hwe8xiWg26VV+Xnr4avVPU YwDEhbUcO3C8Ylf0=; b=ahOZwBEHSRGtImyy93XgI7ZGOzXF5zLx4UpO8Ip9AsS cu4X+439lK0Fp1qqy5dEJ/TNdtZ1wStduI1Qw/s8pcV28cYtFyaxfmAwMWBVwdxR S2ViKbqjjW8E1U8j7hSMlQyL7EskBZbCTMcTi6+jsqpkf5l/OqM6YwaqFA5O/QP8 KdAbpR6mOOjWjefxXUXrgEW7AJD/6EtX9EawuJbfB78RSkrzvuf+aaQo9A+zG4RF HZmFteZuXT5IIoJpeoCse7IJzf1XPKXa8Ad3CVoNqwPsliB82Gm7rtfKek54jBmO dZXl0z8u3krHw7VusrrYzcZfpl9hB8kLIYAyxQm1EUg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=2d8e7h we8xiWg26VV+Xnr4avVPUYwDEhbUcO3C8Ylf0=; b=wJziNQ6ubEqbbumB1fUwK7 C4JHf584X8zyd9Hdd+cZh//okRi4S+G5s8oi7j509XsK+/QOQbnLlicmJYe2eW8t 4qgno5IgNwfHG9+PEr2eS3MTKbcIm2DM//rc/nD0tEd1tFTnCShpOw1Xx00+PLP7 75uDdhk7YTOuRG4ppledSyxdhEw/YkpD3vyCM2qMC1Qr2zhZoFe96hA6nsN+XkLq tlZz5HlVCdOdZ6MDm0YthuhmruLgPhS16VCc9TlEtisH73oRT0O6BomKHSqsex6m lJyKQdCQTsHk1rqVSh2Ockx03RxGL8Ss+jpF4PPSNhoNhshrfCoxTl+ATNyOOmdw ==
X-ME-Sender: <xms:0bvlW_mQVPtsiArBIhUqMtkbeL2EmMl0MPPLdza-BYKfTU1qPs7IyQ>
X-ME-Proxy: <xmx:0bvlW8oZW7aMb59gBLgqG3eD0gUJ5SHaVdCgW5IumNdFK4KycoGYvQ> <xmx:0bvlW8vWesKb1b3o6tAzz39E5GrvyVAdgAvUDtYLOXvbV6TlhddZXw> <xmx:0bvlWxEyRqzbLpK3vJtWBBPnE1KbgHzfIdgsDhtqEPWvZd3TZQ4sCA> <xmx:0bvlW1aS897wR8TZbd5HzeKHsUU_HN8MizDxmjubHSqjoyA6fDB19g> <xmx:0bvlW5VQA9JR9Tn6BLXcSV0k7V0yGMODUtEj4qKUGjueEdTE-9sM5g> <xmx:0rvlWz1qQlZ9b-byUSxdj_G1eH2fxHbwpISP9lvzJb-dbIISIdyL3Q>
Received: from localhost.localdomain (14.sub-174-224-140.myvzw.com [174.224.140.14]) by mail.messagingengine.com (Postfix) with ESMTPA id 5ED32E4750; Fri, 9 Nov 2018 11:54:41 -0500 (EST)
To: Alexey Melnikov <alexey.melnikov@isode.com>, extra <extra@ietf.org>
References: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com>
From: Ken Murchison <murch@fastmail.com>
Organization: FastMail US LLC
Message-ID: <fb5a5946-3c09-fa42-7f9e-fc0344e134da@fastmail.com>
Date: Fri, 9 Nov 2018 11:54:39 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <2a2f0f33-b056-1a04-aa11-8b8d0a448a4c@isode.com>
Content-Type: multipart/mixed; boundary="------------13B2525C5F3E3AFF44B223B8"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/hbbg3r1IlXLkalcCeH-wwxi63f0>
Subject: Re: [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: Fri, 09 Nov 2018 16:54:46 -0000

On 10/16/18 12:35 PM, Alexey Melnikov wrote:
> 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>


Hmm.  I'd like to use a syntax which can be extended to include 
compatible fileinto arguments as part of FCC (related to your point 
below about use of =/


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


I think some of this text was borrowed from special-use.  Would be be 
acceptable to do what fileinto does, which is if the target mailbox 
doesn't exist, then the message ends up in INBOX?  I'm also fine 
treating it as an error.



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


I will use "can".



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


The default comparator used by notify_method_capability is 
i;acsii-casemap.  In fact, the example in RFC5435 is quite similar.



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


Agreed.  Your text is clearer.



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


See above.  I'm open to suggestions on how to handle the grammar.



>
>    ":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
>
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC