Documents with mixed languages

[Philip Linde]

On Tue, 14 Dec 2021 00:21:52 +0000
Krixano <krixano@protonmail.com> wrote:

> Let me just be clear here, in response to this:
> > I can instead treat it as a weird
> > mutation of the protocol, and generally not worry about the whims of
> > a few implementors that ignore the spec in various ways. In this way, I
> > avoid the tyranny of a multitude of "loud minorities" that would have
> > been much more disruptive without a canonical specification of the
> > protocol.
> 
> 1.) I agree with what is your most important argument, Clients and Servers should only be *expected* to adhere to the literalness of the spec

If by that you mean that they should be expected to adhere to the
specification, yes, we agree. I don't know exactly what you mean by the
"literalness of the spec".

> 2.) The intended protocol design is necessary for pointing out needed clarifications to the specification, and for people who want to adhere to the intended design of the spec.

Yes, changes to the protocol need to be considered in terms of the
objectives of the project, and we can use the objectives to discuss what
should be specified. But the objectives insofar that they haven't been
specified aren't a specification.

> 3.) Clients and Servers should therefore not be derided for adhering to the intended design even if it goes against the literalness of the spec, as the spec is possibly flawed or unclarified while still n development.

Agreed, but I think derided is a little too strong a word if you are
referring to my example that you quoted. If that's how it came across, I
apologize to who ever felt it unfair, and I recognize that it's blunt
to the point that it might seem rude without the tone only I can hear.
My point was that diverging implementations that stray from the
specification create exactly the kind of governance by "loud minority"
that Michael Lazar sees in centralized authority over the protocol,
just multiplied by the number of different divergent behaviors.

> 4.) Clients and Servers that adhere to the literalness of the official spec are just as valid as clients that adhere to the intentions behind the spec when it comes to an unfinalized spec. *Both* are valid.

So we have two protocols. Possibly many more, depending on our value
judgement of what the "intended spec" is. As far as I'm concerned,
there either is a specification, or there isn't. There can be working
ideas and discussions for changes to or replacement of a specification,
but that isn't a specification unto itself until it actually specifies
something.

As far as validity go, I wouldn't say in any absolute sense that a
particular piece of software is valid or invalid. But I do consider
software that fails to fulfill a specification to be incorrect in terms
of the specification. I try not to add much value to that; sometimes
that's a good thing and sometimes it's not. But it seems clear that we
both agree that it's better for everyone if the specification and
implementations reflect each other closely.

-- 
Philip