As this specification standardizes Multihash, it would be beneficial to resume the effort to register it in the appropriate IANA registries, like the old repository did.
Specifically, I propose to include a section in the IANA Considerations based on the section of the original IETF draft:
<section anchor="mh-ni-hash-algorithm" title="The 'mh' Named Information Hash Algorithm">
<t>
This memo registers the "mh" hash algorithm in the
<eref target="https://www.iana.org/assignments/named-information/named-information.xhtml#hash-alg">Named Information Hash Algorithm</eref>
registry with the following values:
</t>
<t>ID: 49</t>
<t>Hash Name String: mh</t>
<t>Value Length: variable</t>
<t>Reference: this document</t>
<t>Status: current</t>
<t>
The hash value used to create ni URIs is formed by base64url-encoding (without "=" padding characters) the whole multihash, i.e. the hash function identifier, the digest length, and the digest value concatenated.
As an illustration, the <eref target="#tv-blake2s128">blake2s128</eref> example multihash would form this URI:
<figure>
<artwork>ni:///mh;0OQCEApOxvFinkkmLXCT4vgqMng</artwork>
</figure>
</t>
</section>Getting this registered will be beneficial for using Multihash as the unifying identifier for hash-based objects, useful in various content-addressing schemes. The original proposal can be found here.
As this specification standardizes Multihash, it would be beneficial to resume the effort to register it in the appropriate IANA registries, like the old repository did.
Specifically, I propose to include a section in the IANA Considerations based on the section of the original IETF draft:
Getting this registered will be beneficial for using Multihash as the unifying identifier for hash-based objects, useful in various content-addressing schemes. The original proposal can be found here.