Updated draft... http://www.ietf.org/internet-drafts/draft-snell-atompub-link-extensions-04.txt
- James On Wed, May 12, 2010 at 5:53 PM, James Snell <[email protected]> wrote: > 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] > -- - James Snell http://www.snellspace.com [email protected]
