On Tue, May 4, 2010 at 11:57 AM, Peter Keane <pkeane@xxxxxxxxxxxxxxx
> On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <bob@xxxxxxxx
>> 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  -- 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 . 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. 18.104.22.168 and 22.214.171.124) 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
>  http://martin.atkins.me.uk/specs/atommedia
>  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