Sorry for shooting this approach down, but I&#39;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.<br>

For protocol choices we already have a good mechanism in place (nServices) to negotiate capabilities.<br><br>I for one vote for keeping it as simple as possible, just a simple string, without any further meaning.<br><br>
<div class="gmail_quote">
On Sat, Nov 5, 2011 at 4:39 PM, Amir Taaki <span dir="ltr">&lt;<a href="mailto:zgenjix@yahoo.com">zgenjix@yahoo.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="HOEnZb"><div class="h5"><div><div style="color:#000;background-color:#fff;font-family:times new roman, new york, times, serif;font-size:12pt"><span>From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP):</span><div style="font-family:times new roman, new york, times, serif;font-size:12pt">

<div style="font-family:times new roman, new york, times, serif;font-size:12pt"><div><div><div style="color:#000;background-color:#fff;font-family:times new roman, new york, times, serif;font-size:12pt"><div><br><span></span></div>

<div><span>User-agent strings are a good starting point, however they aren&#39;t easy for parsing so we&#39;ll make a small modification to them.</span></div><div><br><span></span></div><div><span>We need a hierarchy from protocol, variant, gui, flavour,
 build</span></div><div><span><br></span></div><div><span>/Satoshi:314700/bitcoin-qt:0.4/</span></div><div><br><span></span></div><div><span>How does that sound? In BitcoinJ&#39;s case:</span></div><div><br><span></span></div>

<div><span>/BitcoinJ:0.2/AndroidBuild:0.8/</span></div><div><br><span></span></div><div><span>Thoughts:</span></div><div><br><span></span></div><div><span>- Do we need a freely defined comments
 field?</span></div><div><br><span></span></div><div><span>/BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/</span></div><div><span>/Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/<br></span></div><div><br></div><div style="font-family:times new roman, new york, times, serif;font-size:12pt">

<div style="font-family:times new roman, new york, times, serif;font-size:12pt"><font face="Arial" size="2"><hr size="1"><b><span style="font-weight:bold">From:</span></b> Christian Decker &lt;<a href="mailto:decker.christian@gmail.com" target="_blank">decker.christian@gmail.com</a>&gt;<br>

<b><span style="font-weight:bold">To:</span></b> Mike Hearn &lt;<a href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>&gt;<br><b><span style="font-weight:bold">Cc:</span></b> Amir Taaki &lt;<a href="mailto:zgenjix@yahoo.com" target="_blank">zgenjix@yahoo.com</a>&gt;; &quot;<a href="mailto:bitcoin-development@lists.sourceforge.net" target="_blank">bitcoin-development@lists.sourceforge.net</a>&quot; &lt;<a href="mailto:bitcoin-development@lists.sourceforge.net" target="_blank">bitcoin-development@lists.sourceforge.net</a>&gt;<br>

<b><span style="font-weight:bold">Sent:</span></b> Saturday, November 5, 2011 2:45 PM<br><b><span style="font-weight:bold">Subject:</span></b> Re:
 [Bitcoin-development] Lock protocol version numbers<br></font><br>
<div>On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-)<br><br><div>On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn <span dir="ltr">&lt;<a rel="nofollow" href="mailto:mike@plan99.net" target="_blank">mike@plan99.net</a>&gt;</span> wrote:<br>



<blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">BitCoinJ already sets the subver field to its name and version.<br><br>
<br>------------------------------------------------------------------------------<br>
RSA(R) Conference 2012<br>
Save $700 by Nov 18<br>
Register now<br>
<a href="http://p.sf.net/sfu/rsa-sfdev2dev1" target="_blank">http://p.sf.net/sfu/rsa-sfdev2dev1</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a rel="nofollow" href="mailto:Bitcoin-development@lists.sourceforge.net" target="_blank">Bitcoin-development@lists.sourceforge.net</a><br>
<a rel="nofollow" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br>
</div><br><br></div></div></div></div></div><br><br></div></div></div></div></div></div><br>------------------------------------------------------------------------------<br>
RSA(R) Conference 2012<br>
Save $700 by Nov 18<br>
Register now<br>
<a href="http://p.sf.net/sfu/rsa-sfdev2dev1" target="_blank">http://p.sf.net/sfu/rsa-sfdev2dev1</a><br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a><br>
<a href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development" target="_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a><br>
<br></blockquote></div><br>