Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1SqhfX-0007vX-Lf for bitcoin-development@lists.sourceforge.net; Mon, 16 Jul 2012 09:32:43 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.213.47 as permitted sender) client-ip=209.85.213.47; envelope-from=g.rowe.froot@gmail.com; helo=mail-yw0-f47.google.com; Received: from mail-yw0-f47.google.com ([209.85.213.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1SqhfS-0003G4-4D for bitcoin-development@lists.sourceforge.net; Mon, 16 Jul 2012 09:32:43 +0000 Received: by yhjj56 with SMTP id j56so1659783yhj.34 for ; Mon, 16 Jul 2012 02:32:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.101.165.37 with SMTP id s37mr2650151ano.71.1342431152737; Mon, 16 Jul 2012 02:32:32 -0700 (PDT) Sender: g.rowe.froot@gmail.com Received: by 10.236.48.201 with HTTP; Mon, 16 Jul 2012 02:32:32 -0700 (PDT) In-Reply-To: References:

Date: Mon, 16 Jul 2012 10:32:32 +0100 X-Google-Sender-Auth: UZtpbFZDLS-Qo447KV4QCL8zD3c Message-ID: From: Gary Rowe To: bitcoin-development@lists.sourceforge.net Content-Type: multipart/alternative; boundary=001636c92834fe8c5f04c4ef1b21 X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (g.rowe.froot[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1SqhfS-0003G4-4D Subject: Re: [Bitcoin-development] Accepting broken QRcodes X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2012 09:32:43 -0000 --001636c92834fe8c5f04c4ef1b21 Content-Type: text/plain; charset=UTF-8 I'm sure that there are many but my Google Search-Fu is not strong enough to build a query to identify how widespread they are. Maybe once we have sufficient evidence to support the suspicion we should post to the main developer forum asking for a cleanup. After all, a Bitcoin URI starting bitcoin://

doesn't actually make much sense because there is no hierarchy in Bitcoin - it's flat with only an address being a mandatory element. I don't want to be all anal about this, but looking at RFC 3986 #10 ( http://tools.ietf.org/html/rfc3986#page-10) it's pretty clear that introducing a false hierarchy is breaking the specification since it presumes the existence of a relative URI. On 16 July 2012 10:02, Wladimir wrote: > But is he the only one using the broken URLs? It was my impression that > they were widespread already. > > Wladimir > > > On Mon, Jul 16, 2012 at 10:52 AM, Gary Rowe wrote: > >> Is it worth having a few more people email Ben to ask him politely to >> fall into line with the BIP? No point encouraging broken windows by not >> speaking out. >> >> >> On 16 July 2012 09:16, Andreas Schildbach wrote: >> >>> > 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. >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> > --001636c92834fe8c5f04c4ef1b21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm sure that there are many but my Google Search-Fu is not strong enou= gh to build a query to identify how widespread they are.

Maybe once = we have sufficient evidence to support the suspicion we should post to the = main developer forum asking for a cleanup. After all, a Bitcoin URI startin= g bitcoin://<address> doesn't actually make much sense because th= ere is no hierarchy in Bitcoin - it's flat with only an address being a= mandatory element.

I don't want to be all anal about this, but looking at RFC 3986 #10= (http://tools.ietf.= org/html/rfc3986#page-10) it's pretty clear that introducing a fals= e hierarchy is breaking the specification since it presumes the existence o= f a relative URI.

On 16 July 2012 10:02, Wladimir <laanwj@gmai= l.com> wrote:

But is he the only one using the broken URLs? It was my impression that the= y were widespread already.

Wladimir

On Mon, Jul 16, 2012 a= t 10:52 AM, Gary Rowe <g.rowe@froot.co.uk> wrote:

Is it worth having a few = more people email Ben to ask him politely to fall into line with the BIP? N= o point encouraging broken windows by not speaking out.

On 16 July 2012 09:16, Andreas Schi= ldbach <andreas@schildbach.de> wrote:

> 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 g= one
> 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<= br> > thing. Hopefully at some point, Ben will stop generating such QRcodes<= br> > and we can remove these hacks and get back to BIP compliance.

The problem with this "accept everything even if broken" ap= proach 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.

---------------------------------------------------------------------------= ---
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

-----------------------------------------------------------= -------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122= 263/
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment

--001636c92834fe8c5f04c4ef1b21--