OK, so I just did some heavy changes to the methods for forward compatibility in BIP 21. Instead of a version number, now new variables will be added either as-is or with a mustimplement: prefix. If a clients does not know what the variable is that is after mustimplement:, it should consider the entire URI invalid and either notify the user or just drop it silently. That way things like expiretime can be added without worrying about old clients ignoring the field.
All that said, I dont think its an ideal solution, depending on the names of variables to provide information is ugly. If anyone has a better idea on how to do backward compatibility, please suggest it. In terms of the expiretime field being implemented now, I dont think its appropriate. Because some clients already have an old implementation, the possibility of it getting ignored is too large. The BIP now states that "It is recommended that additional variables prefixed with mustimplement: not be used in a mission-critical way until a grace period of 6 months from the finalization of this BIP has passed in order to allow client developers to release new versions, and users of old clients to upgrade." Mostly, however, I want to keep the list of changes from the Bitcoin-Qt implementation to this BIP very, very minimal this late the 0.6 release cycle (I want to get this BIP finalized and implemented for 0.6, so that at least Bitcoin-Qt will have no version which support OS URI opening with a broken implementation). Matt On Tue, 2012-01-31 at 11:04 -0500, Matt Corallo wrote: > On Tue, 2012-01-31 at 06:27 -0800, Amir Taaki wrote: > > BIP 20 really has no support among implementations such as Bitcoin-Qt, > > Electrum, MultiBit or Bitcoin-JS. As the most active and visible user > > facing GUI projects (all with some form of URI Scheme), their opinion > > carries the most weight. To a lesser degree Bitcoin-Qt has the large > > majority of users too (although that's a line of reasoning I'd discourage). > > > > Normally we should probably Reject BIP 21 and re-submit a new standard (for > > history's sake), but as a) BIP 21 is largely a copy paste of BIP 20 sans > > some sections b) it is still a draft, probably the best thing here is if > > you all agree on something to run it by BlueMatt and then we'll make it the > > new BIP 21. > > > > I can see a consensus forming on most parts. Just the send private key is > > contentious, and there's the topic of adding a time to expire field for > > merchants (this is a very good idea IMO). > > > > Also BIP 20 is problematic because it is incompatible with about every > > standard on the web. All the HTML, URI and everything uses decimal numbers > > alone. I see no reason for breaking with tradition. Note that everytime I > > have to write Color or Vectorize (as a British speaker) in my code, I die a > > little inside. But it's convention and American English = International > > English. Also it would be cool if all code used a *real* international > > language (like Esperanto) but the world ain't perfect! We live in a > > decimal-counting English-speaking Windows-using God-worshipping world! > > > > (no offense to decimal-counting English-speaking Windows-using > > God-worshipping world- I do half those things too :) > > The send crap was not in the original spec, is not implemented anywhere, > and should have been removed as part of the BIP 21 copy/paste. It is > now gone. > > As for the expire time, well thats a bit problematic IMHO. Technically > BIP 21 is still a draft, but it is implemented in all versions of > Bitcoin-Qt for drag and drop and adding a field which restricts the > validity of a URI for new clients, but which old clients will gladly > accept could result in some ugly situations IMO. > > Matt ------------------------------------------------------------------------------ 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
