RFC 569

NETED: A Common Editor for the ARPA Network

📅 published October 1973, from ietf

RFC 569: NETED: A Common Editor for the ARPA Network 🎀

okay bestie, the title block first! 💖 This one is by Mike Padlipsky, written for the NET-USING group as RFC 569 / NET-USING Memo 1, with NIC # 18972, dated October 15, 1973. The header doesn't list a category, and it doesn't say what this RFC obsoletes or updates. 🧚

BACKGROUND ✨

ngl, this one starts with a little drama. 🙈 At the recent Resource Sharing Workshop, people were surprisingly united on what Mike thought would be the least popular part of his "Unified User-Level Protocol" proposal. Basically everyone agreed, no arguments, that it would be iconic to have "the same" context editor on all Servers. By "the same" he means the same user interface, obviously. People even liked the name "NETED" 😭. But the rest of the proposal didn't really get anyone hyped, so he decided to split the editor off into its own stand-alone proposal. 💅

He was even more motivated after the organizing meeting of the Network User Interest Group, which came right after the Workshop. That group cares about user issues, so they were obsessed with a common editor. This proposal has actually been reviewed by the group and is endorsed by them. 👑

REASONS 🎀

The need for a common editor might be super obvious to a lot of you. 💅 If so, you can skip this section. It's for the people who haven't seen the light yet. 🌈

First of all, it's basically axiomatic that to use a time-sharing system, you have to be able to create files ("datasets" or "segments"). Even if you're only using the Network to send "mail," you'd still want to make a file on its own so you can edit it before sending. And if you want to write a program, or even a "runoff" source file, you simply must be able to use some editor command on the system you're on. 💖

The problem is there are even more editors than there are systems, and every single one has its own conventions and quirks. So "Network users" (people who use several Servers, as opposed to people who only ever use the Network to reach one particular system) have to go through the annoying chore of learning several sets of incompatible reflexes if they want to get along. It can be done, and a bunch of Network Working Group members have done it. 🦋

NETED SPEC p.2 🌸

The real kicker, though, is for the users who are joining the Network community in ever-increasing numbers and who are not professional programmers. 🥺 They just want to get some work done "on the Net," which means no matter what operating system they're talking to. They're going to be appalled, not amused, to have to learn a dozen ways of getting to first base. 😩 So it seems clear we don't just need a common editor, we need a simple common editor. 🫶

CHOICES 💅

Simplicity isn't the only thing that rules out the "obvious" choices of TECO or QED. 🙃 (It's a big factor, though, as shown by the old test of "Consider explaining it to a naive secretary -- now consider explaining it to a corporation president.") Even worse is the problem of "dialects." Features vary across implementations, and agreeing on a shared set of features (or dialect) is going to be a super hard task, because programmers get very attached to their familiar goodies. 🍓 Plus, both TECO and QED have strong, fanatic advocates who probably would never settle for the other one. 💀 And not every system has both. Implementing the other one is a pretty big job, even if the NWG could agree on which one, and how much of it. 😵‍💫

Anyway, the difficulties feel overwhelming when you try to pick a high-powered editor as the common one. So Mike tried to think of a nice low-powered editor instead. Then it suddenly hit him that he not only knew of one, but it was even fairly well documented (!). 🤩 The editor is called "eds" on Multics. It's the same member of the "ed" family of editors that started on CTSS, and it's a line-oriented context editor. It has no "regular expressions," but it also has no line numbers. 🧚 It's used as an extended example of programming in the Multics environment in Chapter 4 of the Multics Programmers' Manual, which includes an annotated PL/I listing of the actual working program. It's simple to learn and should be pretty easy to implement. The PL/I version works as a detailed model, so you'd only have to worry about equivalent system calls and choice of language. 💖 He urges its adoption as the common Network editor, to be known on all participating Servers as "NETED" and/or "neted." ✨

DOCUMENTATION 📚

Here's the thing: if "eds"/NETED gets adopted, only maybe a dozen NWG members will actually have to implement it. So it'd be wasteful to distribute about 30 pages of the MPM to everyone 🙄, especially since most of the people involved already have access to the MPM. (Not including it here also solves the question of whether he'd be violating copyright by doing so. 👀) The exact reference is pp. 24-54 of Chapter 4 of Part I of the Multics Programmer's Manual. 📖

Anybody who needs a copy can just let him know. The document focuses on Multics-specific stuff, of course, but he thinks the listing is clear enough to work as a model for implementors without much trouble. 🦋 If they do get to the implementation stage, he'll gladly explain any non-obvious system calls, either one at a time or in a follow-up memo. Even though we "initiate" where you "open," or we "call los_$read_ptr" where you "IOT TTY" (or something), it shouldn't cause much trouble. ✨ Some implementers might even prefer to skip the existing program entirely and just work from the function specifications (below). 🫶

LIMITATIONS 🚧

It became super clear during the review of this document by the User Interest Group that the limitations of NETED must be acknowledged (even insisted upon) and explained here. 💅

First, NETED is not being proposed as "THE" Network editor. It's an insistently simple-minded editor for two major reasons: 1) it's meant mainly for non-professional programmers, and 2) even more important, it's meant to be extremely easy to implement. 🌸 So it seems way more important to go with the published program, with all its warts, than to add new, undebugged features. The goal is to make it implementable in man-days by an average to average-plus programmer, instead of in man-weeks by a superstar programmer. 🏆

