DRM in RSS 2, OPML 2 and ATOM 1

DRM, Digital Rights Management

DRM handles the description, layering, analysis, valuation, trading, monitoring and enforcement of the usage restrictions that accompany a specific instance of a digital work.

Any blog post is a "digital work" and as a creator of aggregation software, the rights of the author is important to me. But I'll go beyond that and say that I want authors to earn from their work and I want our software to handle that for them. I'll go even further beyond that and say that our software can encourage and enforce correct usage restrictions too.

To what extent do the existing web feed specs make provision for DRM? Or… to put it another way, if our software was to implement DRM on behalf of the authors, which spec has the features we need and which ones don't?

I've posted about the need for extensions to RSS in order to safeguard the content creators rights. As a creator of an aggregation product, I think it's very a important topic. Here are some of my posts that contain practical suggestions:

Although these posts are not in the same focus area (rights protection) as my own posts, I've found quite a few comments about the limitations of RSS and the inability to influence the "owners" of the spec who will take charge in dealing with the changes that are needed. Here are some of the posts I have found:

Clearly we need some changes, otherwise companies (Microsoft?) and people will just begin to implement their own changes as they see fit, on behalf of their customers. Another wild west scenario.


Dave might be onto some of the things I am looking for:

I'm leading a lunch discussion today about Identity in RSS and OPML, particularly OPML 2.0, which has a element for the author's identity. It's specified in 2.0 as a URL, and should plug into the work being done in this community.

The OPML 2.0 spec has some really useful information in the <HEAD> area.

<dateCreated> is a date-time, indicating when the document was created.
<dateModified> is a date-time, indicating when the document was last modified.
<ownerName> is a string, the owner of the document.
<ownerEmail> is a string, the email address of the owner of the document.
<ownerId> is the http address of a web page that contains an HTML a form that allows a human reader to communicate with the author of the document via email or other means.

Dave is clearly interested in taking the long view by including this element:

<docs> is the http address of documentation for the format used in the OPML file. It's probably a pointer to this page for people who might stumble across the file on a web server 25 years from now and wonder what it is.

But OPML is not designed to contain content, but rather to link to content – and perhaps to link to the content which is linked to by that content (recursively). It's very good and useful at that. OPML is not what I'm looking for.


The RSS 2.0 spec contains only 1 author related element and it's an email address:

An item's author element provides the e-mail address of the person who wrote the item (optional).

I don't think it's sufficient because email addresses change over time. So RSS would not provide enough information for the protection of the rights of the author.


The W3C Atom format spec (not Atom 0.3) has far more useful information than either RSS or OPML in terms of tracking the lifetime of the "item" (content) and in always being able to find the original author. Atom even hasa "rights" element. No wonder entire sites are converting to ATOM.

The "atom:author" element is a Person construct that indicates the author of the entry or feed.

The "atom:contributor" element is a Person construct that indicates a person or other entity who contributed to the entry or feed.

The "atom:id" element conveys a permanent, universally unique identifier for an entry or feed.

The "atom:published" element is a Date construct indicating an instant in time associated with an event early in the life cycle of the entry.

The "atom:updated" element is a Date construct indicating the most recent instant in time when an entry or feed was modified in a way the publisher considers significant. Therefore, not all modifications necessarily result in a changed atom:updated value.

The "atom:rights" element is a Text construct that conveys information about rights held in and over an entry or feed.

I really like the foresight of this next element!

If an atom:entry element does not contain an atom:rights element, then the atom:rights element of the containing atom:feed element, if present, is considered to apply to the entry.

Atom does a far better job of giving the elements that can be used to protect the authors of the content. In the two specs above the main author element which is intended to contain an email. But email addresses change over time – and in this way an author could lose touch with the ways in which their content is being used.

Atom uses this word "person" throughout ther spec. What is a "person" in Atom?

A Person construct is an element that describes a person, corporation, or similar entity (hereafter, 'person'). This specification assigns no significance to the order of appearance of the child elements in a Person construct. Person constructs allow extension Metadata elements.

The "atom:name" element's content conveys a human-readable name for the person. The content of atom:name is Language-Sensitive.

The "atom:uri" element's content conveys an IRI associated with the person. Person constructs MAY contain an atom:uri element, but MUST NOT contain more than one.

The "atom:email" element's content conveys an e-mail address associated with the person. Person constructs MAY contain an atom:email element, but MUST NOT contain more than one.

Overall I can imagine Atom providing us with enough elements to be able to implement some form of protection for the rights of the initial author.

What is the issue here?

If we don't take action now, we will have a situation where people earn off content in the same way as people earn from paintings. If I paint a wonder piece of art, I sell it – and that's the end of my revenue. The artwork can be resold 20 times and increase in value 100 times… but I make nothing. Speculators make everything, I get nothing.

Without protecting the author and providing them with income, we really cannot expect to see the emergence of professional authors who create great content over the long term.


Here are links to the specs:

This is an important issue to me because we're building the reBlogger website based aggregator and I want to honor the digital rights of the author… but I can't programmatically determine what their rights are!



Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: