Podlove Alternate Feeds

Podlove Alternate Feeds is a method for describing related podcast feeds from within another feed, therefore creating a group of related feeds that podcast clients can automatically detect and present to the user.

Motivation and scope

Some podcasts create multiple feeds relating to the same or similar content. Depending on which podcast feed a user has subscribed to, different types of media containers or codecs might be used. Alternative feeds might also present either audio or audiovisual representation of an original recording or present different transport mechanisms like BitTorrent.

Podlove Alternate Feeds is a very simple definition to make discovery of alternative feeds easy and automatic as users often never look up background information on feeds on websites and therefore might not know of their options.

Using the method described below podcast clients can decide to present this information to the user when subscribing to a feed initially (or whenever they feel appropriate) to provide additional options.

Setting a title for feeds

Each podcast feed SHOULD include <atom:link rel="self" ...> element in the feeds global section to link back to its original feed. This is a common procedure. But the optional title attribute is usually left out. We recommend setting this title to describe the nature of the feed in the podcast feed’s original language.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">

 <title>My Cool Podcast</title>
 <link rel="self"
       title="MP3 audio"/>

By providing a title for the current feed itself, podcast clients can display this title alongside the titles of alternate feeds (see below)

Including alternate feeds

Extending the above section, the podcast feed CAN now list all other available podcast feeds that serve the same content.

The following example states feeds delivering different media containers for the same audio content:

 <link rel="alternate"
       title="MP3 audio low-bandwidth"/>
 <link rel="alternate"
       title="MP4 audio"/>
 <link rel="alternate"
       title="Ogg Vorbis audio"/>

This example lists video variants as well as BitTorrent feeds for the same content:

 <link rel="alternate"
       title="MP4 video"/>
 <link rel="alternate"
       title="MP4 video (via BitTorrent)"/>

Please note the only real difference in these elements is the feed URL and the title. Make sure the title is descriptive enough for the user to understand the difference at first glance. Maintain a common style among all titles to achieve coherency for the user.

The title is not meant to be machine readable or automatically selected by software. A podcast client SHOULD provide a list of options and make the user choose from the list.

Linking in RSS

The above examples describe Atom feeds only. In RSS, you can use the very same method but MUST make sure you declare the Atom Syndication namespace properly and use the namespace prefix with the link element.

<?xml version="1.0" encoding="utf-8"?>
<rss version=2.0" xmlns:atom="http://www.w3.org/2005/Atom">

 <title>My Cool Podcast</title>
 <atom:link rel="self"
       title="MP3 audio"/>

16 thoughts on “Podlove Alternate Feeds

  1. Woooohoooo, Congrats to the good work, hope this grand-sceme gets big enought to become a default in the podcast-world :). But sady, in this Post is no definition about time/date, that someone would have to correct :D.

  2. Pingback: der firtz geht um | die Hörsuppe

  3. atom:feed elements MUST NOT contain more than one atom:link element with a rel attribute value of “alternate” that has the same combination of type and hreflang attribute values.

    Will heißen: ATOM-Feeds mit mehr als einem alternate link sind eigtl nicht valide. Ein kurzer Test mit dem feedvalidator (http://validator.w3.org/feed/) bestätigt dies.

  4. It is generally possible to generate a multi attachment feed, using multiple enclosures. However the different clients support this very differently, but maybe this could be a future way to allow the client to decide for itself.

    From what I found out until now, Firefox and IE show the first element, Safari (Win) shows all and iOS Podcast app tries the last entry. If these unaware clients are picking according to this, there could be an easy fallback, by just serving a good order of the multiple enclosure, to serve the unaware clients in the best way possible.

    Here is a test feed from the guys at “Wir müssen reden” where I added for enclosures in the following order: M4A, MP§, OGG, Torrent-M4A.

    Maybe you guys can check this out on more devices/clients and comment and maybe consider multiple enclosures as a way to reduce the amount of feeds.


  5. Pingback: Problem Solving a Podcast | Chris La Nauze

Leave a Reply to christian Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.