Keith,
I resonate with your points except that the earliest IETF standards
(i.e., IP itself, TCP itself, others) were incompletely specified by
RFCs. Therefore, interoperable implementations could only occur with
reference to the reference implementations.
I don't know what reference implementations you are talking about. The
ARPAnet was quite diverse in terms of host architectures and operating
systems, and at least for the protocols whose early implementations I
have seen, high-level languages were rarely used. Which platform's
implementation would serve as a reference?
Nor do I believe your conclusion follows. In particular, the "be
conservative in what you send, be liberal in what you accept" rule
would allow for some degree of interoperability even in the case of
incomplete specifications. Of course, just as today, when people found
that their implementations wouldn't interoperate, they'd try to fix
them.
However, the actual motivation for my query is the following: the IETF
didn't accept the existence of middleboxes until 2000 - 2002. Thus, I am
trying to convince a middlebox implementor that they misunderstood a
standards track RFC originally written in 1995 and re-published in 1998.
That RFC said "hosts do X" and other devices (which in that era meant
routers) do Y. They do Y because they are not hosts -- rather than
correctly behaving as middleboxes are supposed to do.
Most protocols weren't designed to operate with middleboxes. In the
absence of a provision in a protocol specification for a middlebox,
any middlebox that interferes with interoperation of a protocol is
inherently violating the protocol standards.
In general, protocol specifications don't (and shouldn't) try to
explicitly enumerate "don't do X" for every possible "X" that is
harmful. And middleboxes are generally harmful.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf