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 ) 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 ; 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: References: <1327881329.49770.YahooMailNeo@web121003.mail.ne1.yahoo.com> Date: Tue, 31 Jan 2012 13:03:56 +0100 Message-ID: From: Wladimir To: Andreas Schildbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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

IMHO its standard that unknown URL parameters are simply ignored. I think we should not change this principle.

<= 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.

Whatever will be defined in the BIP is the standard in = this case.
=C2=A0
> (For example, if something that restricts the validity, such
> as "expires" is added later on, it is pretty important not t= o 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 c= lient rejects URLs with a version number higher than what it knows about.

That's the simplest way to handle it, and enough IM= O.

Wladimir

--e89a8ff1c89cf6e89a04b7d1c116--