Subject: Re: line terminator

From: Thomas Down <[email-masked]>
Date: Wed, 21 May 1997 09:07:55 +0100 (BST)

A while ago, Tim Showalter wrote:
> You have your choice of two reasonable choices:
> 
> LF|CRLF|CR: This works with any OS that purports to save files in ASCII
> text.
> 
> CRLF: This is what a standard does normally.
> 

Noooo... for a lot of users, they will initially be creating their
scripts as local text files, either on the machine that does the filtering
or on another machine then FTPing... Once it becomes routine to use ACAP
to store scripts, then things become a little better, but until that day
I'm afraid to say LF|CRLF|CR wins for me. Yes, it takes a little extra
code to cope with this, but on many systems coping with CRLF is little
easier that coping with all three anyway. ClarionSiever _will_ accept
at least LF-terminated scripts even if the standard doesn't actually say
so, 'cos that's what users are likely to be feeding it until I start using
ACAP.

[Personally, I find CRLF an abomination, but it seems to be a fact of
life so...]

Thomas
-- 
Upon these holy ancient trees,
Now cast your lovely silver light;
Uncloud your face that we may see
Unveiled its shining in the night                  -- The Forest House

---

From: "Matthew Wall" <[email-masked]>
Date: Thu, 29 May 1997 16:52:14 -0500

--On Mon, May 26, 1997 10:11 AM -0600 "Steve Hole" <[email-masked]> wrote: 

> 
> On Tue, 20 May 1997 23:15:00 -0400 (EDT)  Tim Showalter 
> <[email-masked]> wrote:
> 
> I would make the text canonical and always use CRLF.   Most 
> mail applications already have canonical->local line translators in them 
> to support saving RFC822 text to local files.   In the worst case, a Mac 
> or UNIX editor will just show the extra line end character.   The other 
> way around, you end up with lines all running together.  

I agree with Steve.

- mw

> 
> ---  
> Steve Hole			VP,  Research and Development  
> The Esys Corporation		EMail: [email-masked]
> 900 10040 - 104 St.		Phone: 403-424-4922  
> Edmonton, AB, Canada		Fax:   403-424-4925  
> T5J 0Z6  
> 
> 
> 

-----------------------------------------------------------------------
Matthew Wall                       mailto:[email-masked]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: +1 412 605 0499             Fax: +1 412 605 0705
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
          "Internet Mail from the Ground Up" (tm)
-----------------------------------------------------------------------

Date: Thu, 29 May 1997 16:52:14 -0500
From: "Matthew Wall" <[email-masked]>
To: "MTA Filters" <[email-masked]>
cc: "Steve Hole" <[email-masked]>, "Tim Showalter" <[email-masked]>
Subject: Re: line terminator 
Sender: [email-masked]

--On Mon, May 26, 1997 10:11 AM -0600 "Steve Hole" <[email-masked]> wrote: 

> 
> On Tue, 20 May 1997 23:15:00 -0400 (EDT)  Tim Showalter 
> <[email-masked]> wrote:
> 
> I would make the text canonical and always use CRLF.   Most 
> mail applications already have canonical->local line translators in them 
> to support saving RFC822 text to local files.   In the worst case, a Mac 
> or UNIX editor will just show the extra line end character.   The other 
> way around, you end up with lines all running together.  

I agree with Steve.

- mw

> 
> ---  
> Steve Hole			VP,  Research and Development  
> The Esys Corporation		EMail: [email-masked]
> 900 10040 - 104 St.		Phone: 403-424-4922  
> Edmonton, AB, Canada		Fax:   403-424-4925  
> T5J 0Z6  
> 
> 
> 

-----------------------------------------------------------------------
Matthew Wall                       mailto:[email-masked]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: +1 412 605 0499             Fax: +1 412 605 0705
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
          "Internet Mail from the Ground Up" (tm)
-----------------------------------------------------------------------

Date: Tue, 27 May 1997 15:34:12 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Chris Newman <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: Sieve Clarifications
Sender: [email-masked]