Second, just adding new features is fraught with peril. 😬 Some examples from the review-phase comments: in the first draft, Mike accidentally forgot to document how you "go backwards" (meaning reversing the direction of the current-line pointer described below). Several reviewers strongly argued for including a mechanism for that. But he didn't know it was already "in" the code, so he argued, successfully, for leaving it out, on the grounds that we should stick to what's in the existing code, which is known to work as published. 🙈 Even what to call such a new request would have been debatable. Should it be "-" and become the only non-alphabetic name? Should it be "b" for "bottom"? Should "n" (for "next") become "+"? And so on. 🌀 Although this particular issue turned out to be a false alarm, he left it in to show the kinds of pitfalls we can fall into by haggling over particular "features." Another familiar feature is some sort of "read" request, so the file name doesn't need to be given as an argument to the command. Then, of course, you'd want a "create" or "make" request too. And maybe a file delete request? It keeps going on and on. 😵‍💫

The point is, if we let ourselves go into "tinker mode," we could spend as many years chasing consensus on features as we've already spent on Telnet or FTP... and still not please everyone. 💀 So he urges the NWG to accept that having a working model to use as a pattern matters more than any particular extra features. (Even though he personally finds "=" for "what's the current line's number?" annoying to live without. 🥹)

RESPONSES 💌

For anyone who doesn't want to slog through the functional spec, this seems like a good spot to say what good responses to this proposal would look like. 🧚 Ideally, he'd love to hear from a responsible system programmer at places like TENEX, CCN, UCSD, UCSB, AMES-67, one of the DEC 10/50 Hosts, and any experimental Servers that happen to be interested. He wants them to say it's a fine idea and why don't he log in next week to try their NETEDs. 🤞 The next most desirable thing would be agreement in principle, followed by specific questions about "eds." 💖 He hopes haggling over specific features won't happen, since they aren't trying to make a definitive editor, just an easy, commonly implemented one based on an existing implementation. Unfortunately, he can't legislate those haggles out of existence. 🙃 At the very least, he'd like to either hear or see reasoned arguments for why it's not worth doing. 🫶

As usual, phone, mail "mail" ("map.cn" in sndmsg, or "map cn" in "mail" on Multics) or RFCs are the assumed media for responding. 📬

USAGE 🦋

