> You can't argue with the readability, portability, simplicity, or usability of JSON. Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding

> You can't argue with the readability, portability, simplicity, or usability of JSON. Hah, the joke's on you: ASN.1 has JER, which is the ASN.1 JSON Encoding Rules :) So you can specify JSON schemas in ASN.1 syntax, which means that you could transcode from any of the other ASN.1 encoding rules, which include: - BER/DER/CER (TLV encodings) - OER/PER (like XDR, but with one octet alignment) - XER (yes, the X is for XML -- XML Encoding Rules) - GSER (a pre-JSON JSON-like encoding rules for ASN.1 invented at IETF) - and other ERs that are proprietary - and any ER you care to create, which could just be bindings of other encoding schemes like Flat Buffers or anything else you like. I've been wanting an XDR-based encoding rules... Which goes to show that a lot of the encoding schemes you listed could just have been ASN.1 ERs from the get-go and: - benefited from existing ASN.1 modules - benefited from transcoding - benefited from existing ASN.1 compiler codebases But no, people had to reinvent the wheel all the way to the syntax and semantics without adding much of anything truly new. > I like DNSSEC and DANE because the combination adds another security layer to corroborate what PKI says. If browsers adopted it, it would be widely deployed to web-facing services. Like GPG, it has a UX problem and is a PITA to setup. (Sadly, a major DNSSEC multi browser extension effort shutdown.) I thought we were pro defense-in-depth rather than less security, so I don't understand the hate DNSSEC receives because it's not an alternative so much as a secondary trust-supporting mechanism. I agree with this, though I'm not sure what is the antecedent of "it" in "[l]ike GPG, it has a UX problem..." -- could be DNSSEC, but it could also be PKI! :)