Matthew Gertner wrote:
Gordon Mohr wrote:
If you receive a file with ID "allpeers:1234:5678" from anyone other
than Mr. 1234, it's hard to know it's really that file.
Hash-based identifiers are easily verifiable. If anyone gives you a
file they say is <urn:sha1:QYSLZWXFLOXO6AGNCHK57T5GB5UHCCQC>, you can
easily check.
Sure, that's understood. We actually include the hash as part of the
file metadata for verification purposes.
My question, in a nutshell was: why use
<urn:sha1:QYSLZWXFLOXO6AGNCHK57T5GB5UHCCQC> rather than just
<sha1:QYSLZWXFLOXO6AGNCHK57T5GB5UHCCQC>?
Sorry, I misunderstood.
I have in the past preferred the 'urn:' prefix to both emphasize the
location-independent nature of these identifiers, and to hint that other
URNs might reasonably be usable in the same place (even if in practice,
software only supports one or a small number of hash-based-names).
I also once thought 'sha1' was more likely to get standards-body
approval as a registered URN 'NID' than top-level 'URI scheme'. But, as
'sha1' has never been officially registered as either, yet is still
widely understood, this factor probably isn't important.
As you've noted and per the W3C 'clarifications', the URL/URN/URI
distinction has become less important over time, and it's obviously
reasonable for URIs to behave like 'classical view' location-independent
URNs without beginning 'urn:'.
- Gordon
_______________________________________________
p2p-hackers mailing list
[email protected]
http://lists.zooko.com/mailman/listinfo/p2p-hackers
