>
> 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
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
