Re: Fwd: Proposal - UUID data type

Gregory Stark wrote:
> "Mark Mielke" <mark(at)mark(dot)mielke(dot)cc> writes:
>
>> I'm sure one or two examples must exist, but I cannot think of any. Every
>> enhancement I can think of that eventually made it into a standard, was first
>> implemented within a popular product, and then demanded as a standard to be
>> applied to all other products.
>>
>
> C99? SMTP? NTP?
>
> It tends to be important for network protocols since there's no gain in having
> non-interoperable protocols.
>

For C99 - GCC had most of the C99 features years before C99 started.
There are now some incompatibles that need to be dealt with.

For SMTP and NTP I think these protocols are just so old that people
don't realize how much they have evolved, and how many products existed.
I wasn't in the know at the time they were written (I was either a baby
or in grade school), but I bet either: 1) they were written before it
existed at all (not really an enhancment), or 2) they followed the
prototype as it was implemented. There have been many extensions to SMTP
that I have been aware of included support for SSL, that I doubt were in
the standard first. The "RFC" is a "request for comment". The "STD"
process came a lot later.

If we grab a phrase from RFC 1305 for NTP - "In Version 3 a new
algorithm to combine the offsets of a number of peer time servers is
presented in Appendix F. This algorithm is modelled on those used by
national standards laboratories to combine the weighted offsets from a
number of standard clocks to construct a synthetic laboratory timescale
more accurate than that of any clock separately." This seems pretty
clear that the "standard" was updated based upon existing implementation.

To some degree, except for the simplest of designs, it is almost bad to
write down what WILL be done, without having experience, or a prototype
to based ones conclusions from. Ivory tower stuff. The purpose of a
standard is to have one common way that things are done - hopefully the
best way - not just the only way that was considered. :-)

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>