Re: deprecating Postel's principle - considered harmful

[Eric Rescorla <ekr@xxxxxxxx>]

On Thu, May 9, 2019 at 9:17 PM Doug Royer <douglasroyer@xxxxxxxxx> wrote:

Sometimes I find mild bugs in the other endpoints implementation. So I
tweak my code to accept their bug when I recognize their implementation.
Networking code is full of 'bug compatibility switches'. Hopefully fewer
over time.

I think this graf does a good job of bringing out the key point which I take Martin to be pushing on. As you say, it would be nice to have fewer bug "bug compatibility switches".

One way to achieve that is for the initial implementations to be very strict about rejecting violations of the specification.Then, when new implementations are introduced into the ecosystem, if they do not conform to those aspects of the specification and are forced to implement the protocol correctly. By contrast, if the early implementations are very loose in their enforcement of protocol violations, then it is likely that some set of implementations will also violate the specification in the data they transmit, with the result that future implementations will have to implement "bug compatibility switches" in order to be able to function correctly.

These issues seem particularly relevant in the case of new protocol migration. As you say, we often design our protocols with a specific plan for migration but that plan depends on specific behavior by the implementations of the older/current version, and if those implementations are nonconformant, then it may be the case that our migration plans do not work (as was the case with the TLS 1.3 migration). Here, too, then, having implementations strictly enforce that their counterparties are implementing the specification directly -- even up to testing it directly by mechanisms such as "greasing", can smooth the path towards a future migration.

-Ekr