This could probably help: http://tools.ietf.org/html/draft-snell-http-prefer-00
Request: ======== GET /feed Host: example.org Prefer: feedsync-tombstones Response: ========= HTTP/1.1 200 OK Vary: Prefer ... - James Joe Cheng wrote: >> Now, Steven indicates that their implementation will not include the >> tombstone by default. Clients that want tombstones would have to ask for >> them explicitly. > > This doesn't belong in the implementation, it belongs in the spec. > (Would this discussion even be taking place if opt-in had been in the > spec from the start?) I have advocated HTTP headers for opt-in the > past, but to avoid caching problems it seems like a link relation would > be better. > > I like the idea of building tombstone-aware clients on top of client > libraries that are not tombstone aware. The inline opt-in model seems > like the easiest way of achieving that, to me. > > By the way, it's worth noting that while we're all still more or less > talking about using tombstones in simple scenarios where AtomPub is > already being used today, like keeping a feed reader store synchronized > with a blog, Steven and his team is thinking of more ambitious > scenarios, such as (but not limited to) multi-master replication with > eventual consistency. >
