NETED: A Common Editor for the ARPA Network
RFC 569

Document Type RFC - Historic (October 1973; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 569 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                   Mike Padlipsky
RFC 569/ NET-USING Memo 1                                    NET-USING
NIC # 18972                                           October 15, 1973

             NETED: A Common Editor for the ARPA Network

BACKGROUND

At the recent Resource Sharing Workshop, there was a somewhat
surprising degree of consensus on what I had anticipated would the
least popular aspect of the my "Unified User-Level Protocol" proposal:
A number of the attendees agreed without argument that it would be
a good thing to have "the same" context editor available on all
Servers -- where "the same" refers, of course, to the user interface.
We even agreed that "NETED" seemed to be a plausible common name.  In
view of the fact that the rest of the proposal didn't seem to capture
anybody's imagination, though, it seemed to be a useful notion to
separate out the common editor and make it the subject of a
stand-alone proposal.

My resolve to come up with the following was further strengthened at
the the organizing meeting of the Network User Interest Group, which
followed the Workshop.  Being primarily concerned with user issues,
this group was downright enthusiastic about the prospect of a common
editor.  Indeed, this proposal has been reviewed by the group and is
endorsed by it.

REASONS

The need for a common editor might well be obvious to many readers.
They are encouraged to skip this section, which is for the benefit of
those who don't already see the light.

In the first place, it's almost axiomatic that to use a time-sharing
system, you have to be able to create files (/"datasets"/"segments").
Even if you're only using the Network to send "mail", you'd still like
to be able to create a file separately, so as to be able to edit it
before sending.  And if you want to write a program -- or even make a
"runoff" source file -- you simply must be able to use some editor
command on the system at hand.

Unfortunately, there are even more editors than there are systems;
and each one has it own conventions and peculiarities.  So "Network
users" (who use several Servers, as opposed to those who use the
Network only to access a particular system all the time) are faced
with the unpleasant chore of developing several sets of incompatible
reflexes if they want to get along.  This can certainly be done.  It
has been by a number of members of the Network Working Group.



NETED SPEC                                                        p.2

The real kicker, however, comes when we consider the needs of those
users -- who are coming into the Network community in ever-increasing
numbers -- who are not professional programmers.  They just want to
get some work done, "on the Net" (that is, irrespective of which
operating system they might be talking to).  They are likely to be
appalled rather than amused by having to learn a dozen ways of getting
to first base.  Therefore, it seems clear than not only do we need a
common editor, but we also need a simple common editor.

CHOICES

Simplicity is not the only criterion for rejecting the apparently
"obvious" choice of either TECO or QED.  (That it is a strong factor
is indicated by the old test of "Consider explaining it to a naive
secretary -- now consider explaining it to a corporation president.")
Perhaps even worse is the problem of "dialects".  That is, features
vary across implementations, and settling on a common set of features
(or dialect) is likely to be a very hard task, for programmers tend to
get very fond of their familiar goodies.  Besides, both TECO and QED
have their own strong (/fanatic) advocates, who's probably never be
willing to settle for the other one.  Further, not every system has
both, and implementing the other is a fairly large job even if the NWG
could agree on which (and how much).

At any rate, the difficulties seem overwhelming when it comes to
choosing a high-powered editor as the common editor.  Therefore, I
tried to think of a nice low-powered editor, and it suddenly occurred
to me that I not only knew of one, but it was even fairly well
documented (!).  The editor in question is known on Multics as "eds"
(the same member of the "ed" family of editors which started on
CTSS), a line-oriented context editor (no "regular expressions", but
also no line numbers).  It is used as an extended example of
programming in the Multics environment in Chapter 4 of the Multics
Programmers' Manual, which gives an annotated PL/I listing of the
actual working program.  It is simple to learn and should be quite
easy to implement,  PL/I version serves as a detailed model with only
equivalent system calls and choice of language to worry about.  I urge
its adoption as the common Network editor, to be known on all
participating Servers as "NETED" and/or "neted".

DOCUMENTATION

In view of the fact that if "eds"/NETED is adopted only perhaps a
dozen members of the NWG will actually have to implement one, it seems
wasteful to distributed some 30 pages of the MPM to everyone --
Show full document text