Slashdot Mirror
How Are Standards Monitored And Enforced?
Pubman asks: "I suspect virtually everyone appreciates the value of standards, especially the open variety. Where would we be without TCP/IP? At my company, we have been going through a continuous process of defining, implementing and enforcing standards. An associate has posed the following question to me. 'How are standards monitored for compliance?' I would appreciate everyone's thoughts on how standards are monitored and enforced on the Internet, by IETF, ISO, NIST, etc. so we can design a process based upon the published and unpublished experience of others.
Thanks ... "
IMHO, There are 3 ways of standardisation:
1) Interoperability. Test your stuff with other peoples' and make sure it works. If it doesn't, good luck selling it. This is the Internet way.
Sometimes comes out very badly - viz. tons of not-quite-RFC-compliant mail servers...
2) Certification. Certification bodies test your product for compliance with a written standard. Of course, this assumes that such a written standard actually exists... This is the best way for non-upgradable stuff - imagine having to upload new firmware to your cellphone every two weeks.
3) Being Microsoft. Not an option for most non-Microsoft companies. May result in antitrust proceedings.
Any technology which is distinguishable from magic is not sufficiently advanced.
For an internet based standard (i.e. TCP/IP) - you pretty much have to go by cooperation. Since the internet was pretty small when it started (read: DARPANET, etc.) and sort of grew into an agregate of individual networks, it was pretty easy for everyone to comply. Now, if you don't abide by the TCP/IP protocols that just about everyone uses on the net, you don't get on the net :-) It's pretty easy to enforce something that has absolutely no reason not to be used. Otherwise, the best way to figure out the standards on the net are, of course, to read all of the RFC's out there. There really is no "enforcement" of these, per se...but they're used because they're good.
As far as a business is concerned, well that's a whole different bag of tricks. Standards, unfortunately, for any size company are going to have to be monitored by individuals...details would be, of course, different from situation to situation. While this works for small companies, large companies will have to figure out how best to utilize manpower to make sure that what works best is actually being implemented.
The best rule of thumb, as far as i'm concerned, is don't standardize something that no one is going to/want to use....anything is enforceable so long as people say "hey...that's a good idea." but you're going to have a hell of a time if everyone is rebelling.
FluX
After 16 years, MTV has finally completed its deevolution into the shiny things network
"It is seldom that liberty of any kind is lost all at once." -David Hume
The nice thing about standards is that there's so many to choose from...
As one wag once said, standards are good, lets have more of them ....
Standards by Fiat
- flog a new product/protocol, then define it as *THE* standard
Standards by Proclaination
- competitors create me-too "compatible" clones
Standards by Committee
- someone creates a group to knock heads
Standards by Concensus
- define a lowest-common demonomiator subset that people can live with
Standards by Irritation
- result is so grotty that someone is pissed off enough to write a free|open implementation
Standards by stealth
- works so well that everyone else just accepts it
What we need instead is a mechanism to help seek and destroy *bad* standards/interfaces.
LL
While the standard is being developed, release a revision around the office and solicit responses. Some decisions in the standard may be very obvious, but if you've recieved a response from 10 people "demanding" this obvious implimentation, they'll feel that they've "fought hard" to help shape the standard, and will help others to use it. (remember, your goal is achieve buy-in first, then rely on network effects to spread the word).
If I'm handed a 30 page document with instructions that read "Do It", I might be a little put off. But if my opinion is saught throughout the development of that same document, I not only will impliment it's use, but will be proud to help other people use it too.
This leads to the "chapter and verse" quotes that help to keep a standard in place. "Clearly, if you take a look at 'Foo Co. RFC chapter 3 page 4' you'll notice it calls for . . ". these are the kinds of network effects that help to educate people, and help to move your company in the direction you need.
___
From now on i think standard must become more rigid and controlled by someone (like Kerberos). It may suck, but I think that's a small price to pay considering what MS is capable of and any MS-wannabe that may show up after MS's fall. What do you think?
Thank you.
//Frisco
--
"At the end of the journey, all men think that their youth was Arcadia..." -Goethe
$HOME is where the
-- silver_p
Haphazard design?
Fret not. So many standards...
Must comply with one!
One approach is conformance testing. In the USA, this has been done by the National Institute of Standards and Technology, Electronic Data Systems, and other private and government organisations. One problem is that a product can pass the test and also be a bloated, slow and buggy piece of junk.
Mea navis aericumbens anguillis abundat
Generally there is no enforcment for the standards, if you don't follow them you don't get to play in the playground. You won't be interoperable with everyone else. This is the problem with proprietary extensions to these open standards. If some company in a monopolistic position(Names witheld to protect the guilty) were to impliment their own proprietary extension it throws the whole thing out the window. This is why it's the USERS responsibility to make sure that the products they by are from companies who play nicely otherwise they are only hurting themselves by squashing innovation(hmm....)
"as plurdled gabbleblotchits on a lurgid bee" - Prostetnic Vogon Jeltz. (One man's humorous is another mans flamebait)
Not.
Or at least not by an independent group or even a collaboration of various parties or an organization standing up for consumer rights.
Office file formats have become the de facto standard, not any of the well documented open text/data formatting standards. The HTML specifications are not the standard, the way MSIE renders HTML is. MP4 was embraced and extended/altered by Microsoft even before it was a standard.
There are probably even better examples, and non-Microsoft ones as well. They deserve to be bullied but their are a symptom, not the disease. The real disease are the huge companies:
Five years ago there was a lot of rumble about mega-fusions resulting in mega-corporations. I shrugged. Now, I see AOL/Time Warner, Microsoft, Viacom, UPC etcetera and start to get scared, because these big corporations do not only control the standards, they make them.
They have no or little interest in consumer benefits. Money is their primary (only?) motivation. Communism was a good idea in theory, but failed in practice. And perhaps capitalism is being driven too far and this might eventually make an end to it as we know it as well.
Think about it: the UCITA, the whole Napster/Gnutella affair, deCSS, human beings even _considering_ a hyperlink could be copyright infringement..
My apologies for this possible piece of flamebait. But the big buck is already starting to undermine certain principles of the democracy and freedom we enjoy and I am worried it will only get worse and worse.
End of rant..
The current "standards" bodies that supposedly govern the internet are a legacy of government control over the development and direction of the network. Back in the early days of the net it might have worked, but in the fast-changing culture of the net we see today, these dinosaurs are doing little to aid progress, and much to hold it back.
Despite the promise of the much-needed IPv6 it has still failed to materialise apart from on a few private networks run solely for the benefit of the elite few, and even then it is running on top of IPv4. What kind of progress is this? Will we be forced to wait another five years for this very necessary change to the architecture of the net?
No, like every other government "standards" body, those that govern the net - IETF, ICANN and so on - have become ossified to the point of inaction. Do they ever check RFCs any more? Hopefully not since they all seem to be specifications for pigeons, coffee or monkeys on typewriters nowadays, hardly a sound basis for an "information revolution" that looks less and less likely to happen. Red tape, meetings and arguments are the bane of any group, and it looks like those that attempt to control the net are suffering badly from these malaises, to the detriment of all its users, both at home and at work.
A solution? These older bodies need to go, in order for something new to take their place. ICANN is somewhat of a step in the right direction since it is not dominated by the ivory tower academics who prefer to deliberate for long weeks at the taxpayers expense, but rather by corporate interests who, despite their faults, will at least get something done within a time scale where it will be useful.
So standards bodies? Keep them well focused on what they are supposed to do, and don't keep them for any longer than they're required.
Enforced, that is. Not real ones, anyway. The world of computing is littered with dead or undead standards "enforced" by government fiat, corporate white papers, or other forms of "enforcement." The fact is that true standards, like TCP/IP, exist as standards because they work, and it is in the interests of all concerned to comply with them.
If I build a packet of random data and toss it out onto my network, the TCP/IP police won't come and get me for failing to comply with the standards. Similarly, if I connect to an FTP server and start trying to talk to it in english, no jack-booted IETF thugs will show up at my door. On the other hand, my packet will get tossed out as soon as it reaches a router, and the FTP server just isn't going to send me the file I keep asking it for. I comply with the TCP/IP and FTP standards because it is in my interests to do so. Otherwise, things don't work.
Note that this requires a key distinction be made between a standard and a specification. A specification is what passes through the comittee and gets written up in a white paper. A standard is what people actually use. People violate specifications all the time, and the world continues to turn, so long as there is a standard. Most internet standards were standard long before they were specified by the IETF, for example the mapping from port names to services. On the other hand, there is HTML. There is no HTML standard. There are plenty of specifications, of course, but no standard, which is why being a web designer is such a nightmarish job.
From your question, however, I get the impression that a specification, not a standard, is what you are creating. Honestly, the only thing you can do is make sure your specification is so good that it is adopted as a standard, a process which can only take place voluntarily. Quality is the only real determinant of whether a specification becomes a standard, and no amount of enforcement can save a specification that people don't want to follow.
"Never let your sense of morals prevent you from doing what is right" -Salvor Hardin
Standards generally boil down to two kinds. The first kind is usually a legal minimum of quality imposed on manufacturers for civic purposes. Thus we have standards for toys, car safety and food. The second kind of standard is when everyone agrees to work to the same specs. It is this kind of standard that dominates the software industry.
The IETF is perhaps the most influential "bazaar" group of them all. Before Linux, before GNU, there was a bunch of guys who believed in "rough consensus and running code". The IETF makes the standards of how the Internet runs. Basically if it's IETF-approved, it's in.
The irony is that the IETF is as non-enforcing as groups come. It is, in fact, quite anarchic in nature. Anyone may join. Anyone may attend any meetings and generally propose anything they like. If it's good, it will garner consensus. If you have code to show, you're way ahead on points.
The enforcement of IETF standards is not coercive, as you are looking for: it is social. Individual developers, tool companies, software companies, publishers, and software buyers - all of these derive advantage from standards-based software. For any company to break these standards there must be substantial reason - and even then, they will cop a lot of flack.
So if you are looking for a "method" to derive, derive this: Discussion, Design and Disclosure makes a Standard. Discuss the standard widely, give it a solid grounding of design, and disclose your code and detailed designs to everyone.
Just some quick observations to catch the 25-post moderator's theshold :)
be well;
JC.
--
"Don't declare a revolution unless you are prepared to be guillotined." - Anon.
Classical Liberalism: All your base are belong to you.
- When a standard says MUST, then the implementation might
- When a standard says SHOULD, then the implementation will not
- When a standard RECCOMENDS, then the implementer will laugh scornfully
- When there are two possible interpertations of a standard there will be 4 possible implementations, correct for readings 1 and 2, a mad attempt to fit both contraditory meanings and the the old reliable invention of something completely incompatible with both.
The situation is farcical for many standards, they work together but everyones code and documentation is riddled with lines like "do this technically incorrect or unnecessary thing for this broken but important application", A perfect example is the rfc822 mail standard. Read the qmail information on the reality of what shows up in headersYour average programmer is a completely incompetent ego riden madman. A standard is an affront to his cherised belief that he is the best programmer on the planet. How dare someone restrict his options to make a complete mess. So they trample all over the standards, and each program that is broken but not broken enough to fail immediately and catastrophically adds to the standards pollution. Limiting the solution space in which it is possible to create an app that interoperates correctly with everything else.
A proper standard shouldn't be released unless it has a few things which most lack,
- A rationale, Why are decisions made, egoboy is more likely to follow a standard if its reasoning is made clear and the thinking behind various decisions are explicit.
- A big set of tests which the app must pass before it can conform to the standard. Not that that mattered much in the case of rfc822 btw most mail programs wouldn't know what to do with the complex commenting and line folding behaviour.
- A section threatening intense physical suffering for anyone caught trying to subvert it. "By reading this document you hereby agree to a punishment no less than being nailed to a tree for creating any software which almost but not quite matches the standard herein"
- And a sample implementation released.
Thus the md5 and sha1 rfcs are solid as they have tests and an implementation hanging off them. Telnet and mail were doomed for the beginning to always spawn numerous implementations almost correctly work together but always requiring vast amount of under the hood trickery and special case handling.C.
I sometimes write stuff
So tell me, who appreciates closed standards? In other words, proprietary standards? The real power of standards lies in their openness, no?
Everyone knows that standards are regularly ignored and "embraced and extinguished" (to borrow a phrase from the M$ toolkit). So apart from raising a stink about it (e.g., Kerberos), is there any other way to "coerce" adherence to the standards? Specifying "strict" standards will not be useful as it leaves no room for changing the standards in an upward-compatible way. Any other options?
Sreeram.
----------------------------------
Observation is the essence of art.
Sometimes the language of the spec is so general that it can be interpreted many different ways, or is so vague that there can be incompatible implementations of the same portion of the spec. Often, this is the result of "group writing" and a series of compromises. When working through a spec, it's in everyones best interest to avoid putting any language of this kind into the spec.
___
Standards are adopted and used as a baseline simply beacause they work. Good technology gets adopted, not so great technology doesn't, at lease not for the long haul.
Standards by Fiat - flog a new product/protocol, then define it as *THE* standard
e.g. Samba, Word, Audio Compact Disc
Standards by Proclaination - competitors create me-too "compatible" clones
FAT16
Standards by Committee - someone creates a group to knock heads
Jpeg, Ethernet. Tends to have the disadvantage of having a lot of numbers based on 1.5 * 2^n when nobody could decide whether to go for 2^n or 2^(n+1)
Standards by Concensus - define a lowest-common demonomiator subset that people can live with
The X window system
Standards by Irritation - result is so grotty that someone is pissed off enough to write a free|open implementation
Any X toolkit
Standards by stealth - works so well that everyone else just accepts it
A standard that works well? Naah.
1. Find an system that works well, such as kerbos
2. Innovate to add new features to the protocol.
3. Make certain that the inovations ruin interoperability.
4. Call it the same name as the stadardized protocol, kerbos.
5. Hire intern to refresh slashdots web page every 25 seconds and ensure that nobody published the documentation for your innovation into an open standard.
------------------------------------------
If God Droppd Acid, Would he see People???
What are we going to do tonight Brain?
I couldn't agree more!
Look at it this way, the TCP/IP spec is "a way to interoperate". That's why it's called: Transmision Control Protocol/Internet Protocol (TCP/IP) instead of Transmision Control Law/Internet Law (TCL/IL). You can provide as many tools as you want to help people make sure they are compliant, but in the end, it has to be in there own interest to comply, and not be forced upon them.
___
You forgot:
6. Misspell kerberos.
That said, I think it's time I changed my
Then later when I started learning the Internet protocols, I wanted to see the ``recommendations''. But all I could find was ``Requests for Comments''. Once again, I asked to see the _real_ recommendations. And once again, it turned out that there were none.
It seems to me that ``standards'' are just not politically/diplomatically accepted. It's all done by subtle diplomacy. ``Raise a flag and see if anyone salutes it'', as you say in America, or ``fly a kite and see anyone shoots it down'', as we say in Australia.
Nowadays, we have IEEE 754, which says a 32 bit float has 23 bits (plus an implied 1 bit) in the mantissa, 8 in the exponent, and of course the sign bit. Intel, Motorola, Sun, et all followed the standard, which presumably had input from all the major players. The major IC manufacturers caused the compilers and other tools to follow, which generally caused most software to follow the standard, and today the idea of using floats other than IEEE 754 is thought only by developers of very resource limited embedded devices, who typically convert their space-saving floats to the standard when they communicate.
With the recent M$ kerberos slashdot story/hype, I suspect a lot of slashdot folk will complain about monopolies breaking standards, and probably trademarks, patents, and all the other usual slashdot stuff.... cynical and jaded as many slashdotters may be, there are lots of computer related standards that are well followed.
Why follow standards? Nobody enforces standards, except for customers. Customers generally like it when products interoperate, and if a group of competing products interoperate because they all follow a standard, a new product that doesn't generally won't sell.
Now there are lots of de-facto standards, where a single company had enough market share that they could just come up with something and everyone else followed. ISA bus (IBM), PDF (Adobe), and .DOC/.XLS format (Microsoft) come to mind, though there are many others.
Whether a format or de-facto standard, the reason to follow the standard is usually because a product which inter-operates with others has a market advantage over other products that don't. Look at Microsoft Exchange Server and Lotus Domino, which have their own proprietary protocols, but also have to support the standards to be accepted by customers.
PJRC: Electronic Projects, 8051 Microcontroller Tools
Most internet standards today originated from research labs and universities. They were developed by people whose prime aim was to do something well and to create something that would be useful. This should be the underlying spirit when one begins to work on a new standard. Somehow, the fact that these ideas developed in a research environment, where the prime emphasis was on good design, ensured that a good job was done, and also that they were respected by other labs and universities. So they were able to become universal.
I am not suggesting that companies should not develop their own standards. If they are in the poistion to do so, they certainly should---everyone benefits from a good idea. I do believe however, that in any such effort, the spirit should be the one displayed by researchers. I think it is possible to wed the profit motive to good research.
Ulitmately, interoperability can only be ensured through trust and people acting in good faith. Remember the Microsoft versus Netscape feud? It was settled only when the two companies, voluntarily decided to do the right thing.
--Sanatan
They're all different. Sure the actuall "communication" works, but most people claim BSD IP stack as the standard, and others always speak of the Windows IP stack or how linux is just hacked together (which is the reason many people believe freebsd is better, but that is another story).
So how could one claim in this "Standards" war of the new millenium that one group is right over another. Sure Mozilla may be standardized, but hell the linux components are changing every 2 seconds. You can't publish fast and publish early and still maintain a standardized system, chaos is NOT standardization my friend.
Atleast Windows as a product line standardized on the Windows IP stack. A win31 app works on a Windows 2000 stack and that what microsoft has kept. Sure new features have been added, but again, what is considered a standard. Is TCPIP as a whole standardized? Nope. I can't load BSD stack in linux without horkin the internals of the OS and simply just acknowledging tcpip data streams is not standards compliance (as we have all made it aware that microsoft products are not standards compliant because they change or add features).
So tell me my friend. What does standardized mean? Does it mean a bunch of overly paid fat asses sitting around and deciding our future or does it mean the acceptance by a consumer or product group that is widely used and established and commited? Sounds like the sitting around doesn't do jack, yet the people building a stable product such as the BSD stack or the MSIE browser or the Mozilla Browser or the Posix standards actually get work done.
So in slashdot world, conformatiy is standardization, and being unique and innovating is illegal and antitrust.
Isn't this a great time to live?
Well it's worse than that.
They have pointed www.chello.nu ( a page that complains about chello) to www.chello.com.
Not that isn't a really nice thing to do.
It's what we all fear that AOL will do but it's already been done, albeit i smaller scale, but if it begins who knows where it will stop?
It's called new wave but it's just the same.
Hardware standards are much easier to get acceptance for -- who ever heard of someone baking their own hdd, electronics and all, and coming up with a gimpy version of ATA?
JPEG? Sure, but not JPEG2000 -- Unisys redux, much?
MPEG: everyone and their mother has refused to use MPEG and created a competing 'standard'. ASF, RM, AVI (all 10**10 flavors) and whatever comes out *next* week.
Standards are a rat's nest. The only thing that can even try to enforce compatibility is the requirement of strict adherence. HTML will read in most browsers even if it's not perfect. And look what happened to that!
-Grendel Drago
Laws do not persuade just because they threaten. --Seneca
"Truth is what works" Standards are monitored and enforced through usage. Id does not matter what some piece of paper says, it is what works in the context. A bit like language that. The dictionary is sort of a backstop, but new words and new contexts can be added to the language at any time. The will survive iff they are useful and used. As an example, consider what happened when I wrote a perfectly good perl script that did a number of things and then mailed the results using mime in accordance to the published standards. Outlook did not want to understand the enclosure. Netscape, Quickmail, etc. had no problem, but Outlook displayed a pile of base64 garbage. Needless to say, M$ enforced their standard on me, rather than the published standards being enforced on M$. A bit Darwinian, but standards are what works in the context of people trying to use them. This is actually one of the problems with the evil empire. Since they are large enough, they get the chance to define unpublished standards and then enforce them through their actions.
I work for a large telecom company, and we typically sell networks consisting of many products that were developed independently, possibly including 3rd party equipment and/or equipment from companies where we just bought the company out-right.
So, we have the same problem on a smaller scale -- we may have 10 different implementations of the same protocol -- some in firmware, some in (ack) hardware, some in one language, some in another, some off-the-shelf, etc.... (We try to avoid having multiple people doing the same thing, but sometimes it just can't be helped.)
To enforce adherence to the standards: we write that requirement into contracts with third-party vendors; we have testers who pound on the different protocol implementations and generate a lot of negative press when something isn't up to standards; and we do a lot of interoperability testing -- if an implementation isn't doing what it's supposed to do, then the people who did it get a *lot* of heat put upon them to fix it.
The main reason why standard processes go so badly is the whole array of companies who have copyrights and patents and are trying to position themselves to be at a competitive advantage. Without these, there is plenty of motive to comply to common standards and to create rational new ones as the need arrises. You only see the standards problems between closed software and hardware vendors. Communities like the Linux community have a much better agreement about standards.
For some ISO standard programming languages such as Ada and C++ there are validation test suites one can exercise against a compiler to determine whether that compiler conforms to the standard. As far as I know, only the Ada developers demand that a compiler publisher include a certificate of conformance with their compilers. This could be because Ada is targeted at safety-critical software where an accident can kill or maim someone. Or it may be that few C++ compilers could actually pass the validation suite. In either case, when developing software where high reliability is essential, standards do have some virtue. For experimental software and programming for fun, standards can be a nuisance.
I assume that your company uses a modern operating system, but has some legacy components from prior installations as well. And, I'll go even further and assume that you want to remain current with where the rest of the world is going so that your standards are compliant with what others expect to plug into.
Today it seems that standards are pretty much defined Microsoft. The easiest way to be standards compliant across the board is to migrate from legacy systems with their confusing array of standards and protocols to Microsoft systems. MS has put a lot of work into interoperability to make this much easier for you, and as standards continue to evolve and improve you can get the latest updates on line from Microsoft licensed servers. With the most comprehensive kind of licenses, software upgrades occur transparently with no effort required on your part except to have the connections. Microsoft's servers will automatically detect your IP addresses and update your systems without your even being aware that this is happening, except to note with satisfaction that everything "just works better".
Microsoft does not claim to have invented all standards. But MS can proudly claim to have improved and enhanced legacy standards and protocols which have been in wide use, such as the HTML standard and the Kerberos authentication protocol, breathing new life into these standards which were not fully defined in early versions. It is the goal of Microsoft to enhance and extend all such standards, where possible, rather than to introduce more confusion into the situation by introducing a completely foreign standard or protocol into the matrix. Over time, Microsoft intends to shape all protocols and standards to insure the highest desgree of interoperability with the standards Microsoft has defined and patented to prevent these standards from becoming corrupted or abused.
Of course, in today's world of corporate intranets and internet technology, a standards compliant web browser like MSIE is a must have. Your customers and staff will also expect standards compliant internet components from Microsoft because it's very likely that customers and suppliers are already using Microsoft products for creating web sites, browsing and accessing your sites, and transferring data both ways. If your systems are not compliant customers will become dissatisfied and suppliers may charge you extra for maintenance service and tie-ins to legacy components that really should be replaced. Micrsoft offers competetive upgrade discounts in many such situations, especially where a high number of units may be involved. To help make the transition from legacy systems and offbrand standards, Microsoft offers technical training for your staff and 24 hour, seven days a week online technical support.
It's better to be safe than sorry, and there is really little risk to you in licensing the latest, most innovative technology from Microsoft because MS has a proven committment to keep on innovating and keeping you current. And, if you do not have the very latest standards-setting technology from Microsoft, it is very likely that your company will be unable to interoperate with the rest of the IT world.
Consider, for a moment, language standards, as defined by a body such as ISO. One of my current tasks is to develop a C++ application that is platform-independent. Do I then write my code to the ISO C++ Standard? Certainly not. No compiler, on any platform, fully implements the ISO C++ Standard; most implementations (Microsoft's being a particular example) fall significantly short of the Standard. So I analyze several compilers on various platforms, developing code based on a common subset of the standard. In other words, the "real" standard is what I can accomplish in the "real" world, and not what ISO has written in their document. Some standards are more concrete than others, and the validity of a Standard is largely based on practice and not theory. I would put TCP/IP at the "hard" end of the standard spectrum, and C++ at the "soft" end. If I don't implement TCP/IP completely, I can't talk to the net; if my C++ compiler lacks certain features, I can usually live without them. Perhaps it has much to do with complexity: The C++ Standard is a 778-page monstrosity birthed by an ugly committee process, while TCP is the result of long-time practice in a focused task.
All about me
If you do commit it to memory, make sure to spell 'riden' correctly.
In some cases, the standards become, in effect, a government regulation. Standards describing air bags and seat belts for automobiles may start out as voluntary ISO (or in the old days ANSI) standards and end up enacted into legislation or into a regulation.
In some cases, large purchasers, like governments, require complaince to some standard in order to bid for government contracts. POSIX, for example, is a US government purchasing requirement in some cases. Companies obey the standard because it's cheaper than having one product line for governments and other big contractors and another for everybody else.
In other cases, like TCP/IP, the standard is self-enforcing. There's no law to stop somebody from writing their own TCP/IP variant, but if it isn't compliant with the standard, it probably won't work on the 'Net.
This is the kind of thing companies love. Early on, they can try to twist the standard by putting out their own, incompatible variant and then locking their customers into it. Microsoft is famous for this manoevre, and HTML is good example of a standard that ought to be just as self-enforcing as TCP/IP but isn't because of vendor intransigeance.
What makes standards work is that they tend to be safe choices, not enforced ones. There are a number of standards for the manufacture of, for example, luggage. No law prevents luggage manufacturers from making luggage with dimensions and properties that don't comply with the standard, but then they'll find that their luggage doesn't fit into aircraft luggage bins (which are also described in a standard designed to be compatible with the standards for luggage) and don't fit into standard sized cardboard boxes (which makes them more expensive to ship.) So, the luggage company sticks to the standard, because it's safe.
Now, standards like ISO 9000 and ISO 14000 aren't manditory in law, but many people require, or at least consider, ISO compliance in purchasing. For those standards, there are national certification bodies that let companies say they are ISO 9000 or 14000 compliant if they can verify that they meet certain conditions. But most standards don't work that way and don't come with certification.
Dr. Metcalfe (inventor of Ethernet and founder of 3COM) just had an InfoWorld column on this subject. He mentions two poles of the standards process: (1) market aggression by single source, e.g. MicroSoft or IBM and (2) a bureaucratic committee representing a broad number of clients, often attached to a professional society or government agency. Although both of these kinds have had successes, there have also been a lot of failures. Bob's preferred third way is for an organization to develop innovative technology and license it fairly openly- to everybody and inexpensively. AT&T UNIX, Sun NSF are examples.
(Please don't nitpick my examples, and these companies, which have tried all three kinds of standards.)
Despite all of its flaws, the InterNet burst from its cocoon in the early 90s to become a trillion dollar enterprise in less than a decade. This was partly due to some open, simple, and flawed standards such as TC/IP and http/html. There were a lot of false starts along the way such as the IEEE seven layer network protocols, IBM token networks, AOL/MSN/prodigy dial-up bboards, and so on.
At least in the real (i.e. not software) world, standards are enforced by people who buy products based on the standards. I work at one of the places mentioned in this post measuring devices for conformance with standards, but I certainly don't "enforce" them. The companies that make the devices present a copy of their certificate of conformance to potential buyers, who then use that in their purchasing decision.
The other thing we do, of course, is settle disagreements between users and producers. The users say "[producer's] widget doesn't work" and send it to us. We check it out (for a price) and tell them whether or not it conforms to relevant standards. They then have a basis to complain to the producer, if it doesn't conform.
User complaints, interoperability testing, compliance testing, conscientious developers (aka "standards weenies"), and validation utilities can all help enforce standards to some degree. But ultimately it's the most widely deployed software that determines the standards. If the most widely deployed software accepts non-compliant syntax without complaint, that almost guarantees that non-compliant software will eventually be deployed (usually because of developer ignorance or a simple bug). So if you're creating a new standard and don't want it to creep away from the spec in practice, release a quality open-source implementation which complains about every spec violation you can imagine. Also make sure your spec never says or implies "implementation defined" unless you're sure it can't be abused.
Actually, the group that creates the standards aren't really allowed to enforce them. In fact,
standards groups are really only allowed as an exception to the anti-trust/collusion laws that
exist in many countries (including the US).
The basic idea is that several companies can't get together and create an interoperability standard
unless they provide a level playing field to all potential players in that standard's field. To
comply with these provisions, almost all standards organizations provide open membership, not because
they want to, but because the have to to get around the legal restrictions of creating standards.
The same laws the prevent collusion in creating the standards also prevent the standards body
from any enforcement ability. This leaves the standards body with only a few options to protect
the integrity of a standard: copyright and independent certification organizations.
Copyright is the big one, you can't publish your modified standard including the original, although
you can reference it (fair use), people will always know about the original unmodified work.
Independent certification organizations (such as UL or BSI as large examples), provide the main
enforcement of standards by the value of their service marks. Note there are several competing
standards organizations operating off the same data (the published standard's specs) so this
avoids most of the anti-trust concerns.
Anti-trust principles are the main driving force behind breaking up MSFT. Just being a monopoly
isn't actually illegal. Believe it or not these rules were mostly put in place during the
formulation of gasoline. Imagine several oil companies wanting to supply gasoline for cars
and several car companies wanting to make cars that could use the cheapest/most available gas.
Instead of everyone getting together and coming up with a standard gasoline formulation, several
companies (standard oil being the biggy) just made their own proprietary standard and since they
were vertically integrated (own both refineries and gas-stations) and were the largest, they sort
of dictated the standard w/o any of the other oil company's input. Some of the anti-trust laws in
the US are directly a result of breaking up standard oil and trying to make sure something
like that never happen again...
This is old stuff, time to get off that computer and dust off a history book or two. The people
who came up with these laws were pretty clever and anticipated all sorts of things and designed
very clever laws to prevent problems...
There is a good reason why people are allowed to extend a standard w/o recourse: innovation.
Color TV, closed captioning, metric/english wrenches, call waiting, etc... were all originally
proprietary standards extensions.... (yes there are acutally ANSI/ISO standards for wrenches)
The main problem with standards is that the groups the create them are often only chartered to
"codify existing practice". The ANSI-C group for example, went way beyond their original charter.
However most are just "least common denominator" and extension is often desirable to create a
reasonable product.
If we are however talking about standards compliance, the right answer is to get on the
independent certification organizations (like UL, BSI, good housekeeping???) or maybe work to create
one specifically for the computer protocol industry (ala X/Open). I suspect that this would
make an excellent tax-exempt non-profit organization that would get heavy donations from
many of the large fortune 500 companies...
I'm making this post at the risk of having it moderated to "repetitive" but no one seems to have explicitly addressed this before.
;)
Personally, I think the idea of "enforcing" a standard is a strange way to bring up the issue of overall standard conformance / nonconformance. Either something conforms to a standard or it does not. However, this line is (usually) not a clear one, as there almost always exists *some* ambiguity in the way someone describes, understands, or implements a standard. Personally, I found the use of term "enforcement" a bit confusing, but I'm not sure that I have a better word for it either.
But, before you even try to ask the question "does product X comply with standard Y" I think one needs to define which sort of compliance / conformity you are addressing. I believe that there are two kinds of compliance. First, there is the compliance to the standard as it is on paper (if there is one!). Second, there is the compliance to the *implicit* standard that evolves from the majority of implementatations of that standard. These can often be very different; and when tyring to ask the question "Does our product/system conform?", one must first address the question of "to what?"
For instance, suppose Standard Y on paper says nothing about the implementation of Feature Z. Yet, suppose a significant majority of products out there support Feature Z. Then, I would consider the paper standard simply "Standard Y", but in some ways, there is an implicit standard that consists of "Standard Y + Feature Z." (Simply because it's out there.) I do *not* mean to imply that this is a Good or Bad Thing (that's a *whole* 'nother can of worms). I simply want to illustrate that standard "conformance" may mean building a system that complies to an implicit, evolved standard, as opposed to a standard by committee.
I think you're mistaking the implementation of individual TCP/IP components with the standard itself. I usually think of TCP/IP as communcations protocol which provides a standard means of passing information between computers. There are many implementations of this protocol and that seems to bother you.
Now about some of the outrageous statements you made:
I'll bet that a lot of those that say the BSD stack is the standard are old BSD bigots. I've recently heard that the Linux TCP/IP implementation was the one that most closely adhered to the actual standard.
Well, that's certainly a less-than-widely-touted technical achievement. (He says, his voice dripping with sarcasm.) I wonder why I haven't seen a Bill Gates TV commercial explaining why this compatibility is such an important innovation.
Does this mean that MS is moving to de-commoditize TCP/IP now?
I believe that the answer to the first part if the above quotation is: YES. As to the second part: Methinks you need to actually do a little research into what a standards group actually does and, what a standard even is before making a ludicrous comment like this! Using the same logic, I should be able to say that Multinet for VMS (does that even exist any more?) must be an inferior product since I can't load it on an AS/400 without doing some serious hacking of OS/400. You seem to think that something written for one operating system should run on another without change.
FYI: There are a number of Microsoft representatives (``fat asses'' as you call 'em) attending standard bodies meetings as well. Microsoft just seems to do whatever the hell they want to do anyway regardless of what gets decided in those meetings. And, BTW, the Posix standards were arrived at by a whole slew of those so-called ``fat asses'' from industry and IEEE. I used to work with another engineer (years ago) who was on the ANSI FORTRAN working group. He was just a regular guy and wasn't overly paid (and I didn't pay much attention to his backside). When you say ``overly paid fat asses sitting around and deciding our future'' are you referring to people like the denizens of the boardrooms in Redmond, WA?
My dictionary contains the following:
So, yes, ``conformatiy'' (sic) is part of following a standard.
OK. Now we know who your preferred software vendor is.
(My apologies to Random House for quoting from their dictionary. This seems like `fair use', though.)
--
CUR ALLOC 20195.....5804M
This concept doesn't go over well in a geek community like /. where people have pathological fear of authority, but the way the real world works is that authority doesn't really exist. The question presumes the existance of an authority capable of monitoring/enforcing standards compliance. Such authority doesn't exist (except in small domains).
Thus, you are free to implement something like TCP/IP in any way you like. The only problem is that if you want to actually communicate on the Internet, you should probably follow the spec.
In other words, ultimate you must monitor your own compliance.
This issue is important because lots of peole try to use standards bodies in order to pursue political agendas. People have the mistaken impression that if an official organization like the ISO puts their stamp of approval on something, then everyone must adopt it. You can look at the failed ISO/OSI protocol suite for an example of where this failed: they created a standard for something that nobody wanted to implement, and thus the standard failed. The authority is powerless to coerce its members to follow its guidelines.
Another example is the word "hacker" vs. "cracker". Many geeks have the mistaken impression that a dictionary has authoritative powers; it doesn't. Instead, it is a coorperative effort. The dictionary writers attempt to monitor how words are used and understood, then write that information down in a book. When people hear a word they don't understand, they read the book in the hopes of discovering what the speaker meant. Conversely, if somebody is using a word "incorrectly", the dictionary will tell them why people are misunderstanding what the speaker is saying. In other words, the dictionary doesn't tell the speaker that they are wrong; only that their audience understands something different than what they intend to convey. If the speaker doesn't care about being understood, then they can use any meaning they want.
Coercion to follow standards that people ultimately don't want to follow always leads to failure. For example, trying to coerce the non-technical crowd to adopt the word "cracker" or "wormer" are doomed.
As noted in the XMLHack piece, conformance is typically monitored by external organizations like The Web Standards Project, or XML.COM.
MS has been extremely effective with their logo certification program. My prior employer would jump through any hoop, do anything at all without regard to process, resources, etc. in order to get the MS logo compliance. I almost wish that IETF or W3C would try such heavy handed stuff.
In the case of IETF standards (which there really aren't any.. just rfc's...)...
the only enforcement is interoperability.
If you don't do it the right way.. it won't work.
IF you break interoperability with someone else, and they do it by the book, and you don't.. you look bad, not them. Nothing 'forces' you to do it though.
Better be careful. That might not be covered under copyright law, especially the way things are going.
-=Canar=-
Simple. If you don't conform to basic standards, you don't get to talk to anybody else. Unless you're Microsoft, and consequently only need to talk to yourself anyway. In that case, it really does not matter. ;)
Mmmmmmm. Floor pie!
The fine folks at Jakarta (the Apache-related server-side Java group) have a product called Watchdog that is an automated test library to verify conformance with the Java Servlet and JSP specs.
Watchdog doesn't define compliance; only the spec does that. But I understand that Watchdog is a great way to check an implementation. At JavaOne today, the Tomcat developers say that they regularly run Watchdog against their implementations to make sure that they don't break anything.
The computing industry has no such system of absolute conformance. This is because the government has to get involved to enforce such a thing. Standards for computing have been around a long time relative to the industry's age (check the date for ASCII if you don't believe me), but still there is no way to enforce compliance to a standard. This is mostly because there simply isn't an easy way to classify the products being sold and to determine whether they should be standards compliant or not. The Government would have to be involved, and would have to enact legislation requiring products to be standards compliant before they could be sold to the public, much in the same way that construction is so regulated. Until computers are seen as life-threatening and as life-preserving and as essential to modern human existence as buildings are, this isn't going to happen.
OTOH, there are perfectly good reasons why the computing industry shouldn't have enforced standards. Innovation in engineering and construction doesn't proceed as rapidly as it does in computing. A standards organization charged with reviewing the state of the art in plumbing can barely keep up with the workload it is presented with; it's absolutely unreasonable to imagine a standards organization reviewing the state of the art in computing. Also, engineering and construction have been around for two thousand years or more -- most of the major concepts have been worked out already and are well known. In computing, which has only been around fifty years or so (at least in its current form), the grounding concepts are still being debated in academia and the reasearch communities. We still aren't totally sure how to describe a programming language -- how can we determine whether a given implementation of a language complies with the standard? Debates still rage about the vagaries of user interfaces, and the underlying concept of a user interface is terribly hard to pin down (Just try thinking about that -- what exactly is a user interface? What makes a user interface good?), so it's absolutely impossible to enforce user interface design. Also, remember that standards don't get updated but about once every five years or so, and any legislation regarding standards usually doesn't change without major political action. Imagine having a standards enforcement representative (read `code police') reading your code. Not a happy idea.
IMHO there should be some level of enforcement requiring compliance to a standard if such compliance is going to be an integral, advertised part of the product. Thus, if Web Browser v23 claims to comply with HTML 5.0 then it has to abide by every last little requirement of the HTML 5.0 standard. Extensions are always possible, but advertising that Web Browser v23 complies with HTML 5.0 when it actually doesn't can result in legal action by the standards body, possibly causing that product to be pulled from the shelves until it either complies with the standard or is replaced by one that makes no such claim.
I'd really like to see such a system enforced for the hardware manufacturers. IIRC there's no reason that some random motherboard manufacturer can't claim that their new board has PCI support even if it only implements a broken subset of the actual PCI standard. The existence of this glib attitude towards hardware standards is probably due to the fact that most IA32 machines are still based around the `industry standard' IBM PC design, which being an `industry standard' was never really a formal, enforceable standard. Nowadays nearly all the parts of an IA32-based PC are standardized in one form or another, but even today major manufacturers sell machines with broken implementations and gratuitously incompatible hardware. If they were regulated by a standards requirement of some form then this sort of thing would happen much less often (I won't say it wouldn't happen at all).
So, computing standards aren't grown up. They haven't reached the stage where they are enforceable by legislated authorities. Someday they probably will be, but only if the end users want such a thing. If the end users don't complain enough the Big Money in corporate hands will keep such a thing from ever happening. The situation is very similar to that of automobiles in the 1970s -- until Ralph Nader and friends started making ugly noise with class-action lawsuits and large, expensive legal cases, the manufacturers blithely ignored their end users, often with horrible results.