On Wed, 30 Apr 1997, Chris Newman wrote:
> On Wed, 30 Apr 1997, Tim Showalter wrote:
> > On Wed, 30 Apr 1997, Chris Newman wrote:
> > 
> > > Section 2.5.2.
> > > 
> > > Also a useful section.  Need to add comments about how to RFC 822 quoting
> > > of addresses is dealt with.  Remember that junk like:
> > >    <"foo"  .  "bar"@baz.biff>
> > > is a legal RFC 822 address, but for comparison one probably wants to treat
> > > it as <[email-masked]>
> > 
> > I'm not sure about this.  While a comparison in addresses should make them
> > the same, a comparision of From headers might treat them differently.  In
> > the document as it stands, there are no direct comparisons of addresses.  At
> > least, I didn't intend any.
> 
> Sorry, I was looking at notes on my document that I wrote as I
> read it.  Comparison isn't so big a deal actually. More important is the 
> addresses allowed in commands like "forward".  The problem is that 822
> syntax is different from 821 syntax.  It also includes a lot of 
> syntactical junk that's completely unnecessary.  If we want to make this
> easy for implementors, I think we should require addresses in some
> canonical form.
> 
> Choice 1:
> 
> Addresses must meet both 821 and 822 quoting rules.  Specifically, it's
> either <local-part@domain> or <"local-part"@domain>.  Quotes around
> name-components, whitespace and embedded comments should be disallowed.
> 
> Choice 2:
> 
> Address must be in unquoted form.  This means you have just
> <local-part@domain>.  To convert to quoted form, one looks for the
> rightmost "@" sign and has to quote the local-part if it contains any
> specials other than "." (e.g. "@" is particularly nasty in local part).

Sorry for the very delayed response on this; I prefer choice 2 only because
it seems cleaner to me to users.  (Wording for the affected section would be
appreciated.)

Tim

-- 
                                           Tim Showalter [email-masked]

Date: Tue, 27 May 1997 00:49:45 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: Jack De Winter <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: vacation
Sender: [email-masked]

On Thu, 22 May 1997, Jack De Winter wrote:

> At 07:02 PM 5/22/97 -0400, Tim Showalter wrote:
> >Should the base spec provide a way to do vacation-style forwarding?
> >What should this mechanism be?
> 
> I thought that sieve kind of made a vacation system surpufluous (sp?)?
> Are are you talking about the mechanics behind vacation?  If so,
> could you spell out what you think those mechanics entail so we can
> get a clear picture?

I'm looking for a mechanism to
* specify how frequently a reply comes out
* provide support for storing ids at the filtering agent level

You can't do this in the draft as written, and the reasons you can't do it
are pretty good and have already been discussed.  You can approximate it,
but this has two problems:
* what I just stated is completely impossible, so you have vacation spam
* people won't get it right and you'll have lots of replies to mailing lists

I'd like to avoid the mailing list problem. (What addresses does this guy
have?  I have roughly three addresses that people send mail to, and would
like to accomidate all of them.  That's what I get for using legacy mailers,
I guess.)

A first pass at a comamnd would be
	vacation [-days NN] [-addresses <STRINGLIST>] <REPLY-TEXT>

This is the first command that would have optional arguments.  Maybe it's
appropriate to squeeze them in the draft now so that they'll be consistant;
people will add them.

REPLY-TEXT is the text of the vaction message, as a string (probably
multi-line); -addresses specifies a list of addresses to treat as "mine",
which must be in the to:/cc: lines to generate a reply; -days NN gives a
number to specify the "You'll get this message only every NN days", probably
14, the way the UNIX vacation program does.

I think the above paragraph makes sense, but it probably only works if you
are thinking what I am.  Please gripe at me if it's not clear.

-- 
                                           Tim Showalter [email-masked]

Date: Tue, 27 May 1997 00:38:01 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: Re: line terminator 
Sender: [email-masked]

I believe concensus is for CRLF and have put that in the draft.

-- 
                                           Tim Showalter [email-masked]

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Ned Freed <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: vacation 
Date: Mon, 26 May 1997 10:29:45 -0600 (MDT)
Sender: [email-masked]

On Thu, 22 May 1997 16:50:39 -0700 (PDT)  Ned Freed 
<[email-masked]> wrote:

> > Should the base spec provide a way to do vacation-style forwarding?
> > What should this mechanism be?
> 
> It can be there but it has to be optional, since vacation forwarding depends on
> a database of addresses-already-sent-to, which implies significant per-user
> storage, storage some implementations may not want to allow for. Management of
> this database may be a bit more than we need in the base document, too...

I agree with Ned here.   It is an extension that we should probably work 
on right away though because it is such a highly sought after function.   
Doing that would be a nice way to test out how well the extension 
mechanisms specified in the base document work.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: mutli-line strings (again) 
Date: Mon, 26 May 1997 10:27:10 -0600 (MDT)
Sender: [email-masked]

