General

What kinds of scenarios does FeedSync enable?

Just as RSS and Atom enable the aggregation of information from a variety of data sources, FeedSync enables the synchronization of information across a variety of data sources. Data sources that implement FeedSync will be able to exchange and synchronize data with any other data source that also implements FeedSync. From the user's perspective, this means that you will be able to share your data (such as calendar appointments, contact lists, and favorites) across all of your devices or services and with anyone else that you choose, regardless of infrastructure or organization. FeedSync is particularly useful for scenarios in which there are multiple masters and/or asynchronous updates. For example, FeedSync could be used to share your work calendar with your spouse--either of you could enter new appointments, even if not currently connected. Similarly, FeedSync could be used to synchronize a set of calendar entries among a group of people, each working in a different company and using different infrastructure.

What are the end user benefits of FeedSync?

There are two primary benefits for end users:

• FeedSync unlocks your data to make your stuff yours by enabling two-way synchronization over the web.
• FeedSync improves your publishing and sharing experience by enabling reliable one-way synchronization over the web.

See the introduction on http://feedsync.org for more details.

Why did you change the name?

We wanted to have a name that matched the simplicity of the concept. It’s about synchronization through feeds, hence “FeedSync”.

What is the FeedSync specification?

FeedSync is a specification that extends existing formats such as RSS or Atom from unidirectional to bidirectional information flows. This version of the specification describes a “binding” for FeedSync to Atom and RSS; future versions of the spec are expected to include FeedSync bindings for other formats as well. FeedSync defines the minimum extensions necessary to enable loosely cooperating applications or services to use formats such as RSS or Atom as the basis for item sharing--that is, the bidirectional, asynchronous synchronization of new and changed items among two or more cross-subscribed feeds. For example, FeedSync could be used to share your work calendar with your spouse. If your calendar were published to a FeedSync feed, changes to your work calendar could be synchronized to your spouse's calendar, and vice versa. As a result, your spouse could see your work schedule and add new appointments, such as a parent-teacher meeting at the school, or a doctor's appointment. FeedSync allows you to synchronize any set of independent items (for example, calendar entries, lists of contacts, list of favorites, blogrolls) using simple RSS or Atom semantics. If you can publish your data as a feed, the simple addition of FeedSync will allow you to synchronize your data to any other application or service that implements the FeedSync specification.

Why release the 1.0 spec now?

We’ve been working with a number of implementers inside and outside Microsoft, and based on the feedback we received, we feel that the v1 specification is done.

Are you going to be bringing the FeedSync specification to a formal standards body?

Since the beginning, we’ve sought community input on the specification, and the FeedSync 1.0 specification reflects significant input from the web community. Our primary interest now is to work with developers to have a broad range of FeedSync implementations. If there is strong interest in the community in creating a formal standard based on FeedSync or FeedSync concepts, then we’d seriously consider participating in such an effort.

When should I use FeedSync as opposed to some other synchronization technology?

FeedSync is ideal for synchronizing data that can be published in an RSS or Atom feed. That includes collections of items such as calendar appointments, contacts, favorites, and news items. In addition, FeedSync is ideal for bidirectional, asynchronous synchronization, particularly for scenarios where multiple people can independently edit or create entries--where there is not a single “master” copy of the data and each end user has their own copy of the data. FeedSync was designed with simplicity in mind, and developers will find that implementing FeedSync synchronization is easy, especially for an application that already supports RSS or Atom.

How is FeedSync related to the Microsoft Sync Framework?

FeedSync is primarily a specification: an algorithm and format that describes how any two endpoints can synchronize data. The Microsoft Sync Framework is primarily an implementation: it’s a code library that makes it easy to produce and consume FeedSync feeds.

Are there any license restrictions to using FeedSync?

Microsoft has released the FeedSync specification under the Creative Commons license. This license lets others remix, tweak, and build upon the specification even for commercial reasons, as long as they credit Microsoft, and license changed specifications under the same terms. Read this for more information about the Creative Commons license.

There is a separate patent promise called the Microsoft Open Specification Promise available to parties interested in implementing software that conforms to the FeedSync specification. This patent promise is available here.

Why did Microsoft use the Open Specification Promise approach for Feed Sync?

It was a simple, clear way to assure a broad audience of developers and customers that the specification could be used for free, easily, now and forever.

Has the Open Specification Promise been used for other Microsoft specifications?

Yes. More details are available at http://www.microsoft.com/interop/osp/default.mspx.

What is the Open Source community's opinion of the OSP?

The Open Source community has been very positive about the OSP. You can read specific comments here.

Why is Microsoft using the Open Specification Promise in conjunction with the Creative Commons Attribution-ShareAlike License?

The Creative Commons license is a copyright license vehicle for materials such as specifications. The Open Specification Promise provides a separate patent promise to assure a broad audience of developers and customers that the specification could be used for free, easily, now and forever.

What’s new in the 1.0 version of the FeedSync Spec?

Since the 0.93 version of the spec, we have made a number of small revisions and clarifications based on feedback. We also removed the “unpublished” element, and slightly changed the merge algorithm to better match the original intent of the spec.

Does this mean that you’re done working on FeedSync?

The first version of the base specification is done. We are excited to work with the community to help people deliver FeedSync implementations. We will continue to work with the community to develop and deliver additional specifications and guidance related to protocols, authentication, and the other features required for an end-to-end implementation.

Technology

How does FeedSync work?

