tus / tus-resumable-upload-protocol

Open Protocol for Resumable File Uploads
https://tus.io
MIT License
1.48k stars 103 forks source link

how does tus name checksums? #156

Open nigoroll opened 4 years ago

nigoroll commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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

Acconut commented 4 years ago

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 commented 4 years ago

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

Acconut commented 4 years ago

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 commented 4 years ago

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

Acconut commented 4 years ago

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