I've noticed that Google has actually started using an etag attribute in their API which has roughly the same concerns about binding, etc. I'm a big fan of including as much metadata as practical possible without going overboard and think that a hash attribute (or set of hash attribute options not limited to md5) would be a good thing in general. I've been starting to dust off a few of the old I-D's this week starting with the tombstones draft (again) so perhaps I'll also pull out that link extensions draft and give it a do-over.
- James On Tue, May 4, 2010 at 11:57 AM, Peter Keane <[email protected]> wrote: > > On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <[email protected]> wrote: >> I find that I have a real need for the "md5" Link rel mechanism defined in >> James Snell's old Atom Link Extensions draft or something functionally >> equivalent. Basically, what I need to do is ensure that the "src" attribute >> on an atom.content element is pointing to a known version of a resource >> rather than simply to any resource that has the same URL as in the src >> attribute. I'm then going to sign the Atom entry that contains this "by ref" >> content element. > > There have been a number of discussion of such in the past on > atom-syntax -- usually focussed on James Snell's link extension draft. > You might also look at the Atom-Media extensions that came out of > activity streams work [1] -- no md5, but that'd be an obvious > addition. I think the MediaRSS spec is widely used, and it does have > an md5 as a <media:hash> element w/ @algorithm [2]. When I have had > need for it, I generally used a locally name-spaced attribute on > atom:link, although that's obviously a sub-optimal solution. > > The RESTful implications of such a use are (I think) somewhat > interesting. It creates a tight-binding (early binding) that is > somewhat at odds w/ the late-binding nature of REST. I think that's > why attributes on atom:link are always "advisory" and overridable (see > RFC4287 sec. 4.2.7.3 and 4.2.7.6) by what's actually at the end of the > wire. Another (probably impractical) approach is to have the resource > as actual content instead of just a link. > > --peter keane > > [1] http://martin.atkins.me.uk/specs/atommedia > [2] http://video.search.yahoo.com/mrss > > >> I've looked at the HTML5 RelExtentions Wiki but don't see anything there >> that looks like it does the job. >> Has anyone else needed hashed links in Atom? If so, what approach did you >> use to provide them? Is anyone aware of plans to introduce an "md5" or >> equivalent attribute to the HTML5 list? >> bob wyman >> > > -- - James Snell http://www.snellspace.com [email protected]
