summaryrefslogtreecommitdiff
path: root/7b/31808b5278e5c46a2a250536934b57cfc0ad03
blob: 0fc611692dc36fafe0f2cb8d1ba4e94a79a8312c (plain)
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
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
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 <g.rowe.froot@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>;
	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: <CA+s+GJBPQWYy1oftKkndZ8FF1hTaL-Zoc3bO_c3=s_LNkW635g@mail.gmail.com>
References: <CANEZrP1=VLpRL5cWTS1gQnYmg0eChBmwWd_-i0S5Zqm3r6Jg5g@mail.gmail.com>
	<ju0ilq$7q7$2@dough.gmane.org>
	<CAKm8k+2UTofgBOCZ_VtHPJdPs4w3oEv4bSDzFbW4M2tw9ZtjRg@mail.gmail.com>
	<CA+s+GJBPQWYy1oftKkndZ8FF1hTaL-Zoc3bO_c3=s_LNkW635g@mail.gmail.com>
Date: Mon, 16 Jul 2012 10:32:32 +0100
X-Google-Sender-Auth: UZtpbFZDLS-Qo447KV4QCL8zD3c
Message-ID: <CAKm8k+3dZZmGTC_ezkgyC0UDwKnzXmiU3-x-8h_sRdJ12REFvQ@mail.gmail.com>
From: Gary Rowe <g.rowe@froot.co.uk>
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: <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 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://<address> 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 <laanwj@gmail.com> 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 <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? No point encouraging broken windows by not
>> speaking out.
>>
>>
>> On 16 July 2012 09:16, Andreas Schildbach <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 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&#39;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.<br><br>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://&lt;address&gt; doesn&#39;t actually make much sense because th=
ere is no hierarchy in Bitcoin - it&#39;s flat with only an address being a=
 mandatory element. <br>
<br>I don&#39;t want to be all anal about this, but looking at RFC 3986 #10=
 (<a href=3D"http://tools.ietf.org/html/rfc3986#page-10">http://tools.ietf.=
org/html/rfc3986#page-10</a>) it&#39;s pretty clear that introducing a fals=
e hierarchy is breaking the specification since it presumes the existence o=
f a relative URI. <br>
<br><div class=3D"gmail_quote">On 16 July 2012 10:02, Wladimir <span dir=3D=
"ltr">&lt;<a href=3D"mailto:laanwj@gmail.com" target=3D"_blank">laanwj@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left=
:1ex">
But is he the only one using the broken URLs? It was my impression that the=
y were widespread already.<span class=3D"HOEnZb"><font color=3D"#888888"><d=
iv><br></div></font></span><div><span class=3D"HOEnZb"><font color=3D"#8888=
88">Wladimir</font></span><div>
<div class=3D"h5"><br><br><div class=3D"gmail_quote">On Mon, Jul 16, 2012 a=
t 10:52 AM, Gary Rowe <span dir=3D"ltr">&lt;<a href=3D"mailto:g.rowe@froot.=
co.uk" target=3D"_blank">g.rowe@froot.co.uk</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">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.<div>

<div><br><br><div class=3D"gmail_quote">On 16 July 2012 09:16, Andreas Schi=
ldbach <span dir=3D"ltr">&lt;<a href=3D"mailto:andreas@schildbach.de" targe=
t=3D"_blank">andreas@schildbach.de</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt 0pt 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div>&gt; I asked Ben to =
fix this (social networks don&#39;t parse QRcodes after<br>
&gt; all), but after explaining that social networks don&#39;t parse URLs<b=
r>
&gt; without :// in them, he stopped responding to my emails. So I&#39;ve g=
one<br>
&gt; ahead and added support for reading these types of URLs to bitcoinj,<b=
r>
&gt; in the interests of &quot;just works&quot; interoperability.<br>
&gt;<br>
&gt; This mail is just a heads up in case anyone else wants to do the same<=
br>
&gt; thing. Hopefully at some point, Ben will stop generating such QRcodes<=
br>
&gt; and we can remove these hacks and get back to BIP compliance.<br>
<br>
</div>The problem with this &quot;accept everything even if broken&quot; ap=
proach is<br>
that people will probably never fix the broken stuff. So we likely end<br>
up with a fragmented de-facto standard.<br>
<br>
That does not mean I am totally against accepting broken URLs, but there<br=
>
should be at least a promise that they will be fixed at the source.<br>
<div><div><br>
<br>
---------------------------------------------------------------------------=
---<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br>
</div></div><br>-----------------------------------------------------------=
-------------------<br>
Live Security Virtual Conference<br>
Exclusive live event will cover all the ways today&#39;s security and<br>
threat landscape has changed and how IT managers can respond. Discussions<b=
r>
will include endpoint security, mobile security and the latest in malware<b=
r>
threats. <a href=3D"http://www.accelacomm.com/jaw/sfrnl04242012/114/5012226=
3/" target=3D"_blank">http://www.accelacomm.com/jaw/sfrnl04242012/114/50122=
263/</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
<br></blockquote></div><br></div></div></div>
</blockquote></div><br>

--001636c92834fe8c5f04c4ef1b21--