The following text is copyright 2000 by Network World, permission is hearby given for reproduction, as long as attribution is given and this notice is included.

Over specification?

By Scott Bradner

Standards are good things. Standards are good for customers and good for vendors. They are good for customers because they ensure that there are compatible alternative products. They are good for vendors because they can significantly increase the market for a technology. But there can be too much of a good thing.

There has certainly been a problem with some vendors deciding to "embrace and extend," in the words of one, standards in a way that negates any reasonable standards process but some of that can be fought in the market place. A more systemic problem is that standards organizations have a tendency to produce standards that over specify in ways that may reduce the ability for the market to develop innovations that can differentiate products yet still interoperate.

A few years ago I, with a bunch of help from discussions on the IETF mailing list, put together an IETF document that tries to give some guidance about when to mandate features in standards. This document (RFC 2119 www.ietf.org/rfc/rfc2119.txt) ostensibly defines some key words for use in standards documents such as MUST, MAY and MUST NOT. But a key part of the RFC is a paragraph of guidance in the use of the specific terms:

"Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm. (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementers where the method is not required for interoperability."

This guidance came to mind yesterday when I took a look at a new TIA/EIA interim standard on "Performance and Interoperability Requirements for Voice-over-IP (VoIP) Feature Telephones." (www.tiaonline.org/standards/ip/)

This is a very well done document. It does an excellent job of how VoIP phones need to work. And it does so for three different types of VoIP technologies: the ITU's H.323, the IETF's SIP and megaco/H.248 which is the product of a joint IETF/ITU effort. But I think it goes a little too far.

The document has a table (table 5.2) which is an overview of telephony features. It has a list of 23 features and sub features, each with a requirement level. These range from the "mandatory" ability to originate and accept calls to the "recommended" ability to encrypt calls. But I see too many features that are labeled mandatory which are not needed for interoperability. I see no interoperability or harm-avoiding reason to mandate a message waiting indicator for example.

To steal from Einstein, standards should be as complete as they need to be and no more complete. Going over the fuzzy line is counterproductive and will ensure less innovate products.

disclaimer: Harvard, like any good university, ensures that lines are rarely sharp, but the above worry is my own.