Subject: Re: sieve bugs

From: Rob Earhart <[email-masked]>
Date: Wed, 16 Dec 1998 17:24:28 -0500 (EST)

(Tim asked me to go over the grammar...)

  The example in section 3 is bad, as has been pointed out on the list:
else is followed by a block, you can't put a command (like "if") there.
If you could, you'd be allowing the thing after an if or an else to be a
command, allowing you to write "if (foo) if (bar) baz; else qux;", which
is ambiguous to an LALR(1) parser.  So, yeah people need to use elsif,
they can't just use "else if".

  I thought we'd agreed that the rule was, "Tests don't have
side-effects", which meant that whether or not short-circuit evaluation
was performed was implementation-defined (you'd have no way to tell)?

  require: I wouldn't mind making it Magical; all require commands have to
come at the top of the script, and they're illegal after the first
non-require is processed. 

  Note that the way WSP is defined, something like

	foo; # do foo
             # because it's good

is illegal -- the space after the ';' is the after-command [WSP] in
commands, so the comment has to be the before-command [WSP] in
commands, so the spaces on the next line (not to mention the
comment) are illegal; there *must* be an indentifier there, to start 
a command.

  Heck,

	foo;# This is the after-command [WSP] in commands
	# This is the before-command [WSP] in commands
	# This is illegal

  This could probably fixed by putting the alternative inside the 1* in
the WSP rule.

  As written, the grammar has a shift/reduce conflict related to the way
tests are handled.  Here's an example of the ambiguity: 

	anyof allof true

The thing is, a test is an identifier, followed by zero or more arguments,
followed by an optional test-list.  A test can be an argument, though.  So
in this case, "allof" is an argument to "anyof", but "true" could be an
argument to either -- the scanner doesn't know whether to shift, making it
an argument of "allof", or reduce "allof" to a test and make "true" an
argument of "anyof".

  I'd solve this by removing "test" as a possible "argument", and putting
an optional "test" into the rule for "command", just before the block /
";".  I think this still fits with all the existing commands, and makes
the system as a whole cleaner.  I thought about making seperate "command
arguments" and "test arguments", where test arguments couldn't themselves
contain a test, but that leaves open another subtle hole: 

	command test "foo";

can be parsed with "foo" being an argument to the test (if shifted) or to
the command (if "foo" is reduced).  The other thing which came to mind was
to require that tests used as arguments be parenthesized, but that would
be a pretty significant change -- nothing that uses tests bothers
parenthesizing them, in the current spec.

  The grammar might be simpler if it were chopped it into seperate
lexical, syntactic, and semantic sections -- then it'd be a lot easier to
avoid mistakes like not allowing comments inside an empty block, and it
wouldn't have all the [WSP] all over the place.  It'd be easier to read
and easier to use, too.

  (I'll volunteer to write the grammar... it'd be a nice way to relax.)

  )Rob

---

From: Larry Greenfield <[email-masked]>
Date: 26 Dec 1998 21:55:29 -0500

Rob Earhart suggested the following fix for the grammar:
   [...]
   As written, the grammar has a shift/reduce conflict related to the way
   tests are handled.  Here's an example of the ambiguity: 

      anyof allof true
   [...]
   I'd solve this by removing "test" as a possible "argument", and putting
   an optional "test" into the rule for "command", just before the block /
   ";".  I think this still fits with all the existing commands, and makes
   the system as a whole cleaner.  [...]

Unfortunately, this doesn't work.  A "not" takes a test as an
argument, and this would prevent that.

Larry

---

From: Rob Earhart <[email-masked]>
Date: Sat, 26 Dec 1998 23:44:08 -0500 (EST)

> argument, and this would prevent that.

  Oops--missed that.  Yeah, you really need the optional test at the end
of the "test" rule as well.  How 'bout something like

           test = identifier arguments

           command = identifier arguments [WSP] ( ";" / block )

           arguments = *(WSP argument) [WSP (test / test-list)]

?  (It's also possible to just make test-list an argument, but the
optional test really needs to be there with both test and command; this
isn't ambiguous, because there's still only one optional test at the end
of a test or command, so the parser can always shift when it sees a test 
without the parens.)

  )Rob

Date: Sat, 26 Dec 1998 23:44:08 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: sieve bugs
Sender: [email-masked]

