by Darius Kazemi, Feb 20 2019
The technical content
This paper outlines the Network Interchange Language. Spoilers: like the Decode/Encode Language, it was never implemented. It is an alternative proposal to Crocker's Network Control Program, and in fact is wider in scope than DEL was.
NIL is supposed to be both the network's interface with the operating system and a high-level representation of things “to express the front end part of an interactive system”. DEL was, if my reading is correct, a front end / interactive layer that could be layered on top of something like NCP. NIL aims to do what NCP and DEL combined would do.
I am mostly skipping describing the technical details of this paper, for reasons outlined in the next section.
I will readily admit that I'm out of my depth on this RFC. It's highly abstract and mathematical. I imagine its complexity is among the reasons that it was never implemented by the ARPANET teams!
The document oscillates between high level concepts and low-level minutiae (lists of specific control operations) but never provides a concrete example to the reader. Compare this to DEL as described in RFC-5, which provides plenty of sample code. DEL just seemed a lot more concrete and understandable than NIL. While there is not much writing on either of the two systems, DEL has been written about more often. I believe this is because it's more understandable as a concept.
There is an interesting use of “front end” in this paper, referring to the client-side interactive elements. I didn't know this term was this old.
In the introduction, Elie says the idea for NIL derives from something called UNCOL. UNCOL was proposed in 1958 and never implemented. It was meant to be an intermediate language for compiler compatibility. Basically the idea is to make it so that you can compile programs written in many programming languages on many different computer hardware architectures. I know very little about compilers personally, but the LLVM IR is an example of something similar to UNCOL that today's programmers end up dealing with a lot.