> On Oct 7, 2024, at 9:47 AM, Christian Huitema <huitema@xxxxxxxxxxx> wrote: > > My initial reaction was to wonder what this draft brought us. FNV is well known, documentation is widely available from multiple sources. There is for example a wikipedia page with plenty of details, largely sufficient for implementing it. > > I read the authors argument. FNV is widely used, referenced by multiple RFCs, and our standards would be better if these references were to an RFC rather than to a scattering of other sources. > > Maybe. The main issue with FNV is the multiplicity of variants. It is arguably more precise to refer to the variant as "section 3.5 of RFC xyz", than "64 bits variant 2 of FNV as defined in [2]". So yes, there is some value. > > On the other hand, that's not a whole lot of value. Whether that's enough value for adding to RFC series inflation is a good question for the IESG. > I have found it helpful when reading a RFC to implement it when there is code or pseudo-code available, and there’s a history of putting C (or similar) code into standards, eg: 1760 (s/key) which always struck me as a bit odd, but having seen how URL bit-rot occurs over time, I understand the desire to store it in a more permanent repository. (+1 on the question to the IESG, but not enough to send my own discrete e-mail) This is now off-topic, but is perhaps of value - having an appendix of code that is related is valuable, perhaps that is something to consider. Reference implementations could live there, including test cases. - Jared -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
