On Wed, May 12, 2010 at 12:53 PM, Bob Wyman <[email protected]> wrote: > 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 >
Hmm... for me, this immediately starts screaming overkill. I'd almost prefer to go the route of defining individual attributes for each hash algorithm... e.g. md5="..." sha256="..." Each using the basic hex encoding. The spec can define a handful of these for the most common hash algorithms and establish the pattern. New attributes for new algorithms can be added later. Just seems simpler. > 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] > > -- - James Snell http://www.snellspace.com [email protected]
