Hmm, did you miss my reply on these points to your previous post?
Rather than repeat my comments...
http://www.imc.org/ietf-mta-filters/mail-archive/msg06094.html
I think I was waiting for a response or more comments before making
changes. I should have added them to the open issues list while
waiting.
Sorry, I probably really missed it. :(
Strings Containing Header Names
Section 2.4.2.2:
A header name never contains a colon. The "From" header refers to a
line beginning "From:" (or "From :", etc.). No header will match
the string "From:" due to the trailing colon.
No header will match it, but what's the result? How about ""? If users
write "From:", most likely they made a mistake. Should that really not
cause an error?
MIME-Encoded NUL Characters
Header Test With Invalid MIME Encoding In Header
Hmm. To paraphrase (and mangle) something that Dave Crocker said at the
meeting in Minneapolis: when there's a spec for something, it's a bad
idea to try to address general problems arising from it anywhere but in
that spec.
As I quoted, I see a contradiction in the base spec. Either
interpretation could be valid, but only one probbaly is. The fact that
the same Sieve code yields different results on different implementations
is not something to be described in the MIME RFCs.
String Arguments
As you can see, I agree with you and probably everybody else here
now. Yet, the RFC still does not specify it. If the collation draft
determines caseful or caseless matching, then please refer to it doing
so. That does not answer how other extension names are being matched,
although we agree it should be caseful.
My read of section 2.10.6 is that an implementation is only required to
detect errors in code that is actually executed, but that it is
permitted to also detect them code that is skipped ("if false { ... }")
or not reached ("stop; ..."). Script writers should disable code using
unsupported extensions by removing it completely or commenting it out,
as they cannot depend on implementations accepting such code when
wrapped in an "if false {...}" block.
That's what I finally thought: Everything is possible. To me,
compile-time is both syntactic and semantic checks, but Sieve may be
compiled or interpreted. An implementation may parse and interpret at
the same time, and not notice junk after executing "stop;". It may build
a syntax tree, thus first parsing everything, and then interpret that,
only doing semantic checks on interpreted parts. Or it may perform
semantic checks on the entire parse tree before interpreting it.
Perhaps we should split the description in syntactic, semantic and
run-time checks. The syntax is described in section 8. The description
of control structures, tests and actions must not talk of syntax, but
of semantics and run-time checks.
That's uncommon, because most languages (LISP being one exception) do as
much on the syntactic level as possible. I have no idea why extensions
do not extend syntax instead of semantics with the requirement that
words of the extended grammar must be words of the generic grammar,
but I guess it is too late now.
What can be done is to use the terminology right. When starting my
implementation, it confused me to no end that the previously described
syntax did not appear in the grammar. I would like to save the next
person from that confusion:
----------
Sieve implementations MUST perform syntactic, semantic and run-time
checks on actually executed code. Implementations are free to perform
those checks, or part of them, on not executed code, and they are free
to perform them before or during execution.
----------
Smells like the range found in BASIC implementations. :-)
Michael