Sieve Meeting Notes
Tim Showalter <tjs+@andrew.cmu.edu> Tue, 08 December 1998 02:24 UTC
Received: (from majordomo@localhost) by mail.proper.com (8.8.8/8.8.5) id SAA25594 for ietf-mta-filters-bks; Mon, 7 Dec 1998 18:24:51 -0800 (PST)
Received: from marvin.andrew.cmu.edu (MARVIN.ANDREW.CMU.EDU [128.2.36.192]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id SAA25589 for <ietf-mta-filters@imc.org>; Mon, 7 Dec 1998 18:24:49 -0800 (PST)
Received: from hitchhiker.adsl.net.cmu.edu (ietf-177-219.mtg.ietf.org [198.67.177.219]) by marvin.andrew.cmu.edu (8.8.7/8.8.7) with SMTP id WAA04284; Mon, 7 Dec 1998 22:34:23 -0500
Date: Mon, 07 Dec 1998 21:30:10 -0500
Message-ID: <emacs-smtp-640-13932-36658-537059@hitchhiker.adsl.net.cmu.edu>
From: Tim Showalter <tjs+@andrew.cmu.edu>
X-Mailer: BatIMail version 3.1
X-Spook: Bosnia Qaddafi Peking radar BATF plutonium SDI
To: ietf-mta-filters@imc.org
Subject: Sieve Meeting Notes
Mime-Version: 1.0 (generated by tm-edit 7.108)
Content-Type: text/plain; charset="US-ASCII"
Sender: owner-ietf-mta-filters@imc.org
Precedence: bulk
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 <tjs+@andrew.cmu.edu>
- Sieve Meeting Notes Tim Showalter
- Re: Sieve Meeting Notes Tony Hansen
- Re: Sieve Meeting Notes Randall Gellens
- Re: Sieve Meeting Notes Randall Gellens