Here is my recollection of what happened at the Filtering portion of the
Submit & Filtering BOF at IETF Memphis. This is reconstructed from memory.
FILTERING:
Discussion of Tim's draft (posted to list and copies passed around).
Consensus: good start, make minor fixups and submit as I-D. Discussion of
extension mechanism. Consensus: define capability string, which each
extension adds to. How client gets string not defined in this spec. Could
be ACAP, could be shared file, could be magic. Question: how to write
script such that it can work on different servers, with or without
extensions. Consensus: need dynamic test for extension supported, either
REQUIRES or IF-EXTENSION or both. Discussion on how script gets from
client to server. Consensus: leave for a different draft. Could be ACAP,
could be file (.filters), could be anything.
Discussion of where filtering occurs. Consensus: during "final delivery",
which will differ depending on implementation, but is before message goes
into mailbox.
Discussion on specific elements of draft: IF/ENDIF vs. "{" and "}". No
resolution; arbitrary choice. Discussion of blocks: needed or not? No
consensus for them. Discussion of BOUNCE action: do we need it? Does it
generate DSN or MSN or neither? Does it need parameter for text to be
returned? Call for dropping BOUNCE since we have REPLY and TRASH.
Discussion on how to specify text of REPLY. Series of lines with
continuation character? Length-prefixed series of bytes? Series of lines
ending in dot by itself (standard SMTP etc.)? Discussion of line-endings.
CR vs. LF vs. CRLF. Consensus: add ABNF to allow any of three. Message
text is series of lines, ending in dot on line by itself. Question:
doesn't this make it hard for cross-platform clients, or client on one
platform reading filter rules written by client on another platform?
Answer: they have to deal with it now.
Discussion on gearing language for machine-readability or human-readability
(continuation of list thread). Consensus: current language is pretty good
balance.
Question on complexity of script vs. ability to be handled by GUI in
client. Answer: if more complex elements (perhaps ELSE) are not used, GUI
can read & display existing ruleset. If GUI encounters constructs it can't
display, it can punt and open a text window. This should be added to
document as suggestion to client implementors.
Questions on filtering on envelope contents, syntax to do INCLUDE, filing
into folders other than INBOX, and regular expressions. Consensus:
filtering on envelope contents to be an extension. Syntax for INCLUDE to
be in URI notation, but as an extension, not in base spec. Filing into
folders other than INBOX, and regular expressions to be extensions.
Question on STOP. Answer: it ends all rules. Any actions already
specified (for example, filing, replying) get done, but no additional rules
or actions are processed.
Question on what if no actions specified/no rules matched. Answer: default
action (file into inbox).