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

From: Russ Housley <[email-masked]>
Date: Thu, 3 Feb 2022 15:54:04 -0500

I have read and implemented this draft.  Please publish it.

Russ

> On Feb 2, 2022, at 7:25 PM, The IESG <[email-masked]> wrote:
> 
> The IESG has received a request from an individual submitter to consider the
> following document: - 'The Base45 Data Encoding'
>  <draft-faltstrom-base45-09.txt> as Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits final
> comments on this action. Please send substantive comments to the
> [email-masked] mailing lists by 2022-03-02. Exceptionally, comments may
> be sent to [email-masked] instead. In either case, please retain the beginning
> of the Subject line to allow automated sorting.
> 
> Abstract
> 
>   This document describes the Base45 encoding scheme which is built
>   upon the Base64, Base32 and Base16 encoding schemes.
> 
> The file can be obtained via
> https://datatracker.ietf.org/doc/draft-faltstrom-base45/
> 
> No IPR declarations have been submitted directly on this I-D.

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 3 Feb 2022 20:59:26 -0000

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.

Adrian

-- 
last-call mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/last-call

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 Feb 2022 17:12:44 -0500

> day and it works well and is essential to my life.

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?

-- 
    Viktor.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 3 Feb 2022 23:23:33 +0100

> points would suffice.  What is the rationale for using additional code

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

---

From: John C Klensin <[email-masked]>
Date: Thu, 03 Feb 2022 21:51:03 -0500

--On Thursday, February 3, 2022 23:23 +0100 Carsten Bormann
<[email-masked]> wrote:

>...
>> 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/gnX1E6qp0NttNjbuhe
> phcG6BnSQ> 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.

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.

> 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.

Yes to the latter.   For "best possible" see below.

> 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.  There are also arguments for compactness,
especially compactness of the encoding for characters that are
likely to appear together when more of Unicode it used -- that
is the reason that drove the Punycode encoding for IDNA.   I
suggest one can determine "best" only by stating a set of
criteria (or selecting an application that will generate them)
and that different, equally reasonable, criteria will yield
different "best"s.  There is, however, one other issue: 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.  So, my response to a base-41 suggestion would be,
"well, sure, but do we really need another one of these", or,
put a bit differently, "if we count the interoperability issues,
the possibility of incorrect decoding by wrongly guessing which
system is in use, and the need to carry around additional code
to deal with an additional scheme as costs, what are the
benefits that outweigh those costs".

For the present document, it is implemented, it is deployed, it
is in heavy use in some important applications, and, even if it
were appropriate to ask those questions, it would be too late.
So let's get it published and move on... whether moving on
involves yet more systems of this type or not.

   john

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Feb 2022 11:10:10 +0100

> 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.

> 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
> 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