craig@bbn.com (Craig Partridge) (03/27/89)
> Reply-To: jms@mis.arizona.edu (Joel M. Snyder) > Organization: U of Arizona MIS Dep't > > ... But the requirements > for commercial systems, and interworking between national networks, commercial > networks, and research systems, mean that expansion upon RFC 791 > is really required. I realize this statement was an intro to a particular criticism but I'd like to discuss the philosophy itself. It is not uncommon to hear people say that "if you want to do real networking, you need more features" and I think that's the wrong approach. I believe, on principle, that more options means less interoperability. People tend to implement only those subsets they need. Since different people want different subsets, the community either finds that not all implementations interoperate, or that they only interoperate at their least common denominator (i.e. most of the optional features are lost). Since interoperability is the primary goal, why not look instead for ways to make the simpler protocols do everthing you want? A couple of examples to support my point: - OSI supports a lot of options. But in the end, what is happening is different countries are developing their own profiles, which chose particular subsets of OSI that they deem useful. There's a very real chance that those profiles won't interoperate. - The Internet Host Requirements working group is in the final stages of defining what could be considered an Internet host profile (along with glosses to repair errors or ambiguities in various specifications). One of the things the group is doing is decommissioning some protocol features that few or no people implemented. In other words, we are yielding (in some cases) to something close to the least common denominator. With experience like this, I'd argue that options are too often a cop-out, not an answer. Craig