On Mon, May 17, 2010 at 4:41 PM, James Snell <[email protected]> wrote:
> 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. Actually, for the applications that I'm most interested in at the moment, such "point-in-time" values are exactly what I want. I want to be able to point to a specific version of a resource and say that if you read something that I did not, then you're not looking at the same version of the document that I saw. The best example would be something like a contract, petition or poll that I might "sign" by-reference. My signature would only be "valid" if the resource linked to is exactly the same as it was at the point in time when I generated the hash value that I later included in a signed Atom entry. bob wyman > 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] >
