* The potentially unacceptable length associated with the standards process
This is the fourth in a series of newsletters devoted to the standards process. This newsletter will discuss the potentially unacceptable length associated with the standards process.
The previous newsletter mentioned that Jim participated on an ECMA (European Computer Manufacturers Association) committee that was chartered with developing ISDN standards. These meetings would typically run from about nine in the morning to at least eight in the evening and would run for several days at a time. During one of these meetings a heated half-hour debate broke out about whether or not the committee was using the proper format for footnotes. While such debates were not common, this debate does serve to exemplify how slow and painstaking the standards process can be.
To get an understanding of just how painstaking the standards process can be, it is insightful to Google the phrase Internet Standard. What comes back is: An Internet Standard is a special Request for Comments (RFC) or set of RFCs. An RFC that is to become a Standard or part of a Standard begins as an Internet Draft, and is later (usually after several revisions) accepted and published by the RFC Editor as a RFC and labeled a Proposed Standard. Later, an RFC is labeled a Draft Standard, and finally a Standard. Collectively, these stages are known as the standards track, and are defined in RFC 2026. The label Historic (sic) is applied to deprecated standards-track documents or obsolete RFCs that were published before the standards track was established.
We are not trying to be unduly critical of the standards process. It is clearly important that ideas get vetted and that there is time for a wide-ranging discussion. It is in all of our best interests that the standards committees take the time to get it right. That being said, the next newsletter will look at the impact of the lengthy standards process on enterprise IT organizations.
In the meantime, we want to hear from you. We all know that standards are important. However, how important are proprietary extensions to standards? How long into the standards process is it before there actually is a working standard that enables interoperability? Do you choose one vendor over another based on their support for standards?
