1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1SqgUa-0008Kf-5D for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jul 2012 08:17:20 +0000
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;
Received: from plane.gmane.org ([80.91.229.3])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1SqgUW-0002aA-2A
for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jul 2012 08:17:20 +0000
Received: from list by plane.gmane.org with local (Exim 4.69)
(envelope-from <gcbd-bitcoin-development@m.gmane.org>)
id 1SqgUP-0007dc-Ov for bitcoin-development@lists.sourceforge.net;
Mon, 16 Jul 2012 10:17:09 +0200
Received: from e179073119.adsl.alicedsl.de ([85.179.73.119])
by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jul 2012 10:17:09 +0200
Received: from andreas by e179073119.adsl.alicedsl.de with local (Gmexim 0.1
(Debian)) id 1AlnuQ-0007hv-00
for <bitcoin-development@lists.sourceforge.net>;
Mon, 16 Jul 2012 10:17:09 +0200
X-Injected-Via-Gmane: http://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
X-Complaints-To: usenet@dough.gmane.org
X-Gmane-NNTP-Posting-Host: e179073119.adsl.alicedsl.de
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>
X-Spam-Score: -0.4 (/)
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 SPF_HELO_PASS SPF: HELO matches SPF record
1.1 DKIM_ADSP_ALL No valid author signature,
domain signs all mail
-0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1SqgUW-0002aA-2A
Subject: Re: [Bitcoin-development] Accepting broken QRcodes
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Mon, 16 Jul 2012 08:17:20 -0000
> 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.
|
