> 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