Hello! A while ago there was discussion about two link extensions I-D:s by James Snell:
* Link Extensions <http://tools.ietf.org/html/draft-snell-atompub-link-extensions-02>, and * Tombstones <http://tools.ietf.org/html/draft-snell-atompub-tombstones-05>. I'm quite eager for these to become RFC:s. The project I'm working in is getting close to roll out a big data integration project between swedish government agencies. Currently I use extensions from these I-D:s to manage a flow of entry updates and deletions (both of whom will be rare but necessary). Primarily we need the tombstones. Additionally, we use the "md5" attribute (and possibly the "etag") as a compact way of providing an explicit means of checking the correctness of transported documents. We use this very instrumentally, and we could define our own extensions of course. There are also more or less usable alternatives in the wild, but (from what I've seen) those fit the bill much less precisely. * For Tombstones, just using GData:s <gd:deleted/> marker in entries does do the job. So does the "deleted" attribute on the sync element defined in FeedSync (AFAIK). But these other specs incorporate *much* more than what we need, and I'd prefer not to overload the respective feed producers with the burden of filtering those specs just to get at this very specific need. (Our working implementation handles all three kinds; but I'd prefer to remove this choice.) * Regarding the Link Extensions, as mentioned we only use one (or two) of them. But I haven't found much of comparable simplicity and with the quality of specification I (IMHO) perceive this I-D has. (Though I'd perhaps prefer if it was possible to supply checksum and algorithm separately, as seen in some of the alternatives mentioned below). There's the Yahoo Media RSS extensions, or going all the way to embed XML-DSIG-chunks just to mark the links with checksums (I think, the semantics of DSIG:s seem very complex for this simple case). I also recall seeing some extensions for md5/checksum while "googling". Still, neither have seemed better to supply to the feed producers. (Admittedly, if GData had also defined a checksum extension (for both atom:content and atom:link) I'd probably just go with GData pieces for all of this, for better or worse.) One resort might be to keep on using the extensions of these I-D:s regardless of that such a practise is formally inappropriate. That or just remint namespaces for them and keep this usage "in-house" (as big as this "house" might be). However, this will divert what would otherwise be (what I hope to be) a concrete usage, which could promote wider adoption if these where already accepted RFC:s. (I also fear that an effort from us (we have limited resources) to specify equivalents of these ourselves and publish publicly is much less likely to be adopted than these already ongoing I-D:s.) Is there any way forward in this? I'd love to supply time to get these accepted as RFC:s, but I don't know (at all) what that would entail. Or is there simply not enough interest to push them forward? Best regards, Niklas Lindström
