1971–1995

Line Mode

For twenty-four years the way to use the internet was to type at it. Not metaphorically: you opened a connection to a port, typed a line, pressed return, and the far end answered in text you could read. That worked because a command was a line of ASCII ending in a carriage return and a line feed, and it worked for file transfer, news, mail, menus, chat and the web alike. A keyboard was a sufficient client. Then it stopped, in two steps, and only the second one was impossible.

I spent 1994 and 1995 at Spry, in Seattle, the company that put Internet in a Box on a shelf. Part of my job was a crawler for Usenet news, and there is no way to write one of those without learning NNTP as lines, or to debug one without opening a connection to port 119 and typing at it until you can see what your program got wrong. That is what this page is: the thing I did at a terminal in 1994, and the reason a person cannot casually do it any more.

One terminal, nine ports

Pick a protocol and type at it. The hint under the box is a line that will do something; everything else the grammar allows works too.

connected to: —
what this one shows: —
specified in: —

try: —

typed so far: —

Nine protocols, three shared ideas, and where they stop

They were designed by different people for different jobs across twenty-two years, and six of them agree about three things. That agreement is why one pair of hands could drive all of them. The last three are here because they do not agree, and an idea is easiest to see in the place something was built without it.

Each protocol: its port, the year of the specification quoted here, and the idea it contributes or withholds
protocol	port	year	what it contributes

The first idea: a command is a line of ASCII ending in CR LF. Two bytes with no glyph, which is why the wire column above is worth turning on — a five-character line costs seven bytes and the two extra are the reason the far end knows you have finished.

The second: a reply starts with three digits and the FIRST one is the category. FTP prints the five in its own standard, SMTP and NNTP use the same shape, and IRC calls it “the three digit numeric”. Four protocols, one idea about how to answer.

RFC 959's five reply classes, by first digit
code	name	what it means

The third is the one worth building. A block of text ends with a line containing only a period — which immediately creates a problem, because the text might contain such a line. Switch to SMTP or NNTP above, start a data block, and type a line beginning with a period.

And then the three that do not agree

POP3 keeps the third idea and drops the second. Its multi-line response ends with the same lone period, and RFC 1460 spells out the same doubling under a third name: the line is “byte-stuffed” by pre-pending the termination octet. But there is no three-digit code anywhere in it. The standard says there are “two success indicators: positive ("+OK") and negative ("-ERR")”, and that is the entire vocabulary. Four protocols reached for three digits and a fifth, written in the same decade for the same kind of job, did not need them.

Finger keeps only the first. There is no command: RFC 1288 defines the whole client side as a grammar for one line, optionally a flag, optionally a name, then CR LF. No verb, no reply code, and no terminator — the block ends because the server hangs up. It is the purest form of the claim this page opens with, and it is the one place where a keyboard is not merely a sufficient client but the only thing a client could be.

WHOIS says it outright. RFC 954 describes the entire protocol in three sentences: connect to port 43, “Send a single "command line", ending with <CRLF> (ASCII CR and LF)”, and then “The server closes its connection as soon as the output is finished.” The close is the terminator. That is a real design choice with a real cost, and it is why nothing built on it could ever ask a second question.

Which is the argument, rather than a longer list. Three digits and a lone period are not what a line protocol IS. They are what you reach for once a conversation has more than one turn in it, and the three protocols that never needed a second turn never reached.

How a reply ends, and what it costs

The three digits are three answers, not one number to look up. And a reply has two ways of ending, fourteen years apart, which are the same idea solved twice — once reversibly and once not.

Three digits, three questions

The first digit is the category and this page said so from the start. The second is a fact of the same section that went unsaid: RFC 959 encodes six “function groupings” there, and calls the third digit only “a finer gradation of meaning” within them. So two thirds of any reply code can be read without a table at all.

A three-digit reply code

first digit — the category: —
second digit — the function group: —
third digit — the gradation: —

RFC 959's six function groupings, by second digit
code	name	what it means

Two ways to end, and only one of them gives the text back

A block of text ends with a lone period, which is the rule the terminal above implements. A reply ends a different way: RFC 959 brackets it, first line xyz- and last line xyz with a space. Same hazard as the period — a line of the body that reads like the closing line would end the reply early — so “if an intermediary line begins with a 3-digit number, the Server must pad the front”. Note how much wider that is than the danger. Only the same code and a space really ends the reply, and the rule pads any three digits at all, because the routine writing the body does not always know which code will wrap it.

Here is the part worth typing at. The period's answer is a transparency procedure: the sender doubles, the reader collapses, and the text arrives byte for byte as it left. The reply's answer has no collapsing step. The reader is told to search for the code followed by a space and to ignore every line before it, and that is the whole rule. Nothing takes the pad off. Put a line beginning with three digits into the body below and watch the space survive the round trip.

The text a server wants to send inside one reply

on the wire: —
what the client reads back: —
same as what was sent: —

RFC 959 protects the frame at the payload's expense, and says so in the open: the padding is described going out and never described coming back. It is a smaller loss than a broken reply and it is still a loss, which is the sort of trade a specification makes once and everybody lives with for forty years.

The keyboard was the client, and once it was not enough

