On 2022-02-03, at 23:12, Viktor Dukhovni <ietf-dane@xxxxxxxxxxxx> wrote: > > On Thu, Feb 03, 2022 at 08:59:26PM -0000, Adrian Farrel wrote: > >> I have read this draft and sent Patrik a few nits which he acted on. >> >> I run an application that uses the content of this document several times a >> day and it works well and is essential to my life. >> >> Please publish it. > > Why is it base-45 and not base-41? With (41**3) > 65535, just 41 code > points would suffice. What is the rationale for using additional code > points? I made this point in <https://mailarchive.ietf.org/arch/msg/cbor/gnX1E6qp0NttNjbuhephcG6BnSQ> and earlier in private mail to one of the authors. What I got back was apparently telling me that QR-Codes do offer 45 different characters, so hence base-45. This is, of course, equivalent to saying that ASCII offers 95 graphic characters, so with that argument base-64 should have been base-95 all along. I think we can all agree that the base-45 specification does not describe the best possible design. However, the approach is now widely used, e.g. in the European Digital Health Certificate, so the window to get this fixed has closed. Let’s get this published. Instead of trying to fix this document, another specification could be written that defines a base-41 (or base-40 + overflow) variant that could present fewer of the interoperability concerns base-45 does. Grüße, Carsten (Yes, I’m old enough to know what RAD50 [1] was. But that was about storing characters in integers; this is about storing integers in characters.) [1]: https://en.wikipedia.org/wiki/DEC_RADIX_50 -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
