in defense of standards

> > So working back, I end up saying you SHOULD NOT say things like that,
> > and MUST NOT do so knowingly.
> 
> Piffle. Why project your fears and insecurity onto specs? 

There's "best practices" advice and there's conformance to
specifications.  Certain constraints in the design of open systems can
be expressed in either place, often with tradeoffs in ease of
implementation and likely failure modes.

Look at any protocol specification, and you'll see lots of statements
constraining what the parties are supposed to do.  If they don't
behave according to the protocol, the overall system generally fails.
In practical open systems, one hopes the failure doesn't affect things
too widely, and fingers can be pointed.  

Did you notice in the ICANN threats to Verisign how their contract
says that Verisign's domain servers have to conform to certain RFCs?
(Of course purchasers of parts are quite familiar with buying things
conforming to certain standardized specifications.  MilSpec and all
that.)  

Because Verisign is required to act in certain ways, everyone else can
write software which does cool stuff (resolves domain names!).  When
Verisign cheats, software around the world breaks!  If there was no
expectation that Verisign was going to stick to the protocol, none of
that cool software could have been written in the first place.

Maybe you know some way to build open systems without protocol
specifications?

It may be that my particular suggested SHOULDS and MUSTS don't need to
be in the spec, but if you're going to argue that nothing needs to be
said, and you're still going to build an open systems, I think you're
just arguing for an undocumented protocol.

> If you don't 
> like it, communicate with your partners. You're free to say, "That way 
> of saying this irritates me. I'm avoiding that"

Negotiating with partners doesn't scale.  That's why we have
standards.

     -- sandro

Received on Thursday, 9 October 2003 22:21:03 UTC