This page opens by saying a keyboard was a sufficient client. That is a claim, so here is where it comes from and here is the one protocol of the nine that half breaks it.

It comes from a specification, not from habit. RFC 854 defines a Network Virtual Terminal, and the sentence is as plain as it gets: “The NVT has a printer and a keyboard.” It is “a half-duplex device operating in a line-buffered mode” — which is where the words line mode come from. A terminal is the abstraction these protocols were written against. So typing at port 21 is not a trick that happens to work; RFC 959 says “The FTP uses the Telnet protocol on the control connection”, and adds that in practice it “relies on very little” of it. The terminal was the specified client.

And then FTP does something none of the other five do. It opens a second socket. “Files are transferred only via the data connection”; the one you are typing at carries the commands and the replies and nothing else. Step through a real transfer and watch which line lands where.

on the connection you typed at: —
on the one you cannot see: —

Seven of the eight lines are yours. The eighth is the file, and it is the reason FTP is the protocol that stopped working first. A second connection, opened in the other direction on a port chosen at run time, is exactly what a network address translator cannot follow and what a firewall is built to refuse.

The escape hatch was already in the box, and the order of events is worth getting right. PASV is in RFC 959, October 1985: it asks the server to “listen” on a data port and wait “rather than initiate one upon receipt of a transfer command”, so the client opens both connections outward. The first NAT specification, RFC 1631, is May 1994 — eight and a half years later. So PASV was not invented to get through anything. It was a mode for a different problem that turned out, much later, to be the only way an ordinary client could still transfer a file at all. This page used to say “PASV exists because of it”, and an outside reader was right to call that backwards.

And then you could not

The same request, three times, twenty-four years apart. It degrades in two steps and only the second is impossible.

The same request in three eras: what you type, whether it works, and what comes back
year	what you type	result	what comes back

the first five bytes of a TLS record: —
can you type them: —

The first step was not impossible, it was ambiguous: one machine began answering for many names, so a request that did not carry the name reached the wrong site. You could still type it. You had to know to type more.

The second step is a different kind of thing. A handshake is not text and was never meant to be: the five bytes above are outside printable ASCII, which is what the readout beside them measures. This page used to say there is no arrangement of keys that produces the byte 22, and that is simply false — a terminal can emit control characters, and 22 is one of them. The real barrier is larger than the keyboard. What follows those five bytes is a cryptographic state machine: a key exchange, a transcript hash, records the client has to construct and verify in order. A line of text ending in CR LF is no longer a sufficient client, whatever you can persuade the keys to send. And the reason is a good one: everything above crosses the wire in the clear, including the password you typed into FTP.

What this page checked when it loaded

Each claim, whether it held, and the values behind it
claim	held	measured

What is real here, and what is not

Nothing here opens a socket

There is no server at the other end of that terminal and no connection of any kind. The replies are written from each protocol’s own grammar as published, and a real server would differ in its greeting, its capabilities and most of its text. What is faithful is the SHAPE: the commands are the commands, the reply codes are real codes in their real classes, and the terminators are the terminators. A page that recorded real sessions would be more honest about the text and would need nine servers still running nine protocols, several of which are effectively gone.

The transparency rule is real code, not a description

Everything else here is a grammar written down. The doubling of a leading period is an actual transformation with an actual inverse, implemented and checked: twelve shapes of text including a line that is only a period, stuffed, sent through the wire form with its terminator, read back, and compared with the original. That is the one thing on this page you could take away and use.

Nine protocols is a selection, and Archie was cut

The plan had a seventh, Archie, and it came out on research rather than for space. RFC 1580 is a guide to network tools rather than a specification, and it documents how a person reached Archie — a local client, a telnet login, or email — without defining a wire protocol of its own. A service you reached by logging in and typing at somebody else’s program is a different thing from a protocol with a grammar, and it would have been the only member of the nine that could not answer the question this page asks.

The dates are the specifications, not the inventions

1971 is RFC 114, “A File Transfer Protocol”, dated 16 April 1971, which is where this era starts. 1995 is where it ends, and the end date moved during the build: the roster said 1994, which is when SSL 1.0 existed inside Netscape and was never released because it was broken. The first version an ordinary person could use was SSL 2.0, in Navigator 1.1, in February 1995. Ending the era at a version nobody could run would have been a nicer round number and a worse fact.

Line Mode is named after a browser this page does not simulate

CERN’s Line Mode Browser was written by Nicola Pellow during a student work placement and, in CERN’s own words, “By March 1991, a simple ‘Line-Mode’ browser was made available to users of CERN’s central computers.” It was the second browser there ever was and the first that ran on more than one kind of machine. It is the name because line mode is the real term for the thing this page is about — a screen you drive one line at a time — not because anything here reproduces that program. CERN built a faithful simulator of it in 2013 and this is not that.

What the neighbouring machine already covers

Winsock, on this same roster, gets to HTTP from underneath: it builds the dial-up link a layer at a time and then uses HTTP/0.9 narrowly, to show what a crawler misreads when there is no status line. That is the same protocol and a different question, and the overlap was checked rather than assumed before this page was built. This one is about the typing.

How this machine was built, what each of its claims is measured against, and where it was wrong first: the engineering notebook.