Hi James, and James! Great, that sounds sufficient for our needs.
(As far as I understand Informational RFC:s, they have the potential of wide-spread adoption, right?. Or is e.g. RFC 1591 an exceptional case? (I'm just getting this from <http://en.wikipedia.org/wiki/Request_for_Comments>.)) It's good to hear that there's another implementation using "deleted-entry". While we intend to opensource our implementation, it's not going to happen yet for a while. (For the interested: our implementation is basically a feed-archive (RFC 5005) collector; sort of a one-way sync to a central registry/repository. The tombstones work perfectly for signalling removal of mispublished resources. I've also come across other scenarios (some regular "unpublish" needs) where I would have recommended "deleted-entry" had it been stable. So I definitely think it is good as it stands.) .. One additional thing that *may* be useful though, is if it was allowed to include the actual deleted entry *within* the deleted-entry element (kind of like GData:s entryLink (<http://code.google.com/intl/en/apis/gdata/elements.html#gdEntryLink>) does it). Perhaps in an at:copy or at:trash element.. This would be for scenarios where the consumers have "failed" to remember e.g. which linked representations the entry entailed. I haven't seen this need myself though, and in regular scenarios I assume this information is at best irrelevant, at worst exposing unwanted, false or even malicious information (as per the prior discussions of whether markers within plain entries are good enough for deletions). But I'm satisfied either way. Just wanted to mention this for consideration. Best regards, Niklas (And thanks by the way, for all your work on these things.) On Thu, Feb 19, 2009 at 2:18 AM, James M Snell <[email protected]> wrote: > > Good to know. I could push the draft forward with Informational status. That > would allow us to finalize it and get it an RFC# but it wouldn't be > standards track. Would that be sufficient? > > - James > > James Holderness wrote: >> >> James M Snell wrote: >>> >>> As with several of the other drafts I put out a while back, I let these >>> expire because at the time there was no solid consensus or significant >>> demonstrated interest. Was hoping that someone other than myself would go >>> out and get some implementation experience on these issues. I can certain >>> help to move them forward if there's enough interest. >> >> FWIW, I've had a working implementation of the deleted-entry element in an >> internal build of Snarfer which I've been using for months now. It should be >> more-or-less compatible with drafts 1, 4 and 5. >> >> However I believe we decided against including the code in our public >> release because the future direction of the spec seemed very much up in the >> air at the time. If the spec ever did get finalised in a form resembling >> draft 5, it would be easy to ship it in our next release (although, to be >> honest, I'm not sure that's going to happen anytime soon). >> >> Regards >> James >> >> > >