On Tue, 20 May 1997 23:13:14 -0400 (EDT)  Tim Showalter 
<[email-masked]> wrote:

> And Chris' modification of what's in the draft:
> | text:
> | This is a multi-line string.
> | .. This line begins with a single dot.
> | .

I'll have to vote for this one.   None of them really impress me, but this 
is the most "script like".   One can write a simple interface that 
displays this without having to be too clever.

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: MTA Filters <[email-masked]>
Subject: Re: line terminator 
Date: Mon, 26 May 1997 10:11:40 -0600 (MDT)
Sender: [email-masked]

> CRLF: This is what a standard does normally.

I would make the text canonical and always use CRLF.   Most 
mail applications already have canonical->local line translators in them 
to support saving RFC822 text to local files.   In the worst case, a Mac 
or UNIX editor will just show the extra line end character.   The other 
way around, you end up with lines all running together.    

---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

Date: Mon, 26 May 1997 15:25:22 +0100 (BST)
From: Thomas Down <[email-masked]>
Subject: Re: line terminator
To: Chris Newman <[email-masked]>
Cc: MTA Filters <[email-masked]>, Tim Showalter <[email-masked]>
Sender: [email-masked]

A while ago, Chris Newman wrote:
> 
> Let's not repeat the mistakes of the past.  If there's only one format,
> there's only one way to do a parser which seems to work, and it will work
> with everything.  If there's multiple formats, there's multiple ways to do
> a parser which seems to work, and so it won't work with everything.
> 

This runs into _big_ problems for users who want to edit their sieves
by simply dropping them into a text editor on the machine the sieve will
run on perhaps their UNIX box, or, as in my case, my Risc PC. I admit this
objection may not be valid for users who are storing their sieves with ACAP
or something, but these will be in a minority to start with. It is not
viable to rely on people being able to edit files with your chosen line
terminator easily on a given system.

Whatever the decision, I _will_ accept LF as a line terminator in my
implementation, even if I immediately deprecate this... It will be 
sufficiently useful to me and my alpha test group that it would be 
stupid not to accept this. 

If we specify that the line terminator is CR|CRLF|LF (any of these
acceptable) then there will NOT be a compatibility problem. _All_
compliant implementations MUST accept all three.

Regarding the PostScript case, I doubt we'll see binary inlined into
sieves. The only place it is meaningful is in an autoreply, and it 
probably ought to be BASE64-encoded there anyway. To be quite honest,
I hope I don't live to see the day when people add binary attachments
to autoreply messages anyway...

Thomas
-- 
Interalia design - purveyors of fine mailers since 1998 (maybe)

Date: Fri, 23 May 1997 16:52:49 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: line terminator
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

> CRLF: This is what a standard does normally.

I find LF|CRLF|CR completely unacceptable.

A format needs to have a *single canonical* form.  I don't care if you map
that canonical form to your local system newline conventions as long as it
is crystal clear that it has to be mapped back to canonical form before
sending to another system.

Case study 1: Postscript
On different systems postscript ends up with different newline
conventions.  If you map the newline conventions it can break the
postscript document since there can be embedded binary.  So postscript
files on some systems don't work on other systems.

