In his post Really Simple Sharing, Ray Ozzie announced Simple Sharing Extensions for RSS and OPML. He writes

As an industry, we have simply not designed our calendaring and directory software and services for this “mesh” model. The websites, services and servers we build seem to all want to be the “owner” and “publisher”; it’s really inconsistent with the model that made email so successful, and the loosely-coupled nature of the web.

Shortly after I started at Microsoft, I had the opportunity to meet with the people behind Exchange, Outlook, MSN, Windows Mobile, Messenger, Communicator, and more. We brainstormed about this “meshed world” and how we might best serve it - a world where each of these products and others’ products could both manage these objects and synchronize each others’ changes. We thought about how we might prototype such a thing as rapidly as possible – to get the underpinnings of data synchronization working so that we could spend time working on the user experience aspects of the problem – a much better place to spend time than doing plumbing.

There are many great item synchronization mechanisms out there (and at Microsoft), but we decided we’d never get short term network effects among products if we selected something complicated – even if it were powerful. What we really longed for was "the RSS of synchronization" ... something simple that would catch on very quickly.

Using RSS itself as-is for synchronization wasn't really an option. That is, RSS is primarily about syndication - unidirectional publishing - while in order to accomplish the “mesh” sharing scenarios, we'd need bi-directional (actually, multi-directional) synchronization of items. But RSS is compelling because of the power inherent in its simplicity.
And so we created an RSS extension that we refer to as Simple Sharing Extensions or SSE. In just a few weeks time, several Microsoft product groups and my own 'concept development group' built prototypes and demos, and found that it works and interoperates quite nicely.

We’re pretty excited about the extension - well beyond the uses that catalyzed its creation. It’s designed in such a way that the minimum implementation is incredibly easy, and so that higher-level capabilities such as conflict handling can be implemented in those applications that want to do such things.

The model behind SSE is pretty straightforward; to sychronize data across multiple sources, each end point provides a feed and the subscribes to the feeds provided by the other end point(s).  I hate to sound like a fanboy but SSE is an example of how Ray Ozzie showed up at Microsoft and just started kicking butt. I've been on the periphery of some of the discussions of SSE and reviewed early drafts of the spec. It's been impressive seeing how much quick progress Ray made internally on getting this idea polished and evangelized.

