Untitled 2008 edit

What about James Leitzel's Robustness Principle with regards to vice (as an extension of John Stuart Mill's harm principle)? It is fairly well publicized in journals as well as at least one book on the matter (not to mention copious amounts of blog posts out there). Might call for a disambiguation or second section? —Preceding unsigned comment added by 128.135.169.129 (talk) 22:08, 10 March 2008 (UTC)Reply

random editor cannot believe something edit

I cannot believe that this criticism of "Postel's Law" is valid. It is not the application of Postel's Law that leads to the problem, it is the misapplication. That is, the statement of Postel's Law leaves considerable room for interpretive error, trying to understand what 'liberal' and 'conservative' should really mean. If you allow as 'liberal' what should not be allowed, then of course you will have the problem described: bugs that should have been detected and fixed go unnoticed.

It is important to notice that just as with many other aphorisms, Postel's Law is stated more compactly than precisely. This is to provide a convenient summary that sticks in the mind. The statement of Postel's Law must NOT be taken as a prescription for how to apply it.

Instead, one should remember the principle far older than even that font of wisdom, "The Mythical Man-Month", and remember NOT to take anything to excess.

The problem described in this article happens ONLY when the summary statement is taken to excess, or otherwise misinterpreted.

204.119.233.161 00:11, 7 December 2006 (UTC)Reply

I agree, and I have added a deeper interpretation of the principle.--Nick 17:40, 23 March 2007 (UTC)Reply
It's irrelevant what you can or cannot believe and what you do or do not think is valid. WP is based on reliable sources, not the opinions of editors, and this is not a blog. As for your claim as to what Postel's word "liberal" really means, you are simply wrong ... from RFC 760, "That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." -- and contrary to your claim, that is subject to the criticism. -- Jibal (talk) 00:00, 25 April 2021 (UTC)Reply

History of the Principle edit

I hereby grant permission to incorporate any or all of the text from my history of the principle (currently just linked to in this article). --Nick 17:43, 23 March 2007 (UTC)Reply

Wikipedia doesn't work like that. -- Jibal (talk) 00:05, 25 April 2021 (UTC)Reply

July 2010 edit

I've just changed the article substantially:

  • Summarized the big block quotes.
  • Formatted the refs nicely.
  • Simplified the lede.
  • Broadened the exposition to be less Internet-specific: the principle applies to many aspects of computing, not just implementation of networking protocols.
  • Removed the {{refimprove}} and {{quotefarm}} tags.

I'm sure my work can be improved. Any comments? CWC 09:57, 24 July 2010 (UTC)Reply

Thank you. The article certainly reads better now without excessive direct quotations of RFCs. However, I felt the new prose removed some discussion of problems too far from the original context, giving undue weight to some aspects any new application faces one way or another when either the robustness principle, or the strict interpretation of standards is applied too stringently. The history of OSI networking for example is a grand example of excessive application of Rose's 'strictness principle', to the point were none of the early implementation of OSI were interoperable at all, which likely contributed to the demise of the model, while the Internet is an example of the success of the openness and flexible interpretation of standards. Surely this comparison is somewhat superficial as well, but the overwhelming success of the Internet model speaks much in favor of the robustness principle. This aspect should be discussed in some shape or form in this article, I believe reliable references also exist in this area. AS it stands this article is merely a statement of existence of the concept, while it probably deserves much deeper presentation. Kbrose (talk) 20:07, 24 July 2010 (UTC)Reply
Thanks for your edits, Kbrose. You've made it into a much better encyclopedia article.
I'd love to see any good refs for the Robustness Principle as a key contributor to the Internet's success. (Both for the article and for personal reading.)
Other explanations for the IETF's success include the "end-to-end principle" and "rough consensus and working code". It's interesting to ponder how those tie in with the Robustness Principle. I wonder if anyone has written about the way these work together?
Cheers, CWC 05:43, 25 July 2010 (UTC)Reply

My misinterpretation of the principle edit

I saw this quoted on a website a few months back. At the time I assumed it was talking about software, and I thought it was a good idea and have been trying to adopt it since then! My interpretation was that it meant:

  • Use other people libraries/software often, but only publish your best software, not your rubbish.

Now despite having learned the principle was targeted at a different field, I still believe it applies well to software. (Having said that, I am still a hoarder, and will probably publish everything, but will ensure that the good quality stuff is clearly marked and separated from the chaff.) 82.32.31.166 (talk) 19:01, 5 August 2012 (UTC)Reply

Cautionary: Of course, we should not be too liberal with the software we accept from the Internet, as this may eventually lead us to install some virus or spyware. As with the TCP packets, we may want to inspect and verify the incoming information a bit first! 82.32.31.166 (talk) 19:09, 5 August 2012 (UTC)Reply
Uhm, actually the opposite is often applied in software, when there is incorrect input, break as early as possible. Done so that the bug is found at the origin of the problem, not when there are already many confounding 'bugs' that were handled by things 'doing the best thing', making it very complicated. If there is a wiki page on that principle, probably should link to it from here!88.159.65.93 (talk) 17:30, 3 December 2012 (UTC)Reply
What you are describing is known as the fail-fast principle. – Smyth\talk 17:25, 16 May 2013 (UTC)Reply
Why would anyone care that some anonymous person misinterpreted something? This page is not a blog, let alone your personal blog. -- Jibal (talk) 00:10, 25 April 2021 (UTC)Reply

Criticism edit

The Marshall Rose criticism is somewhat misguided in making little distinction between testing and deployment. Of course, testing should be as strict as conceivable, whenever and whenever possible. I find it ridiculous to think Postel meant anything else. — MaxEnt 00:48, 28 November 2016 (UTC)Reply

This page is not a blog. It doesn't matter what some editor thinks is misguided. If you have a reliable source that argues that the criticism is misguided, then contribute that. And FWIW, Postel was not talking about testing at all, he was talking about deploying systems that accept ill-formed inputs. From RFC 760: "That is, it should be careful to send well-formed datagrams, but should accept any datagram that it can interpret (e.g., not object to technical errors where the meaning is still clear)." -- and that policy is subject to the criticisms noted in the article. -- Jibal (talk) 00:18, 25 April 2021 (UTC)Reply

add summary of CACM 2011 to article edit

it be good to add & cite the points raised in this CACM article. https://cacm.acm.org/magazines/2011/8/114933-the-robustness-principle-reconsidered/fulltextLentower (talk) 20:29, 27 March 2018 (UTC)Reply

"Robustness Principle (Temporary Name)" listed at Redirects for discussion edit

  An editor has identified a potential problem with the redirect Robustness Principle (Temporary Name) and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2023 January 22 § Robustness Principle (Temporary Name) until a consensus is reached, and readers of this page are welcome to contribute to the discussion. 1234qwer1234qwer4 14:24, 22 January 2023 (UTC)Reply