Case study 2: TIFF
The TIFF file format allows either big-endian or little-endian encoding
(it's very clear in the spec).  But many implementations only support one
of the two encodings, so many implementations now have options to generate
one or the other in order to interoperate.  Ever seen a "Mac Tiff" or "PC
Tiff" checkbox?  I have.

Let's not repeat the mistakes of the past.  If there's only one format,
there's only one way to do a parser which seems to work, and it will work
with everything.  If there's multiple formats, there's multiple ways to do
a parser which seems to work, and so it won't work with everything.

From: "Steve Silverberg (Exchange)" <[email-masked]>
To: "'Jack De Winter'" <[email-masked]>, Tim Showalter <[email-masked]>, MTA Filters <[email-masked]>
Subject: RE: vacation
Date: Thu, 22 May 1997 17:21:43 -0700
Sender: [email-masked]

I think the point that Ned made was that to do Out of Office processing
you expect the mail system to keep a database of recipients who have
received your oof message. You could certainly implement out of office
using sieve but that would probably require extensions to maintain your
database. 

> -----Original Message-----
> From:	Jack De Winter [SMTP:[email-masked]]
> Sent:	Thursday, May 22, 1997 5:14 PM
> To:	Tim Showalter; MTA Filters
> Subject:	Re: vacation
> 
> At 07:02 PM 5/22/97 -0400, Tim Showalter wrote:
> >Should the base spec provide a way to do vacation-style forwarding?
> >What should this mechanism be?
> 
> I thought that sieve kind of made a vacation system surpufluous (sp?)?
> Are are you talking about the mechanics behind vacation?  If so,
> could you spell out what you think those mechanics entail so we can
> get a clear picture?
> 
> regards,
> Jack
> -------------------------------------------------
> Jack De Winter - Wildbear Consulting, Inc.
> (519) 884-4498		http://www.wildbear.on.ca/
> 
> Author of SLMail for 95 & NT (http://www.seattlelab.com/)

Date: Thu, 22 May 1997 20:14:17 -0400
To: Tim Showalter <[email-masked]>, MTA Filters <[email-masked]>
From: "Jack De Winter" <[email-masked]>
Subject: Re: vacation
Sender: [email-masked]

At 07:02 PM 5/22/97 -0400, Tim Showalter wrote:
>Should the base spec provide a way to do vacation-style forwarding?
>What should this mechanism be?

I thought that sieve kind of made a vacation system surpufluous (sp?)?
Are are you talking about the mechanics behind vacation?  If so,
could you spell out what you think those mechanics entail so we can
get a clear picture?

regards,
Jack
-------------------------------------------------
Jack De Winter - Wildbear Consulting, Inc.
(519) 884-4498		http://www.wildbear.on.ca/

Author of SLMail for 95 & NT (http://www.seattlelab.com/)

Date: Thu, 22 May 1997 16:50:39 -0700 (PDT)
From: Ned Freed <[email-masked]>
Subject: Re: vacation
To: Tim Showalter <[email-masked]>
Cc: MTA Filters <[email-masked]>
Sender: [email-masked]

> Should the base spec provide a way to do vacation-style forwarding?
> What should this mechanism be?

It can be there but it has to be optional, since vacation forwarding depends on
a database of addresses-already-sent-to, which implies significant per-user
storage, storage some implementations may not want to allow for. Management of
this database may be a bit more than we need in the base document, too...

				Ned

Date: Thu, 22 May 1997 19:02:22 -0400 (EDT)
From: Tim Showalter <[email-masked]>
Reply-To: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: vacation
Sender: [email-masked]

Should the base spec provide a way to do vacation-style forwarding?
What should this mechanism be?

-- 
                                           Tim Showalter [email-masked]

Date: Wed, 21 May 1997 11:54:46 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: mutli-line strings (again)
CC: [email-masked]
Beak: Is Not
Organization: cmu
Sender: [email-masked]

Thomas Down <[email-masked]> writes:
> Chris' mechanism works for me, on the condition that instead of 
> differentiating between quoted strings and messages, we just have a
> single type of string in the grammer, and _always_ allow either a 
> quoted string or a Chris-string.
> 
> Anyone else?

  Me.  (Sorry for not saying anything about it in the first post...)

  )Rob

Date: Wed, 21 May 1997 09:10:21 +0100 (BST)
From: Thomas Down <[email-masked]>
Subject: Re: mutli-line strings (again)
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Sender: [email-masked]

A while ago, Rob Earhart wrote:
> 
>   I think I'd prefer the Chris mechanism; the ANSI-C way works; I
> really don't like the LISP mechanism at all.
> 

Chris' mechanism works for me, on the condition that instead of 
differentiating between quoted strings and messages, we just have a
single type of string in the grammer, and _always_ allow either a 
quoted string or a Chris-string.

Anyone else?

Thomas
-- 
The aim of science is not to open
the door to infinite wisdom, but to
set limits to infinite error.                       -- Brecht

Date: Wed, 21 May 1997 09:07:55 +0100 (BST)
From: Thomas Down <[email-masked]>
Subject: Re: line terminator
To: [email-masked]
Sender: [email-masked]

Thomas

Date: Tue, 20 May 1997 23:47:16 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: line terminator
Beak: Is
Organization: cmu
Sender: [email-masked]

> CRLF: This is what a standard does normally.

  The only problem with LF|CRLF|CR is that it *doesn't* work with any
OS - you can't read files that were created on another platform.

  We could just let it be LF|CRLF|CR, and leave it up to the transfer
mechanism / editors to do the translation... (this is the approach
HTML takes, although I'm not sure whether that's an argument for or
against :-)

  )Rob

Date: Tue, 20 May 1997 23:36:12 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: Re: mutli-line strings (again)
Beak: Is
Organization: cmu
Sender: [email-masked]

  Referring to them ANSI-C, LISP, and Chris...

  The ANSI-C way is ugly, but manageable.

  In both the LISP and Chris mechanisms, a missed terminator hoses the
rest of the file, but at least with Chris's the terminator's easy to
see; it's harder to leave it off.  The LISP mechanism offers no win
over the Chris mechanism.

  I think I'd prefer the Chris mechanism; the ANSI-C way works; I
really don't like the LISP mechanism at all.

  )Rob

