Subject: Comment on draft-showalter-sieve-02.txt

From: Tomas Fasth <[email-masked]>
Date: Wed, 29 Oct 1997 15:49:34 +0100

I have a comment on draft-showalter-sieve-02.txt chapter 3.2. Require,
Page 15:

Is there a good reason why the the "require" declaration exists?
Can someone provide a good argument or two?
I have some arguments for removing it.

1. Terminating a script because it may or may not use an extension later
on seem to be a rather exotic need. Too exotic for requiring (!) a
separate declaration?

2. The "require" declaration can become an unecessary source of
confusion when debugging a faulty script. The relation, or perhaps the
connection, between the "require" declaration and the extension call is
not that obvious.

3. For a programmer (like me :-), a better approach to address problems
like extensions is by introducing a basic exception handling. I know,
it's not a programming language in that sense. But I cannot restrain
myself from giving you an example of exception handling, using the
excellent programming language called Python:

if header ("subject") contains-nocase ("the secret message")
  try:
    dwim blurdybloop body
  except ActionNotFound:
    keep # leave it alone

Note that Python is indentation sensitive, an alternative to "{}". Some
may regard it cleaner, other's may not. Anyway, the try-except
(try-catch in C++) mechanism is a powerful tool for providing clean
programming in modern programming languages.

4. The "support" conditional test seem adequate in most cases. May be
that is sufficient for our needs.

regards,

Tomas Fasth

---

From: "Fred L. Drake" <[email-masked]>
Date: Wed, 29 Oct 1997 10:42:45 -0500

> if header ("subject") contains-nocase ("the secret message")

  Wow, I didn't expect to hear Python mentioned here, but that's great
with me!
  I would like to point out that really only the layout and try/except
lines are legal Python.  I'd expect a Python translation to look more
like:

  if string.find(string.lower(header["subject"]), "the secret message") > -1:
    try:
      dwim.blurdybloop(body)
    except ActionNotFound:
      keep()

  ;-)

  I like the idea of exceptions in a "normal" programming language,
but am not convinced that they are appropriate here.  Perhaps all
exception-like conditions should be handled by the implementation as
keep commands; this seems to be in the spirit of the proposal.

  -Fred

--
Fred L. Drake, Jr.
[email-masked]
Corporation for National Research Initiatives
1895 Preston White Drive
Reston, VA    20191-5434

---

From: Tomas Fasth <[email-masked]>
Date: Wed, 29 Oct 1997 17:25:21 +0100

>   if string.find(string.lower(header["subject"]), "the secret message") > -1:

You're right. I wasn't using pure Python syntax. But this mistake became
deliberate as I copied the example from the draft to modify it. I
realized how similar the syntax really was, part from your correction
above, so I left much of it as is, as a slight attempt to provoke. :)

> keep commands; this seems to be in the spirit of the proposal.

I tend to agree, sorry for the diversion.
My real mission was rather to question the overall existence of the
"require" declaration. Is it correct to call it a declaration, by the
way? It just felt like not doing any good in the spec and might, as Tim
was expressing concerns about in the open paragraph, cause trouble when
implementing a parser/evaluator/executor.

Someone willing to stand up and defend "require"?

BTW, Tim and others, I was pleased to discover this workgroup and what
it tries to achieve. Very much needed, IMHO. It is my intention to use
the final proposal as part of a IMAP-based filtering agent.

- Tomas

---

From: Tim Showalter <[email-masked]>
Date: Fri, 31 Oct 1997 14:55:53 -0500 (EST)

So I should point out that this isn't a working group, just for the sake of
completeness; it's just a mailing list, despite the name.

Regarding exceptions, I'm against them.

* Syntax/link errors shouldn't be exceptions.

* Can't-write-to-mail-spool errors (i.e., user is over quota) should be
  handled by not filtering messages if the user is over quota, or otherwise
  having a temporary failure, waiting until the user isn't over quota, and
  then filing the message.

Those are the only exceptional cases I can think of that can come up.
Having exception handling in a language without loops, subroutines, or
variables seems like overkill.

Regarding Python-style indents, I'm one of the people who doesn't think it's
"clean" and am against it.

-- 
                                           Tim Showalter [email-masked]

---

From: "Fred L. Drake" <[email-masked]>
Date: Fri, 31 Oct 1997 15:52:27 -0500

> * Syntax/link errors shouldn't be exceptions.

  I'm not sure what a link error would be in a language like sieve;
was thinking that all implementations would be heavily based on a
lisp-like engine of some sort, but perhaps I misunderstand it.  I
agree that syntax errors should not be exceptions.  Further, I think
syntax errors should be caught before interpretation begins.

 > variables seems like overkill.

  Ok, this makes sense.

 > "clean" and am against it.

  Hmm, perhaps I wasn't clear; I'm not advocating the adoption of a
