W3C home > Mailing lists > Public > uri@w3.org > April 2010

Re: URIs in QR

From: Erik Wilde <dret@berkeley.edu>
Date: Fri, 09 Apr 2010 10:13:36 -0700
Message-ID: <4BBF6040.6010601@berkeley.edu>
To: uri@w3.org
CC: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>, Dan Brickley <danbri@danbri.org>, Sandro Hawke <sandro@w3.org>, Bob Aman <bobaman@google.com>, wot@webofthings.com
hello martin.

> Living in Japan, I'm a bit surprised that QR codes suddenly seem to be 
> so 'in'. There are definitely quite a few around here in Japan, but not 
> that all the walls are covered with them.

i don't think there is any sudden change, but maybe because we missed 
the "QR on feature phones" phase, now the move to catch up with 
smartphones is a bigger leap.

> The extraction of URIs from QR codes seems to work about as well (or not 
> well) as extraction of URIs from email. Definitely your email reader's 
> mileage may vary quite a bit with respect to what it recognizes and what 
> not.

agreed. and email programs certainly also have their problems with 
properly recognizing, decoding, and dispatching URIs.

> As for 'tying URIs/URI schemes to applications', some advice (and maybe 
> actual standards work if that prooves necessary) about how to avoid the 
> problems with URI scheme proliferation due to application proliferation 
> (what started with iTunes and now continues with iPhone and so on) would 
> be very helpful. I don't see much other items of work for this area, 
> because even in the PC world, it's the user's business of how to 
> configure this association.

the one thing that's different between email and QR is capacity and 
packaging. email has MIME so if i am attaching my vcard then there's a 
way how to do this and how to indicate the type. there is no such 
packaging for QR, and there are some conventions (business card 
conventions, for example, seem to exist in a variety of flavors), but 
email has a more robust structure for that. i see three main areas:

- how to encode and decode and process URIs: this mainly looks at how to 
properly encode and decode and process URIs, so that at least in theory 
QR readers behave well for http: and tel: and sms: and geo:

- how to encode and decode and process "rich text": no idea whether this 
should even be possible, but if something like email-style rich content 
(like http://www.flickr.com/photos/dret/4498124087/) should be 
encourages, then it would be good to have some recommendations for this 
as well.

- how to encode and decode and process self-contained data: this gets 
probably tricky because of size limitations. however, something like a 
business card probably is useful to have as QR, but in this scenario we 
need some way how to indicate a content type (maybe...).

> When QR codes were reasonably new here in Japan (must have been quite a 
> few years back), I looked into what W3C might be able (or need) to do 
> for them, but at that time, I got told that there was no pressing need 
> for further standardization. I don't know whether this might have 
> changed in the meantime.

this to a large extent depends on your personal opinions about what and 
when to standardize. but from what i have experienced just from looking 
what's out there and how it is working, it seems to me that the current 
situation certainly is less than ideal, creating unpredictable results 
and thus unsatisfactory user experiences when you try to use QR codes.

> What I seem to remember was that QR codes were defined only for ASCII 
> and for Shift_JIS; ideally, they should use UTF-8, of course.

i still have some basic QR reading to do. my current understanding is 
that on the lowest level (the ISO QR standard), QR can encode four 
different content types, numeric, ASCII, binary, and kanji. this alone 
may be unfortunate because then you cannot encode general unicode unless 
you create a convention to use binary and UTF-8 (for example). i am 
still catching up in these areas, but it seems to me that these are 
exactly the things that need to be clarified and documented. maybe it 
needs just clarification and documentation, but maybe there also is a 
need for producing new conventions; we'll see.

as an example that still confuses me a bit: http://✪df.ws/ez9 is a IRI 
and should somehow work, i guess. if i paste that into 
http://www.mskynet.com/static/maestro it complains that this is not 
ASCII (so both the URL and the RAW modes on that site seem to support 
ASCII only). if i paste it into firefox address bar for producing a 
google QR chart, it looks like this and sort of works:

http://chart.apis.google.com/chart?cht=qr&chs=150x150&choe=UTF-8&chld=H&chl=http%3A%2F%2F✪df.ws%2Fez9

it produces a URI that in some QR readers actually displays as the ✪, 
but on my iphone, for example, forwarding that URI to safari then breaks 
it. i don't know exactly where things are going wrong and it would take 
a lot more testing to figure out what's going on in various scenarios 
and what should be going on, but i think scenarios such as this should 
be well-defined and documented, and since all of this is basically the 
question how reliably web identifiers can be handled, the w3c might be a 
good candidate to support such an activity.

cheers,

dret.
Received on Friday, 9 April 2010 17:14:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:25:14 UTC