Date: Tue, 20 May 1997 23:18:52 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: block structure,s upport, and require
Sender: [email-masked]

The previous few messages are my perception of issues recently argued.  They
include my bias -- that is, I am likely to forget about anything I don't
want to argue about.  Worse, I'm doing this from memory.  

I do not believe we had concensus on any of these issues and would like to
cover them in the next draft.

Please post any issues that I've missed (a seperate subject line would be
helpful, by the way).

(I would have sent this introduction on the first message, if only I'd
gotten the address on the first message right ...)

The require/support commands must be evaluated before the language is
parsed if they are to be used usefully.  If you don't parse them, the
extension keywords look like syntax errors.  This is broken. It is not
consistant with whichever part of the draft demanded the script be
syntactically correct before running it.

Rob's post looks to be right to me.  I'd like to see some other mechanism.
What, I'm not sure, but something else; would real block commands ("{",
"}", or "BEGIN"/"END" if there are any pascal bigots on the list), fix
anything?  (I think it helps, provided someone doesn't do something
stupid with control structures.)  Can we do something more useful with
require (all requires must be stated in the first line of the script)?
(ugh)

(for those recent subscribers, the archive is under 
<http://www.imc.org/ietf-mta-filters/>.)

-- 
                                           Tim Showalter [email-masked]

Date: Tue, 20 May 1997 23:15:00 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: line terminator
Sender: [email-masked]

If it's LF|CRLF|CR, you can assume that it'll be saved that way on the file
system and the mail server can just read this file.

If it's CRLF, Unix and Mac users won't be able to just drop in a new
filter; they'll have to run a conversion program.  (So it's a syntax
checker too; this isn't necessarily a bad decision.)

What's in the draft, as I had intended it (not that I've read the draft
recently, not that it's without error) is that a newline is any of the
three and an implementation is required to turn them into a CRLF when
printing out a message for servers.  This is what made *me* happy; it is by
no means the right solution.

I feel like a skunk for arguing this and not just conceding that
all-the-world-is-either-CRLF-or-should-be, but I'm going to anyway.

-- 
                                           Tim Showalter [email-masked]

Date: Tue, 20 May 1997 23:13:14 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: MTA Filters <[email-masked]>
Subject: mutli-line strings (again)
Sender: [email-masked]

I never saw what I'd consider concensus, so I'd like to hash this out
again.

There are at least three proposals for multi-line strings:
| ANSI-C style:
| "This is a multi-line string.\n"  "It is spread over several lines.\n"
| "\"This is a quoted string.\"\n"

This is a second try; I think LISP lets you get away with this:
| "This is a multi-line string.
| There is a line break. \"I suppose this is a quoted string.\"
| "

And Chris' modification of what's in the draft:
| text:
| This is a multi-line string.
| .. This line begins with a single dot.
| .

-- 
                                           Tim Showalter [email-masked]

Date: Tue, 13 May 1997 02:35:25 -0400 (EDT)
From: Tim Showalter <[email-masked]>
To: [email-masked]
cc: MTA Filters <[email-masked]>
Subject: Re: some input on sieve-00
Sender: [email-masked]

On 10 May 1997 [email-masked] wrote:

> Tim Showalter <[email-masked]> writes:
> 
> >I won't change the word "sort" to "autofile" as I find that to be worse, but
> >I think the section might be a little vague.  Can someone give me a wrong
> >interpretation of the section?  Or is it better to change "sort" to
> >"filter"?
> 
> Filter tends to imply altering something.  That might not be appropriate
> in this context.

I don't think filter implys altering anything; the term has been in use in
various circles.

> >Can you offer a counterproposal?  I can't see another good way to do it; the
> >syntax errors falling through cause too many problems.  Furthermore, the
> >design of the language allows one if clause to stop processing; aborting out
> >of that if clause to allow the rest of the script to run would make it
> >very difficult to predict control flow during a syntax error.
> 
> Expressed in this way, I'm willing to agree that it's acceptable
> behaviour.  If that's the goal of the statement in the document, I would
> like to see verbage in the document stating the reasoning. Without such
> an explanation, I think the behaviour would be viewed in a poor light.
> It might also serve to inhibit non-compliant implementations.

I don't think inhibit is the right word.

In any case, it is the goal of the statement in the document.  I have this
idea that someone will case off all their mail except for things that look
like bombs and toss 'em.  This would cause problems if anything had errors.

I could add some explanatory text to the document.

> In general, I'd like to see more of the rationale of the design decisions
> documented in the spec.

Isn't that very atypical for a standards document?

-- 
                                           Tim Showalter [email-masked]

From: [email-masked]
Date: 10 May 1997 15:31:22 -0000
Subject: Re: some input on sieve-00
To: [email-masked]
Sender: [email-masked]

Tim Showalter <[email-masked]> writes:
>I agree with Ned completely, but want to add some things.

>On 26 Apr 1997 [email-masked] wrote:

>> 1. Introduction

>> The word 'sort' in 4th paragraph is maybe a bit ambiguous when talking
>> about sorting mailboxes.  Maybe something like 'autofile' or something.
>> Not a big point, just a comment.

>I won't change the word "sort" to "autofile" as I find that to be worse, but
>I think the section might be a little vague.  Can someone give me a wrong
>interpretation of the section?  Or is it better to change "sort" to
>"filter"?

Filter tends to imply altering something.  That might not be appropriate
in this context.

Maybe 'sift'.  It is a sieve, after all :-)