Python-like syntax for sieve.  I was just trying to clarify the point
about Python syntax.  (Which is not to say that I think
indentation-based syntax is bad; I like it.  It's just not that
important for something like sieve.)

  -Fred

---

From: "Paul Falstad" <[email-masked]>
Date: Fri, 31 Oct 1997 13:50:14 -0800

| I'm not particularly happy with the way required works out, but it may be
| needed; all Internet protocols are required to have an extension mechanism.
|
| I'd like to drop require and rely on support.

Well, sieve is a language rather than a protocol...  There's no way
to negotiate what features are supported, without introducing something
like a preprocessor (#ifdef FEATURE_X...) and that's not a particularly
attractive way to do it.

Any protocol that used sieve to describe filters would have to be
extensible, of course.  For example, if IMAP or ACAP or whatever were
extended to allow a user to set up filters, then the client could
attempt to pass a filter that used a certain feature..  A server that
didn't understand that feature might return with a parse error.  If
the parse error were specific enough, the client could restate the
filter without using that feature if possible.  This could be automated
so that human intervention isn't required.

If you keep "require", and make it processed at parse time, and then
make some standard way for a server to report require failures, then
the client could easily use extensions if they are there, and fall back
to more basic constructs if they're not.  So, it's extensible.

Or, you could drop "require" from the language itself, and rely on
something like it being present in whatever protocol is used to pass
filters back and forth.

Either that have some standard way of describing revisions of
sieve.  Then the server could just tell the client what revision it
supports, and the client could form the text accordingly.

So I don't think the sieve language itself needs to support an
extension mechanism, necessarily.

--
Paul Falstad                                 Software.com, Inc.
[email-masked]                    805-957-1790 x520
http://www.ttinet.com/pjf/                   http://www.software.com/

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 1 Nov 1997 01:05:14 +0100 (CET)

> completeness; it's just a mailing list, despite the name.

Sorry, I think I was the one that mixed this up.
I understand the difference, but still hope the opinions expressed
on this list are considered in the process of making a public spec
on Sieve.

> Regarding exceptions, I'm against them.

In the context of the sieve language, I can understand this.
Still, there might occur error conditions that may have to be
handled in some way, as an exception or something else. But I
am not in a position to give examples so I will shut my mouth.
:)

> variables seems like overkill.

Yes, you have a point there.

> "clean" and am against it.

Oh, I see. I have done C-programming as long as I can remember.
The curly brackets offered a formatting freedom, but also allowed
some programmers to abuse the de facto style of programming,
sometimes making the code close to unreadable.

The beauty of Python is that the code is always readable, regardless
of the programmer's personal style.
Also, dropping the programmer hat and putting on the non-technical
hat (my mother is a good example), Python style is more consistent.
It is less intuitive for my mother to understand why curly brackets
is sometimes missing and sometimes required.

Anyway, I'm not arguing to change Sieve's programming style.
Regard my comment about curly brackets as a personal reflecton.

--
Tomas Fasth

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 1 Nov 1997 01:29:16 +0100 (CET)

> syntax errors should be caught before interpretation begins.

My personal view is that syntax errors should be caught before the
script is put to work. I am not willing to equal this particular
situation with avarage execution of command shell scripts.
These scripts are about to execute in batch mode as part of a
delivery process.
An good example is aliases as used by sendmail. The aliases file
have to be processed before being put into the message dispatch
process. Syntax errors are reported to the operator. The alias
lookup mechanism in sendmail does not have to deal with
syntactical errors.
Why not apply a similar requirement on filtering?

> important for something like sieve.)

I tend to agree, with one exception(!):
I thought of Sieve as potentially being exposed to the end user.
In that case, indentation based syntax can make a difference.
Otherwise I agree, it's not that important.

--
Tomas Fasth

---

From: Tomas Fasth <[email-masked]>
Date: Sat, 1 Nov 1997 01:47:43 +0100 (CET)

> so that human intervention isn't required.

Hmm, a very interesting idea, indeed.
I had a similar idea of having a more detailed protocol where client
and server could exchange not only capabilities and general parsing
errors, but also ok/no responses on individual lines of filtering
rules. My idea is not very different from the ipfw command in
FreeBSD, if you happen to know about it, although message filtering
will require more sofisticated conditional expressions.

> to more basic constructs if they're not.  So, it's extensible.

But then, why would "require" be part of the script?
If you have established a two-way communication to the server,
wouldn't it be better to exchange the requirements, or capabilities,
as part of the protocol and not as part of the script?

> supports, and the client could form the text accordingly.

No, I don't like the version style.
Versions is something that should be coordinated.
Extensions or capabilities is, at least as I view it, a method to 
extend a base spec without the need of coordination. Which I think
was the idea for Sieve.

> extension mechanism, necessarily.

To that I can concur. Thank you for pointing out the difference in
this regard between a protocol and a language.

--
Tomas Fasth