[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Sieve Meeting Notes
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
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"
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.
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.
We didn't take attendance.
Tim Showalter <tjs+@xxxxxxxxxxxxxx>