Standards fun

Today, I sat through an unusual meeting of the IEEE P1619.3 group, the people that are supposed to be developing a useful standard for key management. This group has been deadlocked for a while over the issue of what type of transport mechanism to use for communications between a key server and a client. Some people want a heavy but full-featured way to do this, like WS-Management or SOAP. Others want a bare-bones, low-level way like a fixed binary format or a TLV format like a suitably-encoded ASN.1 structure. Others want something between these two extremes.

The group has been unable to decide on which format or formats to adopt. This impasse seemed a bit unusual for a standards group that's trying to quickly define a reasonable standard for which there is considerable demand, and it certainly looked like the group was starting to focus more on discussing procedural issues than in the actual content of a standard for key management. Today it got even odder.

The source of the unexpected weirdness was a motion introduced to have the entire P1619 group vote on whether or not to require a single (unspecified) transport mechanism and allow others to be optional. If this doesn't pass, then it looks like vendors will be able to implement any one of a several possible choices and still claim to be compliant with the standard even there'll be absolutely no guarantee of interoperability at all.

After all, if you can't count on all compliant implementations to have a common way to communicate, you really can't guarantee any level of interoperability, can you? We might as well vote on whether or not the standard should actually be useful once it's completed. Is there really any need for a standard that doesn't guarantee some minimal level of interoperability?