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; 
MIME-Version: 1.0
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
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP 21 (modification BIP 20)
Precedence: list

--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&#39;s usually the right thing to do to be open to future backward-co=
mpatible changes, but=C2=A0I don&#39;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">

&gt; (For example, if something that restricts the validity, such<br>
&gt; as &quot;expires&quot; is added later on, it is pretty important not t=
o ignore it.<br>
&gt; Older clients should refuse to comply.)<br>
<br>
</div>In this case, you&#39;d need to refuse *all* parameters you don&#39;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&#39;s the simplest way to handle it, and enough IM=
O.</div><div><br></div><div>Wladimir</div><div><br></div></div>

--e89a8ff1c89cf6e89a04b7d1c116--