Re: sieve bugs

[Rob Earhart <[e-mail]>]

On 26 Dec 1998, Larry Greenfield wrote:
> Rob Earhart suggested the following fix for the grammar:
>    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.

  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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id UAA12380 for ietf-mta-filters-bks; Sat, 26 Dec 1998 20:37:13 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id UAA12373 for <[e-mail]>; Sat, 26 Dec 1998 20:37:12 -0800 (PST)
Received: from thunderbolt.andrew.cmu.edu (THUNDERBOLT.ANDREW.CMU.EDU [128.2.109.109]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id XAA02383 for <[e-mail]>; Sat, 26 Dec 1998 23:44:07 -0500 (EST)
Date: Sat, 26 Dec 1998 23:44:08 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: sieve bugs
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

On 26 Dec 1998, Larry Greenfield wrote:
> Rob Earhart suggested the following fix for the grammar:
>    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.

  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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA01370 for ietf-mta-filters-bks; Sat, 26 Dec 1998 18:52:09 -0800 (PST)
Received: from rutgers.rutgers.edu (RUTGERS.EDU [165.230.4.76]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA01365 for <[e-mail]>; Sat, 26 Dec 1998 18:52:08 -0800 (PST)
Received: from catch22.andrew.cmu.edu (coretop-asy-6.rutgers.edu [128.6.171.64]) by rutgers.rutgers.edu (8.8.8/8.8.8) with SMTP id VAA05607; Sat, 26 Dec 1998 21:59:01 -0500 (EST)
Date: 26 Dec 1998 21:55:29 -0500
Message-ID: <[e-mail]>
From: Larry Greenfield <[e-mail]>
X-Mailer: BatIMail version 3.1
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve bugs
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA19052 for ietf-mta-filters-bks; Wed, 16 Dec 1998 14:21:51 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA19047 for <[e-mail]>; Wed, 16 Dec 1998 14:21:48 -0800 (PST)
Received: from SPOOKY.ANDREW.CMU.EDU (SPOOKY.ANDREW.CMU.EDU [128.2.35.162]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA09018 for <[e-mail]>; Wed, 16 Dec 1998 17:28:01 -0500 (EST)
Date: Wed, 16 Dec 1998 17:24:28 -0500 (EST)
From: Rob Earhart <[e-mail]>
To: [e-mail]
Subject: Re: sieve bugs
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

  (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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id NAA00110 for ietf-mta-filters-bks; Wed, 9 Dec 1998 13:38:45 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id NAA00105 for <[e-mail]>; Wed, 9 Dec 1998 13:38:39 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-110.mtg.ietf.org [198.67.177.110]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id RAA04659; Wed, 9 Dec 1998 17:48:06 -0500
Date: 9 Dec 1998 16:43:41 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: radar [Hello to all my fans in domestic surveillance] smuggle Serbian Vince Foster nuclear Panama
To: [e-mail]
Subject: require inside an unused block
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26734 for ietf-mta-filters-bks; Wed, 9 Dec 1998 06:38:26 -0800 (PST)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26730 for <[e-mail]>; Wed, 9 Dec 1998 06:38:26 -0800 (PST)
Received: from [129.46.55.120] (ra5399a-port28.qualcomm.com [129.46.55.128]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id GAA04846; Wed, 9 Dec 1998 06:43:11 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103603b29357bb4415@[129.46.55.120]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 8 Dec 1998 17:25:33 -0500
To: Tony Hansen <[e-mail]>, Tim Showalter <[e-mail]>
From: Randall Gellens <[e-mail]>
Subject: Re: Sieve Meeting Notes
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk

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.


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA26673 for ietf-mta-filters-bks; Wed, 9 Dec 1998 06:37:55 -0800 (PST)
Received: from illyana.qualcomm.com (illyana.qualcomm.com [129.46.2.83]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA26666 for <[e-mail]>; Wed, 9 Dec 1998 06:37:54 -0800 (PST)
Received: from [129.46.55.120] (ra5399a-port28.qualcomm.com [129.46.55.128]) by illyana.qualcomm.com (8.8.5/1.4/8.7.2/1.14) with ESMTP id GAA04823; Wed, 9 Dec 1998 06:42:51 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Message-Id: <v04103602b2935698ffa8@[129.46.55.120]>
In-Reply-To:  <[e-mail]>
X-Mailer: QUALCOMM Eudora Pro v4.1 for Macintosh
Date: Tue, 8 Dec 1998 17:23:29 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Randall Gellens <[e-mail]>
Subject: Re: Sieve Meeting Notes
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id GAA22915 for ietf-mta-filters-bks; Tue, 8 Dec 1998 06:56:22 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id GAA22909 for <[e-mail]>; Tue, 8 Dec 1998 06:56:21 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-230.mtg.ietf.org [198.67.177.230]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id LAA04400; Tue, 8 Dec 1998 11:06:00 -0500
Date: 8 Dec 1998 10:01:39 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: smuggle Legion of Doom Saddam Hussein explosion Khaddafi Serbian COSCO
To: Tony Hansen <[e-mail]>
Cc: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: sieve & short-circuit evaluation
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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

> 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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA17473 for ietf-mta-filters-bks; Mon, 7 Dec 1998 22:58:28 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA17469 for <[e-mail]>; Mon, 7 Dec 1998 22:58:27 -0800 (PST)
Received: from kcig1.att.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender att.com!tony (att.com!tony); Tue Dec  8 01:03 CST 1998
Received: from dns.maillennium.att.com (labmail.maillennium.att.com [135.25.114.19]) by kcig1.att.att.com (AT&T/IPNS/GW-1.0) with ESMTP id BAA09628 for <[e-mail]>; Tue, 8 Dec 1998 01:03:50 -0600 (CST)
Received: from att.com (bual.research.att.com[135.207.24.19](may be forged)) by maillennium.att.com (labmail) with SMTP id <19981208070353un120386n3e>; Tue, 8 Dec 1998 07:03:54 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Dec 1998 01:52:14 -0500
From: Tony Hansen <[e-mail]>
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: Sieve Meeting Notes
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
    [e-mail]




Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA17374 for ietf-mta-filters-bks; Mon, 7 Dec 1998 22:48:37 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id WAA17369 for <[e-mail]>; Mon, 7 Dec 1998 22:48:35 -0800 (PST)
Received: from kcig1.att.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender att.com!tony (att.com!tony); Tue Dec  8 00:53 CST 1998
Received: from dns.maillennium.att.com ([135.25.114.19]) by kcig1.att.att.com (AT&T/IPNS/GW-1.0) with ESMTP id AAA08221 for <[e-mail]>; Tue, 8 Dec 1998 00:53:49 -0600 (CST)
Received: from att.com (bual.research.att.com[135.207.24.19](may be forged)) by maillennium.att.com (labmail) with SMTP id <19981208065352un120386n1e>; Tue, 8 Dec 1998 06:53:52 +0000
Message-ID: <[e-mail]>
Date: Tue, 08 Dec 1998 01:42:13 -0500
From: Tony Hansen <[e-mail]>
X-Mailer: Mozilla 4.07 [en] (Win98; I)
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: sieve & short-circuit evaluation
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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
    [e-mail]



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA25594 for ietf-mta-filters-bks; Mon, 7 Dec 1998 18:24:51 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA25589 for <[e-mail]>; Mon, 7 Dec 1998 18:24:49 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-219.mtg.ietf.org [198.67.177.219]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id WAA04284; Mon, 7 Dec 1998 22:34:23 -0500
Date: 7 Dec 1998 21:30:10 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: Bosnia Qaddafi Peking radar BATF plutonium SDI
To: [e-mail]
Subject: Sieve Meeting Notes
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA25080 for ietf-mta-filters-bks; Mon, 7 Dec 1998 17:38:03 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA25076 for <[e-mail]>; Mon, 7 Dec 1998 17:38:01 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-219.mtg.ietf.org [198.67.177.219]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id VAA04276; Mon, 7 Dec 1998 21:47:35 -0500
Date: 7 Dec 1998 20:43:23 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: Delta Force clones NSA Ruby Ridge Saddam Hussein strategic $400 million in gold bullion
To: [e-mail]
Subject: match-keyword in address match primitive
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA24309 for ietf-mta-filters-bks; Mon, 7 Dec 1998 16:31:34 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA24305 for <[e-mail]>; Mon, 7 Dec 1998 16:31:32 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-252.mtg.ietf.org [198.67.177.252]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id UAA04256; Mon, 7 Dec 1998 20:41:08 -0500
Date: 7 Dec 1998 19:37:00 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: AK-47 Treasury Semtex radar DES Croatian SDI
To: [e-mail]
Subject: sieve & short-circuit evaluation
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id RAA00445 for ietf-mta-filters-bks; Sun, 6 Dec 1998 17:54:22 -0800 (PST)
Received: from darius.cyrusoft.com (darius.cyrusoft.com [206.31.218.194]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id RAA00441 for <[e-mail]>; Sun, 6 Dec 1998 17:54:20 -0800 (PST)
Received: from ietf-177-91.mtg.ietf.org (ietf-177-91.mtg.ietf.org [198.67.177.91]) by darius.cyrusoft.com (8.8.5/8.8.5) with ESMTP id UAA26581; Sun, 6 Dec 1998 20:59:34 -0500 (EST)
Date: Sun, 06 Dec 1998 21:02:55 -0500
From: Matthew Wall <[e-mail]>
To: [e-mail]
cc: Tim Showalter <[e-mail]>
Subject: Meeting time
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Originator-Info: login-id=wall; server=imap.cyrusoft.com
X-Mailer: Mulberry (MacOS) [1.4.0, s/n S-171717]
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Sender: [e-mail]
Precedence: bulk

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 [e-mail] 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 <[e-mail]>
> 
> Alexey Melnikov
> 
> 
> 
> 



 =====================================================================
   Matthew Wall * mailto:[e-mail] * 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
 =====================================================================



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id QAA29841 for ietf-mta-filters-bks; Sun, 6 Dec 1998 16:48:06 -0800 (PST)
Received: from main ([194.87.43.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id QAA29836 for <[e-mail]>; Sun, 6 Dec 1998 16:48:04 -0800 (PST)
From: [e-mail]
Received: FROM demo.ru ([198.67.176.97]) BY main.demo.ru (Baikonur Mail Server) WITH ESMTP; 07 Dec 1998 03:54:24 +0300
Message-ID: <[e-mail]>
Date: Sun, 06 Dec 1998 16:40:08 -0800
X-Mailer: Mozilla 4.5 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Tim Showalter <[e-mail]>
CC: [e-mail]
Subject: Re: draft-showalter-sieve-05.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>

Alexey Melnikov






Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA15459 for ietf-mta-filters-bks; Fri, 4 Dec 1998 12:34:23 -0800 (PST)
Received: from att.com (cagw1.att.com [192.128.52.89]) by mail.proper.com (8.8.8/8.8.5) with SMTP id MAA15455 for <[e-mail]>; Fri, 4 Dec 1998 12:34:21 -0800 (PST)
Received: from caig1.fw.att.com by cagw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender maillennium.att.com!gsereda (maillennium.att.com!gsereda); Fri Dec  4 14:13 EST 1998
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by caig1.fw.att.com (AT&T/IPNS/GW-1.0) with ESMTP id OAA01598 for <[e-mail]>; Fri, 4 Dec 1998 14:23:01 -0500 (EST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19981204192303un1203864ee>; Fri, 4 Dec 1998 19:23:03 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 04 Dec 1998 14:27:18 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Other bugs in draft 5 specification
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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
   ["[e-mail]", "[e-mail]"]' 

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

4.1. Action reject

   Example:  if header "from" contains "[e-mail]" {
                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 ["[e-mail]"]
             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


Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id WAA27296 for ietf-mta-filters-bks; Thu, 3 Dec 1998 22:04:16 -0800 (PST)
Received: from smtp2.andrew.cmu.edu (SMTP2.ANDREW.CMU.EDU [128.2.10.82]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id WAA27292 for <[e-mail]>; Thu, 3 Dec 1998 22:04:14 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp2.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id BAA16620; Fri, 4 Dec 1998 01:09:07 -0500 (EST)
Date: 4 Dec 1998 01:09:18 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: SEAL Team 6 Ft. Bragg Noriega CIA KGB Mena Treasury
To: [e-mail]
In-reply-to: <000b01be1701$767ca940$[e-mail]>
Subject: Re: draft-showalter-sieve-05.txt
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA12555 for ietf-mta-filters-bks; Thu, 3 Dec 1998 14:49:26 -0800 (PST)
Received: from att.com (kcgw1.att.com [192.128.133.151]) by mail.proper.com (8.8.8/8.8.5) with SMTP id OAA12551 for <[e-mail]>; Thu, 3 Dec 1998 14:49:24 -0800 (PST)
Received: from kcig1.att.att.com by kcgw1.att.com (AT&T/IPNS/UPAS-1.0) for imc.org!ietf-mta-filters sender maillennium.att.com!gsereda (maillennium.att.com!gsereda); Thu Dec  3 16:23 CST 1998
Received: from dns.maillennium.att.com (dns.maillennium.att.com [135.25.114.99]) by kcig1.att.att.com (AT&T/IPNS/GW-1.0) with ESMTP id QAA29102 for <[e-mail]>; Thu, 3 Dec 1998 16:22:36 -0600 (CST)
Received: from benji (benji.bl-els.att.com[135.25.111.225](may be forged)) by maillennium.att.com (labmail) with SMTP id <19981203222232un120386gie>; Thu, 3 Dec 1998 22:22:32 +0000
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Thu, 03 Dec 1998 17:26:32 -0500
To: Tim Showalter <[e-mail]>, [e-mail]
From: Gregory Sereda <[e-mail]>
Subject: Re: List of expected changes for sieve 05 draft
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk

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" ["[e-mail]", "[e-mail]"]
            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
   [e-mail];  message B, to [e-mail]; any other
   message is forwarded to [e-mail].

   Example:  if header ["From"] contains ["coyote"] {
                forward "[e-mail]";
             } else if header "Subject" contains "$$$" {
                forward "[e-mail]";
             } else {
                forward "[e-mail]";
             }
----
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 ["[e-mail]"]
             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 "[e-mail]";
             } else {
                if header "Subject" contains "$$$" {
                    forward "[e-mail]";
                } else {
                    forward "[e-mail]";
                }
             }

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

Greg Sereda



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA02186 for ietf-mta-filters-bks; Wed, 2 Dec 1998 18:07:20 -0800 (PST)
Received: from netscape.com (h-205-217-237-46.netscape.com [205.217.237.46]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA02182 for <[e-mail]>; Wed, 2 Dec 1998 18:07:17 -0800 (PST)
Received: from fusion.mcom.com (fusion.mcom.com [205.217.255.82]) by netscape.com (8.8.5/8.8.5) with ESMTP id SAA24365 for <[e-mail]>; Wed, 2 Dec 1998 18:11:51 -0800 (PST)
Received: from netscape.com ([208.12.60.96]) by fusion.mcom.com (Netscape Messaging Server 3.62)  with ESMTP id 437 for <[e-mail]>; Wed, 2 Dec 1998 18:11:47 -0800
Message-ID: <[e-mail]>
Date: Wed, 02 Dec 1998 18:14:50 -0800
From: [e-mail] (Bruce Steinback)
Organization: Surely you jest
X-Mailer: Mozilla 4.5 [en]C-NSCP  (WinNT; U)
X-Accept-Language: en
MIME-Version: 1.0
To: [e-mail]
Subject: Hi, and meeting at IETF
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk

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



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id OAA27923 for ietf-mta-filters-bks; Tue, 1 Dec 1998 14:04:19 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id OAA27919 for <[e-mail]>; Tue, 1 Dec 1998 14:04:16 -0800 (PST)
Received: from wopr.andrew.cmu.edu (WOPR.ANDREW.CMU.EDU [128.2.36.7]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id RAA24352; Tue, 1 Dec 1998 17:09:13 -0500 (EST)
Date: 1 Dec 1998 17:09:14 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Spook: Peking AK-47 Honduras North Korea Croatian Mena BATF
To: [e-mail]
In-reply-to: <000b01be1701$767ca940$[e-mail]>
Subject: Re: draft-showalter-sieve-05.txt
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> From: "Barry Leiba" <[e-mail]>
> 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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id MAA25352 for ietf-mta-filters-bks; Tue, 1 Dec 1998 12:23:16 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id MAA25348 for <[e-mail]>; Tue, 1 Dec 1998 12:23:13 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (HITCHHIKER.ADSL.NET.CMU.EDU [128.2.108.65]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id PAA14495; Tue, 1 Dec 1998 15:28:06 -0500 (EST)
Date: 1 Dec 1998 15:31:00 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: AK-47 Qaddafi Albania clones [Hello to all my fans in domestic surveillance] radar quiche
To: [e-mail]
In-reply-to: <[e-mail]>
Subject: Re: Sieve - definition of comments
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

> Date: 30 Nov 1998 16:03:31 -0500
> From: Tim Showalter <[e-mail]>
> 
> > Date: Mon, 23 Nov 1998 12:13:53 +0100
> > From: Wilbert de Graaf <[e-mail]>
> 
> > 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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id LAA24571 for ietf-mta-filters-bks; Tue, 1 Dec 1998 11:18:13 -0800 (PST)
Received: from smtp1.andrew.cmu.edu (SMTP1.ANDREW.CMU.EDU [128.2.10.81]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id LAA24567 for <[e-mail]>; Tue, 1 Dec 1998 11:18:07 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (HITCHHIKER.ADSL.NET.CMU.EDU [128.2.108.65]) by smtp1.andrew.cmu.edu (8.8.5/8.8.2) with SMTP id OAA06931; Tue, 1 Dec 1998 14:22:59 -0500 (EST)
Date: 1 Dec 1998 14:25:55 -0500
Message-ID: <[e-mail]>
From: Tim Showalter <[e-mail]>
X-Mailer: BatIMail version 3.1
X-Spook: SEAL Team 6 arrangements fissionable cryptographic Craig Livingstone Waco, Texas clones
To: [e-mail]
In-reply-to: <002001be1d59$c38300f0$[e-mail]>
Subject: Re: Sieve - ABNF of block
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset=US-ASCII
Sender: [e-mail]
Precedence: bulk

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 <[e-mail]>



Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id KAA23782 for ietf-mta-filters-bks; Tue, 1 Dec 1998 10:35:06 -0800 (PST)
Received: from forward.hetnet.nl (smtp1.hetnet.nl [145.7.225.1]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id KAA23778 for <[e-mail]>; Tue, 1 Dec 1998 10:35:02 -0800 (PST)
Received: from hetnet.nl ([194.151.104.129]) by forward.hetnet.nl  with Microsoft SMTPSVC(5.5.1875.185.18); Tue, 1 Dec 1998 19:33:32 +0100
Received: from bit ([145.53.2.21]) by hetnet.nl  with Microsoft SMTPSVC(5.5.1877.117.11); Tue, 1 Dec 1998 19:38:16 +0100
Message-ID: <002001be1d59$c38300f0$[e-mail]>
From: "Wilbert de Graaf" <[e-mail]>
To: <[e-mail]>
Subject: Sieve - ABNF of block
Date: Tue, 1 Dec 1998 19:36:52 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01BE1D61.F1F1EE30"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 4.72.3110.5
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Sender: [e-mail]
Precedence: bulk

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