--On Sunday, 11 September, 2005 16:54 +0200 Frank Ellermann
<nobody(_at_)xyzzy(_dot_)claranet(_dot_)de> wrote:
John C Klensin wrote:
I think the big point here is that one can't make _any_
change of this sort lightly. There are almost always
complications.
Sure, but we have enough ABNF experts / fans here, adding
Bill's validator I'm confident that we won't introduce
new "bugs" unintentionally.
I would only point out that no validator can distinguish or
decide between two alternatives, each of them perfectly valid
ABNF. Both the 2821bis form of the relevant productions and the
2821 form are valid; they just have slightly different
implications.
In some cases it's a question of "what's less harmful",
you can't allow crap like bare-CR and forbid it at the
same time. If absolutely necessary there's that MUST
accept + MUST NOT generate option.
Yes. But please go review the robustness principle and remember
that implementers will do whatever the consider morally and/or
commercially necessary. If the standard tells them to do
otherwise, the standard will be ignored. Every single time.
But that's also where the headaches begin, resulting in
a split ABNF as in 2822 chapter 3 and 4 (obs-cenities
in chapter 4). But obviously it's even then possible
to get it right, maybe we should adopt this example...
To a considerable extent, having different generate and accept
syntax or semantics is just an attempt to turn some special
cases of the very broad robustness principle into specific rules
that require much less intelligence and insight to follow. That
can be a very valuable approach, especially when "common
practice" and "good practice" have diverged, it is desirable to
try to bring them back together, and implementation history
makes it clear that what is "conservative" and what is "liberal"
need to be spelled out. DRUMS came to the conclusion that 2822
should take that approach and that it was not necessary (and
therefore was not desirable) to do it in 2821. One might take
that as an indication of where the greater abuses and confusion
had occurred in the past, but there are a large number of other
interpretations.
Again, opinions differ, but there were claims a very long time
ago that the essential difference between 821 and 822 is that
the former basically specified semantics and used syntax and
syntax productions as a means of specifying how those semantics
were to be enabled. RFC 822, in the view of that group, had
much more tendency to specify syntax and hope that, aided by the
names of the productions, the semantics would largely take care
of themselves. My own opinion is that characterization is
somewhat unfair to 822, but that there are small grains of truth
in it that led to a need, in 2822, to do much more work to try
to clarify such things as Message-ID, personal name phrase,
implications of comments, and Sender and Resent-* field meanings
and interpretations.
In any event, I think it would take making a really strong case
to get either strategy changed now.
john