The key challenge is that the digests contained in the atom:link cannot be viewed as being authoritative and only reflect a point-in-time value that may only be true for the producer of the Atom feed. There are many factors which influence whether the same hash value can be generated for the linked resource. If the hash-value happens to match... fantastic. If the hash-value doesn't match, then the feed consumer knows that they need to do more work to figure out what happened... including performing a more authoritative check of the resource.
On Mon, May 17, 2010 at 1:18 PM, Bob Wyman <[email protected]> wrote: > I'm curious about the vigor with which you seem to be denying the utility of > hash functions in integrity checking when you write: > > hash attribute values MUST be considered to be strictly advisory and cannot > be used reliably as an end-to-end integrity check. > > I am, of course, aware of the limitations of both hash functions and > end-to-end links, but it seems to me that the real risk here is limited to > false-negatives. (i.e. If hash values don't match, I can't really be sure > that I haven't linked to the correct resource.) However, it seems like the > risk of false-positives is no greater than in any other hash-based system. > (i.e. if the hash values do match, then I've can be reasonably, but not > completely, assured of integrity.) > I think I understand the standard issues. Is there something more exotic > that I'm missing? > bob wyman > > On Mon, May 17, 2010 at 3:47 PM, James Snell <[email protected]> wrote: >> >> Ok, draft is updated with the new syntax for the hash attribute. >> >> http://www.ietf.org/staging/draft-snell-atompub-link-extensions-05.txt >> >> There is also one additional 'media' attribute added. I wanted to wait >> to add it until after I was sure the other three attributes were fine. >> The 'media' attribute serves the same purpose as the 'media' attribute >> on HTML5 links... the value is a media query. For example: >> >> <link href="foo" media="handheld and (min-width = 20cm)" /> >> >> The use case is to be able to provide multiple links targeted at >> specific types of media... e.g. screen, print, mobile devices, etc. >> >> Another change that I am contemplating making is introducing a new >> child element for the atom:link element that would allow it to serve >> the same basic purpose as the GData feedLink and entryLink elements >> except with greater flexibility... specifically, it would allow a >> representation of the linked resource to be dropped directly into the >> link element, e.g. >> >> <link rel="alternate" href="foo" type="text/plain"> >> <data type="text">this is a representation of the data</data> >> </link> >> >> <link rel="alternate" href="foo" type="image/jpeg"> >> <data type="encoded">abc...def==</data> <!-- base64 --> >> </link> >> >> <link rel="alternate" href="foo" type="application/atom+xml"> >> <data type="markup"> >> <feed>...</feed> >> </data> >> </link> >> >> Or something along those lines. >> >> Thoughts? >> >> - James >> >> On Sun, May 16, 2010 at 10:44 PM, Peter Keane <[email protected]> >> wrote: >> > On Sun, May 16, 2010 at 11:00 PM, Sam Johnston <[email protected]> wrote: >> >> Are the commas earning their keep? If they're unnecessary then remove >> >> them, >> >> otherwise LGTM. >> >> Sam >> > >> > I was going to ask the same question. (re: the commas) >> > >> > --peter >> > >> >> >> >> On Mon, May 17, 2010 at 7:36 AM, Bob Wyman <[email protected]> wrote: >> >>> >> >>> +1 LGTM >> >>> >> >>> On May 16, 2010 11:29 PM, "James Snell" <[email protected]> wrote: >> >>> >> >>> Ok, although I seriously dislike having to do additional parsing on >> >>> attribute values, the arguments made so far are valid and parsing hex >> >>> encoded hash digests is -- fortunately -- quite simple to do. So let's >> >>> go with the following syntax... >> >>> >> >>> hash = attribute hash { hash-list } >> >>> hash-list = # ( token ":" 1*HEX ) >> >>> >> >>> The token and HEX productions are defined by RFC2616... >> >>> >> >>> The spec would defer to the existing IANA registry for hash functions >> >>> to define the "tokens" >> >>> >> >>> This would result in a syntax of... >> >>> >> >>> hash="md5:abc...xyz, sha-1:123...567, sha-512:xyz...abc" >> >>> >> >>> This seem acceptable to everyone? >> >>> >> >>> - James >> >>> >> >>> On Sat, May 15, 2010 at 11:46 PM, Sam Johnston <[email protected]> wrote: >> >>> > James, >> >>> > In consideration o... >> >> >> > >> >> >> >> -- >> - James Snell >> http://www.snellspace.com >> [email protected] > > -- - James Snell http://www.snellspace.com [email protected]