>> 2.7 Evaluation

>> The second paragraph mentions the possibility that implementations may
>> impose restrictions on the number of actions per message.

>> I think this is a bad thing. [...]

>Implementations are free to disallow the limits, but I want those limits.
>We have too many creative users.

>> With a restriction like this, the sieve becomes significantly less useful
>> for many of the users that are most likely to use it the first place -
>> users adept at email.

>Can you give an example?  Mailing lists and bizarre autoresponders are best
>handled on private machines or by administrators.  If sites need things like
>this, and can trust their users, they should turn the limits off.  However,
>in order for this to be useful here, or for an ISP, there must be some way
>to keep users from writing instant automated mailbombs.

>> 6. Errors in Processing a Script

>> The stipulation that implementations SHOULD NOT try to recover from a
>> script with errors is a problem for me.  Aborting within an 'if' clause
>> makes sense to me, but to totally stop filtering if any error is encountered
>> is the wrong thing to do.  I would venture a guess that most users would
>> consider this a very bad characteristic of the mechanism.

>Can you offer a counterproposal?  I can't see another good way to do it; the
>syntax errors falling through cause too many problems.  Furthermore, the
>design of the language allows one if clause to stop processing; aborting out
>of that if clause to allow the rest of the script to run would make it
>very difficult to predict control flow during a syntax error.

Expressed in this way, I'm willing to agree that it's acceptable
behaviour.  If that's the goal of the statement in the document, I would
like to see verbage in the document stating the reasoning. Without such
an explanation, I think the behaviour would be viewed in a poor light.
It might also serve to inhibit non-compliant implementations.

In general, I'd like to see more of the rationale of the design decisions
documented in the spec.
-- 
thx,
kjj

From: [email-masked]
Date: 10 May 1997 15:07:46 -0000
Subject: Re: some input on sieve-00
To: [email-masked]
Sender: [email-masked]

Ned Freed <[email-masked]> writes:
>> 0.2 - Open Issues.
>
>> I'm curious why "fileinto" is being considered for moving into a separate
>> document.  Maybe I missed an earlier thread on this.
>
>"fileinto" needs to be a separate, optional facility becase many
>implementations will not be able to support it. It also isn't something that's
>going to be at all easy to write a security analysis of (something the IETF has
>gotten a lot pickier about lately).

Ah.
That makes sense.

>> It might also be nice for users to not have to use quotes around words that
>> don't need them.

>This is highly problematic, for the simple reason that it may have a very
>adverse effect on future extensibility. The ability to distinguish between a
>string argument and, say, a function that returns a string, is crucial if we
>want to keep the parser implementable with single-token lookahead and the
>language backwards-compatible.

