From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP language on normative behavior
Date: Tue, 20 Dec 2011 16:59:00 -0800 (PST) [thread overview]
Message-ID: <1324429140.3740.YahooMailNeo@web121001.mail.ne1.yahoo.com> (raw)
In-Reply-To: <CAAS2fgQpMWYLoT_1Za5AxvgNaXvEuJOZ2BjE94o09=t+LyfM5A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4681 bytes --]
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 <gmaxwell@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
[-- Attachment #2: Type: text/html, Size: 6368 bytes --]
next prev parent reply other threads:[~2011-12-21 0:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-19 22:29 [Bitcoin-development] BIP language on normative behavior Gregory Maxwell
2011-12-19 22:36 ` [Bitcoin-development] Lying about User Agent (was: BIP language on normative behavior) Luke-Jr
2011-12-21 0:59 ` Amir Taaki [this message]
[not found] ` <201112202007.49399.luke@dashjr.org>
2011-12-21 1:14 ` [Bitcoin-development] BIP language on normative behavior Amir Taaki
2011-12-21 9:27 ` Andy Parkins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1324429140.3740.YahooMailNeo@web121001.mail.ne1.yahoo.com \
--to=zgenjix@yahoo.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox