5 ms·

> If you need to debug it, it's trivial to even look at the hex dump of packets. The problem, of course, is that it's not trivial to generate those packets in

• danbruc 11y ago
  Seems pretty obvious to me, why that failed - the linked specification describes how to represent a tree of pairs of byte strings. What do I do with that? That's not much more helpful than saying that I can encode my information as a sequence of zeros and ones. It is redundant and vague. Why six ways to represent a byte string? Or even more if you count things like quoted strings and length prefixed quoted strings separately. It has the feel of just do whatever you want. As some kind of type information one can associate display hints with each byte string. What are valid display hints? Arbitrary byte strings, of course. »Many of the MIME types work here.« Where would you even start to build a useful library around this specification? It is so general that it is useless.
  • wtbob 11y ago
    > Seems pretty obvious to me, why that failed - the linked specification describes how to represent a tree of pairs of byte strings. What do I do with that? Whatever you want to. Once you have lists, trees and byte strings, you have everything you need (note that JSON is this, with some sugar for alists). > Why six ways to represent a byte string? Because different approaches make sense in different contexts: for a single word the word itself is completely fine; for an English phrase "this is a small phrase" works; for certain constants hex works, e.g. #DEADBEEF#; for large binary strings then Base64 encoding works, since it's opaque anyway. And all of that is really for display: for transmission (and cryptographic hashing) the length-prefixed canonical form works perfectly, but is still visually-inspectable in time of need (unlike, say, a pure-binary format). > It has the feel of just do whatever you want. It's a tool for one's toolbox, not a finished product: you use it to build whatever you want. > Where would you even start to build a useful library around this specification? It is so general that it is useless. How does one build a useful library around JSON? Canonical S-expressions live at the same level of abstraction (but are efficient and visually appealing, unlike JSON). Are you aware that S-expressions are how Lisp code is represented? This takes that same universal code format and turns it into a universal data format. How would you build a library around it? How do Lisp implementations build a useful library around S-expressions? Simple: they offer functions like READ to read in structured data, and functions like EVAL to evaluate it as code. Likewise, the user of canonical S-expressions would have some library to read in the expressions, and some other library (or his own code) to evaluate that structured data as code in whatever format he's using. I point you to the SPKI RFCs as an example. In the context of the parent to my post, one can use S-expressions as an alternative to tag-length value. Instead of 0x01666f6f20626172, one might have (name "foo bar") as something a human being can read & write, which encodes down to (4:name7:foo bar), which is fast to parse, reasonably efficient for transmission, and can be read by a human in duress. And if for some reason one wanted a copy-pastable version (maybe for end users to paste auth tokens, or to survive emails, or something) then one could use {KDQ6bmFtZTc6Zm9vIGJhcik} (that's just Base64-encoded). Or you could use JSON: {"name": "foo bar"}. Which is larger, more error-prone to type, uglier, harder to parse, and still needs to be evaluated in its context anyway (What if name isn't the only required attribute? What if it must be in HTML format? &c. &c. &c.).