Repository navigation
Should base64 advance alone or should it be part of a larger proposal? #7
Description
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 )
Activity
bakkot commentedon Jul 1, 2021
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:
domenic commentedon Jul 7, 2021
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.