Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of m.gmane.org
	designates 80.91.229.3 as permitted sender)
	client-ip=80.91.229.3;
	envelope-from=gcbd-bitcoin-development@m.gmane.org;
	helo=plane.gmane.org; 
To: bitcoin-development@lists.sourceforge.net
From: Andreas Schildbach <andreas@schildbach.de>
Date: Mon, 16 Jul 2012 10:16:58 +0200
Message-ID: <ju0ilq$7q7$2@dough.gmane.org>
References: <CANEZrP1=VLpRL5cWTS1gQnYmg0eChBmwWd_-i0S5Zqm3r6Jg5g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:13.0) Gecko/20120615 Thunderbird/13.0.1
In-Reply-To: <CANEZrP1=VLpRL5cWTS1gQnYmg0eChBmwWd_-i0S5Zqm3r6Jg5g@mail.gmail.com>
Subject: Re: [Bitcoin-development] Accepting broken QRcodes
Precedence: list

> I asked Ben to fix this (social networks don't parse QRcodes after
> all), but after explaining that social networks don't parse URLs
> without :// in them, he stopped responding to my emails. So I've gone
> ahead and added support for reading these types of URLs to bitcoinj,
> in the interests of "just works" interoperability.
> 
> This mail is just a heads up in case anyone else wants to do the same
> thing. Hopefully at some point, Ben will stop generating such QRcodes
> and we can remove these hacks and get back to BIP compliance.

The problem with this "accept everything even if broken" approach is
that people will probably never fix the broken stuff. So we likely end
up with a fragmented de-facto standard.

That does not mean I am totally against accepting broken URLs, but there
should be at least a promise that they will be fixed at the source.