> argument, and this would prevent that.

  Oops--missed that.  Yeah, you really need the optional test at the end
of the "test" rule as well.  How 'bout something like

           test = identifier arguments

           command = identifier arguments [WSP] ( ";" / block )

           arguments = *(WSP argument) [WSP (test / test-list)]

?  (It's also possible to just make test-list an argument, but the
optional test really needs to be there with both test and command; this
isn't ambiguous, because there's still only one optional test at the end
of a test or command, so the parser can always shift when it sees a test 
without the parens.)

  )Rob

Date: 26 Dec 1998 21:55:29 -0500
From: Larry Greenfield <[email-masked]>
To: [email-masked]
Subject: Re: sieve bugs
Sender: [email-masked]

      anyof allof true
   [...]

Larry

Date: Wed, 16 Dec 1998 17:24:28 -0500 (EST)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: sieve bugs
Sender: [email-masked]

	foo; # do foo
             # because it's good

  Heck,

	anyof allof true

	command test "foo";

  )Rob

Date: 9 Dec 1998 16:43:41 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: require inside an unused block
Sender: [email-masked]

Consider the following:

	if false { require "whatever"; }
	fileinto "INBOX.foo";

Does the script process at all?  (I'd like it to just out-and-out fail,
but that requires a very specific idea of what "require" does that some
people will probably not like.)

What exactly happens in the

	fileinto "INBOX.foo"
	if true { require "whatever"; }

case?

My preference is that when a script is going to go wrong, it do so at
the first possible moment, and making require sufficiently magic would
make that very easy (albeit gross).

-- 
Tim Showalter <[email-masked]>

Date: Tue, 8 Dec 1998 17:25:33 -0500
To: Tony Hansen <[email-masked]>, Tim Showalter <[email-masked]>
From: Randall Gellens <[email-masked]>
Subject: Re: Sieve Meeting Notes
Cc: [email-masked]
Sender: [email-masked]

At 1:52 AM -0500 12/8/98, Tony Hansen wrote:
> The only thing I caught as missing was the discussion of matching 
> on the group
> name portion of an address, known as the display name in 821bis parlance.
> This was discussed, but not enough interest was shown to support it.

It was decided that this is done by simply using HEADER.

Date: Tue, 8 Dec 1998 17:23:29 -0500
To: Tim Showalter <[email-masked]>, [email-masked]
From: Randall Gellens <[email-masked]>
Subject: Re: Sieve Meeting Notes
Sender: [email-masked]

> With both capability and failure notification, we concluded that there had to
> be a third party to get extensions from and to make notes of failure on.  It
> was noted that due to the nature of the game, we were doomed to 
> having a third
> party (not delivery server, not client) that holds extension and failure
> information;

This does not have to be a third party.  The Sieve execution agent 
can implement just enough ACAP to allow clients to access and store 
scripts, and get capability and warning/error info.

>
> Envelope-matching command should take similar commands to address match:
> :localpart / :domain / :all
>
> This also requires parts of an 822 parser, but less of them (see above).

Well, an 821 parser if the actual envelope is still around or has 
been passed to the Sieve execution agent.

Date: 8 Dec 1998 10:01:39 -0500
From: Tim Showalter <[email-masked]>
To: Tony Hansen <[email-masked]>
Cc: [email-masked]
Subject: Re: sieve & short-circuit evaluation
Sender: [email-masked]

> Date: Tue, 08 Dec 1998 01:42:13 -0500
> From: Tony Hansen <[email-masked]>

> I may be stating the obvious here, but don't forget that short circuit
> conditionals can always be rewritten using nested if statements.

Okay, good point.  Thank you.

Tim

-- 
Tim Showalter <[email-masked]>

Date: Tue, 08 Dec 1998 01:52:14 -0500
From: Tony Hansen <[email-masked]>
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: Sieve Meeting Notes
Sender: [email-masked]

Tim Showalter wrote:

> 1:30 7 dec 1998 Poolside Sieve Meeting Notes
>
> Here are my notes combined with some of Ryan Troll's from today's Sieve
> meeting.  These notes have drifted somewhat out of order, especially
> towards the beginning, as the discussion was meandering and in order to
> make the notes pretty I had to split out conclusions.

The notes look pretty complete.

The only thing I caught as missing was the discussion of matching on the group
name portion of an address, known as the display name in 821bis parlance.