The spec looks good modulo the issues that tend to dog Microsoft when it ships specs like this. For example,  is a lack of detail around data types (e.g. nowhere is the date format used by the spec documented although you can assume it's RFC 822 dates based on the examples) and there is also the lack of any test sites that have feeds which use this format so enterprising hackers can quickly write some code to prototype implementations and try out ideas.

Sam Ruby has posted a blog entry critical of Microsoft's practices when it publishes RSS extension specifications in his post This is Sharing? where he writes

The first attribute that the the Simple Sharing Extensions for RSS and OPML is to “treat the item list as an ordered set”.  This sounds like something from the Simple List Extensions Specification that was also hatched in private and then unleashed with great fanfare about five months ago. Sure a wiki was set up, but any questions posted there were promptly ignored.  The cone of silence has been so impenetrable that even invoking the name Scoble turns out to be ineffective. 

Now the Simple List Extensions Specification URI redirects to an ad for vaporware.  Some things never change.

Should we wait for version 3.0?

I agree with all of Sam's feedback. Hopefully Microsoft will do better this time around.


Categories: Syndication Technology
Tracked by: [Pingback]
"zyban side affects" (zyban side affects) [Trackback]
"flagyl side effects how long" (flagyl side effects how long) [Trackback]
"scuola lingua" (scuola lingua) [Trackback]
"birdhouse distributors" (birdhouse distributors) [Trackback]
"business cards" (business cards) [Trackback]
"foto scolaretta sex sex" (foto scolaretta sex sex) [Trackback]
"bed and breakfast positano" (bed and breakfast positano) [Trackback]
"prom dresses" (prom dresses) [Trackback]
"blue cross of ca" (blue cross of ca) [Trackback]
"mouse pad" (mouse pad) [Trackback]
"I Want to Play the Price Is Right" (I Want to Play the Price Is Right) [Trackback]
"plants retail frisco%2c tx" (plants retail frisco%2c tx) [Trackback]
"invisibile ragazze inculate" (invisibile ragazze inculate) [Trackback]
"piu caldo fuoriclasse papa" (piu caldo fuoriclasse papa) [Trackback]
"street racing videos" (street racing videos) [Trackback]
"altro consumo it" (altro consumo it) [Trackback]
"lake compounce" (lake compounce) [Trackback]
"amore segreto" (amore segreto) [Trackback]
"amateur adult mpeg archives" (amateur adult mpeg archives) [Trackback]
"what is my computer hz" (what is my computer hz) [Trackback]
"girls gone wild" (girls gone wild) [Trackback]
"volagratis" (volagratis) [Trackback]
"song lyrics riding dirty" (song lyrics riding dirty) [Trackback]
"owner builder homes" (owner builder homes) [Trackback]
"handsome teen scopata" (handsome teen scopata) [Trackback]
"fast weight loss wellbutrin" (fast weight loss wellbutrin) [Trackback]
"free teen sex video" (free teen sex video) [Trackback]
"citizen wrist watch" (citizen wrist watch) [Trackback]
"ragazza ginevra" (ragazza ginevra) [Trackback]
"girls ugly" (girls ugly) [Trackback]
"cpa client newsletters" (cpa client newsletters) [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback]
"" ( [Trackback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback] [Pingback]

Monday, November 21, 2005 7:53:17 PM (GMT Standard Time, UTC+00:00)

The spec *does* say RFC 822 in section 1.2. Note that the dates in the examples aren't RFC 822 as they contain 4 digit years, nor do the months match the month_name production in either RFC 822 or its successor RFC 2822.

Based on these, and other problems, the IETF no longer recommends these date formats. Instead, they suggest the one defined in RFC 3339 which not only avoids these problems, it also can be used in a fashion that is compatible with xsd:dateTime.

The question that should be considered: is this extension intended only for RSS 2.0 and OPML, or might it be useful in other documents? No, I'm not talking about Atom here, but other documents which might be described by an xsd.

You likely have a greater opportunity to cary forward this feedback than I ever will. If so, I'd appreciate hearing what reception it gets.

P.S. You have a copy/paste error where a few extra words were added to my quote.
Monday, November 21, 2005 8:32:50 PM (GMT Standard Time, UTC+00:00)
I fixed the copy paste error. I'll probe around internally as to where to send feedback and start sending it. If you have any issues you can either blog them or send them my way via email. I'll make sure the right folks read it if they aren't subscribed to your blog already.
Monday, November 21, 2005 9:08:28 PM (GMT Standard Time, UTC+00:00)
Thanks for your post, Dare. Feel free to email feedback directly to me.

Sam, thanks for your feedback also. You are right about RFC 822--our intent is to be compatible with RSS 2.0, which says dates should be 822, but which also uses 4-digit years. We'll look into it and see what the right thing to do is. RFC 3339 is tempting, but then we wouldn't be compatible with RSS dates. Maybe we should specify that either 3339 or RSS dates are valid? Just a thought.
George Moromisato
Monday, November 21, 2005 11:45:31 PM (GMT Standard Time, UTC+00:00)

Thanks. Anything more I have to say, I'll either say it here (as a comment on this post), or will post a link to it here. I'm most interested in seeing if MS is interested in going forward with both SLES and SSE, or if they will be reconciled.


"wouldn't be compatible" is perhaps putting it a bit too strong, particularly as RSS feeds supported dc:date long before pubDate was ever created.

Think about it. The recommendation has been superceded by the very organization that published RFC 822. Furthermore, it is error prone, as evidenced by the fact that either you or one of your collegues got it wrong in the examples in the spec. And trust me, I've met a lot of developers, and as a general rule, MS developers don't tend to fall on the lower end of the scale.

Sure, most "liberal" parsers will compensate for this, but is depending on that really the right way to go?

However, none of the above is as compelling as the question: is this extension intended narrowly for RSS 2.0 and OPML 1.1? Or might it find uses in other areas, ones where a formal XML Schema is of value? (FYI: the last time I checked, the dates produced by the MS SOAP implementations weren't normalized to GMT. I'd suggest dropping that restriction).
Tuesday, November 22, 2005 2:30:47 AM (GMT Standard Time, UTC+00:00)
The choice of RFC 822-style dates make good sense in 1997. It makes absolutely no sense in 2005.
Tuesday, November 22, 2005 2:49:19 PM (GMT Standard Time, UTC+00:00)
The Simple List Extension Specification and the Simple Sharing Extensions provide distinct and different mechanisms for declaring that a feed is to be treated as an ordered set of entries.

Is Microsoft intending to continue with both mechanisms? Is there any possibility of these two being converged and/or reconciled?
Tuesday, November 22, 2005 2:52:21 PM (GMT Standard Time, UTC+00:00)
From personal experience, many people jump right to the examples, tailor them to suit their purposes, and don't bother with validators. For this reason, it is vitally important that the examples be correct - not just the date format problem mentioned above, but also well-formedness:
Tuesday, November 22, 2005 3:00:10 PM (GMT Standard Time, UTC+00:00)
Identity is an important property of feed entries. Given the history of feed formats, consumers have had to implement a set of heroic set of heuristics to accomplish this. This problem is made worse by the number of different ways in which a globally unique id can be specified.

Into this context, SSE introduces a sx:sync/@id. To cope, I expect that most producers of RSS 2.0 will duplicate the same information in the link, guid, and now sx:sync/@id, and consumers will have to add the sx:sync/@id attribute to the growing number of places that they look for a unique id.

A much superior approach would be to state that the sx:sync/@id attribute is only to be used if the underlying format does not provide a mechanism for specifying uniqueness (e.g., OPML). In the case of RSS 2.0, that purpose would be served by a guid. In RSS 1.0, rdf:about. In Atom 1.0, atom:id.
Tuesday, November 22, 2005 3:11:32 PM (GMT Standard Time, UTC+00:00)
This comment is merely stylistic, and therefore does not merit the same level of attention as some of the others previously mentioned.

sx:related has a type attribute, which is different than the type attribute defined on rss enclosures or on opml outlines. Introducing such an attribute into a pre-existing container may cause confusion.

Atom 1.0 has a very similar feature for defining related resources, and employs a syntax which will be very familiar to people who have ever dealt with [X]HTML: a link element. Incidentally, the type attribute on the atom:link element is compatible with the usage in rss 2.0 enclosures.

A more complete and concrete suggestion would be to consider naming this element "sx:link", change the "link" attribute to "href", change the "type" attribute to "rel" (possibly, but not necessarily changing the values for this attribute), and keep the "title", "since", and "util" attributes.
Thursday, December 1, 2005 3:11:28 AM (GMT Standard Time, UTC+00:00)
Great comments, Sam. As you pointed out on the Atom list, leaving comments on random blogs is a less-than-efficient way to provide feedback on a spec.

To help with the getting these comments heard, we set up a mailing list for discussion of this spec, and any other specs. Details are in Jack Ozzie's post (which also has some background info that's worth reading):

Comments are closed.