Maybe part of the job of a working group should be to both/either produce or approve a reference implementation and/or a test for "interoperability"? I always thought a spec should include an acceptance test. Contracts often do. If a company submits code that becomes reference code for interoperability tests, that code is automatically interoperable and "certified". That might mean more companies would spend money to produce working code. It might mean that more working code gets submitted earlier, as the earliest approved code would tend to become the reference. By code, I don't mean source, necessarily. Then there would be a more objective test for compliance and less dependence on capitalization and the description. ++++++++++++++++++++++++++++++++ Meh. I know the IETF has a thing about these terms, and insofar as they can lead to the use of and/or overreliance on compliance testing rather than interoperability testing, I agree with that sentiment. OTOH, when it comes to actually, you know, writing code, this entire attitude is IMNSHO more than a little precious. Maybe I've missed them, but in my experience our avoidance of these terms has not resulted in the magical creation of a widely available perfect reference implementation that allows me to check interoperability. In fact in a lot of cases when I write code I have absolutely nothing to test against - and this is often true even when I'm implementing a standard that's been around for many years. Ned