I feel like a lot of design failures with new wire protocols, come down to the organization responsible for the specification not having enough leverage to convince the clients/stakeholders who will eventually implement the specification to “meet them in the middle” by adapting their systems to suit the protocol; instead, the clients/stakeholders hold all the leverage, and so demand that the specification change to a shape where it has knobs allowing each of them to implement the standard with no change to their current system whatsoever, at the expense of every other client essentially having to reify “the way each other client/stakeholder does things” in the form of each knob.
I wonder if any specification group has ever thrown up their hands and said, “you know what? Fine. Let’s just create one named sub-protocol for the way each of you major players does things; and then have the clients of this protocol do a sub-protocol negotiation; and then have the client use a plugin specific to the sub-protocol that’s been negotiated. Then you don’t need any knobs; all the policy can be baked into the plugin.”
(Come to think of it, this is kind of how the authentication phase of SSH works, when configured to use PAM. “Pretend we’re MIT” (a.k.a. Kerberos); “pretend this is a Microsoft Active Directory domain” (a.k.a. NTLM auth); etc.
I wonder if any specification group has ever thrown up their hands and said, “you know what? Fine. Let’s just create one named sub-protocol for the way each of you major players does things; and then have the clients of this protocol do a sub-protocol negotiation; and then have the client use a plugin specific to the sub-protocol that’s been negotiated. Then you don’t need any knobs; all the policy can be baked into the plugin.”
(Come to think of it, this is kind of how the authentication phase of SSH works, when configured to use PAM. “Pretend we’re MIT” (a.k.a. Kerberos); “pretend this is a Microsoft Active Directory domain” (a.k.a. NTLM auth); etc.