James, thanks for updating and revising this draft! I would strongly encourage you to make the markup more expressive and flexible by supporting "a generic hash attribute with an internal structure for specifying algorithm and value". Actually, I would suggest that you extend this a bit further to include a specification of the encoding for the hash value.Thus, I would suggest the following pattern:
hash_algorithm.encoding.hash_value Alternatively, you could define a single, required hash_value encoding. (Which wouldn't be too bad a thing to do.) Clearly, there should be a registry of hash_algorithms as well as encodings (if supported). In your blog post, you mention that clients might tend to rely on the value returned by the Content-MD5 header. While this may be reasonable for HEAD requests, clients should probably not trust the remote server when doing GETs; they would be well advised to recompute the hash to ensure that the remote server isn't lying about the hash (there are quite a number of useful, but often deceitful, reasons why this might happen). Also, please note that it should be possible to include a hash value which uses a different hashing algorithm and encoding than is used by the Content-MD5 implementation. Thus, for any particular web resource, we might have quite a number of possible hash/encoding combinations and, in some cases, even have two hashes available for a single GET (i.e. The Content-MD5 header value and perhaps an SHA1/base64 hash specified in the link.) You might make a note about some of these odd cases in your security considerations section. bob wyman On Wed, May 12, 2010 at 12:42 PM, James Snell <[email protected]> wrote: > Updated the Link Extensions Draft... > > http://www.snellspace.com/wp/2010/05/atom-link-extensions/ > > http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-03.txt > > - James > > On Tue, May 4, 2010 at 10:54 AM, 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. > > 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] >
