So the key question is: what are the main algorithms we need to provide attributes for?
- James On Wed, May 12, 2010 at 2:41 PM, Peter Keane <[email protected]> wrote: > 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] >> >> > -- - James Snell http://www.snellspace.com [email protected]
