Interestingly, Transpac, the French X.25/Minitel network (by then the
largest data network in the world, so acting as a kind of reference)
"published" a test machine (probably around 1982?) everyone could use
to verify his conformance to the (stringent) network requirments. At
the Den Hague ISIS Club (1984?) the Dutch PTTs proposed to extend
that pratice to the whole International Network, standardising the
running test program concept (for OSI, DECNET, IBM/SNA, Swift, Sita,
etc.. then supported protocols). . This was further discussed within
the CEPT (European Public Operators Club) for OSI services, but I did
not heard of any decision or CCITT (ITU-T) proposition. This kind of
standardisation by the "running test" was a standard question when
discussing a new root name interconect. But I do not think it was
used by any other OSI operators ?
The concept is however appealing: to add a test running code to an
RFC, as a way to document, check and enforce its standard?
jfc
At 00:05 29/09/2005, Keith Moore wrote:
> 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf