List members,
I have just completed development of a C++ parser/interpreter based on
draft 3 of the sieve language. I sent Tim a couple of corrections that
were incorporated in the draft 4.
I have reviewed draft 4 and have a few comments:
Section 0.3 Open Issues - "I moved the substring matching stuff out of the
header command and into a section of its own..." I can't find it.
Section 2.3 Comments - "XXX this example is broken" It is? Similar
example is used in section 2.11.1. Is this related to the use of
the "new" ':' tagged arguments. Some places use "over", and some
places use ":over".
Section 2.6.1 Match Keyword - What happen to the "matches" keyword
for wildcard glob-style match? And why did we change to use "new"
':' tagged arguments, such as: ":is" and ":contains"? Also, some
of the examples use the "old" style arguments: "is" and "contains".
Section 2.6.2 Comparators - Just what to point out that header
name compares must be case insensitive. That is "From" is the
same as: "from" or "FROM" or "fRoM". However, the sieve default
(and only required) comparator is case sensitive for the keyword
value matching. I think that is would be better to make the
default (and only required) comparator case insensitive. Do
we think people want to do something different if the subject
is "make money fast" and "Make Money Fast" and "MAKE MONEY FAST"?
Section 2.7 Tagged Arguments - Again, I not sure why we switched
to these "new" ':' tagged arguments. However, the statement:
"Tagged arguments may appear in any order, and may be interspersed
with positional arguments."
is little scary. Does this mean these are valid and equivalent?
if header :is "From" "coyote(_at_)desert(_dot_)org"
if header "From" "coyote(_at_)desert(_dot_)org" :is
if header "From" :is "coyote(_at_)desert(_dot_)org
Section 3 Conditionals and Control Structures - Why was "elsif" added?
This is equivalent to "else if", just a shorter way of writing it.
My preference to reduce the number of ways the same thing can be said.
If it looks different, it takes people some time to conclude that it
really is not different.
Section 4.1 Action reject - The example (or message A) is incorrect.
The example is: if header "from" contains "coyote(_at_)zniz(_dot_)net"
However, message A says: From: coyote(_at_)desert(_dot_)org Also, this is
one example of inconsistent use of "contains" vs ":contains"
Section 4.2 Action fileinto - The example is incorrect.
The example is: if header ["to"] contains "coyote"
should be: if header ["from"] contains "coyote"
Section 10 Formal Grammar - Is not complete as in draft 3. I understand
that the command syntax was moved out and is described in the command
sections. However, there is now a disconnect between the command
syntax and what formal Grammar we defined. I thought that draft 3
was pretty good in terms of clarity. In draft 4, we are very formal
in defining just what a "string-list" is. However, in the commands
where it is used, Section 5.3 Test Exists and Section 5.5 Test Header,
the command syntax specifies <header-name-list> and <key-list> without
formally stating that they are, in fact, a "string-list".
In draft 3, we stated:
header = "header" WSP string-list WSP match-keyword WSP string-list
is very precise and clear.
Greg Sereda
AT&T Labs