On Wednesday, September 28, 2005 04:16:58 PM -0400 Keith Moore
<moore(_at_)cs(_dot_)utk(_dot_)edu> wrote:
Specifically, when I first became associated with you all in 1992, the
RFCs of most IETF standards were incomplete and the reference
implementations (i.e., running code) were what was considered to be
normative.
I've been involved with IETF since circa 1990 and have always been of
the impression that standards-track RFCs - not implementations - were
intended to be normative. Frankly I don't see how it could be any
other way. While a discrepancy between an implementation and a
specification _might_ be due to a flaw in the specification, it is at
least as likely to be due to a flaw in the implementation - and the
specification is the primary definition of the protocol, whereas any
particular implementation is merely an artifact. Also, every single
attempt I have seen to try to derive a normative specification of a
protocol from an implementation has produced a document which failed to
adequately specify the protocol.
As far as IETF is concerned, running code should be seen as a
proof-of-concept and a test vehicle, not as primary source material.
Absolutely. Some protocols do have a de-facto reference implementation,
but that's just something to test against; it doesn't override the spec.
However, in the real world, it would be foolish for an implementor _not_ to
do interoperability testing against other well-known implementations, and
to at least consider fixing any problems that are found. Sometimes, that
means being prepared to accept behavior not permitted by the spec.
Similarly, any IETF effort to update or extend a protocol should take into
account behavior of deployed implementations, even if they are
non-compliant. The goal here is to build and maintain a working, stable,
interoperable Internet, not to be protocol lawyers.
-- Jeff
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf