Fair points, although for me the line is blurred between which of those are security considerations vs performance considerations.

Richard

On 19 January 2015 at 19:09, Jeff Garzik <jgarzik@bitpay.com> wrote:

Text formats such as XML or JSON are far less deterministic, are more loosely specified, have wide variance in parsing, are not very hash-able, the list goes on.

On Mon, Jan 19, 2015 at 2:07 PM, Richard Brady <rnbrady@gmail.com> wrote:

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