On Tue, May 4, 2010 at 2:08 PM, James Snell <[email protected]> wrote: > 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. >
Very much appreciated. Glad to see you back on atom-syntax. --peter > - 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] >
