Re: [Cbor] Use and development of draft-faltstrom-base45 (was: Re: CBOR in QRcodes)

Carsten Bormann <cabo@tzi.org> Fri, 25 June 2021 21:34 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B2783A0A46 for <cbor@ietfa.amsl.com>; Fri, 25 Jun 2021 14:34:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBgaWSsu4ezq for <cbor@ietfa.amsl.com>; Fri, 25 Jun 2021 14:34:15 -0700 (PDT)
Received: from gabriel-2.zfn.uni-bremen.de (gabriel-2.zfn.uni-bremen.de [134.102.50.19]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE6C83A0A2C for <cbor@ietf.org>; Fri, 25 Jun 2021 14:34:14 -0700 (PDT)
Received: from [192.168.217.118] (p548dcc89.dip0.t-ipconnect.de [84.141.204.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gabriel-2.zfn.uni-bremen.de (Postfix) with ESMTPSA id 4GBVd05mNSz2xGs; Fri, 25 Jun 2021 23:34:12 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <000b01d769f9$a9dfab20$fd9f0160$@ewellic.org>
Date: Fri, 25 Jun 2021 23:34:12 +0200
Cc: =?utf-8?Q?Christian_Ams=C3=BCss?= <christian@amsuess.com>, Michael Richardson <mcr+ietf@sandelman.ca>, cbor@ietf.org
X-Mao-Original-Outgoing-Id: 646349652.2545559-d0c63e7bd550dd8fbbdbc40adccc9ea0
Content-Transfer-Encoding: quoted-printable
Message-Id: <4B35C787-4076-4982-A5FD-5AEB75B666D3@tzi.org>
References: <9704.1624378576@localhost> <YNN05Efh4/8Xyt63@hephaistos.amsuess.com> <000201d76914$53aa4890$fafed9b0$@ewellic.org> <YNWdchJRQRzm3I9j@hephaistos.amsuess.com> <25746.1624636305@localhost> <YNX/gD4ScCFnDmWW@hephaistos.amsuess.com> <000b01d769f9$a9dfab20$fd9f0160$@ewellic.org>
To: Doug Ewell <doug@ewellic.org>
X-Mailer: Apple Mail (2.3608.120.23.2.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/8ngjHjsrR7LDyneITEpY37u9rTk>
Subject: Re: [Cbor] Use and development of draft-faltstrom-base45 (was: Re: CBOR in QRcodes)
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Jun 2021 21:34:19 -0000

On 2021-06-25, at 21:38, Doug Ewell <doug@ewellic.org> wrote:
> 
> My understanding is also that base45 is intended for the specific alphanumeric encoding for QR codes defined in ISO 18004:2015, sections 7.3.4 and 7.4.4.
> 
> Given that, whether an alphabet of size 45 is maximally efficient, or whether a "better" alphabet could have been chosen, is really not at issue. There is an installed base (QR codes have been around for more than two decades), so there is a significant and probably prohibitive cost to changing it.

Of course, just like base32 and base64 are not out to change RFC20 (aka ASCII).

Both do take a well-deliberated subset of ASCII (32 and 64 characters, respectively) and define a representation of byte strings in these.

The debate is about a sensible choice of a selection of characters out of the 45-character QR-code character set for a basexx that is useful for representing byte strings in the QR-code character set.

> I do note, however, that the specific application described in draft-faltstrom-base45 — encoding 16-bit integral values in three base45 code units, and encoding a trailing 8-bit value in two — does not appear to be part of the standard, so that part could lend itself to "enhancement," although I'm not clear exactly what that would be.

That is the part we are talking about.  Just as we usually don’t use base128, even if that is well-supported by the 128-character ASCII character set (which, as I said, we are not planning to change with base64 and friends), we shouldn’t use base45 for the 45-character QR-code character set.

> Creating incompatible branches of base45 for different applications (such as URIs) still seems like a decision not well supported by experience.

Well, having base45 in the first place is, er, not really a well thought-out decision.

Grüße, Carsten