This was discussed, but not enough interest was shown to support it.

> * Attendees
>
> We didn't take attendance.

There were around 25 of the usual suspects. :-)

    Tony Hansen
    [email-masked]

Date: Tue, 08 Dec 1998 01:42:13 -0500
From: Tony Hansen <[email-masked]>
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: sieve & short-circuit evaluation
Sender: [email-masked]

Tim Showalter wrote:

> Today a bunch of us got together by the pool to discuss whether or not
> Sieve should have short-circut evalation.  After some arguing, we
> concluded that it shouldn't, and that extensions that made use of it
> were just a bad idea.
>
> One note, though.  While I still believe this is the right conclusion,
> this is the mechanism that some languages (C, LISP) use to return an
> exceptional condition (disk full, network exploded, etc.).
>
> This means that if we get a complex extension that can fail when it is
> run AND we have enough of a language for a fallback condition, we'll
> have to provide a way to handle what amounts to an exception.

I may be stating the obvious here, but don't forget that short circuit
conditionals can always be rewritten using nested if statements. It's a
straight forward conversion. Unfortunately, else clauses after such a
conditional need to be duplicated to get equivalent functionality:

This:
    if extension_that_can_fail() && something_else() {
        # this requires short circuit evaluation
    }
becomes:
    if extension_that_can_fail() {
        if something_else() {
            # nested if is equivalent to short circuit evaluation
        }
    }

And this:
    if extension_that_can_fail() && something_else() {
        # this requires short circuit evaluation
    }else {
       some_more_code();
    }
becomes:
    if extension_that_can_fail() {
        if something_else() {
            # nested if is equivalent to short circuit evaluation
        }else {
           some_more_code();
        }
    }else {
       some_more_code();
   }

    Tony Hansen
    [email-masked]

Date: 7 Dec 1998 21:30:10 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Sieve Meeting Notes
Sender: [email-masked]

1:30 7 dec 1998 Poolside Sieve Meeting Notes

Here are my notes combined with some of Ryan Troll's from today's Sieve
meeting.  These notes have drifted somewhat out of order, especially
towards the beginning, as the discussion was meandering and in order to
make the notes pretty I had to split out conclusions.

 * 03 vs 05 specifications

