[
Lists Home |
Date Index |
Thread Index
]
I like #2 as well, but I suspect it fosters all sorts of interoperability issues. It is fine to say that an implementation can ignore extensions beyond the core spec and both the extended and the base implementation are compliant, but it leads to confusion in the marketplace, I think, because one man's extension is another man's requirement.
I can recall, from many moons ago, working on a bisync implementation and having to accommodate any obscure flavor or extension of the protocol that my customers wanted because to them, that extension WAS a part of the protocol. You can tell a customer that it is non-standard, but the bottom line is, they really don't care if they have been using it and getting value out of it. That value, by the way, was often very obscure, and could generally be gotten more efficiently out of the standard itself, if the vendor had only understood it. The marketplace is not a perfect judge of the quality of a mutation (although it is likely the best judge we have). Of course, this problem often exists even where there is a governing standards committee but I suspect your second approach makes it even worse. I kind of like the definition of levels of compliance within a standard a little better- at least you know a priori what you are dealing with.
|
