[resend: forgot to cc list in original reply]
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.
2026 does say things about requiring interoperable implementations.
yes, but they're not required for proposed standards - and the
requiremnt for interoperable implementations is to test the
clarity of the spec, *not* for the spec to document implementations.
if the implementations don't agree with the spec, we don't automatically
change the spec to reflect the implementations. instead, we try to
understand whether the difference is due to a lack of clarity in the
spec (in which case we clarify it) or whether it is due to the failure
of the spec to specify what is really needed (in which case we fix the
spec and typically recycle at proposed). but we don't assume that the
running code is correct, and we don't constrain ourselves to make
the revised spec be consistent with running code.
And let's be very clear about what 2026 actually says: As far as "no
known technical omissions" goes, 2026 says that this requirement can
be waived under certain conditions.
yes, but in practice this is an exceptional case, not the normal case.
IESG rarely waives the requirement.
"Interoperable implementations"
and "operational experience" (which, of course, don't kick in as
requirements until Draft Standard) have no exceptions whatsoever
mentioned in 2026. Moreover, those requirements are *precursors* to
standardization: You don't get to move along the standards track
unless in the standard you are documenting actual running code.
not past proposed standard. though, again, if errors are found
in the proposed standard document the IESG will sometimes approve
fixes to the draft standard version that aren't implemented
in running code. (if those fixes won't interoperate with running
code, then IESG is more likely to reset to proposed, but that's not
the same thing as having them implemented first.)
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.
My experience is that more often, people fudge in the opposite
direction: They write the standard for the way they *want* the
running code to be, rather than having the standard represent what
the actual interoperable implementations are doing.
that's the way it should be. the problem occurs when people get
confused between whether they're documenting existing practice or
writing a standard.
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.
I disagree. Most other standards bodies create de jure standards: Not
a lick of code is written before standardization, and no operational
experience is required for standardization. What we do (in comparison
to others) is *much* more like de facto standards: We require, as
part of standardization, interoperability and operational experience.
we do require that to get to draft standard status. but
since most of our standards never make it past proposed,
it's not required in practice.
and even when we do require running code before standardization, the purpose of
the standard is still to document how things _should_ work, not to describe how
running code does work. if the code doesn't implement the standard, the code
is suspect before the standard is.
None of this is meant to say that the what the IETF does is purely
documentation; certainly we do original work all of the time. But
what we put in standards track RFCs better be, for the most part, a
description of running code, not just rules for how we think running
code should go. The latter are called "Experimental RFCs". They're
different.
no, you have it backwards.
standards-track RFCs describe how things should work (as best we
understand "should"); informational/experimental RFCs can be used to describe
existing practice.
--
Keith Moore http://www.cs.utk.edu/~moore/
27 February 1933 11 September 2001