Re: [Ksummit-discuss] Fwd: [TECH TOPIC] QR encoded oops for the kernel

[Josh Triplett <josh@joshtriplett.org>]

On Wed, May 14, 2014 at 10:20:52AM +0200, Johannes Berg wrote:
> On Tue, 2014-05-13 at 13:18 -0700, josh@joshtriplett.org wrote:
> 
> > > Base32 does sound good until you realize that it requires roughly 20%
> > > more space than Base64 does. We would need some calculations to
> > > decide if we were to go down this path.
> > 
> > QR has several encoding modes; it doesn't matter that base32 uses more
> > space in terms of characters, because QR itself has an alphanumeric
> > encoding mode that only uses 5.5 bits per character to encode 45
> > possible alphanumeric/symbol characters.  base64 wastes far more
> > relative to bytes (6 versus 8 bits) than base32 wastes relative to QR
> > alphanumeric (5 versus 5.5 bits).
> 
> This subthread is kinda going on a tangent now, but ...
> 
> The valid characters seem to be
> 
> 0-9A-Z $%*+-./:
> 
> so you'll need to be careful to not use a ? for URL parameters [1],
> [1] i.e. the previously suggested https://oops.kernel.org/?qr=... will
> not work

https://oops.kernel.org/qr/...
Or:
https://qr.kernel.org/...

> Since you really wouldn't want to use % due to URL-encoding
> difficulties, and $ and space also seem a bit questionable, you could
> still extend the encoding alphabet to at least base36 (0-9A-Z) and even
> add +-./: without much difficulty to get to base41.

space and % seem like the only ones that need avoiding, both because of
URL-encoding issues; you could use all six of $*+-./: , giving 43 of 45
possible characters.  On the other hand, is it worth the complexity of
using base43 encoding rather than base32?

- Josh Triplett