What's a standard?

By: Scott Bradner

A while back I chaired a committee on the future of email at Harvard. We discussed many options for providing as near to ubiquitous service as could be imagined. These options ranged from one monolithic email system to tying the many LAN-based systems together with some sort of common backbone transport protocol. One of the members of that committee kept insisting that the University should mandate a "standards-based" solution. By this he meant that the backbone should use the OSI email protocol X.400 instead of the TCP/IP email protocol SMTP. To him, TCP/IP was not a standard because it had never been approved by a formally constituted standards body. Since X.400 is the product of just such an organization, he reasoned that it must be better and would be a proper solution to our problems for a longer period of time than would SMTP.

Some of you might think that this is a rare view point. It may indeed be rare in the predominately TCP/IP community in most educational and research sites, but it is far from rare the higher one goes in the corporate structure.

In reality (going by what exists and is in use) there are three types of standards for the protocols used on data networks: vendor defined standards, such as DEC's DECnet, Novell's IPX and Apple Computer's AppleTalk; standards promulgated by national or international standards organizations, such as the OSI Connectionless Oriented Protocol (CLNP); and standards created by groups of interested users and implementors.

There is little question that a vendor can define a standard for a proprietary protocol that they have created and use in their own products. If you want something to work with that vendor's products you dang well better implement it following their documentation.

There is no question that a formal body like the International Standards Organization (ISO) or the Institute of Electrical and Electronic Engineers (IEEE) can define a standard, in may cases that is their raison d'etre.

But somehow there seems to be some question of an ad-hoc grouping of network theoreticians, applications programmers and network managers doing the same even though what they come up with works and is in use.

The documents (I call them standards) that define the format and operation of the very large suite of TCP/IP protocols and applications are known as Request For Comments (RFCs). RFCs can be "standards track" or informational. Informational RFCs are just that, for information; they do not define any type of approved-by-the-community standard. Some of the other RFCs have been adopted as standards. Don't let some vendors fool you. Just because some document has an RFC number it may only be an informational RFC or a proposed, but not approved, standard. The actual status of the RFCs is included in another RFC.

In order to become a standard, the protocol or application described in an RFC must have been shown to be implementable and have two or more interoperable implementations. In addition there must be a general consensus in the community that this approach to some problem is a "good" one and that the document adequately and accurately describes the solution.

This to me is a higher barrier to becoming a standard than is required by, for example, ISO. It gotta work before its given an OK.

In a way it is a bit more than silly that there is even a question of the legitimacy of considering TCP/IP a standard protocol. There are millions computers "out there" that can fully interoperate over TCP/IP. What better existence proof could one have of a set of standards than to find that hundreds of independent implementers have been able to create such a high level of compatibility.

PS - If it's organization that you need to make you feel better, "it's in there". I'll say more about that another time.

PPS- If you want to know what the email committee did recommend, you can get a copy of the report via anonymous FTP from ndtl.harvard.edu in pub/email.

sob@harvard.edu