headers
Tim Showalter | 7 Aug 1998 23:02
Picon

new sieve draft

I've submitted a new Sieve draft to the internet-drafts repository.
Since by this point they're completely overburdened until just before
the IETF, I'll include it here.

I'll include it as 7bit-encoded, but I'm pretty sure that my mailer will 
helpfully CRLF-terminate all of the lines, and that may not be
desirable.

I'm sure I introduced more features than bugs.

Support and reply have been removed because of previous discussions.
I'll try and redo the vacation draft since that's more important without 
reply.

Tim

--

-- 
Tim Showalter <tjs+ <at> andrew.cmu.edu>
Attachment (sieve.txt): application/octet-stream, 46 KiB
Permalink | Reply | 10 comments |
headers
Tim Showalter | 11 Aug 1998 03:06
Picon

Re: new sieve draft

> Date: 7 Aug 1998 17:02:31 -0400
> From: Tim Showalter <tjs+ <at> andrew.cmu.edu>

> I'm sure I introduced more features than bugs.

I meant that the other way around, actually.

Tim

--

-- 
Tim Showalter <tjs+ <at> andrew.cmu.edu>
Permalink | Reply | 1 comment |
headers
Gregory Sereda | 11 Aug 1998 19:33
Picon

Comments on draft 4

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"?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Randall Gellens | 14 Aug 1998 23:25

Re: new sieve draft

0.2.2 says "only one forward should be allowed per message".  Why?  I
might want to forward a message to multiple accounts, perhaps I have an
account for my pager and one for my PDA.

0.3 discusses what happens if an error occurs.  I think this is a
quality-of-implementation issue.  I have a parser and an interpreter
built to -03, and it parses first, so that if can abort the
interpretation if there are any errors.  But I don't want to impose
that on other implementers.

1.  says "if the MTA ... lacks the power to sort into separate
mailboxes, as is the case under POP3, the MUA must do filtering into
local disk folders."  I'm not sure what this is trying to say (can't
use Sieve with POP3, or when using POP3, sorting into folders can only
be done by MUA), but I feel it is important that Sieve be usable with
POP3.  The fileinto action should be optional.

2.7: I think we should tighten up the syntax for tagged arguments.  At
a minimum, they should only appear after the keyword.  I think we can
go further, and for each tagged argument, specify where it must appear.
I realize you are trying to make the language open-ended enough to
support all sorts of extensions, but I also think it needs to be easy
to parse.

2.11: I think the short-circuit evaluations do not need to be a MUST.
This isn't a language with pointers and variables, so there is no
danger of something like "if ( p != NULL && *p == 'c' )".

4.1: I think reject also needs to be optional to implement.  In some
environments it may not be possible to generate a DSN, or it may be
(Continue reading)

Permalink | Reply | 1 comment |
headers
Bart Schaefer | 14 Aug 1998 23:58

Re: new sieve draft

Section 0.3 notes that "support" and "reply" have been removed, but Section 7
still says

   Any extensions to this language MUST define a string that uniquely
   identifies that extension.  If a new version of an extension changes
   the functionality of a previously defined extension, it MUST use a
   different name.  The purpose of such a string is for the "support"
   test, which mandates that script requires the use of that extension.
Permalink | Reply | 0 comments |
headers
Ned Freed | 15 Aug 1998 00:30

Re: new sieve draft

> 0.2.2 says "only one forward should be allowed per message".  Why?  I
> might want to forward a message to multiple accounts, perhaps I have an
> account for my pager and one for my PDA.

Two issues here: Ease of implementation (some environments may find it
difficult to provide for multiple forwards) and potential risks (could be
misused as a mailing list mechanism of sorts).

On the other hand, I agree that multiple forwards can be useful.

> 0.3 discusses what happens if an error occurs.  I think this is a
> quality-of-implementation issue.  I have a parser and an interpreter
> built to -03, and it parses first, so that if can abort the
> interpretation if there are any errors.  But I don't want to impose
> that on other implementers.

I've done the same thing and agree with your reasoning.

> 1.  says "if the MTA ... lacks the power to sort into separate
> mailboxes, as is the case under POP3, the MUA must do filtering into
> local disk folders."  I'm not sure what this is trying to say (can't
> use Sieve with POP3, or when using POP3, sorting into folders can only
> be done by MUA), but I feel it is important that Sieve be usable with
> POP3.  The fileinto action should be optional.

