Joe Grace produced a rather nice analysis starting:
Let's apply Occam's razor to this discussion and the specification!
Joe,
As far as I can tell, you've gotten only one things wrong. I want to
disassociate myself from the "Klensin-Rose group" binding for two
reasons. First, the arguments are really Marshall's; he should get
primary (or even exclusive) credit or blame :-)
The second is that I obviously wasn't clear in what I was trying to
say. My main point was that the CRLF business really was important to
model in a different way; Marshall has agreed on that issue. The "small
irritation" comment was not intended to provide significant support or
comfort to *either* side, but to make a version of the case that you
have presented much more elegantly. To restate that in my terms:
-- either approach requires some change, although one changes the
protocol and the other changes "only" the document.
-- if the fact that something has been written into a "proposed
standard" prohibits making protocol changes to tune things and reflect
experience, then there is little point in a multi-stage standards
process.
-- absent an argument that "." *should* be a part of tspecials, it
probably shouldn't be. That position is supported, not only by your
argument from Occam's razor, but from the principle of minimum confusion
for sloppy programmers (which is a corollary to Murphy's Law).
I am not strongly persuaded that the fact that the text says that "."
is in tspecials today determines that, absent demonstration of serious
harm from having it there, it should remain (my reading of Marshall's
argument), not am I completely persuaded that taking it out is the
obvious and correct thing to do (a reading of Mark's argument).
-- it would be wise to find a way to resolve this problem other than
counting kilobytes generated in a religious war.
My personal leanings are actually a little bit toward Mark's position on
this. The reason is that I think we should *never* design protocols
that *require* the robustness principle in order to operate correctly.
Instead, we should reserve that principle for the slack around the
fringe cases that we can't anticipate. To the degree to which we can
anticipate problem areas, we should, IMHO, try to make our protocols as
tight, precise, and, consistent with functionality, as simple to
implement correctly as possible.
--john