Subject: Re: I-D ACTION:draft-ietf-sieve-3028bis-04.txt

From: Michael Haardt <[email-masked]>
Date: Thu, 21 Jul 2005 10:27:48 +0200

Hello,

now there is only one open issue left on my list:

Section 1.1:

   Each section on a command (test, action, or control) has a line
   labeled "Syntax:".  This line describes the syntax of the command,
   including its name and its arguments.

If this line described syntax, its contents would be listed in the
grammar.  There is a number of RFCs that list specific rules throughout
the document, explaining them, and all of them are listed together in
the full grammar.  That's _not_ the case for Sieve.

RFC 3028 confuses syntax and semantics sometimes.  It uses a generic
grammar as syntax for commands and tests and performs many checks during
semantic analysis.  Syntax is specified by grammar rules, semantics by
natural language.  Section 1.1 should either say "Semantics" or there
should be two grammars: A generic grammar (the one currently given)
and a specific grammar.  The latter could be written by introducing a
new structure for sets of elements that may appear in any order.

Michael

---

From: Tim Showalter <[email-masked]>
Date: Thu, 21 Jul 2005 10:02:47 -0700

> the full grammar.  That's _not_ the case for Sieve.

You're right.  The word "Syntax" should be replaced by "Usage" or 
something.  I don't think "Semantics" is right, either.

Tim

---

From: Ned Freed <[email-masked]>
Date: Thu, 21 Jul 2005 14:43:13 -0700 (PDT)

> something.  I don't think "Semantics" is right, either.

"Usage:" would be my choice - it matches what's commonly used in many other
sorts of documents for this stuff. I'm going to switch the vacation and
date/index drafts to use "Usage:" for now.

As to the idea of actually using formal grammar for this sort of thing, been
there, done that, bad idea. Having been on the receiving end of questions for
RFC 1521 issues, I can tell you that using subgrammars (or whatever the correct
term for this is) creates about 10X more confusion than clarity.

The simple fact of the matter is that people just aren't that good at
extracting usage information from ABNF. THis isn't to say we should not have a
precise definition of the overall syntax in ABNF - implementors at the very
least need it - but using ABNF to provide usage information' goes too far. The
form we use now is simple, easy to read, and gets the job done.

				Ned

---

From: Michael Haardt <[email-masked]>
Date: Fri, 22 Jul 2005 10:03:53 +0200

> something.  I don't think "Semantics" is right, either.

"Usage" sounds much better indeed.

Michael

---

From: Michael Haardt <[email-masked]>
Date: Fri, 22 Jul 2005 10:34:46 +0200

> term for this is) creates about 10X more confusion than clarity.

Too bad, but I guess a paragraph like

  All Sieve commands, including extensions, MUST be words of the following
  generic grammar with the start symbol "start".  They SHOULD be specified   
  using a specific grammar, though.

is not going to help most people a lot, despite specifying *exactly*
the same as RFC 3028.

> least need it - but using ABNF to provide usage information' goes too far. 

I built a full ABNF for my implementation to move as much as possible
from semantic analysis to syntactic analysis, but that is just one
possible approach.  I append my implementation notes, but they are
not meant as suggested change to the draft, but to illustrate the step
between RFC 3028 and actual code.  The { } specification is pretty
weak and just "worked for me".

I am pretty sure others use the generic ABNF for syntactic analysis,
following straightforward RFC 3028.  That is well possible and it does
not need a specific grammar.

> The

Once "Syntax" is replaced by "Usage", it is fine with me and I shall
agree to the next released draft.

Michael
----------------------------------------------------------------------
The grammar is specified in ABNF with two extensions to describe tagged
arguments that can be reordered and grammar extensions: { } denotes a
sequence of symbols that may appear in any order.  Example:

  options = a b c
  start =  { options }

is equivalent to:

  start =  ( a b c ) / ( a c b ) / ( b a c ) / ( b c a ) / ( c a b ) / ( c b a )

The symbol =) is used to append to a rule:

  start =  a
  start =) b

is equivalent to

  start =  a b

All Sieve commands, including extensions, MUST be words of the following
generic grammar with the start symbol "start".  They SHOULD be specified
using a specific grammar, though.

   argument        = string-list / number / tag
   arguments       = *argument [test / test-list]
   block           = "{" commands "}"
   commands        = *command
   string          = quoted-string / multi-line
   string-list     = "[" string *("," string) "]" / string
   test            = identifier arguments
   test-list       = "(" test *("," test) ")"
   command         = identifier arguments ( ";" / block )
   start           = command

The basic Sieve commands are specified using the following grammar, which
language is a subset of the generic grammar above.  The start symbol is
"start".

  address-part     =  ":localpart" / ":domain" / ":all"
  comparator       =  ":comparator" string
  match-type       =  ":is" / ":contains" / ":matches"
  string           =  quoted-string / multi-line
  string-list      =  "[" string *("," string) "]" / string
  address-test     =  "address" { [address-part] [comparator] [match-type] }
                      string-list string-list
  test-list        =  "(" test *("," test) ")"
  allof-test       =  "allof" test-list
  anyof-test       =  "anyof" test-list
  exists-test      =  "exists" string-list
  false-test       =  "false"
  true=test        =  "true"
  header-test      =  "header" { [comparator] [match-type] }
                      string-list string-list
  not-test         =  "not" test
  relop            =  ":over" / ":under"
  size-test        =  "size" relop number
  block            =  "{" commands "}"
  if-command       =  "if" test block *( "elsif" test block ) [ "else" block ]
  stop-command     =  "stop" { stop-options } ";"
  stop-options     =
  keep-command     =  "keep" { keep-options } ";"
  keep-options     =
  discard-command  =  "discard" { discard-options } ";"
  discard-options  =
  redirect-command =  "redirect" { redirect-options } string ";"
  redirect-options =
  require-command  =  "require" { require-options } string-list ";"
  require-options  =
  test             =  address-test / allof-test / anyof-test / exists-test
                      / false-test / true-test / header-test / not-test
                      / size-test
  command          =  if-command / stop-command / keep-command
                      / discard-command / redirect-command
  commands         =  *command
  start            =  *require-command commands

The extensions "envelope" and "fileinto" are specified using the following
grammar extension.

  envelope-test    =  "envelope" { [comparator] [address-part] [match-type] }
                      string-list string-list
  test             =/ envelope-test

  fileinto-command =  "fileinto" { fileinto-options } string ";"
  fileinto-options =
  command          =/ fileinto-command

The extension "copy" is specified as:

  fileinto-options =) ":copy"
  redirect-options =) ":copy"

And so on ...

---

From: Philip Guenther <[email-masked]>
Date: Tue, 26 Jul 2005 21:16:29 -0700

>On Thu, Jul 21, 2005 at 10:02:47AM -0700, Tim Showalter wrote:
...
>"Usage" sounds much better indeed.

Done for rev -05...

Philip Guenther