[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Link Extensions. Need "md5" or some kind of hash.
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.
On Tue, May 4, 2010 at 11:57 AM, Peter Keane <pkeane@xxxxxxxxxxxxxxx> wrote:
> On Tue, May 4, 2010 at 12:54 PM, Bob Wyman <bob@xxxxxxxx> 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  -- 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
- James Snell