Many years ago I switched to Atom because the RSS spec was ambiguous with regards to which fields could contain entity-encoded HTML.

Anyone know if that issue with RSS ever got resolved?

There are some recommendations here which I've tried to follow when I've worked with RSS: https://www.rssboard.org/rss-profile

They are from 2007, so you might have seen them already.

The worst use of the <BLINK> tag ever was the discussion held in the early days of RSS about escaping HTML in titles, whose attention-grabbing title went something like this: "Hey, what happens when you put a <BLINK> tag in the title???!!!"

The content of that notorious discussion went on and off and on and off for weeks, giving all the netizens of the RSS syndication community blogosphere terrible headaches, with people's entire blogs disappearing and reappearing every second, until it finally reached a flashing point, when Dave Winer humbly conceded that it wasn't the user's fault for being an idiot, and maybe just maybe there was tiny teeny little design flaw in RSS, and it wasn't actually such a great idea to allow HTML tags in RSS titles.

The RSS 2.0.1 spec at https://cyber.harvard.edu/rss/rss.html is essentially dead, or “frozen” / “settled” as it says there.

2.0.1 was published in 2003 and I don't expect to see a 2.0.2 or 2.0.3.

The ambiguities you mention are real, though. “The url must be an http url” is one that feed validators would adhere to very strictly, for example, rejecting HTTPS URLs as invalid[1], which even caused Apple's Podcast submissions process to reject feeds with HTTPS URLs in them at one point (I was employed at the time by a company that hosted podcasts, and we had to work around it by rewriting URLs to use HTTP).

I received a reply from the spec's author to my email suggesting they update the spec to clarify this (“of course you can use HTTPS”) but the spec itself was never updated and I would consider it unmaintained at this point.

Atom and JSON Feed are good alternatives. Atom because it has fewer ambiguities and JSON Feed because it has an open GitHub repo[2] and was updated in 2020.

[1]: https://github.com/rubys/feedvalidator/pull/12

[2]: https://github.com/manton/JSONFeed

Yes, they got resolved in the Atom 1.0 spec ;)

I recommend that people use Atom for new implementations for basically this reason. However to be honest it probably isn't a big enough problem to switch to Atom of RSS is working for you.

I was wondering the same. At some point it appeared atom was going to take over the feed space, but when I started blogging again last year it appeared we had more or less standardized again on RSS 2.

I have no idea why or what happened.

> […] but when I started blogging again last year it appeared we had more or less standardized again on RSS 2.

Per Gandhi, be the change you wish to see in the world: only provide Atom. :)

Personally for a while initially, I just didn't bother figuring out which one was better.

I'd say the lack of a push towards Atom might be one of the reasons.

I think it's probably as simple as these lines of code from wp-includes/feed.php in WordPress:

  $default_feed = apply_filters( 'default_feed', 'rss2' );

  return ( 'rss' === $default_feed ) ? 'rss2' : $default_feed;

WordPress is a popular enough platform so that people will adapt to its defaults.

I was intrigued by the title of this article and if I remember well Atom was a sensible standard that was quite well defined, but specifically Dave Winer didn't want it to happen because it was not invented by him. I switched all RSS-y stuff I had to develop + all sites I control to Atom long ago, and it pretty much just works.

See my earlier reply, Atom can support rssCloud through the addition of a cloud element.

Yes. Note that you are by far not the first person noticing that collaborating with Dave is... challenging.

Atom feeds can also support rssCloud through the addition of a cloud element as defined in the RSS spec.