Re: Candidate for full standard: RFC 4648 (The Base16, Base32, and Base64 Data Encodings)

[Carsten Bormann <[e-mail]>]

On 2025-10-10, at 15:41, Julian Reschke <julian.reschke=[e-mail]> wrote:
> 
> Ok, with 1) ruled out, how do we fix this? Do we have a summary what's needed?

I didn’t do a formal analysis here.

It would be interesting to see how documents are referencing 4648 (i.e., what qualifications they add) and how documents are referencing those documents because they already contain those qualifications (*).

The discussion we had about the “sloppy” variants of 4648 that led to four different base64 types in 9741 also was interesting [3] [4].
(9741 is one of the ~ 167 RFCs normatively referencing 4648.)

Also, the term “base64 classic” needs to be part of the STD.
(Please also read [5] — can we get rid of (strongly deprecate new adoption of) base64 classic without padding and base64url with padding?)

Why, oh why is base16 “case-insensitive”, DEFAULTING TO UPPERCASE?
(Can’t fix this now.)

Grüße, Carsten


(*) base64url probably is the most important encoding defined in 4648 today.
Cool people are noticing that base64url is best referenced from RFC 7515, which already has the qualifications [1] plus an implementation appendix [2].

[1]: https://www.rfc-editor.org/rfc/rfc7515#page-6

[2]: https://www.rfc-editor.org/rfc/rfc7515#appendix-C
(From a time when it might have seemed reasonable to base this on a base64 classic implementation; probably still a useful trick to know when stuck on APIs of the time.  In C#, of all languages...)

[3]: https://www.rfc-editor.org/rfc/rfc9741#table-2
[4]: https://mailarchive.ietf.org/arch/msg/netmod/2VZTkF4QmwsWrEovxo_m0I7I5tI

[5]: https://www.rfc-editor.org/rfc/rfc9741#section-2.1-6