(The following is meant to do double duty, as both a functional spec now and, with some examples added, a "users' manual" later. So if it seems too "tutorial," sorry. And if it doesn't seem tutorial enough, once examples are added, please let him know. 🫶)

As is typical of "context editors," the NETED command is used both for creating new files and for changing files that already exist. "Files" here means named collections of character encoded data in the storage hierarchy of a time-sharing system. 💅 So NETED operates in two distinct "modes," called "input mode" and "edit mode." ✨

When NETED is used to create a file (that is, when it's invoked from command level with an argument naming a file that doesn't already exist in the user's "working directory"), it automatically goes into input mode. 🌸 It announces this by outputting a message along the lines of File soandso not found. Input. Until you take explicit action to leave input mode, everything you type goes into the specified file. (Technically, it goes into a "working copy" of the file, and only into the real file when you say you want that to happen. 🤓) To leave input mode, type a line consisting of only a period and the appropriate new-line character: .<NL>, where <NL> is whatever it takes to cause a Telnet New-Line to be generated from your terminal. 💖

After leaving input mode, you're in edit mode. Here you can issue various "requests" that let you alter the contents of the (working) file, re-enter input mode if you want, and eventually cause the file to be stored. 🎀 Edit mode is entered automatically if the argument you gave NETED named an existing file. Either way you got there, being in edit mode is confirmed when NETED outputs a message of the form Edit. 💅 Editing happens relative to a (conceptual) pointer that specifies the current line, and lots of requests are about either moving the pointer or changing the contents of the current line. (When edit mode is entered from input mode, the pointer is at the last line input. When entered from command level, the pointer is at the "top" of the file. 🧚)

NETED's edit mode requests come next, in an order meant to be helpful. 🌈 Two important reminders: the requests may only be issued from edit

(to be continued in part 2 💜)

Okay so you're in edit mode now 💖, and every request you send is its own "line" (bestie, that means it ends in whatever new line thing your User Telnet is using: a new line / carriage return / linefeed, as appropriate 🎀). SYNTAX NOTE 🚨: if a request takes an argument, there has to be at least one space (blank) between the request's name and the argument. No skipping that space, bestie 🙈

1. n m

The n(ext) request is your "go down" button 🦋. For unsigned m, it moves the pointer "down" m lines. If m is negative, the pointer goes "up" m lines instead. If m isn't specified, it moves one line. If you hit the end of the file, NETED outputs End of file reached by n m and leaves the pointer "after" the last line 😭

2. l string

The l(ocate) request is the search button 🔍. It moves the pointer to the next line containing the character string "string" (which may contain blanks 🍓) and outputs that line. If nothing matches, you'll see a message of the form End of file reached by l string, and the pointer will have gone back to the top of the file 💀. The search won't wrap around the end of the file, BUT if the string was above where the pointer started, repeating the locate request will find it, since the pointer would have been moved to the top of the file already ✨. To find any occurrence of the string (not just the next one), you have to move the pointer to the top of the file before doing the locate. See the following request 👑

3. t

Move the pointer to the top of the file. Simple, iconic 💅

4. b

Move the pointer to the bottom of the file and enter input mode 🌈

5. "."

Leave the pointer where it is and enter input mode. (The first new line goes after the current old line 🧚)

6. i string

The i(nsert) request causes a line consisting of string (which will probably contain blanks) to be inserted after the current line 🌸. The pointer moves to the new line. Edit mode is NOT left, so you can keep going 🫶

7. r string

The r(eplace) request causes a line consisting of string (probably containing blanks) to replace the current line 💜

8. p m

The p(rint) request outputs the current line and the succeeding m - i lines 📄. If m isn't specified, only the current line gets output. The end of file considerations are the same as with n 🦋

9. c /s1/s2/ m g

The c(hange) request is honestly the most powerful one, though it's a bit complex for new users, so take your time bestie 🫶 In the line being pointed at, the string of characters s1 is replaced by the string of characters s2. If s1 is void, s2 gets inserted at the beginning of the line. If s2 is void, s1 gets deleted from the line. Any character that doesn't appear within either character string can be used in place of the slash (/) as a delimiter, so you've got options 🎀 If a number, m, is present, the request affects m lines, starting with the one being pointed at. All lines where a change was made get printed. The pointer is left at the last line scanned 👀 If the letter g is absent (after the final delimiter), only the first occurrence of s1 within a line gets changed. If g (for "global") IS present, all occurrences of s1 within a line get changed. (If s1 is void, g has no effect 🙃)

NOTE WELL 🚨: blanks in both strings are significant and must be counted exactly. Count your spaces, babe 💀 End of file considerations are the same as with n.

10. d m

The d(elete) request deletes m lines, including the current one, from the working copy of the file 🗑️ If m isn't specified, only the current line gets deleted. The pointer is left at a null line above the first undeleted line. End of file considerations are the same as with n 💅

NETED p. 7

11. w

Write out the working copy into the storage hierarchy but REMAIN in NETED. This is perfect for the worried ones who fear crashes and don't want to lose all the work they've done 😭🫶

12. save

Write out the working copy into the storage hierarchy and EXIT from NETED. Main character exit 👑

Additional specs

a. On Multics, type-ahead is permitted. This approach is recommended for all versions of NETED, but it's of course not required, since various Servers' NCP Implementations may prohibit it. However:

b. If an error is detected, the offending line is output, and any pending typeahead (if any) must be discarded 🚫 This guards against the possibility of the pending request's being predicated on the success of the erroneous request. Don't let a bad request drag the next one down with it 💀

c. The command is not reinvokable, in the sense that work is lost if you "quit" out of it via the Telnet Interrupt Process command or its equivalent 😱 Quitting out is the general method of negating large amounts of incorrect work and keeping the original file intact, so honestly it's a safety net 🧚

(When the time comes, I'll be glad to furnish examples for the users' manual version 📖 but for now, that's all there is 🌸)

NOTE

It really does work, unsophisticated though it may be 🥹 I think it's sufficient to get new users going, and necessary to give them a fighting chance. It would even be of utility within the NWG, for those of us who don't like having to learn new editors all the time 💖 If anybody wants to try it, I'll make a version available to "anonymous users" (see the Multics section in the Resource Notebook if you don't already know how to get in our sampling account 🎀), under the name "neted". (*) (If you do try it, please delete files when done with them 🫶)

(*) Knowledgeable Multics users with their own accounts can instead link to >udd>cn>map>neted. It is also there under the names "eds" if you want to save typing a couple of characters ⭐

📦 where this page comes from