I hope to have an 05 draft out real soon now.
Here are the list of things that I know of (and remember) that have been
requested as changes in the next draft. They're marked as follows:
* "Consensus" indicates something that I believe is consensus, and will change.
* "Bug" indicates something that's just wrong.
* "Request" indicates something that someone has asked for, and will be
changed if I get confirmation that it's consensus.
* "Question" indicates something that I'm not sure how I'm supposed to word
it, and would appreciate some more information.
1. Concensus: Short circuit evaluation is a SHOULD, not a MUST.
2. Question: Should short-circuit evaluation be as is, a MAY, or not
discussed at all?
3. Concensus: i;ascii-casemap is required.
4. Question: Should i;ascii-casemap be the default?
5. Consensus: Fileinto is optional; discussion of local mail folders and POP3
should be removed.
6. Request: A non-present comparator is considered to be basically a syntax
error.
7. Request: Implementations are required to decode header charsets.
8. Bug: Section 7, remove reference to "support" and "reply".
9. Bug: Remove all XXXs (section 2.3, 2.11.1, for instance) and fix all
examples.
10. Bug: Header name compares are always case-insensitive.
11. Bug: 4.2: example is incorrect. ("From" should be "To"; contains should
be :contains)
12. Consensus: What happens when an error occurs should be dropped; it should
not be part of the specification, and is just a quality-of-implementation
issue.
13. Request: Reject should be optional.
14. Consensus: There should be two namespaces for extension names, one "vnd.",
one everything else, just like several other protocols.
I am way overdue for posting the reasons that I made some of the changes to
the draft. Here they are. (Some, not all, of these were made in the long
delay between 03 and 04, and were ok with the circa 03 list participants and
not okay with the influx of people after 04.)
1. "Matches" should be just another comparator, in my opinion.
(This allows easy addition of regular expressions or globs.)
I'm not real attached to this.
2. Tagged arguments: Some time ago, tagged arguments were proposed and
accepted. I strongly prefer them because they allow keywords to be taken
out of the grammar, reducing the number of special cases, and allowing
extensions to be added without changes to the grammar.
2a. Can we keep tagged arguments?
2b. Arbitrarily, I allowed tagged arguments to be in any order and freely
interspersed in commands. This was probably a mistake, but I wanted to
preserve wordings like this:
header "From" :contains "tjs"
What do people want? The dominant stated opinion is that they should only
happen after the keyword, and that's fine with me.
3. Elsif was added because it removes an ambiguity in the grammar, making
"else" yet another command. This is discussed in anything that talks
about writing C parsers; "else if" is an imbiguity, and many languages
have an "elsif" as a result. I have a fairly strong preference for this.
Note that "else if" is illegal in 04.
4. The formal grammar was a major change from 03, and I have strong
reservations against changing it back. 03 had a grammar that was
over-specified, and under-permissive. Every extension required a grammar
change; this seems likely to lead to a horrible grammar when all is said
and done.
This has probably left considerable ambiguity in some other places in the
draft, but I don't beleive that's a good reason to switch back to the
previous grammar.
--
Tim Showalter <tjs+(_at_)andrew(_dot_)cmu(_dot_)edu>