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