Mirror RSS Namespace

Author: Tom Sayles
Version: 0.1.1
Date: 2005-12-26

Contents

• Contents

• Summary

• Status

• Elements

  • mirror:format

  • mirror:location

  • mirror:addMirror

• Sample Files

  • Simple Example

  • Live Example

• Use Cases

• ToDo List

Summary

This specification describes an extension namespace to the RSS 2.0 specification's enclosure tag.  The mirror:format, mirror:location and mirror:addMirror tags defined herein are intended to facilitate the collaborative redistribution of RSS enclosed content in alternate formats and from alternate locations. 

The Mirror RSS Namespace in not intended as a replacement for server side bandwidth supply management solutions like round-robin load balancing. Rather it is meant to apply distributed bandwidth and computation reduction strategies used with other Internet protocols such as FTP.

Status

As of December 2005 the "mirror" tags are just an idea. This specification is intended to flesh out the idea in more detail.

I'm not an expert on writing XML specifications, so any suggestions or assistance would be appreciated. Specifically I'm looking for comments and suggestions from the community on how improve this specification in ways that make implementation easier and/or more effective. Please send any such comments and suggestions to TSayles at Gmail dot com. 

Elements

This document defines a new set of sub elements of the RSS Enclosure Tag to identify alternate locations and formats for an enclosed item. Since the RSS specification is basicly frozen the way to implement this is through a new name space that defines tags and/or attributes for these elements.

The new elements are all sub elements of the RSS Enclosure tag.  I chose to use sub element tags rather then additional attributes because this makes the resulting XML code easier to read and scales better when there are several or many mirrors. The new tags include:

• mirror:format

• mirror:location

• mirror:addMirror

These tags can be used independently or in combination.

I have somewhat different purposes in mind for each of the three tags.

mirror:format

Examples

<mirror:format url="http://main.example.com/mp3/test.ogg" length="12468024" type="application/ogg" trustLevel="10"/>
<mirror:format url="http://backup.example.com/mp3/test_hifi.mp3" length="24680135" type="audio/mpeg" trustLevel="20"/>
<mirror:format url="http://tracker.example.com/mp3/test.torrent" length="2468" type="application/x-bittorrent" trustLevel="100"/>

Attributes

type="audio/mpeg"
type="application/ogg"
type="application/x-bittorrent"

trustLevel="10"
trustLevel="50"
trustLevel="100"

The url. length and type attributes should follow the usage defined in the RSS 2.0 specification's enclosure tag, except as noted below.

Any valid URL that results in a file with content equivalent to the original may be specified by the URL attribute. However not all user agents will support all protocols. User agents that encounter unsupported URLs should by default fail gracefully, probably by ignoring those mirror tags. If the user agent provides some kind of plug-in mechanism that can support additional protocols, some kind of message to the user may be appropriate. 

The trustLevel attribute is intended to represent the relative levels of trust that the RSS feed publisher places in mirror to deliver an accurate copy of the original content.  Valid trust levels should be positive integers, with larger values representing less trusted sources.  The following table contains some suggested values.

Use of the podcache:expectmd5 tag in the mirror:format tag with hashes computed by the RSS Feed author is encouraged.

Intent

The "mirror:format" tag is intended to cut down on the number of
separate feeds that need to be maintained and processed. It came out of
some inefficiencies that the FeedMesh guys were complaining about
regarding the same content showing up in multiple feeds with different
UIDs. So the intent is to more closely connect the the content to the
UID. And yes to make use of "mirror:format" tags, the podcatchers have
to allow the user to prioritize format preferences.

Personally I want my podcatcher to download content in multiple formats and put
each in a different place: low-res audio on my 256mb iRiver; high-res
audio on my desktop; low res-video on my video iPod; and HD video on my
DVR. Then when I've consumed the content in one of those locations, my
podcatcher should delete or archive the content from all those
locations. I think that having multiple formats associated with a
single UID in a single feed makes this easier.

mirror:location

Examples

<mirror:location url="http://mirror.example.com/main/mp3/test.mp3" length="12345678" type="audio/mpeg" trustLevel="10" />
<mirror:location url="ftp://foo.org/mirrors/example.com/mp3/test.mp3" trustLevel="50" />
<mirror:location url="http://bar.com/podcasts/test.mp3" trustLevel="100" />

Attributes

The mirror:location tags use the same attributes as the mirror:format tags except as noted below.

The length and type attributes are optional and any difference from the primary source, i.e. the one given in the enclosure tag itself, should be reported. 

The podcache:expectmd5 tag should not be used in the mirror:location tag. Rather the MD5 hash computed by the RSS Feed author should be included as a podcache:expectmd5 tag in the RSS enclosure tag. If the podcache:expectmd5 tag is present in the RSS enclosure tag, the user agent should varify the downloaded mirror copy against it and report any descripancies.

Intent

The main purpose for the "mirror:location" tag is to enable a simple fall over and/or bandwidth improvement mechanism. This tag is simply a discovery method that gives the podcatcher and/or user choices in where to download from in much the same way that Internet protocols, especialy FTP, have historicaly mirrors. The primary source, i.e. the one given in the enclosure tag itself, may not be the most efficient for every user. Addressing this problem has been the traditional function of mirrors since the early days of the Internet. It's not meant to replace round-robin load balancing.

A seperate tag is used for mirror:location and mirror:format because the expitations as to the length and type of the downloaded file are different. 

mirror:addMirror

Examples

TBD

Attributes

TBD. Will likely include some kind of URL and/or XML-RPC declaration.

Intent

The purpose of the “mirror:addMirror” tag is to provide a mechanism for reporting new mirrors. This will probably be through some yet sort of to be defined XML-RPC exchange. Ideally this tag and the associated process will be flexible enough to allow both the simple instantaneous addition of new mirrors to a feed as well as more complex implementations that verify the integrity of a mirror and/or require human approval before publicizing a mirror from an untrusted source.