A lot of software in the "Enterprise Systems" market now make claims like "utilizes" or "leverages" "standards." "Industry-wide standards." "Open standards." "Standards compliant." It's "based on a standard" (← by far my favorite one – "based on open standards" –
really
WTF?). It's become a buzzword – "standards" – and has lost what it really was. A "standard" is an agreement to do things a certain way. They exist so client system
A can work with server system
B and server system
C in just the same way client system
X can work with server systems
B and
C. That's it. They're not magic. Some standards are company standards. They're developed internally to be used by multiple products within their company. Microsoft's NTLM protocol for authentication is such a thing. Other standards are developed by multiple companies (like an IBM-MS-Sun meeting) that all get together and decide to whip up a standard to do something. Some standards are done out in the open. Some behind close doors. Some have documentation. Some don't. Some just sit on a server at Harvard languishing. When people say "open standards," they are usually referring to standards that are done out in the open, open to participation by anyone, and controlled by a so-called "Standards Organization" like
OASIS,
IETF, or
eduCause. What those organizations provide is a set of rules, a framework for participation, a framework for making revisions to standards, oversight, and some basic legal nicities. Again, nothing magical. Nothing scary. It's all simple and straight-forward. The best use for a standard is trying to figure out when something is wrong. If you have client
A and it isn't working with server
B, what do you do? Well, you look at what they're doing and figure out that client
A is sending something to server
B and is expecting something of
this sort back; but server
B is sending something like
this back. (Go signup and lurk on the
atom-protocol mailing list or
RSS-Public mailing list to get overwhelmed by what this actually entails.) So then you go to the standard and figure out which one is misbehaving. Then, you yell at the people who designed the misbehaving system; you call them a
moron; and you tell them that they aren't spec compliant. Or maybe you don't figure out which one is misbehaving because the spec is unclear. In that case... well, if the creators/maintainers of the standard have an open working group you can participate in, you can bring it to their attention, and they can make a revision to the spec clarifying it. If the spec doesn't have a group to work with, I would strongly (and I can't stress the
strongly part strongly enough) suggest that you just abandon that technology altogether. Trust me on this one... just abandon it. That spec has already wasted enough people's time
1. Just move on. If you don't know what I am talking about, don't look into it. Anways... continuing on... That's it. That's what standards are. I hate it when people use the term "standards" as some kind of magic word.
Engineer: Well, I'm not sure how well it's going to integrate.
Salesperson: It's based on Open Standards
*wink* so it should be no problem integrating it with your standards-compliant architecture. It's even better when their systems say "This system is standards compliant" and isn't. Like "our system uses the XMPP open standard" but it doesn't support TLS while the XMPP standard (
RFC 3920) explicitly states that TLS MUST ("MUST" in the
RFC 2119 sense
2) be supported:
12.1. Servers In addition to all defined requirements with regard to security, XML usage, and internationalization, a server MUST support the following core protocols in order to be considered compliant: ... o XML streams (Section 4), including Use of TLS (Section 5), Use of SASL (Section 6), and Resource Binding (Section 7)
You can't just pick and choose what parts of the spec you want to implement and which parts you want to ignore and then claim your are compliant. You're lying. And there should be a financial penalty for lying in your marketing material because, maybe then, you wouldn't do it anymore. </ranting>
1I dare not spaketh its name. Invoking it causes the Internet to churn and boil unsettling the silt of ignorance that covers the undesirables causing them to unrest and to spew forth with wrath and pitchforks and comments. This is how blogs end.
2MUST in the IETF standards vocabulary (
RFC 2119) means:
1. MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute requirement of the specification.
Compare this with the entrys for SHOULD or MAY:
3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.
5. MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item. An implementation which does not include a particular option MUST be prepared to interoperate with another implementation which does include the option, though perhaps with reduced functionality. In the same vein an implementation which does include a particular option MUST be prepared to interoperate with another implementation which does not include the option (except, of course, for the feature the option provides.)