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 >