Agreed.

> 2.7: I think we should tighten up the syntax for tagged arguments.  At
> a minimum, they should only appear after the keyword.  I think we can
> go further, and for each tagged argument, specify where it must appear.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Gregory Sereda | 17 Aug 1998 22:03
Picon

Re: new sieve draft

At 02:25 PM 8/14/98 -0700, Randall Gellens wrote:
>
>2.11: I think the short-circuit evaluations do not need to be a MUST.
>This isn't a language with pointers and variables, so there is no
>danger of something like "if ( p != NULL && *p == 'c' )".
>
This depends on how we handle extensions.  The MUST was correct for the
-03 draft when we had the "support" test.  You could write something
like:
	
	if allof ( support "newtest", newtest "arg" )

However, I agree that with draft -04, we should downgrade MUST to SHOULD
until we figure out how extensions will be supported.

The difficult part of extensions will be how a parser will deal with
"new control structures, actions, and tests" that have unknown syntax.
Perhaps the C language concept of "#ifdef" would be useful to bracket
a section of code that contains an extension.

Greg Sereda
Permalink | Reply | 501 comments |
headers
Tony Hansen | 17 Aug 1998 23:47
Picon
Favicon

Re: new sieve draft

Gregory Sereda wrote:

> At 02:25 PM 8/14/98 -0700, Randall Gellens wrote:
> >
> >2.11: I think the short-circuit evaluations do not need to be a MUST.
> >This isn't a language with pointers and variables, so there is no
> >danger of something like "if ( p != NULL && *p == 'c' )".
> >
> This depends on how we handle extensions.  The MUST was correct for the
> -03 draft when we had the "support" test.  You could write something
> like:
>         if allof ( support "newtest", newtest "arg" )
> However, I agree that with draft -04, we should downgrade MUST to SHOULD
> until we figure out how extensions will be supported.

Does leaving it at MUST cause problems for implementers? I think it would be
more difficult to make it a MUST later if it doesn't start that way.

> The difficult part of extensions will be how a parser will deal with
> "new control structures, actions, and tests" that have unknown syntax.
> Perhaps the C language concept of "#ifdef" would be useful to bracket
> a section of code that contains an extension.

Most languages that allow extensions either do so within the syntax of the
language, or via a metalanguage defined outside of the syntax of the
language.
An example of the former is doing operator overloading in C++ and Ada. No
language changes are needed to add new actions. However, the extensions are
limited.
Examples of the latter are the C preprocessor language and various C/SQL
(Continue reading)

Permalink | Reply | 501 comments |
headers
Barry Leiba | 19 Aug 1998 17:45
Picon
Favicon

Required comparators

I would like to lobby strongly for requiring the i;ascii-casemap
comparator in any base Sieve implementation.  We've implemented
the Sieve -03 draft here, and we're using it, and we find that it's
very hard to write a reasonable script without ascii-casemap.
You wind up with too many lines that look like this:

if header ("from", "to", "cc")
    contains ("ietf-mta-filters", 
              "IETF-MTA-FILTERS", 
              "IETF-MTA-Filters", 
              "IETF-MTA-filters") { fileinto "Lists/MTA Filters";

...and then you wind up patching in yet another one when the filter
fails because someone did "IETF-mta-filters" and that's not in your
list.  As long as what appears in addresses in mail headers is case-
insensitive US ASCII, we have to have a standard, *required* comparator
that handles case-insensitive US ASCII.

Any objections to adding i;ascii-casemap, in addition to i;octet, as
a *required* comparator?

Barry Leiba, Multimedia Messaging  (leiba <at> watson.ibm.com)
http://www.research.ibm.com/people/l/leiba
Permalink | Reply | 5 comments |
headers
Tony Hansen | 19 Aug 1998 19:54
Picon
Favicon

Re: Required comparators

Barry Leiba wrote:

> Any objections to adding i;ascii-casemap, in addition to i;octet, as
> a *required* comparator?

I think it's a good idea.

    Tony Hansen
    tony <at> att.com
Permalink | Reply | 0 comments |

Gmane