4 ms·

"Postel" is not a term that carries any significance for me, and Googling that word didn't turn anything up that seemed relevant. Who or what is a Postel?

teraflop 2y ago
It's a reference to "Postel's law" which is a pretty well-known principle in the networking world, and in software more broadly. Named after Jon Postel, who edited and published many of the RFCs describing core Internet protocols. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
Ndymium 2y ago
It's a reference to Jon Postel who wrote the following in RFC 761[0]: TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Postel's Law is also known as the Robustness principle. [1] [0] https://datatracker.ietf.org/doc/html/rfc761#section-2.10 https://datatracker.ietf.org/doc/html/rfc761#section-2.10 [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle
- IshKebab 2y ago
  Ironically it leads to less robust systems in the long term.
- thaumasiotes 2y ago
  > Postel's Law is also known as the Robustness principle. 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.
- arcanemachiner 2y ago
  I've always felt that this was a misguided principle, to be avoided when possible. When designing APIs, I think about this principle a lot. 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."
  - joshstrange 2y ago
    When it comes to writing APIs I feel strongly that you should be incredibly strict. 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
  - quesera 2y ago
    HTML parsing is the modern-ish layer-uplifted example of liberal acceptance. 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!
    - pas 2y ago
      It makes sense in a "costumer obsessed" way. The user agent tries to show content, tries to send requests and receive the response on behalf of the client (costumer), and ceteris paribus it's better for the client if the system works even if there's some small error that can be worked around, right? 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?
komon 2y ago
A reference to Postel's Law: be conservative in what you produce and liberal in what you accept. 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
- godshatter 2y ago
  What would have been the result of John Postel advocating for conservative inputs, I wonder? I'm wondering if the most common protocols would have been bypassed if they had all done this by other protocols that allowed more liberal inputs.
  - Joker_vD 2y ago
    Yep. Which is why Postel law is, sadly, more like a law of nature (see also "worse is better") than an engineering principle you may or may not follow.
  - mrighele 2y ago
    I know it is a single example and we should extrapolate much out of it, but in the case of html those who accepted more liberal input (html4/5) won over over those that were more conservative (xhtml).
    - arp242 2y ago
      HTML is rather different because it's authored by people. It's typically (though not always!) a good idea to not be too pedantic about accepting user input if you can. XHTML (served with the correct Content-Type) will completely error out if you made a typo and didn't test carefully enough. Useful in dev cycle? Sure. In production? Less so. "The entire page goes tits up because you used <br> instead of <br />" is just not helpful (and also: needlessly pedantic). 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.
CoastalCoder 2y ago
Adding to the sibling comments, this is briefly covered in Eric Raymond's wonderful book, "The Art of Unix Programming" [0]. [0] https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming
ok123456 2y ago
The fact that googling Postel was worthless also indicates we're in a post-google search world.
- AStonesThrow 2y ago
  Bing had no trouble at all finding him from my device.
- Brian_K_White 2y ago
  2nd result on kagi was about him but in the form of another critic. https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ 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.
- skybrian 2y ago
  Google’s results for “Postel’s law” and “Jon Postel” are fine. “Postel” is ambiguous, a fairly common surname, so websites of unrelated companies show up, and a disambiguating page on wikipedia that links to Jon Postel and several other people.
  - ok123456 2y ago
    I thought the whole point of letting Google surveil your entire life was they would know that if you're interested in computing and networks, to the point of participating on news.hackernews.com, then they'd know that if you're searching for "Postel," you'd probably want Postel's law to be on the first page. We're back at pre-1998 search, where we have to specify more and more context just to get results that aren't noise.
- stackghost 2y ago
runjake 2y ago
Jon Postel was instrumental in making the Internet what it is today. https://en.wikipedia.org/wiki/Jon_Postel 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.

teraflop 2y ago

It's a reference to "Postel's law" which is a pretty well-known principle in the networking world, and in software more broadly. Named after Jon Postel, who edited and published many of the RFCs describing core Internet protocols. https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

Ndymium 2y ago

It's a reference to Jon Postel who wrote the following in RFC 761[0]: TCP implementations should follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Postel's Law is also known as the Robustness principle. [1] [0] https://datatracker.ietf.org/doc/html/rfc761#section-2.10 https://datatracker.ietf.org/doc/html/rfc761#section-2.10 [1] https://en.wikipedia.org/wiki/Robustness_principle https://en.wikipedia.org/wiki/Robustness_principle

IshKebab 2y ago
Ironically it leads to less robust systems in the long term.
thaumasiotes 2y ago
> Postel's Law is also known as the Robustness principle. 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.
arcanemachiner 2y ago
I've always felt that this was a misguided principle, to be avoided when possible. When designing APIs, I think about this principle a lot. 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."
- joshstrange 2y ago
  When it comes to writing APIs I feel strongly that you should be incredibly strict. 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
- quesera 2y ago
  HTML parsing is the modern-ish layer-uplifted example of liberal acceptance. 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!
  - pas 2y ago
    It makes sense in a "costumer obsessed" way. The user agent tries to show content, tries to send requests and receive the response on behalf of the client (costumer), and ceteris paribus it's better for the client if the system works even if there's some small error that can be worked around, right? 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?

komon 2y ago

A reference to Postel's Law: be conservative in what you produce and liberal in what you accept. 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

godshatter 2y ago
What would have been the result of John Postel advocating for conservative inputs, I wonder? I'm wondering if the most common protocols would have been bypassed if they had all done this by other protocols that allowed more liberal inputs.
- Joker_vD 2y ago
  Yep. Which is why Postel law is, sadly, more like a law of nature (see also "worse is better") than an engineering principle you may or may not follow.
- mrighele 2y ago
  I know it is a single example and we should extrapolate much out of it, but in the case of html those who accepted more liberal input (html4/5) won over over those that were more conservative (xhtml).
  - arp242 2y ago
    HTML is rather different because it's authored by people. It's typically (though not always!) a good idea to not be too pedantic about accepting user input if you can. XHTML (served with the correct Content-Type) will completely error out if you made a typo and didn't test carefully enough. Useful in dev cycle? Sure. In production? Less so. "The entire page goes tits up because you used <br> instead of <br />" is just not helpful (and also: needlessly pedantic). 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.

CoastalCoder 2y ago

Adding to the sibling comments, this is briefly covered in Eric Raymond's wonderful book, "The Art of Unix Programming" [0]. [0] https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming

ok123456 2y ago

The fact that googling Postel was worthless also indicates we're in a post-google search world.

AStonesThrow 2y ago
Bing had no trouble at all finding him from my device.
Brian_K_White 2y ago
2nd result on kagi was about him but in the form of another critic. https://datatracker.ietf.org/doc/draft-thomson-postel-was-wrong/ 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.
skybrian 2y ago
Google’s results for “Postel’s law” and “Jon Postel” are fine. “Postel” is ambiguous, a fairly common surname, so websites of unrelated companies show up, and a disambiguating page on wikipedia that links to Jon Postel and several other people.
- ok123456 2y ago
  I thought the whole point of letting Google surveil your entire life was they would know that if you're interested in computing and networks, to the point of participating on news.hackernews.com, then they'd know that if you're searching for "Postel," you'd probably want Postel's law to be on the first page. We're back at pre-1998 search, where we have to specify more and more context just to get results that aren't noise.
stackghost 2y ago

runjake 2y ago

Jon Postel was instrumental in making the Internet what it is today. https://en.wikipedia.org/wiki/Jon_Postel 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.