path: root/f0/c9c2668a45243adf977cc9be8fd56db69a4e58

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <zgenjix@yahoo.com>) id 1RdAWS-0004qW-PY
	for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Dec 2011 00:59:08 +0000
X-ACL-Warn: 
Received: from nm20-vm2.bullet.mail.ne1.yahoo.com ([98.138.91.208])
	by sog-mx-3.v43.ch3.sourceforge.com with smtp (Exim 4.76)
	id 1RdAWQ-0005tD-6F for bitcoin-development@lists.sourceforge.net;
	Wed, 21 Dec 2011 00:59:08 +0000
Received: from [98.138.90.50] by nm20.bullet.mail.ne1.yahoo.com with NNFMP;
	21 Dec 2011 00:59:01 -0000
Received: from [98.138.89.252] by tm3.bullet.mail.ne1.yahoo.com with NNFMP;
	21 Dec 2011 00:59:00 -0000
Received: from [127.0.0.1] by omp1044.mail.ne1.yahoo.com with NNFMP;
	21 Dec 2011 00:59:00 -0000
X-Yahoo-Newman-Property: ymail-3
X-Yahoo-Newman-Id: 923151.90504.bm@omp1044.mail.ne1.yahoo.com
Received: (qmail 15814 invoked by uid 60001); 21 Dec 2011 00:59:00 -0000
X-YMail-OSG: CIPuJIIVM1lAU5nLuevhwY2LxxrzJHZ4UjlReCV9.ZAIL4S
	ySg4UPlTG1VyIHbDKscByzP30Hm0Xe5ebHvACOCfOHWqBVEzRDtTXO1rbZt2
	Zd3E6eg.CiHwncFGHQzWuY0y4vgXSmJpZgpoZMEXUA2dAGpVoTiANzy1R8gx
	kUoHd0SDfRv5C3ru8r7qi_p2GbsmvhKVdHfVb.HhtRxAVqgGKStaQtvlqZdi
	N_PbDcMC3S7QvSis4GWlEnPuisVt37JbPkmASTQJ12hA726v.5V8EseOo6_T
	UCFRvcIInY1aNFyyvPbRp7hv3x3B3tkoWDng0F70xrgYoD0K1lOlAisT1l1V
	foIFwLQHPkXZw3sgrEhaawubUgo_NO7rhwlPDop9_MCFCSLaV4dieC9nfZhE
	k6cbggWm3WmNiPTfTfPHk4h4RtXYpZL__Mf_sKDs3lFKD.ZFQsFEORk7KpME
	8cyh71nUjWCdTirttJGKZqTS7dC87v_S.ZhboxgT3aYAbyNQuC53XzWBHTGb
	i5a4YYNOsIcxHuJulSDJPLMgbTbYdVyK8SDvJsArs7PKwnYejPi.VWB_YIJH
	3o6MHgBIrkRsI6.uAFLnBqWulLBKDkTrpIWETnWXJztIJfEpXvqrnBt_GkTC
	lZortUv1FojrHCZkxkiwsY4J4Lpb.0tHk1r43
Received: from [92.20.117.196] by web121001.mail.ne1.yahoo.com via HTTP;
	Tue, 20 Dec 2011 16:59:00 PST
X-Mailer: YahooMailWebService/0.8.115.331698
References: <CAAS2fgQpMWYLoT_1Za5AxvgNaXvEuJOZ2BjE94o09=t+LyfM5A@mail.gmail.com>
Message-ID: <1324429140.3740.YahooMailNeo@web121001.mail.ne1.yahoo.com>
Date: Tue, 20 Dec 2011 16:59:00 -0800 (PST)
From: Amir Taaki <zgenjix@yahoo.com>
To: "bitcoin-development@lists.sourceforge.net"
	<bitcoin-development@lists.sourceforge.net>
In-Reply-To: <CAAS2fgQpMWYLoT_1Za5AxvgNaXvEuJOZ2BjE94o09=t+LyfM5A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="344044665-927875096-1324429140=:3740"
X-Spam-Score: -2.0 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
	(zgenjix[at]yahoo.com)
	-2.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
	domain 1.0 HTML_MESSAGE           BODY: HTML included in message
	-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
	author's domain
	0.1 DKIM_SIGNED            Message has a DKIM or DK signature,
	not necessarily valid
	-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
	-0.3 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1RdAWQ-0005tD-6F
Subject: Re: [Bitcoin-development] BIP language on normative behavior
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Amir Taaki <zgenjix@yahoo.com>
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Wed, 21 Dec 2011 00:59:08 -0000

--344044665-927875096-1324429140=:3740
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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.=0A=0ASkilled developers have even less=
 time than I do. While this particular RFC is really nice for keeping ambig=