>And what happens if I want to add a function bart to the language?

Suggestion withdrawn.
-- 
thx,
kjj

Date: Fri, 09 May 1997 17:09:24 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: Sieve Clarifications
To: Steve Hole <[email-masked]>
Cc: MTA Filters <[email-masked]>
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Thu, 8 May 1997, Steve Hole wrote:
> Hmm ... maybe this should go into a multipart/report.   There is already a 
> DSN response for MTA based bounces.   Ned would be the guy to ask about 
> that.

I spoke with Ned and he thinks that's the right idea.

The next question is if it's a delivery receipt or a read receipt type.  I
think it's a delivery receipt type.

From: Steve Hole <[email-masked]>
Reply-To: Steve Hole <[email-masked]>
To: Tim Showalter <[email-masked]>
cc: Chris Newman <[email-masked]>, MTA Filters <[email-masked]>
Subject: Re: Sieve Clarifications
Date: Thu, 8 May 1997 15:43:09 -0600 (MDT)
Sender: [email-masked]

On Wed, 30 Apr 1997 16:18:09 -0400 (EDT) Tim Showalter 
<[email-masked]> wrote:

> On Wed, 30 Apr 1997, Chris Newman wrote:
> > Section 4.1.
> > 
> > Need to precisely document the format of a bounce message.  How about a
> > MIME multipart with the first part containing the Sieve text and the
> > second part being the original message/rfc822.
> 
> That's probably the right thing to do.  If anyone wants to suggest precise
> language, I'll add it; otherwise, I'll go chasing references before the next
> draft goes out.

Hmm ... maybe this should go into a multipart/report.   There is already a 
DSN response for MTA based bounces.   Ned would be the guy to ask about 
that.

Cheers.
---  
Steve Hole			VP,  Research and Development  
The Esys Corporation		EMail: [email-masked]
900 10040 - 104 St.		Phone: 403-424-4922  
Edmonton, AB, Canada		Fax:   403-424-4925  
T5J 0Z6  

Date: Tue, 06 May 1997 18:42:02 -0500
From: "Matthew Wall" <[email-masked]>
To: "MTA Filters" <[email-masked]>
Subject: Re: Sieve Internationalization
Reply-to: [email-masked]
Sender: [email-masked]

--On Wed, Apr 30, 1997 9:54 AM -0700 "Chris Newman"
<[email-masked]> wrote: 

> You're going to hate me for this, but IETF standards have to deal with
> this issue.
> 
> Suggestions:
> 
> (1) Sieve scripts use UTF-8 [RFC-2044].  This may require some text for
> message bodies (either all Sieve messages are US-ASCII/UTF-8 or
> non-UTF-8 Sieve messages have to be quoted-printable or base64 encoded).
> 
> (2) Use the concept of "comparators" (formerly ordering functions) from
> ACAP (can even use ACAP's registry).
> 
> Define match-keyword as:
> 
> match-keyword = ("contains" / "matches" / "is") ["-" comparator]
> 
> I'd be tempted to make the default comparator be "en-nocase" for reasons
> I've previously stated, although I'd live with "octet" as the default.
> 
> Note that ACAP's registry will require comparator registrations to state
> if they're suitable for substring matching (some comparators would only
> work with "is").
> 
> Finally, comparators would have extension names of "comparator-<name>".
> 
> (3) Require Sieve implementations to map MIME header encodings to utf-8.
> This is probably the only way to reasonably do international searching.
> Tim, you should be able to use code from the Cyrus IMAP server for this.
> 
> (4) Language tagging probably isn't necessary in Sieve itself since it
> doesn't display strings.  Probably need a way to include a
> "Content-Language" header in reply messages, however.
> 

Speaking of which, has Harald caught up with this stuff yet as promised?

- mw

-----------------------------------------------------------------------
Matthew Wall                       mailto:[email-masked]
Cyrusoft International, Inc.       http://www.cyrusoft.com
Voice: +1 412 605 0499             Fax: +1 412 605 0705
-----------------------------------------------------------------------
     Proud Purveyors of the Mulberry IMAP Email Client
          "Internet Mail from the Ground Up" (tm)
-----------------------------------------------------------------------

Date: Mon,  5 May 1997 00:04:01 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: sample filter implementation
Beak: Is Not
Organization: cmu
Sender: [email-masked]

  Just to see what it would entail, I implemented
