It’s just data

Prisoner's Dilemma

Luke Hutteman: Maybe there’s an exception to Postel’s law after all.

Prisoner’s Dilemma

What’s the dilemma? The decisions made by individual aggregator developers aren’t really in the same league as the decisions being made by Microsoft about the RSS platform that will become part of the operating system.

Posted by Dare Obasanjo at

Prisoner’s Dilemma

The Prisoner’s Dillema is a game where players can chose to “cooperate” or “defect”.  Recast in this particular situation, Luke points out that his users will benefit if Sean decides to “cooperate” — something that is true even if Luke continues to “defect”.

Posted by Sam Ruby at

Prisoner’s Dilemma

Ah. When I think of the prisoner’s dilemma, I usually remember the rule that the best option is always to “defect” if you can’t control what the other prisoner does.

Posted by Dare Obasanjo at

Prisoner’s Dilemma

That depends.  It’s only the best option if the experiment is performed once.  If performed multiple times, it’s much more difficult to determine the best option.  The best option if the prisoner’s dilemma occurs more than once is (approximately) to do whatever the other guy did last time, with the first move being to cooperate.

How that’s relevant... yeah, I dunno.

Posted by Bob Aman at

Postel’s Law - liberal in what you accept, conservative in what you generate

Postel’s Law - from RFC: 793 - TRANSMISSION CONTROL PROTOCOL 2.10. Robustness Principle TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others. Long ago I...

Excerpt from Preston L. Bannister { random memes } at

Prisoner’s Dilemma

Interesting observation.

However, the typical prisoner’s dilemma is symmetrical, i.e. looks the same from both players perspectives:

.          B coops   B defects 
A coops     2,2        0,3
A defects   3,0        1,1

// a,b = A wins a, B wins b

little aggregator-vendor vs. Microsoft is asymmetrical though, as I’d argue that from MSFT’s perspective, defecting would be worse for them no matter what the small aggregator vendors do. As a major technology supplier, a sloppy MSFT XML parser could have some pretty serious consequences for XML use in general, something I doubt MSFT (as a major proponent of XML) would want. Also, because of matters of scale, the small aggregator vendors care much more what they do, than they care what we do.

So the graph in this case would be more like:

.              lilAg coops   lilAg defects
MSFT coops        100,3             99,6
MSFT defects        1,0              0,1

and thus the outcome becomes clear...

(this all is conveniently ignoring MSFT’s alternate option of handling RSS separate from ‘normal’ XML without making the ‘semi-xml’ parser public, but I’d argue that would still be a slippery slope and bad PR for them)

Posted by Luke Hutteman at

Add your comment