Earlier quoted context omitted.
How much better have we gotten at specifying protocols? Have we learned how to make protocols less ambiguous and less susceptible to crazy edge cases which make it burdensome to implement support in practice once there are lots of sloppy implementations in the field?
1. in many cases the misbehaving clients and servers are obviously wrong, but Postel's law means they "worked for me" when the developer tested it 10 years ago before abandoning it. 2. The FTP protocol got a lot of cruft added to it that modern clients don't implement (e.g. any transfer mode other than stream). 3. FTP over TCP predates NATs and firewalls, which caused a lot of problems as well. 4. FTP was designed fo…
I see that there's been a debate over the applying Postel's Law, a.k.a. the Robustness Principle, for some time:
https://en.wikipedia.org/wiki/Robustness_principle#Criticism
> a defective implementation that sends non-conforming messages might be used only with implementations that tolerate those deviations from the specification until, possibly several years later, it is connected with a less tolerant application that rejects its messages.
That Wikipedia page led me on to this IETF draft from 2019 on protocol maintenance
https://tools.ietf.org/html/draft-iab-protocol-maintenance-0...
> Abstract
> The robustness principle, often phrased as "be conservative in what you send, and liberal in what you accept", has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem over time. For a protocol that is actively maintained, the robustness principle can, and should, be avoided.
It seems that you need both for the protocol to be unambiguously, fully specified, and for popular implementations to avoid applying Postel's Law! But we've seen how market forces conspire to work against that.
Brainstorming opportunities for improvement beyond the suggestions in the IETF doc:
• Accompany the protocol with a validation test suite.
• Provide a validation service.
• Treat non-validating messages skeptically ("quirks mode").