Subject: Using I-D:s for tombstones and checksums

From: Niklas Lindström <[email-masked]>
Date: Wed, 18 Feb 2009 22:20:18 +0100

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

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Feb 2009 14:38:29 -0800

Hello Niklas,

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.

- James

---

From: "James Holderness" <[email-masked]>
Date: Thu, 19 Feb 2009 00:37:27 -0000

James M Snell wrote:
> 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

---

From: James M Snell <[email-masked]>
Date: Wed, 18 Feb 2009 17:18:19 -0800

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

---

From: Niklas Lindström <[email-masked]>
Date: Thu, 19 Feb 2009 14:40:18 +0100

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-masked]> 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

---

From: "James Holderness" <[email-masked]>
Date: Thu, 19 Feb 2009 18:06:58 -0000

> standards track. Would that be sufficient?

It doesn't matter to me whether it's informational or standards track - just 
that it's finalized. I was concerned that you might, at some point, revert 
back to the format you were using in drafts 2 and 3, which is not compatible 
with my implementation.

Regards
James