Brian Smith wrote:
In particular, without the timestamp(s) it is hard to see how the tombstones fit in with feed paging and date-range-based queries.
I don't get this, but if you really need a date, I believe the original draft has a "when" attribute that should be suitable. Worst case you can add whatever you need as a child element.
If you trust the aggregator, then you can have a policy of matching tombstones and entries by (source, id).
Bare in mind that the aggregator needs to propogate source elements from the aggregated feeds. So trusting the aggregator means trusting every feed that is aggregated, plus every future feed that might be aggregated. That's an awful lot of trust. And you're asking that of the user who is subscribing to the feed. I'd love to see the text for that checkbox.
If you don't trust the aggregator, and you really need to verify the entry was deleted, then you can use the source metadata to look at the original feed to see if it contains the tombstones or not.
Theoretically, sure. Personally there's no way I'm going to download a whole new feed for each tombstone just to check if it's real. What if the tombstone isn't in the feed anymore? If the feed supports history do you start downloading archives to see the tombstone is in one of the archives? How many megabytes of data do you download before you give up?
This looks like a potential DOS attack to me. It's just not worth the effort, IMHO.
Regards James
