The Robustness Principle Reconsidered (CACM)

if you do so, then it's not a direct security risk.

the only security 'risk' here is that by not rejecting slightly malformed data that you could safely accept, you won't reject connections from faulty programs (or people pretending to be programs). This isn't in itself a problem, but it means that you may not get advance notice that people are sending you 'odd' things.

The cost is incurred in those trying to obey the robustness principle. Those who assume that a reserved field can be used for their own principle aren't obeying it, but they're passing the likelihood of failure onto the people that obey it. As Eric says, reserved fields have been reused for proprietary vendors' own purposes, usually to exclude other implementations that don't make the assumptions (i.e. are more liberal) about that field's meaning. This is not the fault of the robustness principle per se, it's ultimately the fault of the abuser of the standard, even if they want to then hide behind it and say 'well, the standard doesn't say what that reserved field is for'.

Ultimately the process of setting these protocol standards and their implementation has to take place in the open. Trying to bastardise the standard for corporate gain may work in the short term but - crucially - it doesn't invalidate the original standard or the other implementations. Sometimes these abusive implementations gain some traction but rarely because of their changes to the standard per se - usually more because it's a large company foisting their adgerware on everyone else. The implementations that survive, ultimately, are the ones that are flexible and obey the robustness principle.

Have fun,

Paul

The correct thing to do is to develop a test suite. The specification exists to tell developers what direction to head in, but there should be a real "does it actually work the way we intended or doesn't it" test case that can be applied to any implementation.

In the real world, test cases are what the actual developers and engineers use. "Does it load in IE." "Does it boot Windows." "Does it play sound from the iPod." The difference is that these would-be tests are unofficial and may contain non-conforming behavior which then become de facto standards of their own. Not least of all because there were no official tests for those devices, so they all got developed by testing on random bits of existing software/hardware that were popular at the time.

An API or a hardware interface needs to have extensive and exhaustive implementations of both sides of the interface available to implementors. Anything else is just going to result in the mess that pretty much every well-known standard has gotten itself in.

It's worth noting then that the "Robustness Principle" kind of changes meaning. You should absolutely _not_ be liberal in what you accept; you should be conservative and accept only what the test suite forces you to accept. That test suite however should be testing to ensure that fields reserved for future use are ignored or passed through as desired.

Free-software people and hobbyists usually follow standards very well voluntarily because it feels good to solve a problem correctly once and for all. You can not rely on this in a commercial setting, so standards need to be written with market pressures taken into account. The extra work and money required to meet the standard completely compared to just working today needs to be minimized, to zero preferably.

Ready-to-use free test suites and reference implementations can be extremely helpful in that regard. IIRC the USB standard had an interesting approach, where you are not allowed to carry the logo unless your hardware can pass the test suite. This creates another commercial incentive to meet the spec.

We had such an implementation. It was ultra-strict in what it would accept. It uncovered a large number of issues with everybody's implementations (including the reference) and a few problems with the spec itself.