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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <laanwj@gmail.com>) id 1RsCRU-0001Tt-CU
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 12:04:08 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.210.47 as permitted sender)
client-ip=209.85.210.47; envelope-from=laanwj@gmail.com;
helo=mail-pz0-f47.google.com;
Received: from mail-pz0-f47.google.com ([209.85.210.47])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1RsCRO-0002Nx-VU
for bitcoin-development@lists.sourceforge.net;
Tue, 31 Jan 2012 12:04:08 +0000
Received: by dakj40 with SMTP id j40so141625dak.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 31 Jan 2012 04:03:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.212.161 with SMTP id nl1mr49397903pbc.38.1328011437074;
Tue, 31 Jan 2012 04:03:57 -0800 (PST)
Received: by 10.143.8.11 with HTTP; Tue, 31 Jan 2012 04:03:56 -0800 (PST)
In-Reply-To: <jg8kql$bct$1@dough.gmane.org>
References: <1327881329.49770.YahooMailNeo@web121003.mail.ne1.yahoo.com>
<jg88ed$i85$1@dough.gmane.org>
<CA+s+GJDLoUG43hdLKYMwehBO9qqE=YCm7eJ2RN-TTTY_+OLp=A@mail.gmail.com>
<CAKm8k+2wrsNDxEQXjZmqWQtO5DHiTjc0SgU_+QCU_FybeFFY6g@mail.gmail.com>
<CA+s+GJAvEPda7UGHDoz84OavSh5jdN8wOhGgrNUgPU_Wh66Xyw@mail.gmail.com>
<jg8kql$bct$1@dough.gmane.org>
Date: Tue, 31 Jan 2012 13:03:56 +0100
Message-ID: <CA+s+GJCwUYtYX4EYRBMp-FujJnSO6ZBwN67k8DgLh75YbnHeeQ@mail.gmail.com>
From: Wladimir <laanwj@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=e89a8ff1c89cf6e89a04b7d1c116
X-Spam-Score: -0.6 (/)
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
(laanwj[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1RsCRO-0002Nx-VU
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
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: Tue, 31 Jan 2012 12:04:08 -0000
--e89a8ff1c89cf6e89a04b7d1c116
Content-Type: text/plain; charset=UTF-8
>
> IMHO its standard that unknown URL parameters are simply ignored. I
> think we should not change this principle.
>
It's usually the right thing to do to be open to future backward-compatible
changes, but I don't know of any such standard, as it equally makes future
non-backward-compatible changes impossible.
Whatever will be defined in the BIP is the standard in this case.
> > (For example, if something that restricts the validity, such
> > as "expires" is added later on, it is pretty important not to ignore it.
> > Older clients should refuse to comply.)
>
> In this case, you'd need to refuse *all* parameters you don't know
> about. In consequence, all extensions would break older clients.
>
Which is exactly what I want to avoid by defining this up-front.
A versioning scheme can avoid this. Any BIP that breaks backwards
compatibility (for example, adds a multiple-send type or specific
restriction) should increase the version number. A client rejects URLs with
a version number higher than what it knows about.
That's the simplest way to handle it, and enough IMO.
Wladimir
--e89a8ff1c89cf6e89a04b7d1c116
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D=
"im">
<br>
</div>IMHO its standard that unknown URL parameters are simply ignored. I<b=
r>
think we should not change this principle.<br></blockquote><div><br></div><=
div>It's usually the right thing to do to be open to future backward-co=
mpatible changes, but=C2=A0I don't know of any such standard, as it equ=
ally makes future non-backward-compatible changes impossible.</div>
<div><br></div><div>Whatever will be defined in the BIP is the standard in =
this case.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=
=3D"im">
> (For example, if something that restricts the validity, such<br>
> as "expires" is added later on, it is pretty important not t=
o ignore it.<br>
> Older clients should refuse to comply.)<br>
<br>
</div>In this case, you'd need to refuse *all* parameters you don't=
know<br>
about. In consequence, all extensions would break older clients.<br></block=
quote><div><br></div><div>Which is exactly what I want to avoid by defining=
this up-front.</div><div><br></div><div>A versioning scheme can avoid this=
. Any BIP that breaks backwards compatibility (for example, adds a multiple=
-send type or specific restriction) should increase the version number. A c=
lient rejects URLs with a version number higher than what it knows about.</=
div>
<div><br></div><div>That's the simplest way to handle it, and enough IM=
O.</div><div><br></div><div>Wladimir</div><div><br></div></div>
--e89a8ff1c89cf6e89a04b7d1c116--
|
