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] >