Started with discussion on draft 03 (old, rigid grammar) vs draft 04/05 (new
grammar, but the specification is not as precise).  Decided that 05 is
definately the right thing, but that 05 needs to be much more precise than it
is (see Gregory Sereda's comments).  The biggest problem is the loss of proper 
typing information for the arguments, but the erroneous examples are another
problem.

 * Extensions

This lead into a discussion of extensions (again).  After some deliberation,
it was decided that we need a require test, and that the require indicates
that the script is to abort if the extension is not availible.

We discussed extensions, and there were three approaches named:
  - no extensions?  can always validate, but will always suck
  - out-of-band extension discovery?
  - conditional extensions based on execution

We agreed that the workable approach for extensions done as a part of the
language was what LISP, Tcl, and others: An extension is enabled only when a
script has a `requires "fooextension";'.  If the requires is not supplied, the 
extension is not enabled (in order to encourage clients to put the "requires"
in).

The syntax for requires will be this:

  "requires" <extensions: string-list> ";"

  - Failure mode for requires?  Make note in accounts dataset in ACAP?
  - If you don't require an extension, IT DOES NOT WORK.

 * Capability

Without require, there is a clear need for an out-of-band expression of which
extension capabilities are required.  We still assume that many scripts want
this, but we have specified only one way of doing this (ACAP).

 * Third party

With both capability and failure notification, we concluded that there had to
be a third party to get extensions from and to make notes of failure on.  It
was noted that due to the nature of the game, we were doomed to having a third
party (not delivery server, not client) that holds extension and failure
information; Randy Gellens account dataset has scripts for this information.

 * Mail Loops

Decided to allow multiple forwards after a very brief discussion.

Loop detection is REQUIRED.  This is defined as a requirement that message
MUST NOT PASS THROUGH YOU TWICE, but how you do it is up to you.

 * Name of the "forward" command

Rename "forward" "redirect" because "forward" and "resend" are overloaded with
mutually exclsive meanings.  ("Vomit", "regurgitate", and "spam" were rejected
but duly considered by those present.)

 * Short Circuit Evaluation

Short circuit evaluation is not required, because we agreed that it was not a
good idea for tests to have side effects.  So tests must not have side
effects.  It was requested that I add reasoning for this.

 * Address-matching primitive

Decided on an address matching primitive, like this:

"address" :localpart / :domain / :all [ :comparator <argument> ]
   [ :match / :is / :contains ] < list of headers : string-list > 
   < list of keys : string-list >

For address parsing, only significant part of address is matched, a match
keyword can be supplied, and whether to match the left, the right, or both
parts of the address can be specified.

Just parse on significant address, no comments, no phrase.  This may be a
partial punt, but we thought this was mostly the right thing.  This requires
full 822 parser, and while there was some concern of the complexity of this,
we decided that since everyone had an 822 parser we could just do it.

 - standard comparator stuff otherwise, defaulting to i;ascii-casemap.

 * Envelope-matching primitive

Envelope-matching command should take similar commands to address match:
:localpart / :domain / :all

This also requires parts of an 822 parser, but less of them (see above).
 
Envelope is REQUIRED to drop source routes.

 * Interoperability testing

We need to schedule interoperability tests and figure out exactly what that
means given varying implementations and varying mailbox formats.  Matt Wall
plans on putting example scripts and messages on the Cyrusoft web site.

* Attendees

We didn't take attendance.

-- 
Tim Showalter <[email-masked]>

Date: 7 Dec 1998 20:43:23 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: match-keyword in address match primitive
Sender: [email-masked]

At the informal Sieve meeting today, we decided to have an address
matching primitive.  I believe that such a primitive should take a match 
keyword argument (:is, :contains, or :matches), and I think that we
meant to say so.

I assume this is the right thing, so I'm going to put it in my notes,
which I'll post real soon now.

-- 
Tim Showalter <[email-masked]>

Date: 7 Dec 1998 19:37:00 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: sieve & short-circuit evaluation
Sender: [email-masked]

Today a bunch of us got together by the pool to discuss whether or not
Sieve should have short-circut evalation.  After some arguing, we
concluded that it shouldn't, and that extensions that made use of it
were just a bad idea.

One note, though.  While I still believe this is the right conclusion,
this is the mechanism that some languages (C, LISP) use to return an
exceptional condition (disk full, network exploded, etc.).

This means that if we get a complex extension that can fail when it is
run AND we have enough of a language for a fallback condition, we'll
have to provide a way to handle what amounts to an exception.

I'll have real notes from the meeting posted soon.

Tim

-- 
Tim Showalter <[email-masked]>

Date: Sun, 06 Dec 1998 21:02:55 -0500
From: Matthew Wall <[email-masked]>
To: [email-masked]
cc: Tim Showalter <[email-masked]>
Subject: Meeting time
Originator-Info: login-id=wall; server=imap.cyrusoft.com
Sender: [email-masked]

I would propose getting together at or immediately following the Apps area
open meeting on Monday morning. We can pick a time then, or do lunch Monday.

- mw

--On Sun, Dec 6, 1998 16:40 -0800 the entity known as [email-masked] wrote:

> Tim Showalter wrote:
> 
> > By the way, it appears the social was scheduled for Tuesday night (see
> > <http://ietf43.microsoft.com/> for details) which means we either meet
> > at the social, before the social, or at some other time.
> 
> I would rather not overload the social.
> 
> > Tim
> >
> > --
> > Tim Showalter <[email-masked]>
> 
> Alexey Melnikov
> 
> 
> 
> 

 =====================================================================
   Matthew Wall * mailto:[email-masked] * http://www.cyrusoft.com
   Cyrusoft International, Inc.          Proud Purveyors of Mulberry
            "Making the desktop safe for IMAP since 1995"
            Coming soon: "retro" POP and offline features
 =====================================================================

From: [email-masked]
Date: Sun, 06 Dec 1998 16:40:08 -0800
To: Tim Showalter <[email-masked]>
CC: [email-masked]
Subject: Re: draft-showalter-sieve-05.txt
Sender: [email-masked]

Tim Showalter wrote:

> By the way, it appears the social was scheduled for Tuesday night (see
> <http://ietf43.microsoft.com/> for details) which means we either meet
> at the social, before the social, or at some other time.

I would rather not overload the social.

> Tim
>
> --
> Tim Showalter <[email-masked]>

Alexey Melnikov

Date: Fri, 04 Dec 1998 14:27:18 -0500
To: Tim Showalter <[email-masked]>, [email-masked]
From: Gregory Sereda <[email-masked]>
Subject: Other bugs in draft 5 specification
Sender: [email-masked]

At 12:27 PM 12/4/98 -0500, Tim wrote:
>I seem to have real trouble finding bugs in my examples.  If there are
>examples that still aren't valid, or are questionable, that you've
>noticed, please let me know so that I can fix them before I put out the
>next version.  I'll fix all the ones you've mentioned so far.

As I pointed out, I'm having a bit to trouble figuring out what is
valid sieve due to inconsitencies in draft 5.  However, I think
that I now have a good idea what the sieve spec is supposed to say.

Here are other bugs, based on my understanding:

2.4.2.1. String Lists

   For instance, the test `header ["To", "Cc"] contains
   ["[email-masked]", "[email-masked]"]' 

Bug: match keyword should be ":contains" and comes before header names.

4.1. Action reject

   Example:  if header "from" contains "[email-masked]" {
                reject "I am not taking mail from you, and I don't want
                your birdseed, either!";
             }

Bug: match keyword should be ":contains" and comes before header names.

4.7. Action discard

   Example:  if header ["from"] contains ["[email-masked]"]
             discard;

Bug: match keyword should be ":contains" and comes before header names.
     Also, discard must be block, enclosed by { ... }

5.5. Test header

   Syntax:   header <match-keyword> <header-name-list> <key-list>

   The "header" test evaluates to true if the any header name matches
   any key.  How the match is done is described by the second argument,
   which is one of the string comparison arguments discussed in section
   2.6.  The first argument to header, the header-name-list, is a list
   of headers to get values from to be searched.  The key-list is a list
   of keys.

Bug: description is wrong, match-keyword is tagged argument must
     preceed positional arguments.  Syntax does not show optional
     ":compartor" arguments.  Also, syntax does not show that
     <match-keyword> is optional tagged argument.

           header ["X-Caffeine"] is [""]         => false
           header ["X-Caffeine"] contains [""]   => true

Bug: match keyword should be ":contains" and comes before header names.
     match keyword should be ":is" and comes before header names.

5.7. Test size

   Syntax:   size <":over" / ":under"> <limit [quantifier]>

   The "size" test deals with the size of a message.  It takes either a
   tagged argument of ":over" or ":under", followed by a number
   representing the size of the message.

Question: is there a default if neither ":over" or ":under" tagged
   arguments are specified, as in the <match-keyword> case?
   My guess is no, there is no default. Actually, I'm not sure
   why we have a default in the <match-keyword> case, ie ":is"

Greg Sereda

Date: 4 Dec 1998 01:09:18 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Re: draft-showalter-sieve-05.txt
Sender: [email-masked]

By the way, it appears the social was scheduled for Tuesday night (see
<http://ietf43.microsoft.com/> for details) which means we either meet
at the social, before the social, or at some other time.

Tim

-- 
Tim Showalter <[email-masked]>

Date: Thu, 03 Dec 1998 17:26:32 -0500
To: Tim Showalter <[email-masked]>, [email-masked]
From: Gregory Sereda <[email-masked]>
Subject: Re: List of expected changes for sieve 05 draft
Sender: [email-masked]

List members,

I implemented draft 3, and felt that is was a very tight specification
with very little, if any, ambiguity.  I commented on draft 4 that there
was more ambiguity related to "elsif" and "else if", tagged arguments,
and changes to way the language was specified.

Now that draft 5 is out and I am trying to update my draft 3
implementation, I still feel significant ambiguity remains.

Here are some of the issues that Tom tried to address in draft 5
and my comments...

At 04:40 PM 11/6/98 -0500, Tim Showalter wrote:
>2a. Can we keep tagged arguments?
>
>2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
>    interspersed in commands.  This was probably a mistake, but I wanted to
>    preserve wordings like this:
>
>       header "From" :contains "tjs"
>
>    What do people want?  The dominant stated opinion is that they should
only 
>    happen after the keyword, and that's fine with me.

Draft 5 states:
----
2.6
   Tagged arguments must appear before positional arguments.

2.7.1
   In order to specify  what  type  of  match  is  supposed  to  happen,
   commands   that  support  matching  take  optional  tagged  arguments
   ":matches", ":is", and ":contains".  Commands default to using  ":is"
   matching.

5.5. Test header

   Syntax:   header <match-keyword> <header-name-list> <key-list>

   The "header" test evaluates to true if the any header name matches
   any key.  How the match is done is described by the second argument,
   which is one of the string comparison arguments discussed in section
   2.6.  The first argument to header, the header-name-list, is a list
   of headers to get values from to be searched.  The key-list is a list
   of keys.
-----
The way I interpret this is the that match-keyword is optional,
therefore it must be tagged and appear before positional arguments.
The syntax in section 5.5 Test header appears to agree.

However, the description following and all the examples show the
match-keyword as the second positional argument.  What seems to
be clear, is that the match-keyword is definitely optional.

So this example should be OK:
	
	if header "From" ["[email-masked]", "[email-masked]"]
            discard;

>
>3.  Elsif was added because it removes an ambiguity in the grammar, making
>    "else" yet another command.  This is discussed in anything that talks
>    about writing C parsers; "else if" is an imbiguity, and many languages
>    have an "elsif" as a result.  I have a fairly strong preference for this.
>
>    Note that "else if" is illegal in 04.

I don't understand this.  I raised the issue that there was no difference
between "elsif" and "else if".  You say that "else if" is illegal, but
both draft 4 and draft 5 have examples.

You try to distinguish between them in the draft 5 example...
----
   In the following example, both Message A and B are dropped.

   Example:  if header "from" contains "coyote" {
                discard;
             } elsif  header ["subject"] :contains ["$$$"] {
                discard;
             } else {
                fileinto "INBOX";
             }

   In the script below, when run over message A, forwards the message to
   [email-masked];  message B, to [email-masked]; any other
   message is forwarded to [email-masked].

   Example:  if header ["From"] contains ["coyote"] {
                forward "[email-masked]";
             } else if header "Subject" contains "$$$" {
                forward "[email-masked]";
             } else {
                forward "[email-masked]";
             }
----
In that latter example, I cannot see how more than one command
block would be executed, supposedly, the advantage of "elsif".

>
>4.  The formal grammar was a major change from 03, and I have strong
>    reservations against changing it back.  03 had a grammar that was
>    over-specified, and under-permissive.  Every extension required a grammar
>    change; this seems likely to lead to a horrible grammar when all is said
>    and done.
>
>    This has probably left considerable ambiguity in some other places in the
>    draft, but I don't beleive that's a good reason to switch back to the
>    previous grammar.
>

I think Tom was responding to my comment about the disconnect between
what formal grammar we do define, for example "string-list", and
the command syntax section, such as:
----
   Syntax:   header <match-keyword> <header-name-list> <key-list>
----
It is never explicitly stated that <header-name-list> and
<key-list> are in fact "string-list".

This creates ambiguity, for example from draft 5...
----
   In this document, only the "if" control structure is provided.  There
   are three pieces to if: "if", "elsif", and "else".

   Syntax:   if <test> <block>

   Syntax:   elsif <test> <block>

   Syntax:   else <block>
----
In formal grammar section....
----
   block = "{" commands "}"
----
If these are referring to the same "block", the it must be enclosed
by brackets { .... }.  Thus daft 5 examples like:
----
4.4
   Example:  if size :under 1M keep; else discard;

4.7
   Example:  if header ["from"] contains ["[email-masked]"]
             discard;
----
... are both invalid!  I guess the churn in the sieve syntax
has created bugs in the specification, which make it difficult
to determine what is valid sieve and what is not.

Is this why Tom says... "Note that "else if" is illegal in 04."?
It must be written like:

   Example:  if header ["From"] contains ["coyote"] {
                forward "[email-masked]";
             } else {
                if header "Subject" contains "$$$" {
                    forward "[email-masked]";
                } else {
                    forward "[email-masked]";
                }
             }

I guess we are really trying the discourage the use of "else if".

Greg Sereda

Date: Wed, 02 Dec 1998 18:14:50 -0800
From: [email-masked] (Bruce Steinback)
Organization: Surely you jest
To: [email-masked]
Subject: Hi, and meeting at IETF
Sender: [email-masked]

Allow me to introduce myself.  I'm picking up doing Server Side filters
here on the Netscape Messaging Server team (from Jules Cisek -
if anyone remembers him).

I'd be interested in meeting at IETF also.  I do believe that Tuesday
night is the 'social' (M$ is always good for entertainment) so probably
not a good idea

I'm probably going to be there from Monday afternoon thru Wednesday (not
final yet), and would love to meet people in whatever
fashion.

    Cheers,

    Bruce

Date: 1 Dec 1998 17:09:14 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Re: draft-showalter-sieve-05.txt
Sender: [email-masked]

> From: "Barry Leiba" <[email-masked]>
> Date: Mon, 23 Nov 1998 11:51:06 -0500

> Count me in, but I'm leaving on Wednesday evening, so I won't be
> available after 3:00 Wednesday.

How's Tuesday evening?

-- 
Tim Showalter <[email-masked]>

Date: 1 Dec 1998 15:31:00 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Re: Sieve - definition of comments
Sender: [email-masked]

> Date: 30 Nov 1998 16:03:31 -0500
> From: Tim Showalter <[email-masked]>
> 
> > Date: Mon, 23 Nov 1998 12:13:53 +0100
> > From: Wilbert de Graaf <[email-masked]>
> 
> > 1) firts of all, comments cannot have white spaces according to the rule
> > comment    = "#" *VCHAR CRLF
> > [...]
> 
> Good point.
> 
> Should VCHAR be "(%01-0A / %0B-0C / %0E-7F)" or "(WSP / VCHAR)"?

