The internet was designed with a narrow waist
This works well for transport and storage, but not so well if you need to understand and transform the data. For the problems with ad-hoc extension mechanisms, see:<p>On Variance and Extensibility
&lt;<a href="https:&#x2F;&#x2F;acko.net&#x2F;blog&#x2F;on-variance-and-extensibility&#x2F;" rel="nofollow">https:&#x2F;&#x2F;acko.net&#x2F;blog&#x2F;on-variance-and-extensibility&#x2F;</a>&gt;<p>In particular, the section on &quot;The Mirage of Extensibility&quot;, which uses ImageMagick as an example.<p>&gt; One solution is to do both. You declare a standard schema upfront, with common conventions that can be relied on by anyone. But you also provide the ability to extend it with custom data, so that specific pairs of Input&#x2F;Process&#x2F;Output can coordinate. HTTP and e-mail headers are X-able.<p>&gt; The problem is that there is no universal reason why something should be standard or not. Standard is the common set of functionality &quot;we&quot; are aware of today. Non-standard is what&#x27;s unanticipated. This is entirely haphazard. [...]<p>&gt; X- fields and headers are the norm and have a habit of becoming defacto standards. When they do, you find it&#x27;s too late to clean it up into a new standard. People try anyway, like with X-Forwarded-For vs Forwarded. Or -webkit-transform vs transform. New software must continue to accept old input. It must also produce output compatible with old software. This means old software never needs to be updated, which means new software can never ditch its legacy code.<p>Also see: IPv6. IP packets being so universal makes upgrading very difficult.