"We are in a post-Postel world" is a great way to put it. This needs to be repeated by everyone working with file formats or accepting untrusted input.
See also RFC 9413 (https://www.rfc-editor.org/rfc/rfc9413.html), originally called "draft-thomson-postel-was-wrong" (https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...).
When every implementation in wide use has their own quirks, you must support them all to make your program widely used. Every special case is yet another potential bug to chase down.
It also allows "Embrace, extend, and extinguish" -strategy that Microsoft used so successfully to assfuck the internet over a decade.
Younger people don't know how absolutely ruthless and harmful Wintel monopoly was under Gates. Java did not work on purpose. Javascript did not work for purpose.
<!--[if IE]>
They attempted to kill open web in the crib with their blackbird project. Only MSN (The Microsoft Network) for normal people.
You (the generic "you") can complain all you want about Apple today, but you have another perfectly viable option. And Apple is (almost-entirely) happy to grow market share on merits without salting the earth of any rivals.
In Microsoft's heyday, that was not true. Those of us who rejected MS back then did so at a much higher cost than green chat bubbles.
It was worth it though. And we did win, eventually.
Windows was never going to scale down to the portable devices that we now use (because defeating Apple would have been very difficult, and AOSP made it insurmountable).
Windows was never going to scale up to the top 500 supercomputer list (for largely economic reasons).
Microsoft itself has tacitly admitted that Azure is better served by Linux, and we ponder why.
Did the DoJ actions against Microsoft really have an impact? I don't know.
Microsoft embodied the adage "It's not enough to win. Everyone else must lose."
Many of them people that used to complain about Micro$oft and should know better.
https://www.justice.gov/atr/us-v-microsoft-proposed-findings...
See 91.3.2
- Active X.
- VB6, OLE, VBA macros and friends.
Merge both. Now you have a propietary hell full of vulnerabilities.
Said this, I don't like Google's world dominance on the smartphones/web/email/chat/maps/video platforms, neither.
*Apple it's just sucessful in the US.
Who or what is a Postel?
TCP implementations should follow a general principle of robustness:
be conservative in what you do, be liberal in what you accept from
others.
[0] https://datatracker.ietf.org/doc/html/rfc761#section-2.10
My philosophy is more along the lines of "I will begrudgingly give you enough rope to hang yourself, but I won't give you enough to hang everybody else."
I won't argue that this hasn't been a disaster for technologists, but there are many arguments that this was core to the success of HTML and consequently the web.
Which, yes, could be considered its own separate disaster, but here we are!
but of course this leads to the tragedy of anticommons, too many people have an effective "veto" (every shitty middlebox, every "so easy to use" 30 line library that got waaay to popular now contributes to ossification of the stack.
what's the solution? similarly careless adoption of new protocols? and hoping for the best? maybe putting an emphasis on provable correctness, and if something is not conformant to the relevant standard then not considering it "broken" for the "if it ain't broken don't touch it" principle?
1 != ‘1’
true != 1
true != ‘true’
undefined != false
undefined != null
etc
“Flexibility” in your API just means you are signing up for a maintenance burden for the lifetime of your API. You will also run into problems because you have to draw the line somewhere and people will be frustrated/confused since your API is “flexible” but not as flexible as they want. Better to draw the line at complete strictness IMHO. I dislike even optional fields and prefer null to be passed instead except special cases (like when null has a meaning, example: search endpoint where you pass the fields you want to search on and a field can have a null value).
I want people to be explicit about what they are doing/fetching when using an API I have written/maintained. It also encourages less sloppy clients
Really? It seems like it's obviously just a description of how natural language works.† But in that case, there's an enforcement mechanism (not well understood) that causes everyone to be conservative in what they send.
We can observe, by the natural language 'analogy', that the consequence of following this principle is that you never have backwards compatibility. Otherwise things generally work.
† Notably, it has nothing to do with how math works, making it a strange choice for programming.
The law references that you should strive to follow all standards in your own output, but you should make a best effort to accept content that may break a standard.
This is useful in the context of open standards and evolving ecosystems since it allows peers speaking different versions of a protocol to continue to communicate.
The assertion being made here is that the world has become too fraught with exploiting this attitude for it to continue being a useful rule
Also note that HTML5 codified into liberal acceptance some of the "lazy" manual errors that people made in the early days (many of which were strictly and noisily rejected in XHTML, for example).
I also read that XHTML made template authoring hard, as the template itself might not be valid XHTML and/or different template inputs might make output invalid. (I sadly can't find the source of this point right now, but I can't claim credit for it).
With PHP specifically there was an issue where the use of shorthand <? syntax for code snippets would conflict with <?xml declaration that would normally be placed at the beginning of the XHTML document - it would see the <? and try to interpret the rest of it as PHP code, which obviously didn't work. The workaround was to disable short tags and always use <?php explicitly
But that doesn't really apply to protocols like TCP. Postel's "law" is best understood in the context of 1980, when TCP had been around for a while but without a real standard, everyone was kind of experimenting, and there were tons of little incompatibilities. In this context, it was reasonable and practical advice.
For a lot of other things though: not so much. "Fail fast" is typically the better approach, which will benefit everyone, especially the people implementing the protocols.
This is also why Sendmail became the de-facto standard around the same time by the way: it was bug-compatible with everything else. Later this become a liability (sendmail.cf!), but originally it was a great feature.
Imagine a protocol where both sides have to speak JSON with a rigidly-defined structure, and none of the sides is allowed to ask whether the other supports any extension. Such a protocol looks impossible to extend, but that is not the case, you can indicate that you speak a "relaxed" version of that protocol by e.g. following your first left brace by a predefined, large number of whitespace characters. If you see a client doing this, you know they won't drop the connection if you include a supported_extensions field, and you're still able to speak the rigid version to strict clients.
[0] https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming
https://datatracker.ietf.org/doc/draft-thomson-postel-was-wr...
Hard disagree.
It's a valid argument, but I say it's merely an argument, not an argument that wins or should win.
But also, I say that detecting out of spec or unexpected input and handling it in any other way than crashing IS adhering to Postel.
Refusing to process a request is better than munging the data according to your own creative interpretation of reasonable or likely, and then processing that munged data.
I consider that to be within Postel to return a nice error (or not if that would be a security divulgence). Failing Postel would be to crash or do anything unintended.
We're back at pre-1998 search, where we have to specify more and more context just to get results that aren't noise.
https://en.wikipedia.org/wiki/Jon_Postel
The Wikipedia article is kinda unclear and doesn't provide the proper context, so:
- Ran IANA, which assigned IP addresses for the Internet.
- Editor of RFCs, which are documents that defined protocols in use by the Internet.
- He wrote a bunch of important RFCs that defined how some very important protocols should work.
- Created or helped create SMTP, DNS, TCP/IP, ARPANET, etc.
Deciding that nul is invalid data, and refusing to allow it, and refusing to munge the data and proceed based on the munged data that you essentially made up, as long as whatever you did do instead was graceful and intentional, to me that is perfectly Postel.