> 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.
