Michael Welzl wrote:
In reality, people may or may not follow the specs, and you
can always have systems which misuse things that you prescribe -
this is like the house that is then built based on the figure.
The fallacy in this logic is that there is presumption the figure
(proposal) was correct to begin with.
I don't buy this cry that people don't follow specs, that they
bastards, morons, idiots what have you. Step back and try to
understand why there might be varying implementations, why people
(implementators) will not do what you say they should do, or even
exactly under your terms.
To me, there are three kinds of RFC:
1) One that make sense in entirely,
2) One that makes partial sense,
3) One that doesn't make sense at all.
Yet, all of them can be rubber stamped as gospel standards, and many
are done with the smallest consensus where there might be a
significant amount of "purged" disagreement.
This might explain why you might find "deviant" implementations. Many
are put into an ALL or nothing, or maybe even partial support,
filtering what they like or don't like, reading ill-stated semantics
to fit the desired usage which may under Pareto's Principle, work
80-90% of the time with a high payoff.
The rhetorical question I have is whose fault is that?
IMV, this proposal falls under #2 above.
Worst, a key different with this proposal that it is unlike many others:
In the attempt to add useful functionality for end-users,
it attempts to mandate, not encourage a 'migrational'
change, but mandate a drastic change in existing server behavior.
So I don't see how anyone can not expect this to not have a serious
concern or impact or even agreement for endorsement.
Its not really about following the suggested semantics or a "figure" -
it just might be that it wasn't quite right to begin with.
This idea is good. The way it is being proposed is, well, not good. :-)
--
HLS