rich1.0npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwethttps://nostr.ae/npub17qxssk9sj2r7jswvh3y32e7vwz7mcckhz33gk9nurdmw0lhsfkgswupwetnjumphttps://nostr.ae📅 Original date posted:2015-01-19 📝 Original message:Even if a compact binary encoding is a high priority, there are more "standard" choices than Google Protocol Buffers. For example, ASN.1 is a very rigorously defined standard that has been around for decades, and ASN.1 even has an XML encoding (XER) that is directly convertible to/from the binary encoding (BER/DER), given the schema. In practice, I'm mostly agnostic about what encoding is actually used in BIP70, and I wouldn't fault BIP70 for choosing Google Protocol Buffers, but the very existence of Protobuf perplexes me, as it apparently re-solves a problem that was solved 40 years ago by ASN.1. It's as though the engineers at Google weren't aware that ASN.1 existed. On Monday, 19 January 2015, at 7: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