On Wed, May 12, 2010 at 4:10 PM, James Snell <[email protected]> wrote: > > 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.
+1 > > 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] > >