FeedSync defines new XML elements that add synchronization information to items in an RSS or Atom feed. These new elements enable FeedSync applications conforming to the specification to implement bidirectional feeds. In other words, two endpoints can mutually publish and subscribe to each other's feeds. When changes are made in one endpoint, they are propagated to the other and vice versa. The new XML elements described in FeedSync enable feed readers and publishers to generate and process incoming item changes in a manner that enables consistency to be achieved. In order to accomplish this, FeedSync introduces concepts such as per-item change history (to manage item versions and update conflicts) and tombstones (to propagate deletions, and un-deletions). FeedSync also allows preservation of conflicting data to preserve data state for later resolution by end users.

What kinds of topologies are supported by FeedSync?

Any topology of feed interconnection is supported, from a hub-and-spoke to a star, to loops, to an arbitrary mesh. Item update propagation time or reliability might vary depending upon the topology, or the symmetry of feed update periods between cross-subscribed feeds, but the ultimate consistency of all feeds is assured. No "master feed" is required; there is no "true state" retained in a centralized manner.

How many endpoints can participate in FeedSync synchronization?

Any number of applications and devices can participate, representing any number of users. A single collection of items can be shared by two people or two thousand, each being a potential reader or writer.

Can endpoints make changes asynchronously?

As in standard RSS and Atom, feeds can be updated asynchronously. There is no requirement that changes be made online in order to assure consistency.

Does this mean that I can sync an RSS feed to an Atom feed?

While this is possible, because of the differences between RSS and Atom, we recommend that applications choose either RSS or Atom feeds to use for sync, but not both. For instance, a feed publisher could provide a FeedSync enabled RSS feed for two-way sync, and still provide a non-FeedSync Atom feed for one-way publishing, or vice versa.

What protocols does FeedSync support?

The focus is on the data format; HTTP/HTTPS is not required as a transport protocol. As long as a publisher's feed files and their dependencies (such as enclosures) can be transported to subscriber (for example, through a store-and-forward relay), any protocol will work.

Is FeedSync secure?

FeedSync defines a set of XML elements to express synchronization information in an RSS or Atom feed. FeedSync does not define a protocol or a means for communication. It is possible to transmit FeedSync information over any protocol, including secure ones such as SSL, WS-Secure, etc. For Atom feed security, see section 5 of the Atom Specification.

Does FeedSync scale?

Yes. FeedSync are designed to extend RSS and Atom feeds and as such scale to the same degree.

Implementation

Where can I find sample code?

Look at the FeedSync tutorials for Atom and RSS. The FeedSync Developer page also has pointers to sample code.

How often should a subscribing FeedSync application or service poll for Feed changes?

As in any polling system, the average latency that a user will experience to get a notification will be one-half of the polling interval. For some of the examples here, such as calendar synchronization, a polling interval of minutes is appropriate. For other use-cases, such as synchronizing a contact list or (perhaps) favorites list, a polling interval of hours is sufficient. The publishers can use the window attribute in the sx:sharing element to express the size of the window of change history kept by the publisher. Subscribers should poll at least this frequently.

How much item history should I keep?

Publishers should keep as much item history as is practical. For most of the scenarios in which FeedSync is used (calendar synchronization, for example) we recommend that the publisher keep all history. The FeedSync 1.0 spec allows for “sparse purging” of item change history. See the spec for details.

When should I purge deletion tombstones?

Deletion tombstones can be purged if they are older than the window of change history kept by the publisher.

Should the sx:sync id attribute match the atom:id element?

When you use FeedSync with Atom feeds, every Atom entry has a unique id element, and the sx:sync element within the entry element has a unique id attribute. The reason that we require the unique id attribute in sx:sync is because FeedSync will be used in contexts other than Atom (such as RSS, but other formats as well) where it is not required or common to have a unique id. It is reasonable (but not required) for both ids to be the same. FeedSync consumers should not assume that the ids are the same, and must be able to handle feeds where the two ids are different.

What does it mean that an endpoint id must conform to the Namespace Specific String syntax from RFC 2141?

Endpoint identifiers are used in two attributes: the “id” attribute in the sx:sync element, and the “by” attribute in the sx:history element. The requirement in section 2.1, item 1 states that “All endpoint identifiers MUST conform to the syntax for Namespace Specific Strings (the NSS portion of a URN) in RFC 2141.” In practice, what this means is that the endpoint id could be a simple string like “ABC123”, or it could be a URN such as a UUID. Both examples meet the NSS syntax requirement. It is up to the application developer to decide which type of endpoint id makes more sense for their application. For simple applications, it might be possible to ensure that the “id” and “by” attributes are unique without having to use UUIDs. For more complex applications, the application developer might decide that a UUID or URL is more appropriate.

What’s the difference between partial and complete feeds?

The FeedSync spec differentiates between partial and complete feeds in order to improve communication efficiency. Consider the typical sync conversation between two endpoints: after the initial exchange of feed data between the two endpoints, each endpoint has a complete feed representing the full data set. Successive sync operations between the two endpoints would be more efficient if each endpoint had a way to only send the changed data to the other side. This is the role of partial feeds. When an FeedSync consumer reads a partial feed, it views that feed as a set of changes to incorporate into the complete data set. Likewise, an FeedSync publisher produces a partial feed to indicate that the feed only contains a subset of the data. It is up to the application developer to determine exactly what to include in a partial feed. The way to indicate that a feed is partial is by including the sx:related element inside the sx:sharing element. We expect that another common way to improve efficiency after the first full sync is to have some filtering mechanism in the protocol used to retrieve or publish a feed. For example, HTTP has a conditional GET mechanism which allows a Web server to return data to a caller only if the page has changed, and then only return the new data. We would encourage anyone publishing FeedSync feeds over HTTP to use this mechanism. In this case, the FeedSync feed produced will be marked as “complete” because it represents the “complete” feed requested by the client.