A DNS flag day

2. The Protocol Decay Hypothesis

[...]

An implementation that reacts to variations in the manner advised by
Postel sets up a feedback cycle:

o Over time, implementations progressively add new code to constrain
how data is transmitted, or to permit variations what is received.

o Errors in implementations, or confusion about semantics can
thereby be masked.

o As a result, errors can become entrenched, forcing other
implementations to be tolerant of those errors.

An entrenched flaw can become a de facto standard. Any
implementation of the protocol is required to replicate the aberrant
behavior, or it is not interoperable. This is both a consequence of
applying Postel's advice, and a product of a natural reluctance to
avoid fatal error conditions. This is colloquially referred to as
being "bug for bug compatible".

3. The Long Term Costs

Once deviations become entrenched, there is little that can be done
to rectify the situation.

For widely used protocols, the massive scale of the Internet makes
large scale interoperability testing infeasible for all a privileged
few. Without good maintenance, new implementations can be restricted
to niche uses, where the prolems arising from interoperability issues
can be more closely managed.

[...]

Protocol maintenance can help by carefully documenting divergence and
recommending limits on what is both acceptable and interoperable.
The time-consuming process of documenting the actual protocol -
rather than the protocol as it was originally conceived - can restore
the ability to create and maintain interoperable implementations.

Such a process was undertaken for HTTP/1.1 [RFC7230]. This this
effort took more than 6 years, it has been successful in documenting
protocol variations and describing what has over time become a far
more complex protocol.

4. A New Design Principle

The following principle applies not just to the implementation of a
protocol, but to the design and specification of the protocol.

Protocol designs and implementations should be maximally strict.

Though less pithy than Postel's formulation, this principle is based
on the lessons of protocol deployment. The principle is also based
on valuing early feedback, a practice central to modern engineering
discipline.

4.1. Fail Fast and Hard

Protocols need to include error reporting mechanisms that ensure
errors are surfaced in a visible and expedient fashion.

4.2. Implementations Are Ultimately Responsible

Implementers are encouraged to expose errors immediately and
prominently in addition to what a specification mandates.

4.3. Protocol Maintenance is Important

Protocol designers are strongly encouraged to continue to maintain
and evolve protocols beyond their initial inception and definition.
If protocol implementations are less tolerant of variation, protocol
maintenance becomes critical.