4 ms·

This is a great idea. I remember reading a blog entitled something like "ascii-separated values" as a replacement for CSV files. So I took another look at the

• jph 3y ago
  This is really good info, thank you. Can you explain more about what you learned about the streaming, transmission, sessions, etc.? I'm the author of the USV spec and very much interested.
  • rhelz 3y ago
    Sure...and thanks again for writing up this spec. On the hardware, physical networking layer, ASCII gives us SYN, a synchronous idle, which is a bit pattern chosen to make it easy for devices to sync their carrier frequencies and transmission speeds. We also have DC1-4 to specify commands to the networking hardware for additional settings and control. We have EM (end of medium) to indicate we want to stop communicating on this connection. And most charmingly of all, we even have a BEL we can ring to wake up the late-night operator! :-) We also have characters to quite richly format a data packet: start of heading (SOH), start of text (STX), end of text (ETX). We can indicated whether the content is text or binary using the DLE (data link escape) or we can indicate any encoding we want with the SI,SO (shift in, shift out) characters and some extra user-defined protocol. We even have ETB (end of transmission block) to indicate that the content has been broken into several packets. And as your proposal notes, we have 4 layers of separator characters we can use to indicate fields, records, etc within the text of the packet. Spreadsheets, and tabular data from relational databases have a simple and direct encoding, as do X-Y plots and vector-based data. It's comparable to JSON in its ability to articulate structured data--arguably better, since it's table-based and not just key-value based. And since it specifies a flattened-table format instead of a tree format like JSON, we can even directly encode things like circular linked-lists or graphs with cycles in them. For session management, we have ENQ (enquiry) to start a session/initiate login/solicit credentials, ACK and NAK for heartbeating, CAN (cancel) to provide out-of-band directives for session control (such as halting a large file transfer or to interrupt a slow process.) To logout/terminate the session we have EOT (end of transmission). And the great part is that because these are all dedicated characters--distinct from the characters we would typically use to transmit text--we don't have to do any kind of tedious and spoofable text escaping. And yet, we can still use plain text to encode any additional protocols we want (like specifying a network address, or indicating how long the text is, or checksums) because we can delimit such plain text with the reserved characters. ASCII takes 100 years of experience in telegraphy and phone networking, and distills it into a microcosm of everything we needed to create the networked/connected world we have today. All this in the 1960's!!! Sadly, but perhaps inevitably, the adoption of ASCII was way faster than the understanding of ASCII, so lots of the characters have acquired unintended meanings. Even worse, we invented abominations like CSV files.... Also, perhaps inevitably, UNICODE just doesn't seem to have the kind of condensed, crystalline beauty which ASCII has...but what can you do. I can remember, when I first looked at ASCII, it seemed weird to have letters like "ABC" sitting cheek-and-jowl next to data control commands and ringing bells. What kind of alphabet is this?? chuckle. Seemed like a category error to me. Well, once again we're having to expand our conceptions of what a "character" is....