It seems that the authors have decent ideas, but don't have much experience with the subject matter. If you look at the assigned identifiers in the binary scheme, the authors believe that 32-bit truncated cryptographic hash functions are useful. 64-bit truncated cryptographic hash functions are essentially useless from a security standpoint, so the 32- and 64-bit variants would be better served by CRC-32C and CRC-64ECMA. If your standard contains a 64-bit truncated cryptographic hash, people without subject matter expertise will assume that it provides more than a modicum of security.

Also, the authors apparently vastly underestimate the utility of using Merkle trees. I used to be an engineer for LimeWire. Gnutella used SHA-1 as identifiers for the content. Unfortunately, this means only being able to integrity-check an entire large file instead of small pieces, or having to get a Merkle tree root out-of-band. LimeWire just got the Merkle tree root (plus one row of the tree) from the first peer it contacted for download data. This represents a simple denial-of-service poisoning attack where the attacker hands out Merkle trees corresponding to something like 10% of the blocks being corrupted. The clients would then repeatedly request the "corrupted" blocks from peers, until giving up, notifying the user that the download was corrupted, and most likely keeping around a file that had sections that weren't integrity checked. (Corruption really does happen. The TCP checksum is rather weak.) If they had used the Merkle tree root as the file identifier instead, then there would be no opportunity to trick the client into incorrectly associating the wrong Merkle tree with a given file.

If you're going to define a hash URI scheme, please incorporate Sakura trees (a provably secure hash tree scheme) of degree 2 with a fixed leaf block size. Leaving the block size variable leads to the Bittorrent problem where a single set of identical files has multiple identifiers and clients using hashing at one granularity can't share information with clients using hashing at another granularity. Merkle trees with a single standard leaf block size allow different levels of the tree to be shared to in effect give different granularities, without dividing resources due to the multiple identifier problem.

Also, in the case where there are 2^N + 1 blocks (or any other case where you'd be tempted to "optimize" by skipping a node at that level), please have a re-hashing node at each level for all blocks. This means that the final block (along with at most one extra hash per tree level) constitutes a cryptographic proof of the file length corresponding to the tree root. Otherwise, in order to avoid certain denial of service attacks, you also need to always put the length of the file as part of the URI, or the first client needs to send the entire bottom row of the Sakura tree.

Note that the Bittorrent Merkle tree format is broken in the same way that the original Gnutella tiger tree proposal was broken (fixed before implementation in the Gnutella case). Use Sakura trees. They're provably as secure as the hash function you use.