A few weeks back I was in discussion with the IANA on getting a bitcoin URI
accepted in the standard. As a prerequisite I had to read 5 huge documents. I
did not end up writing that RFC.
Skilled developers have even less time than I do. While this particular RFC is
really nice for keeping ambiguity at bay, it is one of many small rules that
bring marginal improvements. "Rule creep" (like feature creep) starts off with
good intentions but degenerates into a situation like Wikipedia or any other
system with a heavy bureaucracy that can use the rules for lawyering against
you.
We want to encourage skilled developers to help set the standards and
participate in discussions. Beyond using good grammar and using the correct
formatting (and I even help with those), I defer on the site of trusting common
sense and human judgement :)
However this is a good RFC, and I will advise any future BIP contributors to
read it. It offers good suggestions.
About what Luke says:
I kind of agree with him. The intention was to specify software stacks rather
than end applications. This allows us to more carefully track software
evolution and behaviour throughout the network. bitcoin-qt need not be tied to
the Satoshi code-base and may in the future use other core systems through its
intermediary layer. BitcoinJava has given rise to a bunch of other application
like Android Bitcoin and MultiBit- however they are both BitcoinJava
derivatives.
However BIPs are a community consensus thing. It depends on the mutual consent
of everybody and if there is a commonly agreed sentiment against the wording of
an Accepted (or even Active) BIP then it can be amended ad-hoc.
The purpose of BIPs is to enhance development by 1. providing a stable system
environment for programmers to work towards an accepted standard 2. serve as an
equaliser for smaller groups (the third party clients vs the current behemoth
client) by giving them a voice or platform.
And they can only function by those who want them to function.
But personally, I really do think splitting bitcoin-qt into XXX and bitcoin-qt
is a smart idea. Starting from lowest to top part of the system is smart:
http://www.useragentstring.com/pages/Firefox/
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110613 Firefox/6.0a2
Mozilla is the application suite (Mozilla Thunderbird, Mozilla Firefox, ...)
Gecko is the rendering engine
Firefox is the end application
In the original intention for BIP_0014, that would map to:
/Gecko:20110613/Firefox:6.0a2/Mozilla:5.0/
With something like WebKit, it becomes easy to see why that would be useful.
You can suddenly do a network wide scan of all browsers using WebKit, rather
than having to maintain a database of all WebKit enabled browsers.
So if this is contentious.
Then discuss. I'll update the BIP according to what everyone decides they like.
:)
________________________________
From: Gregory Maxwell <gmaxw...@gmail.com>
To: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Sent: Monday, December 19, 2011 10:29 PM
Subject: [Bitcoin-development] BIP language on normative behavior
I've been arguing with Luke-JR on IRC about the interpenetration of
BIP_0014— Gavin's recent commit uses the same version string for the
GUI interface and the daemon mode.
Luke believes this is a _violation_ of BIP_0014 and an error in
judgement on Gavin's part, and a failure to conform to the community
adopted standard. I believe Luke is mistaken: that BIP_0014 actually
don't have mandatory requirements for what you put in the version
field and even if it did, that they are in fact the same software and
should have the same name.
I don't think an agreement is likely on the second point, but the
first point highlights some ambiguity in the interpretation of BIP
language. E.g. What is permitted vs encouraged vs required.
There is well established standard language for this purpose:
https://www.ietf.org/rfc/rfc2119.txt
I strongly recommend that all BIPs be written using the RFC2119
keywords where appropriate.
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create
new or port existing apps to sell to consumers worldwide. Explore the
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
