Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-03

Alexey Melnikov <> Tue, 30 October 2018 20:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C585812D4F0 for <>; Tue, 30 Oct 2018 13:15:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UT7Pq_qzB64M for <>; Tue, 30 Oct 2018 13:15:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5709E1276D0 for <>; Tue, 30 Oct 2018 13:15:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1540930499;; s=june2016;; bh=Fd0y315Y0H13A1pEmLsfQSpciedbdUb878//4cr8P5U=; 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=E8GutGEUmm7lRDUmIN0ywbYCSzfgSs3kmbJV1+AOfv2mznICnsz2XJ9nuKcWaPXEGRMl5d 1NTD8V//b7C+6SkLqAnY9g1H9r12xdpBf4GJdXZ6SSpy0Kui9/zYD6bG8Zjna3qeWyEtoD vj0eCXP2F5+vQMAbJlORPRsYskvTWbk=;
Received: from [] ( []) by (submission channel) via TCP with ESMTPSA id <>; Tue, 30 Oct 2018 20:14:58 +0000
To: Stephan Bosch <>,, Ned Freed <>
References: <> <>
From: Alexey Melnikov <>
Openpgp: preference=signencrypt
Message-ID: <>
Date: Tue, 30 Oct 2018 20:15:00 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [Extra] Comments on draft-ietf-extra-sieve-special-use-03
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Email mailstore and eXtensions To Revise or Amend <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 30 Oct 2018 20:15:02 -0000

Hi Stephan,

On 29/10/2018 12:06, Stephan Bosch wrote:
> Hi Alexey,
> Op 28-10-2018 om 16:07 schreef Alexey Melnikov:
>> Hi all,
>> I've just tried to implement this Sieve extension and I have a couple of
>> comments:
>> 3.  Test "specialuse_exists"
>>     Usage:  specialuse_exists [<mailbox: string>]
>>                               <special-use-flags: string-list>
>> This defines an optional argument. According to the base Sieve RFC 5228,
>> optional arguments must be tagged:
>>    2.6.1.  Positional Arguments
>>     Positional arguments are given to a command that discerns their
>>     meaning based on their order.  When a command takes positional
>>     arguments, all positional arguments must be supplied and must be in
>>     the order prescribed.
>>   and
>>    2.6.3.  Optional Arguments
>>     Optional arguments are exactly like tagged arguments except that they
>>     may be left out, in which case a default value is implied.  Because
>>     optional arguments tend to result in shorter scripts, they have been
>>     used far more than tagged arguments.
>> So I don't think you can have "mailbox" being positional without a tag!
> Then what about the entirety of the "imap4flags" extension?

Guilty as charged :-). I entirely forgot about that and the reason why I
haven't noticed is because my implementation doesn't support "variables"
extension, so variable name parameter to addflag/removeflag/setflag is
never allowed.

Any other opinions (Ned?). I just want to make sure that if we violating
some kind of architectural principle specified in the base Sieve script,
than we decide to do this deliberately. (Or maybe we just agree that
there is no architectural principle to begin with.)

> Lots of
> tag-less optional arguments can be found there. I am not against having
> some ":mailbox" tag here, but the current syntax does make things more
> concise.
>> 4.  ":specialuse" Argument to "fileinto" Command
>>     Usage:  fileinto [:specialuse <special-use-flag: string>]
>>                      <mailbox: string>
>> Can I suggest that all special-use-flag strings should not include the
>> leading "\" character? It requires escaping in Sieve, so people might
>> make mistakes when writing scripts.
> I have no strong opinion about that. Disadvantage of doing that is that
> it can be confusing for people with IMAP experience and it becomes
> inconsistent with imap4flags.

Yes, that is true. At the same time in JMAP we can do remove leading "\"
character from flag names as well.

So yes, I am not fully decided on this issue. Anybody else wants to comment?

> Anyone else want to pitch in?
> Regards,