Re: [Cbor] CBOR in QRcodes

Christian Amsüss <christian@amsuess.com> Wed, 23 June 2021 17:52 UTC

Return-Path: <christian@amsuess.com>
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 0BDF33A0766 for <cbor@ietfa.amsl.com>; Wed, 23 Jun 2021 10:52:46 -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 KhqdUoY9ZHQb for <cbor@ietfa.amsl.com>; Wed, 23 Jun 2021 10:52:41 -0700 (PDT)
Received: from prometheus.amsuess.com (alt.prometheus.amsuess.com [IPv6:2a01:4f8:190:3064::3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A329F3A0763 for <cbor@ietf.org>; Wed, 23 Jun 2021 10:52:41 -0700 (PDT)
Received: from poseidon-mailhub.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:a800:ff:fede:b1bd]) by prometheus.amsuess.com (Postfix) with ESMTPS id DA4884000E; Wed, 23 Jun 2021 19:52:37 +0200 (CEST)
Received: from poseidon-mailbox.amsuess.com (hermes.amsuess.com [10.13.13.254]) by poseidon-mailhub.amsuess.com (Postfix) with ESMTP id BDA70D7; Wed, 23 Jun 2021 19:52:36 +0200 (CEST)
Received: from hephaistos.amsuess.com (unknown [IPv6:2a02:b18:c13b:8010:7357:eb96:fa0b:c937]) by poseidon-mailbox.amsuess.com (Postfix) with ESMTPSA id 7897B7D; Wed, 23 Jun 2021 19:52:36 +0200 (CEST)
Received: (nullmailer pid 1141162 invoked by uid 1000); Wed, 23 Jun 2021 17:52:36 -0000
Date: Wed, 23 Jun 2021 19:52:36 +0200
From: Christian Amsüss <christian@amsuess.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: cbor@ietf.org
Message-ID: <YNN05Efh4/8Xyt63@hephaistos.amsuess.com>
References: <9704.1624378576@localhost>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="vjdjUBBLN2mRCkFm"
Content-Disposition: inline
In-Reply-To: <9704.1624378576@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/Dv_wmB6TTA3d3TYVQvJLxduL8BY>
Subject: Re: [Cbor] 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: Wed, 23 Jun 2021 17:52:46 -0000

On Tue, Jun 22, 2021 at 12:16:16PM -0400, Michael Richardson wrote:
> Thus my surprise at needing to encode CBOR in BASE-45.
> I wouldn't have thought that necessary, that one could go directly to binary.
> I imagine that the issue is one of what are the existing scanning equipment
> out there, in airports, customs booths, etc. Many of them pretend to be
> keyboards, and many of the systems they are connected to expect alphanumeric
> inputs into a form field (whether an HTML form, or a 3270 terminal).

Have you had any success with binary data on end user QR code readers?

To my understanding, the limitation is in what can be used with generic
cell-phone based QR code scanners. These, according to what I gathered
from around the base45 spec, seem to sometimes[citation needed] reject
binary data that is not UTF-8. The dispatch into apps of the OS appears
to be focused around interpreting the QR code values as URIs and then
registering prefixes (which may not be registered schemes but look like
them, or may be schemes including host names) for an installed app (or
even to go into the app store).

For example (just picking a random tutorial I found), [1] implies that a
snippet like

<intent-filter>
  <!-- ... -->
  <data android:host="example.com" android:scheme="httpsz" />
</intent-filter>

is used to make a particular class of QR codes open in a to-be-designed
app. Whether or not that is good use of URIs, or whether the schemes
used there are registered, is unfortunately secondary (given the
deployment base of The Two Operating Systems, and the user expectation
to point their OS's camera to the code and go). Practically, that
requires the QR codes to conform to (someone's view of) URI syntax.

To avoid wasting too much of the QR code's encoding space, given
that encoding a URI in ASCII alredy wastes >1bit/byte, and that one
available encoding provides 45 (largely URI-safe) symbols in an
efficient encoding, base45 (or some enhanced version thereof) does
appear useful.

BR
c

[1]: https://techpearl.com/blog/qr-code/index.html

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom