From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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: Message-ID: <1324429140.3740.YahooMailNeo@web121001.mail.ne1.yahoo.com> Date: Tue, 20 Dec 2011 16:59:00 -0800 (PST) From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" In-Reply-To: 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 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 =0ATo: Bitcoin Development =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
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.

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.

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 :)

=
However this is a good RFC, and I will advise any future BIP con= tributors to read it. It offers good suggestions.

About what Luke says:

=
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.

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.

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.
And they can only function by those who wan= t 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: h= ttp://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 i= ntention for BIP_0014, that would map to:

/Gecko:2= 0110613/Firefox:6.0a2/Mozilla:5.0/

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.

So if this is contentious.

Then discuss. I'l= l update the BIP according to what everyone decides they like.

:)

From: Gregory Maxwell <gmaxwell@gmail.com>
<= b>To: Bitcoin Development <= ;bitcoin-development@lists.sourceforge.net>
Sent: Monday, December 19, 2011 10:29 PM
<= span style=3D"font-weight: bold;">Subject: [Bitcoin-development]= BIP language on normative behavior

=0AI've been arguing wi= th Luke-JR on IRC about the interpenetration of
BIP_0014=E2=80=94  = 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_001= 4 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_00= 14 actually
don't have mandatory requirements for what you put in the ve= rsion
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 like= ly on the second point, but the
first point highlights some ambiguity in= the interpretation of BIP
language. E.g. What is permitted vs encourage= d 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 a= nd tools to simplify cross-platform app development. Create
new or port= existing apps to sell to consumers worldwide. Explore the
Intel AppUpS= M 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
=

--344044665-927875096-1324429140=:3740--