I take that back; to allow for UTF-8 characters, that's got to be
something else.  I know U+FFFF is "bad"; should it be disallowed?  Are
there any other characters that can't be allowed by the grammar?

Tim

-- 
Tim Showalter <[email-masked]>

Date: 1 Dec 1998 14:25:55 -0500
From: Tim Showalter <[email-masked]>
To: [email-masked]
Subject: Re: Sieve - ABNF of block
Sender: [email-masked]

I have no problem with making the following legal in the grammar, taking 
Wilbert's suggestions.  As far as I know, they're just bugs in the
specification.

* blocks containing no commands
* scripts taking no commands

Tim

-- 
Tim Showalter <[email-masked]>

From: "Wilbert de Graaf" <[email-masked]>
To: <[email-masked]>
Subject: Sieve - ABNF of block
Date: Tue, 1 Dec 1998 19:36:52 +0100
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0012_01BE1D61.F1F1EE30
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

I believe a block cannot contain -just- comments or be empty, like this:

... {=20
    # commented for now
    # discard;
}

but this might be the intention. If not, these rules prevent this:

block =3D "{" commands "}"
commands  =3D *([WSP] command [WSP])
command =3D identifier ...

Maybe
commands =3D *[WSP] *([WSP] command [WSP])
although this does not really reprsent commands.

