Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.218.51 as permitted sender)
	client-ip=209.85.218.51; envelope-from=rnbrady@gmail.com;
	helo=mail-oi0-f51.google.com; 
MIME-Version: 1.0
Date: Mon, 19 Jan 2015 19:07:30 +0000
Message-ID: <CAN5esQJe0uUm0NyctaBa6WH7_JjeE_OLR=FY_XQWnSr50VRDyA@mail.gmail.com>
From: Richard Brady <rnbrady@gmail.com>
To: Bitcoin <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b5d90b5b7d65d050d060814
Subject: [Bitcoin-development] BIP70: why Google Protocol Buffers for
	encoding?
Precedence: list

--047d7b5d90b5b7d65d050d060814
Content-Type: text/plain; charset=UTF-8

Hi Gavin, Mike and co

Is there a strong driver behind the choice of Google Protocol Buffers for
payment request encoding in BIP-0070?

Performance doesn't feel that relevant when you think that:
1. Payment requests are not broadcast, this is a request / response flow,
much more akin to a web request.
2. One would be cramming this data into a binary format just so you can
then attach it to a no-so-binary format such as HTTP.

Some great things about protocols/encodings such as HTTP/JSON/XML are:
1. They are human readable on-the-wire. No Wireshark plugin required,
tcpdump or ngrep will do.
2. There are tons of great open source libraries and API for parsing /
manipulating / generating.
3. It's really easy to hand-craft a test message for debugging.
4. The standards are much easier to read and write. They don't need to
contain code like BIP-0070 currently does and they can contain examples,
which BIP70 does not.
5. They are thoroughly specified by independent standards bodies such as
the IETF. Gotta love a bit of MUST / SHOULD / MAY in a standard.
6. They're a family ;-)

Keen to hear your thoughts on this and very keen to watch the payment
protocol grow regardless of encoding choice! My background is SIP / VoIP
and I think that could be a fascinating use case for this protocol which
I'm hoping to do some work on.

Best,
Richard

--047d7b5d90b5b7d65d050d060814
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hi Gavin, Mike and co<div><br></div><div>Is there a strong=
 driver behind the choice of Google Protocol Buffers for payment request en=
coding in BIP-0070?</div><div><br></div><div>Performance doesn&#39;t feel t=
hat relevant when you think that:</div><div>1. Payment requests are not bro=
adcast, this is a request / response flow, much more akin to a web request.=
</div><div>2. One would be cramming this data into a binary format just so =
you can then attach it to a no-so-binary format such as HTTP.=C2=A0</div><d=
iv><br></div><div>Some great things about protocols/encodings such as HTTP/=
JSON/XML are:</div><div>1. They are human readable on-the-wire. No Wireshar=
k plugin required, tcpdump or ngrep will do.</div><div>2. There are tons of=
 great open source libraries and API for parsing / manipulating / generatin=
g.</div><div>3. It&#39;s really easy to hand-craft a test message for debug=
ging.<br></div><div>4. The standards are much easier to read and write. The=
y don&#39;t need to contain code like BIP-0070 currently does and they can =
contain examples, which BIP70 does not.=C2=A0</div><div>5. They are thoroug=
hly specified by independent standards bodies such as the IETF. Gotta love =
a bit of MUST / SHOULD / MAY in a standard.</div><div>6. They&#39;re a fami=
ly ;-)</div><div><br></div><div>Keen to hear your thoughts on this and very=
 keen to watch the payment protocol grow regardless of encoding choice! My =
background is SIP / VoIP and I think that could be a fascinating use case f=
or this protocol which I&#39;m hoping to do some work on.</div><div><br></d=
iv><div>Best,</div><div>Richard</div><div><br></div></div>

--047d7b5d90b5b7d65d050d060814--