how does tus name checksums?

[nigoroll]

Ref https://github.com/tus/tus-resumable-upload-protocol/blob/master/protocol.md#checksum

This question might sound picky, but would it not make sense for tus to define how checksums are named or refer to a 3rd party for that definition?
A clarification has already been added that names of hashes are in lower case, yet for example it is unclear to me if SHA3-224 would be called sha3_224, sha3-224 or even differently.

[Acconut]

Good point! There are no strict rules since this question has never arisen but in your particular case, I would stick to the rule of making it lowercase. So SHA3-224 becomes sha3-224.

[nigoroll]

sure, that would work. But I wonder if the project should have a simple registry (need not be more than a file with hash name identifiers)?

[Acconut]

I don't think we need a complete registry where we are required to keep up with the latest hashing algorithms. But maybe we can add a few more naming examples to the spec, that cover most naming conventions. What do you think?

[nigoroll]

I still think that a simple registry would leave the least amount of slack at very low overhead.

[Acconut]

I still disagree :) There are continuously new checksum algorithms added, which come in many variations. So, in some point of time, the registry would be outdated and we would be forced to always update it. I dislike the idea of having a registry which will be incomplete in some time. I think offering a generic approach to naming checksums is better.

[nigoroll]

I don't disagree with naming rules. But they still leave room for interpretation.

I just found the iana hash function textual names registry, which, unfortunately, does not have that many entries. So maybe we could have something like

• if the algorithm is in the registry, use that name
• otherwise, follow this naming convention

[Acconut]

Can you provide a few examples which would "leave room for interpretation"? Please don't take this as an offense, I am just not sure what variety of naming we have to deal with.

[nigoroll]

room for interpretation examples: sha3-256 vs. sha-3-256 vs sha3_256 vs. sha_3_256 etc.

[Acconut]

If you feel so strongly about this, please open a PR with your idea so we can understand what your concrete proposal is like.