- From: Jakub Vysoky <jakub.vysoky@gmail.com>
- Date: Thu, 5 Mar 2020 14:54:22 +0100
- To: MXS Insights <mxsinsights@gmail.com>
- Cc: Wolf McNally <wolf@wolfmcnally.com>, Christopher Allen <ChristopherA@lifewithalacrity.com>, Leonard Rosenthol <lrosenth@adobe.com>, Credentials Community Group <public-credentials@w3.org>, W3C DID Working Group <public-did-wg@w3.org>
- Message-ID: <CAEO8NYwo8zuw=D1kx0kNg6EmYU6mK4i8Vf3OGSoYLNHtyWhgiQ@mail.gmail.com>
Another observer comment here> What works really well is using animated QR codes more like a rotating mechanism, when you have information with short time validity. It is used in the Czech Republic for electronic public transport tickets. Such short term signed messages is something very useful for DID and VC - I believe. On the other hand, it ends up with the need of little bit "custom" reader. For animated codes that are transferring more data in a sequence, the reader would have to be even more specialised. Which little bit defeats the purpose of having the least common denominator. But I agree QR has reasonable wide deployment and we should find ways how to benefit from that. Offline data transfer is important! On Mon, Feb 17, 2020 at 6:58 PM MXS Insights <mxsinsights@gmail.com> wrote: > Commenting as an observer on the WG. > > In a previous life I dealt a lot with barcodes (linear and 2D). One of > the big challenges with symbologies is that the larger they get the greater > occurrence of misreads. This is true with linear Code 3/9, interleaved > Code 2/5 and certainly 2D Data Matrix symbols. I was dealing with the > symbols in a production environment (high volume mail creation equipment - > 24,000 bills/hr). There were vendors in the market that were constantly > putting forward increase data density in the symbols and issues around > print quality, orientation, twist, misreads on in-between pieces all of > these impacted the overall production throughputs. > > There was another approach (which the company I worked for at the time) > put forward, that was a data minimization approach, putting only a > reference pointer in the symbology and then having unlimited data size in > the data file. The approach of increasing the information density is also > an issue that is facing some of the RFID manufacturers where they are > trying to stored specific data in the tag itself. The big challenge there > is that there is never enough space. Nature abhors a vacuum and a symbol > will never be able to hold all the information you would like. > > I would agree with Phil here, making it bigger, chaining them, is the > wrong approach. It will open reliability issues and more problems than you > expect. > > Michael Shea. > > On Feb 16, 2020, at 4:34 PM, Wolf McNally <wolf@wolfmcnally.com> wrote: > > I'd like to point out that any single static barcode will have capacity > limits, and we are talking about encoding something that has no inherent > limits: the DID document. But this does not mean we have to abandon QR > codes, nor does it mean we have to animate them. It simply means we need to > sequence them. A sequence of bar codes, whether it is animated, paged on > user demand as each one is read, or on the printed page "waved over" by the > reading device, has effectively unlimited capacity. Animating a sequence of > QR codes can be thought of as "auto-paging" through them. Animation may or > not be the best way to convey a sequence of QR codes— user testing should > decide that. Obviously, animation is not available on the printed page, but > nor is it required either. I suggest this group not fixate on the idea of > "animated QR codes" or "high density other codes" but simply on a standard > way of effectively removing the capacity limit of *any* bar code by > settling on a standard to sequence them. I described one way to do this in > my AirgappedSigning proposal. > > 🐺 > Wolf McNally > > On Feb 16, 2020, at 5:43 AM, Leonard Rosenthol <lrosenth@adobe.com> wrote: > > Yes, GB18030 is a Chinese national standard for encoding of Chinese > characters. Conceptually like JIS in Japan or ASCII or ISO-Latin-1 for > other countries. > > FYI: CHF118 is the standard price for most ISO standards. > Remember that ISO makes its $$ selling their standards while allowing * > *free** membership in their standards process (vs. the W3C that **charges** > for membership, but makes their standards free). Everyone has to make a > living and both approaches towards standards development are valid. > > Leonard > > *From: *Christopher Allen <ChristopherA@lifewithalacrity.com> > *Date: *Sunday, February 16, 2020 at 6:46 AM > *To: *Credentials Community Group <public-credentials@w3.org>, W3C DID > Working Group <public-did-wg@w3.org>, Wolf McNally <wolf@wolfmcnally.com> > *Subject: *Re: Thoughts on current discussion around QR codes > *Resent-From: *<public-credentials@w3.org> > *Resent-Date: *Sunday, February 16, 2020 at 6:45 AM > > *Han Xin* is a 2D bar code symbology intended particularly for the > representation of Chinese characters. It appears to be based on the > GB18030 > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffileformats.archiveteam.org%2Fwiki%2FGB18030&data=02%7C01%7Clrosenth%40adobe.com%7C4f6c4b477fb64d8e7edc08d7b2d5e5c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637174504111315287&sdata=O4DuUaHlNiUcZjHOnIY9QcE8cZ3vbJ4Lu%2BF6IAdsnvU%3D&reserved=0> character > encoding system, which encompasses Chinese and a number of other characters > from Unicode > <https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ffileformats.archiveteam.org%2Fwiki%2FUnicode&data=02%7C01%7Clrosenth%40adobe.com%7C4f6c4b477fb64d8e7edc08d7b2d5e5c6%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C637174504111315287&sdata=5yq4AnRrA57I4X0cnIIlpvoQ6g738wQfLPh6qbe5w0c%3D&reserved=0>. > It is a proprietary system whose formal spec is paywalled at a $147 price.. > > ISO price is > BUY THIS STANDARD > > *FORMAT* > > *LANGUAGE* > > *PDF* > > * ENGLISH > * > > PAPER > > ENGLISH > > > - *CHF**118* > > > > -- Jakub Vysoky mob: +420 605 852 377 jab: jakub.vysoky@gmail.com twit: https://twitter.com/kvbik
Received on Thursday, 5 March 2020 18:53:16 UTC