draft-showalter-sieve-00.txt.  The code's available from
<URL:ftp://ftp.andrew.cmu.edu/pub/cyrus-mail/filter-v1.a1.tar.gz>.

  A few notes:

  The code's alpha.  It works, it doesn't seem to have any bugs, and
it implements all the features, but the interface is a little
simplistic.  It also has a few hardcoded limitations (no more than 80
characters in a header name, 1024 in a header body, 100 headers,
etc...).  This is not meant to be production code, just stable and
useable by humans for playing with filter scripts.  :-)

  It should be able to figure out how to compile itself on pretty much
anything with lex, yacc, and an ANSI C compiler.

  It basically just takes the name of a filter script, and a message
on stdin, and prints out the actions generated by the script.

  It doesn't have any framework for extensions, although it wouldn't
be hard at all to add one.

  While the diagnostics it prints out are reasonably nice, it doesn't
do error recovery in the parser - figuring out the token to shift to,
with the way control structures are implemented, is a royal pain, and
most yaccs don't have token-insertion recovery.  So you get one error,
and then it exits.

  Still, it's useable, and stable, and proof that it's possible to
implement the draft as it stands.

  Enjoy!

  )Rob

Date: Thu,  1 May 1997 15:08:35 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: Chris Newman <[email-masked]>
Subject: Re: extensions
CC: [email-masked]
Beak: Is Not
Organization: cmu
Sender: [email-masked]

Chris Newman <[email-masked]> writes:
>      d) Forbid extension control structures unless script also includes a
>        "require <extension>" prior to their use.

  That doesn't help.  Consider

  if support "foo" then
	require "bar"
	bar "andrew.cmu.edu" then
	    qux;
	elsif "cs.cmu.edu" then
	    baz;
        else
	    thud;
	endbar
  else
	# do it the old fashioned way
	# ...
  endif

  Okay, so there's a require.  You still lose - you have no idea what
that bar is doing.  You can't even tell that it's a control structure,
and not a command.  You don't know which else goes with your if.  It's
completely ambiguous without knowledge of the bar extension.

  In addition, that's a horrible way to design a language.  A parser
for the base language SHOULD be able to recognize any string in that
language with extensions.

  (As an aside, the example under require in the spec doesn't parse,
'cause require's a control structure, and control structures don't end
with ';'s.  :-)

  )Rob

Date: Thu, 01 May 1997 11:47:15 -0700 (PDT)
From: Chris Newman <[email-masked]>
Subject: Re: extensions
To: Rob Earhart <[email-masked]>
Cc: [email-masked]
Originator-Info: login-id=chris; server=thor.innosoft.com
Sender: [email-masked]

On Thu, 1 May 1997, Rob Earhart wrote:
>   We need to either
>    a) Make the grammar more regular with respect to control structures
>       (maybe a standard block syntax, like C's {}s or Lisp's ()s?),
>    b) Require that control structures end with some standard
>       terminator, or
>    c) Forbid extension control structures.

     d) Forbid extension control structures unless script also includes a
       "require <extension>" prior to their use.

I'm partial to (d).  :-)

Date: Thu,  1 May 1997 14:18:04 -0400 (EDT)
From: Rob Earhart <[email-masked]>
To: [email-masked]
Subject: extensions
Beak: Is Not
Organization: cmu
Sender: [email-masked]

  Just for fun, I wrote a parser for the proposed filtering language.
It's pretty simple and clean; not hard at all.  The only problem came
up while writing the code to handle extensions used by the filter that
the interpreter doesn't know about.

  While handling commands and tests defined by unknown extensions is
fairly simple (commands go to the next ';', tests to the next ',' or
unmatched ')'), dealing with control structures defined by unknown
extensions is impossible.

  You can't just give up parsing the current block - even if you're in
an IF, there might be an IF after the extension (so you can't just go
to the next ELSIF/ELSE/ENDIF), or the extension might use one of those
atoms (so you *really* can't just go to the next ELSIF/ELSE/ENDIF).
(You also can't recover to the next ';', as a control structure may
embed commands, and control structures don't end with ';'s).

  In short, you lose - an extension you don't know about is by
definition a parse error, and there's nothing to synchronize against
to let you keep parsing.

  We need to either
   a) Make the grammar more regular with respect to control structures
      (maybe a standard block syntax, like C's {}s or Lisp's ()s?),
   b) Require that control structures end with some standard
      terminator, or
   c) Forbid extension control structures.

  )Rob