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

From: Ken Murchison <[email-masked]>
Date: Fri, 9 Nov 2018 11:54:39 -0500

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:[email-masked]?message;subject=SIEVE";
>    } else {
>        notify :fcc "INBOX.Sent"
>               :message "You got mail!"
>               "mailto:[email-masked]";
>    }
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 16 Nov 2018 18:25:52 +0000

Hi Ken,

> compatible fileinto arguments as part of FCC (related to your point 

I think you either need to change the comment that starts with "For 
convenience" to reference Sieve RFC syntax or you change FCC to be 
proper ABNF. I think doing the former would be easier.

>> confuse users? I would like to either have a way to test for 
>> different behaviour
>>
That would be fine with me.

>> Please make it clear that subject encodings used by RFC 2231 are Ok 
>> to be used,

Ok. Maybe it is worth pointing this out.

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

I would something like this instead:

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

And explain that FCC_EXTRA can be used any time FCC is included.

It is probably ok to use "=/" for FCC_EXTRA, but you might want to 
define this in prose. Something along the lines of using =/ similar to 
the way that ABNF defines it, although you are not using exact ABNF syntax.

---

From: Ken Murchison <[email-masked]>
Date: Mon, 26 Nov 2018 12:37:30 -0500

>> doesn't exist, then the message ends up in INBOX?  I'm also fine 

Actually, the text that you quote comes straight from the fileinto 
description in RFC 5228.  Do you still want me to put a stake in the 
ground and pick one behavior?

-- 
Ken Murchison
Cyrus Development Team
FastMail US LLC