Re: Link Extensions. Need "md5" or some kind of hash.

[James Snell <jasnell@xxxxxxxxx>]

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 <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 [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
  jasnell@xxxxxxxxx