Re: [Last-Call] Last Call: <draft-faltstrom-base45-09.txt> (The Base45 Data Encoding) to Informational RFC

[Carsten Bormann <[e-mail]>]

>> 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.
> 
> That ASCII example is interesting because the Base-64 design,
> IIR, carefully considered and eliminated characters that were
> not in ISO 646-BV and then settled on upper and lower case
> letters and the digits and then, to get to 64, added "+" and "/"
> (and "=" for padding).  Almost any of the other 30 graphics
> would have raised issues.

Which is exactly what not has been done for base45 — this just uses the entire character set offered by QR-Codes in character mode.

>> 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.
> 
> Well... One can probably make a case for almost any encoding of
> this general type.  

Well, this happened for base64, which was revisited for in-URL usage, and yielded base64url.  I’m essentially asking for a base45url, except that this is easier to do with a base41/base40-with-overflow approach.

> every
> new ASCII-compatible encoding we introduce is a new problem for
> universal interoperability, a problem that gets more serious if
> one cannot easily tell them apart by simple examination of the
> strings.  

What we’d probably do for the base41/40 encoding is describe in more detail how that is embedded in various environments.  Triggering use case could be the URI generated from a standard smartphone camera QR-Code reader (base45 is used with “HC0” for EDGC, but that isn’t even registered, maybe because the URI mapping is broken with % and space in the character set).

But again, I’m writing this because I believe this base45 should be published despite its flaws (so I can refer to it as “legacy base45” later… :-).

Grüße, Carsten