Interesting article on Podcasting 2.0. Early on in the project I think it was misunderstood to be about non-censorship, etc but it’s much more that that, it’s about enriching the listening experience.
The vision he paints of a listener going about her day listening to, watching, and interacting with podcasts is pretty cool. Can’t wait!
Ugh. Just what we don’t need, another “standard.” RSS as is works just fine, thank you.
He says he’s all about RSS and open source, then links to the github repository. Doesn’t seem too terrible at first glance. Is there something specific that you don’t like here? Just curious.
It is RSS, correct? I would think you’d encourage expanding podcasting!
It’s extending RSS. So you’d need new software to support it plus a greatly modified workflow to create shows for it. These kinds of proposals come along every few years, but, as far as I’m concerned, RSS does exactly what it needs to do right now. We don’t need to turn it into Discord. Simple is better.
I appreciate your response and point of view, thanks! 
What Podcasting 2.0 is offering, in many cases with negligible work such as a one time modification to an rss template, are all the features that simply weren’t dreamed of in 2005.
Do you offer closed captions on all your shows? Why not? Who will be the first podcast network to be sued under ADA over this. Podcasting 2.0 has the open standard.
Would you like to notify firm fans that their favorite show is being taped live and a link to your chat room? Podping has the open source, cross app method.
Do you ever get calls asking why {show} hasn’t updated on {podcast client} yet? Podping will fix the push pull problem and adoption is growing.
And that’s before we get to the central feature: a free to use for app developers api which is spurring huge new growth in apps.
These people also just don’t seem to understand the technology. I bet its possible to already (sort of) do something like that. For example they refer to linking to a map, there’s probably a way to do that based on chapters (given not all podcasters include chapters). They refer to that not requiring an API, in any implementation would it? I’d think that data would have to somehow be either encoded in the file or at least the RSS entry which would negate the need entirely (plus they refer to an API being blocked but wouldn’t be more likely that the destination the API is calling would be blocked?).
This podcast happens to be a video podcast. She was only listening to the audio so far (her app knew to only stream the mp3 version of the content) but, now on the treadmill, she unlocks her phone screen and the app switches to the video mp4 version of the podcast on the fly. With her screen in landscape she can see the hosts on the left and the chat window on the right.
What does that have to do with a new standard? I’d think that doesn’t require anything new either, it would be more dependant on the app (I know that Pocket Casts it able to play video files without the screen on). The other stuff mentioned is also possible to implement on an app level (and with this new :standard" probably would still have to be.
I’d have to say that the cloud chapter tool is a cool idea but I’d assume that once again it would have to be implemented at the app level and would require some kind of API since it talks to the internet.
I don’t see what’s new about this. Also, if any of my analysis is wrong comment.
Just like they sued other media? Gimme a break! I’m all for someone choosing to be more accessible to everyone, but it can go overboard. Why don’t magazines have audio, for example? Why don’t radio stations support video so you can have ASL? Taking a quote by a famous Canadian way out of context “The media is the message.”
