Dave Crocker <dcrocker(_at_)brandenburg(_dot_)com> wrote:
I'm not entirely sure I understand the direction of your comments, but
here's an attempt to formulate a constructive response:
My comments were meant to indicate that because RFC's can be vague
and ill-defined, any discussion about the RFC's or implementations is
necessarily vague and ill-defined. While people try their best to
write clear text, English is an imprecise language, and
miscommunication can occur.
If we had a complete state-machine specification of a protocol, we
could use automated tools to validate the protocol, and much of these
problems could be avoided, or dealt with via automatic
tools. (e.g. the TFTP exponential explosion of packets problem could
have been discovered through a protocol validator.)
The problem is that such state machine descriptions often
practically impossible. So we're stuck with specifications which are
English text, incomplete, and thus open to interpretation.
1. Specifications need to be as clear, precise and accurate as the folks
writing them can make them, given the usual constraints of time and
skill.
I agree. But because they are written by humans, they will have
human errors, leading to implementors making guesses about the authors
intent. Such guesses lead to inter-operability problems, security
flaws, etc.
2. Later efforts to write specifications in the same technical arena
must continue this effort. However these later documents must perform a
difficult balancing act, between the history of the earlier documents,
the reality of current practise and discussion, and the needs of future
capabilities.
I agree. The difficulty I have is with things *not* written in the
RFC's. e.g. "The original design goals of SMTP." I can't find those
anywhere. RFC 821 says:
"The objective of Simple Mail Transfer Protocol (SMTP) is to
transfer mail reliably and efficiently."
but beyond that, the goals aren't stated explicitly.
Yet arguments for/against anti-spam systems talk about
fulfilling/countering the "original design goals" of SMTP. For the
life of me, I can't figure out why. It's all magic that people pull
out of the ether, with no documented foundation. It's unproductive,
and causes miscommunication and religous wars.
That's why my intentions are to focus on tangible items: machines in
the network, fields in a protocol, etc. I try to shy away from
discussing "original intent", because it is an intangible.
So to the original subject of "guessing" at what people mean, those
guesses are more likely to be correct when the discussion involves
tangibles.
No specification is ever perfect, either technical or linguistically.
We all just do the best we can. And we revise things as we learn more.
And we can change the accepted interpretation of fields in SMTP, if
we so choose, and if that change doesn't break existing
implementations.
A specification that is so ambiguous as to result in highly differential
interpretations among different readers is a specification that fails.
It is not possible to build interoperable implementations if everyone
reads the specs differently.
Of course, wehich is what interops are for. SPF, et. al. are
currently undergoing inter-operation tests in a live network. If the
evidence there shows them to be useful and backwards compatible, then
there's proof of inter-operability and running code, which indicates
that publication as a standard may be possible.
Alan DeKok.