uity at bay, it is one of many small rules that bring marginal improvements=
. "Rule creep" (like feature creep) starts off with good intentions but deg=
enerates into a situation like Wikipedia or any other system with a heavy b=
ureaucracy that can use the rules for lawyering against you.=0A=0AWe want t=
o encourage skilled developers to help set the standards and participate in=
 discussions. Beyond using good grammar and using the correct formatting (a=
nd I even help with those), I defer on the site of trusting common sense an=
d human judgement :)=0A=0AHowever this is a good RFC, and I will advise any=
 future BIP contributors to read it. It offers good suggestions.=0A=0AAbout=
 what Luke says:=0A=0AI kind of agree with him. The intention was to specif=
y software stacks rather than end applications. This allows us to more care=
fully track software evolution and behaviour throughout the network. bitcoi=
n-qt need not be tied to the Satoshi code-base and may in the future use ot=
her 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.=0A=0AHowever BIPs are a community c=
onsensus 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.=0A=0AThe purpose of BIPs is to e=
nhance development by 1. providing a stable system environment for programm=
ers to work towards an accepted standard 2. serve as an equaliser for small=
er groups (the third party clients vs the current behemoth client) by givin=
g them a voice or platform.=0A=0AAnd they can only function by those who wa=
nt them to function.=0A=0ABut personally, I really do think splitting bitco=
in-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/=
=0A=0AMozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110613 Firefox/=
6.0a2=0A=0AMozilla is the application suite (Mozilla Thunderbird, Mozilla F=
irefox, ...)=0A=0AGecko is the rendering engine=0AFirefox is the end applic=
ation=0A=0AIn the original intention for BIP_0014, that would map to:=0A=0A=
/Gecko:20110613/Firefox:6.0a2/Mozilla:5.0/=0A=0AWith something like WebKit,=
 it becomes easy to see why that would be useful. You can suddenly do a net=
work wide scan of all browsers using WebKit, rather than having to maintain=
 a database of all WebKit enabled browsers.=0A=0ASo if this is contentious.=
=0A=0AThen discuss. I'll update the BIP according to what everyone decides =
they like.=0A=0A=0A:)=0A=0A=0A=0A________________________________=0A From: =
Gregory Maxwell <gmaxwell@gmail.com>=0ATo: Bitcoin Development <bitcoin-dev=
elopment@lists.sourceforge.net> =0ASent: Monday, December 19, 2011 10:29 PM=
=0ASubject: [Bitcoin-development] BIP language on normative behavior=0A =0A=
I've been arguing with Luke-JR on IRC about the interpenetration of=0ABIP_0=
014=E2=80=94=C2=A0 Gavin's recent commit uses the same version string for t=
he=0AGUI interface and the daemon mode.=0A=0ALuke believes this is a _viola=
tion_ of BIP_0014 and an error in=0Ajudgement on Gavin's part, and a failur=
e to conform to the community=0Aadopted standard. I believe Luke is mistake=
n: that BIP_0014 actually=0Adon't have mandatory requirements for what you =
put in the version=0Afield and even if it did, that they are in fact the sa=
me software and=0Ashould have the same name.=0A=0AI don't think an agreemen=
t is likely on the second point, but the=0Afirst point highlights some ambi=
guity in the interpretation of BIP=0Alanguage. E.g. What is permitted vs en=
couraged vs required.=0A=0AThere is well established standard language for =
this purpose:=0A=0Ahttps://www.ietf.org/rfc/rfc2119.txt=0A=0AI strongly rec=
ommend that all BIPs be written using the RFC2119=0Akeywords where appropri=
ate.=0A=0A-----------------------------------------------------------------=
-------------=0AWrite once. Port to many.=0AGet the SDK and tools to simpli=
fy cross-platform app development. Create =0Anew or port existing apps to s=
ell to consumers worldwide. Explore the =0AIntel AppUpSM program developer =
opportunity. appdeveloper.intel.com/join=0Ahttp://p.sf.net/sfu/intel-appdev=
=0A_______________________________________________=0ABitcoin-development ma=
iling list=0ABitcoin-development@lists.sourceforge.net=0Ahttps://lists.sour=
ceforge.net/lists/listinfo/bitcoin-development
--344044665-927875096-1324429140=:3740
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html><body><div style=3D"color:#000; background-color:#fff; font-family:ti=
mes new roman, new york, times, serif;font-size:12pt"><div><span>A few week=
s 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 no=
t end up writing that RFC.</span></div><div><br><span></span></div><div><sp=
an>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 ru=
les that bring marginal improvements. "Rule creep" (like feature creep) sta=
rts off with good intentions but degenerates into a situation like Wikipedi=
a or any other system with a heavy bureaucracy that can use the rules for l=
awyering against you.</span></div><div><br><span></span></div><div><span>We=
 want to encourage skilled developers to help set the standards and partici=
pate in discussions. Beyond using good grammar and using the correct
 formatting (and I even help with those), I defer on the site of trusting c=
