Should base64 advance alone or should it be part of a larger proposal?

[domenic]

Somewhat related to my worries in #6, I worry that working on a one-binary-encoding-per-proposal basis might have subpar ecosystem impacts. If base64 gets promoted to first-class language support, but base64url or hex require packages, that might not be the best outcome.

I understand from the discussions in #4 that the champions here don't like the API shape of https://github.com/lucacasonato/proposal-binary-encoding, but I think that proposal does a better job of putting multiple binary encodings on equal footing and ensuring they all get implemented together.

(It might also be worth doing some research on other binary encodings; base64, base64url, and hex are the ones I'm aware of from the research in https://github.com/lucacasonato/proposal-binary-encoding, but I guess the relevant RFC defines base32 as well, and I guess there are a lot of them: https://en.wikipedia.org/wiki/Binary-to-text_encoding )

[bakkot]

I intend to support both base64 and base64url in this proposal. Hex is the only other format which is particularly common, and I agree it probably makes sense to include it here rather than doing it as a follow-on. I've opened #8 to track that explicitly.

Base32 and UU also exist, but as far as I can tell mostly only historically - I haven't ever encountered either in the wild. Base85/Ascii85 is used in PDFs and git-patch but does not seem to be common otherwise. I don't think it makes sense to include any of those.

Just to look around at our fellows a bit:

• go supports base64, base32, hex, and ascii85
• python supports hex, base32, base64, and Base85, as well as the legacy binhex and UU formats
• java supports base64, and the widely used apache commons provides base16, base32, hex, and www-form-urlencoded
• ruby supports base64 as a first-class module and also supports hex and UU format specifiers in Array#pack and String#unpack
• rust supports hex as a format specifier
• PHP supports base64, hex, UU, and www-form-urlencoded
• C# supports base64 and hex

[domenic]

Elsewhere, @bakkot says that apparently Node.js's Buffer.from(x, "base64"), as well as CSP, support mixing base64 and base64 URL in the same string, when decoding. That might be a variant worth supporting in the API as well.