💾 Archived View for rawtext.club › ~sloum › geminilist › 007703.gmi captured on 2023-09-28 at 16:12:16. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2023-09-08)
-=-=-=-=-=-=-
Philip Linde linde.philip at gmail.com
Tue Dec 14 01:24:26 GMT 2021
- - - - - - - - - - - - - - - - - - -
On Tue, 14 Dec 2021 00:21:52 +0000Krixano <krixano at 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 thespecification, 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 theobjectives of the project, and we can use the objectives to discuss whatshould be specified. But the objectives insofar that they haven't beenspecified 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 arereferring to my example that you quoted. If that's how it came across, Iapologize to who ever felt it unfair, and I recognize that it's bluntto the point that it might seem rude without the tone only I can hear.My point was that diverging implementations that stray from thespecification 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 valuejudgement of what the "intended spec" is. As far as I'm concerned,there either is a specification, or there isn't. There can be workingideas and discussions for changes to or replacement of a specification,but that isn't a specification unto itself until it actually specifiessomething.
As far as validity go, I wouldn't say in any absolute sense that aparticular piece of software is valid or invalid. But I do considersoftware that fails to fulfill a specification to be incorrect in termsof the specification. I try not to add much value to that; sometimesthat's a good thing and sometimes it's not. But it seems clear that weboth agree that it's better for everyone if the specification andimplementations reflect each other closely.
-- Philip-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 488 bytesDesc: not availableURL: <https://lists.orbitalfox.eu/archives/gemini/attachments/20211214/f3fb7a83/attachment.sig>