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
- [Cbor] CBOR in QRcodes Michael Richardson
- Re: [Cbor] CBOR in QRcodes Christian Amsüss
- Re: [Cbor] CBOR in QRcodes Michael Richardson
- Re: [Cbor] CBOR in QRcodes Doug Ewell
- [Cbor] Use and development of draft-faltstrom-bas… 'Christian Amsüss'
- Re: [Cbor] Use and development of draft-faltstrom… Michael Richardson
- Re: [Cbor] Use and development of draft-faltstrom… Carsten Bormann
- Re: [Cbor] Use and development of draft-faltstrom… Christian Amsüss
- Re: [Cbor] Use and development of draft-faltstrom… Doug Ewell
- Re: [Cbor] Use and development of draft-faltstrom… Carsten Bormann