Simple Sharing Extensions for RSS and OPML

It’s nice to connect. I’m Jack Ozzie, development manager for Ray Ozzie’s concept development group. Besides being brothers, Ray and I have worked together for several years now developing and shipping software products with some amazingly talented development teams.  I joined Ray’s dev team at Iris Associates in 1987, contributing to the development of Lotus Notes. In 1997, I moved on with him as co-founder of Groove Networks.  After Microsoft acquired Groove Networks last April, I transitioned to Ray’s CTO staff, running a small development team here in Redmond.

As Ray mentioned in his blog posting on Nov 20, my team has been working with various Microsoft product groups and collaborating with Dave Winer, building proof-of-concept prototypes around the Simple Sharing Extensions for RSS, and refining the spec in the process.  One of the key members of our team who helped to advance the spec and get it to the point where we were comfortable publishing the draft is George Moromisato. George is another member of the Iris/Groove alumni; his knowledge of Notes replication and Groove synchronization are incredibly valuable to this initiative.  Since Dave and Ray’s initial blog postings, I’ve been very encouraged by the development community’s initial reaction; it has definitely generated some interesting conversation, as evidenced by this post. Our team is looking forward to working with the community to complete the SSE spec so we can all get to work building this into our products and services, enabling new seamless sharing experiences for customers, and creating new opportunities for partners.  Here’s some additional context for why we are so excited about the potential for SSE.

Why SSE?

The marketing wonks told us to follow the “Rule of Threes.”  So we’ve come up with three words – all beginning in S – to answer the “Why?” question.

Simple.  Like RSS, SSE was designed with simplicity in mind, and developers will find that implementing SSE replication is easy, especially for an application that already supports RSS. SSE defines the minimum extensions necessary to enable loosely cooperating applications to use RSS as the basis for item sharing.  We view this as a means by which disparate products can work together without hard-coded dependencies. We also wanted to make it simple enough to encourage widespread adoption. We hope you’ll take the time to review our draft specification and give us your feedback on whether we accomplished our goal in relation to simplicity.

Seamless.  The SSE draft specification is just one initiative in our overall objective to provide “seamless experiences” for our customers as they migrate back-and-forth throughout the day from work persona, to family persona, to community volunteer persona, etc. SSE allows you to replicate any set of independent items (calendar entries, lists of contacts, lists of favorites, blogrolls, etc.) using simple RSS semantics.  It also supports asynchronous replication of new and changed items, meaning it can work even when you’re offline.  It also works across firewalls, and across different company infrastructures.  This is but one initiative in our overall plan to provide our customers with the kind of “just works” experiences they’ve come to expect in other aspects of their lives.

Sharing.  The “so what?” of SSE is that it extends RSS and OPML from unidirectional to bidirectional information flows.  Let’s just focus on calendaring for now.  There are three layers of calendar today: 1) Private/personal, 2) A group, and 3) A public calendar for events and schedules to which individuals or groups can subscribe.  The ability to subscribe to a public event calendar is certainly useful, and a step forward.  But it’s still just a one-way exchange of data.  We believe SSE addresses a larger problem that our customers have today.  For example, why do your work and family calendars have to be separate?  With SSE you could share your work calendar with your spouse.  If your calendar were published as an SSE feed, changes to your work calendar could be replicated to your spouse’s calendar, and vice versa.  As a result, your spouse could see your work calendar and add new appointments, such as a parent-teacher meeting, or a doctor’s appointment. Moreover, SSE could be used to replicate a set of calendar entries among a group of people, each working in a different company and using different infrastructure.

Answers to the other two most important questions: “What?” and “How?” are addressed in the draft spec and FAQ.

We would love to get your feedback on this spec. We don’t have a definitive deadline, but we look forward to getting your ideas and comments so we can incorporate them into a 1.0 specification that will be published in the coming months.

In addition to this blog, where you can provide comments, we’ve set up a mailing list at for discussion of the SSE spec (as well as the SLX spec and any other RSS topic of interest to subscribers). Please join us if you want to contribute to the SSE spec.The archive of the mailing list discussion will be available for those who want to follow without subscribing. Major changes to the spec or major issues will be posted for discussion here on the blog as well.

To subscribe to the list: Send email to: with the message body “subscribe feed-tech” or use the web-based subscription form.


