[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: nature of standards (was RE: RESEND: Thoughts on identity attacks)




It would be hard to remove all optional modules since the protocols are
developed to be used under different business cases.  As long as the options
are popular, they will come out as a non-standarded standard.  I see SCEP
and Xauth as the examples.

Even "C" is the same.  All latest C compilers support "//" as comment but
it's not defined in the original C.

--------------------------------------------
Michael Shieh
--------------------------------------------

-----Original Message-----
From: Henry Spencer [mailto:henry@spsystems.net]
Sent: Thursday, February 14, 2002 12:00 PM
To: IP Security List
Subject: nature of standards (was RE: RESEND: Thoughts on identity
attacks)


On Thu, 14 Feb 2002, Khaja E. Ahmed wrote:
> He explains how and why 'a camel is a horse designed by committee.'
Perhaps
> we can consider things like adopting a process which mandates that there
> will always be a cleanly separated 'minimum and mandatory to implement'
part
> in any standard.  Nothing gets added to it unless a compelling case is
made
> for it.  Everything else is separated into optional modules etc.

As an implementor, I'd like to see the process go one step farther, with
most of those "optional modules" simply discarded as not meriting
standardization. 

I was somewhat involved with the original standardization of C.  One of
the most important decisions that committee made was that they did not
wish to see 2^5 or 2^10 different "standard C" languages... and every time
you add an "optional module" to the spec, you add another factor of 2. 
They did eventually end up having, essentially, *one* optional module --
containing all the standard libraries and certain promises about the
execution environment, not necessarily supportable in small embedded
environments -- but that was all. 

                                                          Henry Spencer
                                                       henry@spsystems.net