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

From: Alexey Melnikov <[email-masked]>
Date: Sun, 28 Oct 2018 15:07:10 +0000

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!

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.

Best Regards,
Alexey

---

From: Stephan Bosch <[email-masked]>
Date: Mon, 29 Oct 2018 13:06:23 +0100

Hi Alexey,

> So I don't think you can have "mailbox" being positional without a tag!

Then what about the entirety of the "imap4flags" extension? 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.

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

Anyone else want to pitch in?

Regards,

-- 

Stephan Bosch
Senior Developer

Phone: +49 2761 75252 00  Fax: +49 2761 75252 30
Email: [email-masked]

-------------------------------------------------------------------------------------
Open-Xchange AG,  Rollnerstr. 14, 90408 Nuremberg, District Court Nuremberg HRB 24738
Managing Board: Rafael Laguna de la Vera, Carsten Dirks, Uwe Reumuth
Chairman of the Board: Richard Seibt

Dovecot Oy, Lars Sonckin Kaari 10, 02600 Espoo, Finland
Managing Director: Markku Kenttä
Chairman of the Board: Timo Sirainen
Board Member: Carsten Dirks

-------------------------------------------------------------------------------------

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 30 Oct 2018 20:15:00 +0000

Hi Stephan,

On 29/10/2018 12:06, Stephan Bosch wrote:
> 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

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?