Wladimir [ARCHIVE] on Nostr: 📅 Original date posted:2012-01-31 📝 Original message:> > IMHO its standard that ...

📅 Original date posted:2012-01-31
📝 Original message:>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20120131/677da89f/attachment.html>;