Comments (6)

  1. What’s difference between SSE and SyncML?

  2. While both SSE and OPML are both young specifications, I want to propose a new form of thinking. I like SSE there is no doubt about that, and I really like Dave Winer’s work with OPML, but it is too static.

    Take for example the first MP3 players that ever came out. You sorted the MP3’s into folders that you manually had to change through, and once put on the MP3 player this was the only way to navigate.

    Then as people got more and more music, and space became larger and larger, this way of sorting your music became a bit too cumbersome. Metadata, known as ID3 tags came to save the day. Apple’s iPod is a clear example of metadata navigation done correctly. You can sort by genre, year, artist name, album name, it’s quite nice.

    Now relate those MP3 files to data. As OPML is in it’s current state, it is quite a chore to put everything into specific folders, hell even them some people just dump everything into one folder. OPML needs to evolve right now while it is still young so that people don’t have to deal with it later when changing the specification can be a difficult transition.

    How should OPML evolve? Tagging. Not quite like MP3’s which have fields for all their metadata, just a line with words separated by commas, each word being a tag. In practice, all you need is to add to the OPML specification is a line of XML, so that every item has a tag(s). Block tagging should also be in place, so that instead of folders like you have now, you can have your first 10 items be given the tag “Technology” the second chunk of 10 items in your OPML file be tagged “Personal”.

    Why should you listen to me? Because OPML is nice and cute for bloggers to share their blogroll when they subscribe to less than 100 feeds or so, and the author properly maintains his OPML file in some special order. What about people like Robert Scoble who has more than 500 feeds? More importantly, he keeps them all in one folder! How in the world am I supposed to know what’s what? I would have to subscribe to his entire OPML and look at all the feeds to get an idea of what I like.

    Tagging in the above situation fixes everything. Imagine an OPML viewer, that isn’t static at all, but instead very dynamic. When you load up an OPML file, it lists all the tags in alphabetical order, yea you heard that right, ALL the tags, however many that may be. Then a user clicks on anyone of these tags, and now all the data tagged with this piece of information is displayed AND all the other tags that are related to it.

    Take this example; I am subscribed to 10 feeds in my OPML file. 4 of them are tagged Blogs, of these 4, 1 of these 4 blogs also have the tag Microsoft. Now I also have another 6 items tagged News, and of these 6 items, 3 of them also have the tag Microsoft. So let me make this easier to visualize:

    OPML File

    Item 1: Tags: Blog

    Item 2: Tags: Blog

    Item 3: Tags: Blog

    Item 4: Tags: Blog, Microsoft

    Item 5: News

    Item 6: News

    Item 7: News

    Item 8: News, Microsoft

    Item 9: News, Microsoft

    Item 10: News, Microsoft

    Now when I load up this OPML file into an OPML viewer, there is no predefined folder structure. I merely see all the tags present: Blog, News, and Microsoft. Now when I click on the Microsoft tag I should see 4 items that have this tag, along with two other tags: News, and Blog. I can now click News and Blog much like a sub heading to further break down my list of feeds. So I went from 4 items with the Tag Microsoft, I click the tag Blog which is a subheading and now I am only looking at 1 item.

    These seems a little bit excessive for an OPML file with 10 items, but now imagine an OPML file like Robert Scobles with 700+ items. I can easily load it up, click on Technology tag, this list of 700 now gets cut down, now I click on the tag HDTV and this even smaller list is made now even more refined! With two clicks, I sorted through 700 feeds to show me all the Technology feeds Scoble is subscribed to, and within those technology feeds I made only the Technology feeds with the HDTV tag viewable as well.

    What I am trying to say is, I love Channel 9 a lot, and I watch all the videos. My first Channel 9 video was when Scoble interviewed Amar Gandhi from the RSS team, and from then on, I was hooked. The thing you guys do with Virtual Folders is amazing, using Metadata to sort information; I figured this could be applied to the OPML specification as well.

    I’ve been trying to contact Dave Winer but I suppose he is a busy man since I haven’t heard back from him. As the father of RSS, he has changed my life on the internet dramatically, now I just wanted to get my ideas out to him and to the rest of the world. I might be wrong, I might be right, I’m just telling you from a user perspective how I would like to manage a list, which will only get larger, of items that are of importance to me.

    Keep it up RSS Team!

    You can contact me for further feedback at I hope to help you guys as much as I can!

  3. Neil MacLean says:


    This seems really exciting but to help me get my (not so technical) brain round the potential for SSE could you give some practical examples of how you could see it working, for example, in the travel business?

    Your calendar example above suggests itineraries for a group of passengers could be updated to take account of delays or cancellations on the fly and to keep everybody in sync.

    Can you think of any other examples for the travel space?

    Thanks very much

  4. Bill Wood says:

    Hi Jack,

    Glad to see you landed at MS ok; too bad you’re not on the Groove team anymore though!

    One thing I don’t see in the SSE spec is any sort of access control – who can update, delete, etc. I suppose access control might take the "simple" out of SSE but have you guys thought about it at all? One idea would be to not have access control per se but to have a flag indicating that you wanted any updates to be reviewed by the end user before being applied.

    – Bill

  5. Tony Perrie says:

    It seems that in a star topology, SSE would somewhat approximate what Exchange and Lotus Notes seem to accomplish as pertains to scheduling. If you used SSE in a mesh configuration, it would seem to require a peer-to-peer protocol to negotiate communication between links that use network address translation. Would Avalanche technology or another companion technology be used to negotiate mesh networked nodes? If so, why would you need to poll in the sense that Outlook and Lotus polls a server for mail and schedule updates? If SSE requires a protocol with this additional sophistication, why not use one that would allow broadcasting update metadata to all the nodes that are active on the mesh at the instant of a subcribed feed update from a publisher? It would seem that standard would even allow for this as it is not specified that you must poll outside of the FAQ. If you sent an XMLRPC or SOAP broadcast over Avalanche wouldn’t this eliminate lots of unnecessary poll packets if you scale SSE to a distributed mesh topology? Or am I missing something here?

    Also, it would seem that non-endpoint feed nodes that are sending SSE feed data to or from a node other than itself could be fairly insecure when not transmitted using a secure application protocol. If such a protocol were used, it could be fairly wide security hole. Effectively, this would open up an ad-hoc mesh network where my node would be unaware of what data it is sending if it were protected via key pairs and unencrypted at the end points. This seems to be kind of a Catch 22 situation. If you don’t encrypt it, I can put my ethernet card into promiscuous mode, and gather all the packets from the phy and gain access to unencrypted xml data. If you do encrypt it, such a network would be an anonymized bittorrent and nearly like what Freenet attempts to do by distributing and anonymizing all data. I guess I’m not seeing how SSE can be implemented securely and reliably using an existing protocol. It wouldn’t take much to uuencode binary data and transmit it over a protocol intended for text-only similar to what has happened to nntp.

    Finally, Google seems to have implemented an interesting XML Sitemap Protocol. Within Sitemap, there is a field for priority. I feel that this is a much overlooked notion in RSS Aggregators. Abandoning the schedule syncing example, say you’re syncing news feeds between SSE clients. Within site map, the web site publisher can specify what is the most important data that it serves via the priority field. If SSE were to include some type of optional relevance or priority information, then it would be possible for the users to specify what data is relevant to them to meet their own needs. This data could then be harvested, and used to benefit everyone using the network. Consider recent startups like, Digg, Stumbleupon, Reddit, and Bloglines. These social bookmarking sites are a powerful way to find out the goodness of news and articles based on how many people like or dislike the information. So, if you’re syncing lots of SSE feeds back-and-forth, each node effectively would have access to this metadata. The existence of a link in an RSS feed would roughly be equivalent to what Google refers to as Pagerank. This type of information processing would be better suited in a star topology, but could be extended to a mesh if all priorities were made visible to non-endpoints and thereby eliminate server-side processing. Using priorities would also enable the implementation of automatic server-side priority calculation software. This would enable each web server to automatically use popularity as a way to help the clients adjust the ordering of the RSS feed data that is being offered. In a mesh network, you could essentially farm out the server side processing that’s used to calculate whether or not something is of interest to a particular node.

  6. Mike_J says:

    I really like the SSE idea and prepare to apply it to our bookmark collection synchronization. The collection is a list/tree of bookmarks/or favorites in XML format. Unlike current browser such as IE or FireFox which only has one Favorites or Bookmark tree, you can have many collections in the browser, i.e. many bookmark trees. You can create a collection of all the bookmarks related to your holiday, create a bookmark collection related with a project. If the PC is shared in the family, Dad’s bookmark collection will not interfere with Daughter’s bookmark collection on the same browser. You can download Tablane browser to see how this concept works (

    In the coming months, we will start online trial. You can put your collection online in RSS and Web forma. The collection are divided in three categories: Private, Private shared(group) and Public. You can use any device to access your collections and update them. The SSE seems perfect for our synchronization purpose.