ommon sense and human judgement :)</span></div><div><br><span></span></div>=
<div><span>However this is a good RFC, and I will advise any future BIP con=
tributors to read it. It offers good suggestions.</span></div><div><br><spa=
n></span></div><div><span>About what Luke says:</span></div><div><br><span>=
</span></div><div><span>I kind of agree with him. The intention was to spec=
ify software stacks rather than end applications. This allows us to more ca=
refully track software evolution and behaviour throughout the network. bitc=
oin-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 ri=
se to a bunch of other application like Android Bitcoin and MultiBit- howev=
er they are both BitcoinJava derivatives.</span></div><div><br><span></span=
></div><div><span>However BIPs are a community consensus thing. It
 depends on the mutual consent of everybody and if there is a commonly agre=
ed sentiment against the wording of an Accepted (or even Active) BIP then i=
t can be amended ad-hoc.</span></div><div><br><span></span></div><div><span=
>The purpose of BIPs is to enhance development by 1. providing a stable sys=
tem environment for programmers to work towards an accepted standard 2. ser=
ve as an equaliser for smaller groups (the third party clients vs the curre=
nt behemoth client) by giving them a voice or platform.</span></div><div><b=
r><span></span></div><div><span>And they can only function by those who wan=
t them to function.</span></div><div><br><span></span></div><div><span>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: h=
ttp://www.useragentstring.com/pages/Firefox/</span></div><div><br><span></s=
pan></div><div><a
 href=3D"http://www.useragentstring.com/Firefox6.0a2_id_18498.php">Mozilla/=
5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110613 Firefox/6.0a2</a></div=
><div><br></div><div>Mozilla is the application suite (Mozilla Thunderbird,=
 Mozilla Firefox, ...)<br></div><div>Gecko is the rendering engine</div><di=
v>Firefox is the end application</div><div><br></div><div>In the original i=
ntention for BIP_0014, that would map to:</div><div><br></div><div>/Gecko:2=
0110613/Firefox:6.0a2/Mozilla:5.0/</div><div><br></div><div>With something =
like WebKit, it becomes easy to see why that would be useful. You can sudde=
nly do a network wide scan of all browsers using WebKit, rather than having=
 to maintain a database of all WebKit enabled browsers.</div><div><br></div=
><div>So if this is contentious.</div><div><br></div><div>Then discuss. I'l=
l update the BIP according to what everyone decides they like.<br></div><di=
v><br></div><div>:)<br></div><div><br></div>  <div style=3D"font-family:
 times new roman, new york, times, serif; font-size: 12pt;"> <div style=3D"=
font-family: times new roman, new york, times, serif; font-size: 12pt;"> <f=
ont face=3D"Arial" size=3D"2"> <hr size=3D"1">  <b><span style=3D"font-weig=
ht:bold;">From:</span></b> Gregory Maxwell &lt;gmaxwell@gmail.com&gt;<br> <=
b><span style=3D"font-weight: bold;">To:</span></b> Bitcoin Development &lt=
;bitcoin-development@lists.sourceforge.net&gt; <br> <b><span style=3D"font-=
weight: bold;">Sent:</span></b> Monday, December 19, 2011 10:29 PM<br> <b><=
span style=3D"font-weight: bold;">Subject:</span></b> [Bitcoin-development]=
 BIP language on normative behavior<br> </font> <br>=0AI've been arguing wi=
th Luke-JR on IRC about the interpenetration of<br>BIP_0014=E2=80=94&nbsp; =
Gavin's recent commit uses the same version string for the<br>GUI interface=
 and the daemon mode.<br><br>Luke believes this is a _violation_ of BIP_001=
4 and an error in<br>judgement on Gavin's part, and a failure to conform to=
 the community<br>adopted standard. I believe Luke is mistaken: that BIP_00=
14 actually<br>don't have mandatory requirements for what you put in the ve=
rsion<br>field and even if it did, that they are in fact the same software =
and<br>should have the same name.<br><br>I don't think an agreement is like=
ly on the second point, but the<br>first point highlights some ambiguity in=
 the interpretation of BIP<br>language. E.g. What is permitted vs encourage=
d vs required.<br><br>There is well established standard language for this =
purpose:<br><br><a href=3D"https://www.ietf.org/rfc/rfc2119.txt" target=3D"=
_blank">https://www.ietf.org/rfc/rfc2119.txt</a><br><br>I
 strongly recommend that all BIPs be written using the RFC2119<br>keywords =
where appropriate.<br><br>-------------------------------------------------=
-----------------------------<br>Write once. Port to many.<br>Get the SDK a=
nd tools to simplify cross-platform app development. Create <br>new or port=
 existing apps to sell to consumers worldwide. Explore the <br>Intel AppUpS=
M program developer opportunity. appdeveloper.intel.com/join<br>http://p.sf=
.net/sfu/intel-appdev<br>_______________________________________________<br=
>Bitcoin-development mailing list<br><a ymailto=3D"mailto:Bitcoin-developme=
nt@lists.sourceforge.net" href=3D"mailto:Bitcoin-development@lists.sourcefo=
rge.net">Bitcoin-development@lists.sourceforge.net</a><br><a href=3D"https:=
//lists.sourceforge.net/lists/listinfo/bitcoin-development" target=3D"_blan=
k">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>=
<br><br> </div> </div>  </div></body></html>
--344044665-927875096-1324429140=:3740--