On Mon, 6 Jan 2003 23:31:20 -0600
Pete Resnick <presnick(_at_)qualcomm(_dot_)com> wrote:
Just to make sure this doesn't get by without comment:
On 1/4/03 at 2:06 AM -0500, Leo Bicknell wrote:
Change the RFC, then complain about the program.
Sorry, we don't do that in the IETF. The IETF standards process
doesn't make up rules and then make everybody fix their code. In the
IETF, standards simply document the current state of affairs of
interoperable running code.
I realize I'm taking this out of context, but...
the criteria for standardization levels are documented in RFC 2026.
words like "no known technical omissions" are used. it doesn't say anything
about standards documenting the state of running code.
in my experience, trying to document running code is often a good idea,
and trying to define a standard is often a good idea, but trying to do
both in the same exercise leads to disaster - there is inevitably a
conflict between what meets IETF criteria for standardization and what
is actually done in running code. the result is usually that people are
tempted to lie about either what the running code does, or worse, to
lie about whether the running code meets standardization criteria.
When we work on Proposed Standards where
there is no running code, we sometimes propose ways of doing things
and ask people to make their implementations a certain way, but we
don't tell people who are following a current standard that they are
hereafter wrong without pretty impressive reasons. We do "de facto"
standards, not "de jure" ones.
it's true that we don't often tell people it's wrong to follow a current
standard - at least, not without a good reason, and especially not when
it's one of *our* standards. but our standards are closer to de jure
standards than de facto ones. documenting running code is NOT what we
do in our standards process, at least, not when we're following our rules.
Keith