-
-Sieve Syntax and Semantics
-
-RFC 3028 confuses syntax and semantics sometimes. It uses a generic
-grammar as syntax for actions and tests and performs many checks during
-semantic analysis. Syntax is specified as grammar rule, semantics
-with natural language, despire the latter often talking about syntax.
-The intention was to provide a framework for the syntax that describes
-current commands as well as future extensions, and describing commands
-by semantics. Since the semantic analysis is not specified by formal
-rules, it is easy to get that phase wrong, as demonstrated by the mistake
-in RFC 3028 to forbid "elsif" being followed by "elsif" (which is allowed
-in Sieve, it's just not specified correctly).
-
-RFC 3028 does not define if semantic checks are strict (always treat
-unknown extensions as errors) or lazy (treat unknown extensions as error,
-if they are executed), and since it employs a very generic grammar,
-it is not unreasonable for an implementation using a parser for the
-generic grammar to indeed process scripts that contain unknown commands
-in dead code. It is just required to treat disabled but known extensions
-the same as unknown extensions.
-
-The following suggestion for section 8.2 gives two grammars, one for
-the framework, and one for specific commands, thus removing most of the
-semantic analysis. Since the parser can not parse unsupported extensions,
-the result is strict error checking. As required in section 2.10.5, known
-but not enabled extensions must behave the same as unknown extensions,
-so those also result strictly in errors (though at the thin semantic
-layer), even if they can be parsed fine.
+The following replacement for section 8.2 gives a grammar for specific
+commands of this implementation, thus removing most of the semantic
+analysis. Since the parser can not parse unsupported extensions, the
+result is strict error checking of any executed and not executed code
+until "stop" is executed or the end of the script is reached.