Subject: Re: Standardizing Firefox's Implementation of Link Fingerprints

From: [email-masked] (Anthony Bryan)
Date: Tue, 03 Jul 2007 18:15:35 +0000

-------------- Original message ----------------------
From: "Mark Baker" <[email-masked]>
> 
> On 7/2/07, Roy T. Fielding <[email-masked]> wrote:
> >
> > On Jul 2, 2007, at 4:21 PM, Edward Lee wrote:
> > > For Firefox 3, there are patches [1] that implement Link Fingerprints,
> > > which provide automatic resource verification for URIs that look like
> > > http://site.com/file#hash(sha256:abc123) so that link providers can be
> > > sure that end users download the exact file that the provider intended
> > > (and not a trojaned download).
> >
> > Identifiers should not be abused in this way.  Adding metadata to a URI
> > that is orthogonal to its identifying purpose duplicates the space of
> > references and splits the power of the resulting resources.  The same
> > task can be accomplished better by specifying the hash in an attribute
> > of the link/anchor instead, and deploying that is far less likely to
> > confuse existing clients.
> 
> Exactly my thoughts.  It might look like this;
> 
> <a href="http://site.com/file" hash="sha256:abc123">the file</a>

There's the hash attribute: http://wiki.whatwg.org/wiki/Link_Hashes

Besides that for making automatic use of full file checksums, there is a hash microformat, and these link fingerprints, both of which are basically unused and also the Content-MD5 header and metalink which are in use. 

At some point/file size, a full file checksum is only so useful. It can tell you if there were 0 errors, or some, but no way to find where the error was so it can be repaired instead of re-downloading the whole file from the beginning. metalink contains full file checksums and also partial file checksums for repairing downloads.

-- 
(( Anthony Bryan ... Metalink [ http://www.metalinker.org ]
  )) Easier, More Reliable, Self Healing Downloads

---

From: [email-masked] (Anthony Bryan)
Date: Wed, 04 Jul 2007 06:54:04 +0000

-------------- Original message ----------------------
From: Travis Snoozy <[email-masked]>
> As to why it's bad to try and add a feature to the URL syntax in this
> way -- see the metalink discussion that rattled through the list back
> in April[1]. Now, imagine that syntax, plus the hashing syntax. How
> would you make them work together? Could they? Would *you* want to look
> at a link like that?

That stuff for metalink was based on the original Link Fingerprints syntax. You're right, it wasn't pretty. We tried it because it was taking so long for clients to support the XML metalinks & hoped it could be used in the transition until people were familiar w/ metalinks. There didn't seem to be a real need for it either and it didn't simplify things, it was just easier to have a direct link to a metalink.
 
> Really, what it comes down to, is we need a full file format for richly
> describing links. And, in fact, we have such a format -- RDF. The
> entire point of RDF is to say "Hey, see this resource? Here's a whole
> bunch of information about it." 
> ...
> Yes, if metadata is put into a file, it's not part of the URL anymore.
> However, URLs are just bad, bad, bad ways to shuffle _lots_ of data
> around. Ideally, URLs that correlate to a document with complicated
> extra-URL information would actually point at a metadata file. This is
> how, e.g., ASX works: you get a link to the file, then your media
> player opens that file, sees a few more links and follows them. The
> process can repeat, and metadata is thrown in all along the way. It's a
> little extra work for humans who want to chase down the "last hop" link,
> but it's still all human-readable.

metalink stores metadata about a resource in an XML format [1]. If there's anything missing that would be useful, let us know.

Clients are finally starting to have fun with this metadata (checksums, alternate links, description, version, publisher, license, logo, OS, etc). Also, there's an RDF version [2] of metalink by Dan Brickley.

[1] http://en.wikipedia.org/wiki/Metalink#Example_.metalink_file
[2] http://www.geospatialsemanticweb.com/2007/03/11/metalink-meets-rdf-and-sparql