From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1RMixD-00035V-Va for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:18:47 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.161.47 as permitted sender) client-ip=209.85.161.47; envelope-from=decker.christian@gmail.com; helo=mail-fx0-f47.google.com; Received: from mail-fx0-f47.google.com ([209.85.161.47]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1RMixC-0000A0-Lq for bitcoin-development@lists.sourceforge.net; Sat, 05 Nov 2011 16:18:47 +0000 Received: by faat2 with SMTP id t2so1421056faa.34 for ; Sat, 05 Nov 2011 09:18:40 -0700 (PDT) Received: by 10.152.0.138 with SMTP id 10mr3063969lae.3.1320509919058; Sat, 05 Nov 2011 09:18:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.152.4.138 with HTTP; Sat, 5 Nov 2011 09:17:58 -0700 (PDT) In-Reply-To: <1320507589.87534.YahooMailNeo@web121019.mail.ne1.yahoo.com> References: <1320268981.72296.YahooMailNeo@web121003.mail.ne1.yahoo.com> <1320507570.40074.YahooMailNeo@web121017.mail.ne1.yahoo.com> <1320507589.87534.YahooMailNeo@web121019.mail.ne1.yahoo.com> From: Christian Decker Date: Sat, 5 Nov 2011 17:17:58 +0100 Message-ID: To: Amir Taaki Content-Type: multipart/alternative; boundary=bcaec5485a6ea5db9304b0ff2c51 X-Spam-Score: -0.6 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (decker.christian[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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 X-Headers-End: 1RMixC-0000A0-Lq Cc: "bitcoin-development@lists.sourceforge.net" Subject: Re: [Bitcoin-development] Lock protocol version numbers X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Nov 2011 16:18:48 -0000 --bcaec5485a6ea5db9304b0ff2c51 Content-Type: text/plain; charset=ISO-8859-1 Sorry for shooting this approach down, but I'm against it. User-agent strings are an extremely bad idea as it would lead developers to start making communication choices depending on the client type. User-Agents in HTTP are only useful if the clients (browsers) do not adhere to a well defined behavior. I see the version string more as a kind of vanity point (xyz peers are using my network code) and it would be bad to base choices on it. For protocol choices we already have a good mechanism in place (nServices) to negotiate capabilities. I for one vote for keeping it as simple as possible, just a simple string, without any further meaning. On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki wrote: > From talking with Patrick Strateman (phantomcircuit), he suggested this > idea (which I will elaborate more on in the BIP): > > User-agent strings are a good starting point, however they aren't easy for > parsing so we'll make a small modification to them. > > We need a hierarchy from protocol, variant, gui, flavour, build > > /Satoshi:314700/bitcoin-qt:0.4/ > > How does that sound? In BitcoinJ's case: > > /BitcoinJ:0.2/AndroidBuild:0.8/ > > Thoughts: > > - Do we need a freely defined comments field? > > /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ > /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ > > ------------------------------ > *From:* Christian Decker > *To:* Mike Hearn > *Cc:* Amir Taaki ; " > bitcoin-development@lists.sourceforge.net" < > bitcoin-development@lists.sourceforge.net> > *Sent:* Saturday, November 5, 2011 2:45 PM > *Subject:* Re: [Bitcoin-development] Lock protocol version numbers > > On BitDroid I stopped updating the protocol version at 31700 and set the > string to be both Version and Client, just like BitcoinJ :-) > > On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn wrote: > > BitCoinJ already sets the subver field to its name and version. > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > > > > ------------------------------------------------------------------------------ > RSA(R) Conference 2012 > Save $700 by Nov 18 > Register now > http://p.sf.net/sfu/rsa-sfdev2dev1 > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > --bcaec5485a6ea5db9304b0ff2c51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sorry for shooting this approach down, but I'm against it. User-agent s= trings are an extremely bad idea as it would lead developers to start makin= g communication choices depending on the client type. User-Agents in HTTP a= re only useful if the clients (browsers) do not adhere to a well defined be= havior. I see the version string more as a kind of vanity point (xyz peers = are using my network code) and it would be bad to base choices on it.
For protocol choices we already have a good mechanism in place (nServices) = to negotiate capabilities.

I for one vote for keeping it as simple a= s possible, just a simple string, without any further meaning.

On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki <zgenjix@yahoo.com> wrote:
From talking with Patrick Strateman (phantomcircuit), he su= ggested this idea (which I will elaborate more on in the BIP):

User-agent strings are a good starting point, however they aren&= #39;t easy for parsing so we'll make a small modification to them.

We need a hierarchy from pro= tocol, variant, gui, flavour, build

/Satoshi:314700/b= itcoin-qt:0.4/

How does = that sound? In BitcoinJ's case:

/BitcoinJ:0.2/AndroidBuild:0.8/

Thoughts:

<= span>- Do we need a freely defined comments field?

/BitcoinJ:0.2[iP= ad; U; CPU OS 3_2_1]/AndroidBuild:0.8/
/Satoshi:3147= 00/bitcoin-qt:0.4[Ubuntu Oneiric]/

From: Christian Decker <decker.christian@gmail.com>= ;
To: Mike Hearn <mike@plan99.net>
Cc: Amir Taaki <zgenjix@yahoo.com>; &quo= t;bitcoin-development@lists.sourceforge.net" <bitcoin-d= evelopment@lists.sourceforge.net>
Sent: Saturday, November 5, = 2011 2:45 PM
Subject: Re: [Bitcoin-development] Lock protocol version numbers

On BitDroid I stopped updating the protocol version at 31700 and set t= he string to be both Version and Client, just like BitcoinJ :-)

On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <mike@plan99.ne= t> wrote:
BitCoinJ already sets the subver field to its name and version.

-----------------------------------------------------------------------= -------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.s= f.net/sfu/rsa-sfdev2dev1
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/li= stinfo/bitcoin-development







----------------------------------------------------------= --------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.s= f.net/sfu/rsa-sfdev2dev1
___________________________________________= ____
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--bcaec5485a6ea5db9304b0ff2c51--