Subject: Sieve Meeting Notes

From: Tim Showalter <[email-masked]>
Date: 7 Dec 1998 21:30:10 -0500

1:30 7 dec 1998 Poolside Sieve Meeting Notes

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

 * 03 vs 05 specifications

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

 * Extensions

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

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

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

The syntax for requires will be this:

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

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

 * Capability

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

 * Third party

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

 * Mail Loops

Decided to allow multiple forwards after a very brief discussion.

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

 * Name of the "forward" command

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

 * Short Circuit Evaluation

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

 * Address-matching primitive

Decided on an address matching primitive, like this:

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

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

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

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

 * Envelope-matching primitive

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

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

 * Interoperability testing

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

* Attendees

We didn't take attendance.

-- 
Tim Showalter <[email-masked]>

---

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

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

> We didn't take attendance.

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

    Tony Hansen
    [email-masked]

---

From: Randall Gellens <[email-masked]>
Date: Tue, 8 Dec 1998 17:23:29 -0500

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

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

---

From: Randall Gellens <[email-masked]>
Date: Tue, 8 Dec 1998 17:25:33 -0500

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

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