Sieve BOF, Meetings Notes March 31 1998, IETF, Los Angeles Taken by
Laurence Lundblade ==============================================
The
generally stated thought at the outset of the BOF was move to sieve
to extended last call, not form a working group. Presentation on
Problem Definition - Ned Freed
---------------------------------------------- Goals: - Simple
language for simple filtering - Language performs test, then actions
- Analysis and actions are intentionally limited - Includes an
extension mechanism - Not intended to solve spam problem, just
provide tools - Not intended or do everything MUA filters do now -
Language be such that a GUI or forms-based editor can be used -
Focus
is on the language, not the transport or storage Discussion points:
-
filtering to be done on or around the time of final delivery - Want
to reserve option to do at a gateway - working group charter would
be
very limited (if we get to a working group) - Need language defined
first before we do extensions - Not clear how to manage extensions
yet Some discussion about having a separate requirements draft was
had. It was more or less settled that we would take a closer look at
the first sections of the current draft and refine it if needed.
Review of SIEVE draft - Tim Showalter
------------------------------------- Tim reviewed the -04 draft.
You
can read it yourself :-). The rest are points brought up in the
discussion. Are planning to add "elsif" Issue with mailbox names: -
suggested answer is to use UTF8. Fileinto is (currently) a move,
though it is locally defined, because it would be hard to define
properly. Multiple fileinto may or maynot be allowed - discussion on
the list clarifies a lot of this. Discussion at the meeting more or
less concluded it should not be locally defined. Discussion about
portability between server environments which execute - many want
portability so extensions or commands must work the same in all
environments so scripts are portable. Example of mailbox naming
given. This may be considered a rat hole. Semantics of left side of
commands must be fixed; right side is implementation dependent.
Suggestion for an extension that expands to use stuff known about
IMAP. Suggestion that semantics be created specifically for IMAP
mail
stores. Suggestion to specify some loop detection for the forward
action. Suggestion for duplicate detection in reply action.
Suggestion for URL's on the right hand side - was not met favorably.
Issue over access to the envelope. It is very useful in cases, but
not guaranteed to be available in all environments. Suggestion was
made that "reply" action should be an extension or should include
vacation and necessary local storage to implement it correctly. This
is to avoid it being used a an improper vacation facility. Note: you
can't do DSN's correctly after local delivery. Suggestion that
safe-tcl be examined for address parsing functions. Suggestion that
everything be taken down to UTF-8 to handle character sets. Seems
like a burden on the implementor - take discussion to the list.
Suggestion that unfolding should be done on all headers before
pattern matching. Suggestion that alternate grammars be considered
->
SGML and XML. Suggestion that we scripts be able to forward known
spam to a collection center for organized resistance. Suggestion for
some trace information about actions taken (debugging). Suggestion
that a good extension mechanism is needed so you can find out if
your
script will run for certain or not. Suggestion to have procedures -
can imagine horrible scripts without it. Wrapping up -----------
There was good humming(tm) about going forward on sieve in general.
Roughly equal humming in favor and opposed to forming a working
group. Those opposed said: - will take too long - not baked
enough to start a working group - will thrash if we don't have
something more cooked Course of action decided on is to work on
sieve
in the mailing list, come up with another draft and consider a
working group in a few months after things are more cooked. Brief
presentations on the sieve vacation extension and the use of ACAP
for
storing sieve scripts.