- Wilbert

------=_NextPart_000_0012_01BE1D61.F1F1EE30
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN">
<HTML>
<HEAD>

<META content=3Dtext/html;charset=3Diso-8859-1 =
http-equiv=3DContent-Type>
<META content=3D'"MSHTML 4.72.3110.7"' name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT color=3D#000000 size=3D2>I believe a block cannot contain =
-just- comments=20
or be empty, like this:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>... { </FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; # commented for=20
now</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>&nbsp;&nbsp;&nbsp; # =
discard;</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2>}</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT color=3D#000000 size=3D2>but this might be the intention. If =
not,=20
</FONT><FONT color=3D#000000 size=3D2>these rules prevent =
this:</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT size=3D2>block =3D &quot;{&quot; commands =
&quot;}&quot;</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>commands&nbsp; =
=3D *([WSP]=20
command [WSP])</FONT></DIV>
<DIV><FONT color=3D#000000 size=3D2></FONT><FONT size=3D2>command =3D =
identifier=20
...</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>Maybe</FONT></DIV>
<DIV><FONT size=3D2>commands =3D *[WSP] *([WSP] command =
[WSP])</FONT></DIV>
<DIV><FONT size=3D2></FONT><FONT color=3D#000000 size=3D2>although this =
does not=20
really reprsent commands.</FONT></DIV>
<DIV>&nbsp;</DIV>
<DIV><FONT size=3D2>- Wilbert</FONT></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0012_01BE1D61.F1F1EE30--