Create a registry of hash functions

[nichtich]

It looks like every standard tries to define its own list of hash functions. As suggested in #46 (which argues for a broader kind of registry) we need a normative list of hash functions, each with URI and basic information such as names, link to specification, length of hashes etc. See list of hash functions in Wikipedia and most relevant the table of multicodec project (filter by column tag=multihash). IANA has used many lists of hash functions.

[iherman]

@nichtich that may be a good thing. But I would suggest such details should not be part of the charter; we should keep this issue open for the WG (if it gets off the ground) to consider.

[samuelweiler]

My expectation, and this applies to #46 also, is that it's not enough to just have a list - a registry. Adding entries to such a list typically requires a (hopefully brief) specification, not of the mathematics, but of the details - things like padding, wrapping, maybe other data marshaling details. An example is https://tools.ietf.org/html/rfc4868. So the WG may need to create both the registry and the (brief) specification docs that go with each entry in the registry.

[iherman]

My expectation, and this applies to #46 also, is that it's not enough to just have a list - a registry. Adding entries to such a list typically requires a (hopefully brief) specification, not of the mathematics, but of the details - things like padding, wrapping, maybe other data marshaling details. An example is https://tools.ietf.org/html/rfc4868. So the WG may need to create both the registry and the (brief) specification docs that go with each entry in the registry.

Yes, that should be the case.

The current charter proposal refers to the possible changes in the W3C process for the creation of registries. If that is adopted, then an official registry would also follow, per process, that line of thoughts.