[rectang]

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?

[aidenn0]

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 for human-readable, not machine-readable output. In particular the output of a LIST command is woefully underspecified.

I think #1 is the biggest issue for long-term viability of protocols. Not following Postel's law is a recipe for death (same reason why it's suicide for a browser to unilaterally untrust a major CA; any site that doesn't work in browser X is assumed to be browser X's fault), but following Postel's law is a recipe for undocumented de-facto standards with crazy edge cases.

[rectang]

Thanks, wonderful reply!

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").