I really don't want to be going down the road of requiring HTTP header equivalents in the Atom feed, etc. All I want is the ability to specify a hash of whatever it is that is being linked to. It could work in both link and content elements and one could easily use the Content-MD5 header to verify whether or not the resource referenced has been modified since the time it was included in the Entry.
The URI and the length of the file do not guarantee that the content has not changed and yes, I had considered this as a possible non-core extension but wanted to float it as a core item first. On Sat, 08 Jan 2005 15:02:27 -0500, Robert Sayre <[EMAIL PROTECTED]> wrote: > > Bill de hÓra wrote: > > > > > > >> <link rel="enclosure" href="http://example.com/somefile.mp3"; > >> hash="{generated_hash_value}" > >> hashalg="{uri_identifying_the_hash_algorithm_used" /> > >> > >> The hash and hashalg attributes would be optional but MUST appear > >> together. > >> > >> Thoughts? (If we have more than two people respond favorably to this, > >> I'll write up a Pace for it) > > > > > > > > Seems like a good idea - would it be possible to move them into elements? > > > Well, Content-Length lives in the attributes as "length", but I don't > think we need to make a home for every HTTP header. Content-MD5 will > work just fine; it would probably be wise to send a HEAD request before > automatically downloading a giant mp3. Furthermore, you'll get a good > enough identifier by concatenating the URI and the length. Something > more accurate will require a HEAD request. Thirdly, there's absolutely > no reason to have this in core. > > Robert Sayre > > -- - James Snell http://www.snellspace.com [EMAIL PROTECTED]
