doc: Add RFC documents

1 files changed, 373 insertions, 0 deletions

diff --git a/doc/rfc/rfc569.txt b/doc/rfc/rfc569.txt
new file mode 100644
index 0000000..9b79bc8
--- /dev/null
+++ b/doc/rfc/rfc569.txt
@@ -0,0 +1,373 @@
+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 --
+especially since most of the parties concerned have access to an MPM
+already.  (Another problem solved by not including it here is that of
+whether I'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.
+
+
+NETED SPEC                                                        p. 3
+
+Anybody who needs a copy can let me know.  Although the emphasis in
+the document is, naturally enough, on the Multics-specific aspects, I
+believe that the listing is clear enough to serve as a model to
+implementors without any great difficulty.  If we do get to the
+implementation stage, I'll be glad to try to explain any non-obvious
+system calls, either individually or in a follow-up memo.  But 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.
+For that matter, some implementers might prefer to ignore the existing
+program and simply work from the function specifications (below).
+
+LIMITATIONS
+
+It became abundantly clear during the course of the review of this
+document by the User Interest Group that the limitations of NETED must
+be acknowledged (even insisted upon) and explained here.  In the first
+place, it must be emphasized that it is not being proposed as "THE"
+Network editor.  Rather, it is an insistently simple-minded editor for
+two major reasons:  1) it is meant for use mainly by non-professional
+programmers, and 2) more important still, it is meant to be extremely
+easy to implement.  Therefore, it seems far more important to go with
+the published program, with all its warts, than to specify the
+addition of new, undebugged features.  The idea is to make it
+implementable in man-days by an average to average-plus programmer
+instead of in man-weeks by a superstar programmer.
+
+In the second place, the very act of adding new features is fraught
+with peril.  To take some examples from the comments I received during
+the review phase:  In the first draft, I inadvertently failed to
+document the mechanism by which the ability to "go backwards" (i.e.,
+to reverse the direction of the current-line pointer described below)
+is actuated.  Several reviewers argued strongly for the inclusion of
+such a mechanism; but, not knowing it was already "in" the code I
+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 be a false
+alarm, I've left it in to emphasize the sort of pitfalls we can get
+into by haggling over particular "features".  Another familiar feature
+is some sort of "read" request so that the file name need not be
+specified as an argument to the command.  Then, of course, one would
+also want a "create" or "make" request.  And perhaps a file delete
+request?  It keeps going on and on.  The point, I think, is that if we
+allow ourselves to go into "tinker mode" we could spend as many years
+striving to achieve consensus on what features to add as we've spent
+on Telnet or FTP ... and still not please everyone.  Therefore, I urge
+the NWG to accept the contention that having a working model to use as
+
+
+
+NETED SPEC                                                     p. 4
+
+a pattern is more  important than any particular additional features
+(even  though I myself find "=" for "what's the current line's
+number?" annoying to live without).
+
+RESPONSES
+
+For the benefit of those who don't want to plow through the functional
+spec, this seems to be a good spot to indicate what appropriate
+responses to this proposal would be.  Ideally, I'd like to hear from a
+responsible system programmer at, say, TENEX, CCN, UCSD, UCSB,
+AMES-67, one of the DEC 10/50 Hosts, and from any of the experimental
+Servers who happen to be interested, that they think it's a fine idea
+and why don't I log in next week to try their NETEDs.  Next most
+desirable would be agreement in principle followed by specific
+inquiries about "eds".  I would hope that haggling over specific
+features wouldn't occur (as we're not trying to do a definitive
+editor, just an easy, commonly implemented one based on an existing
+implementation), but unfortunately I can't legislate such haggles out
+of existence.  At the very least, I'd hope to either hear or see
+reasoned arguments why it's not worth doing.  As usual, phone, mail
+"mail" ("map.cn" in sndmsg, or "map cn" in "mail" on Multics) or RFC's
+are the assumed media for responding.
+
+USAGE
+
+(The following is intended to serve double-duty, as both a functional
+spec now and -- with the addition of some examples -- a "users'
+manual" later.  So if it seems to "tutorial", I'm sorry.  And if it
+doesn't seem tutorial enough -- assuming the addition of examples --
+please let me know.)
+
+As is typical of "context editors," the NETED command is used both for
+creating new files and for altering already existing files -- where
+"files" are named collections of character encoded data in the storage
+hierarchy of a time-sharing system.  Consequently, NETED operates in
+two distinct "modes" -- called "input mode" and "edit mode".
+
+When NETED is used to create a file (that is, when it is invoked from
+command level with an argument which specifies the name of a file
+which does not already exist in the user's "working directory"), it is
+automatically in input mode.  It will announce this fact 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 will
+go into the specified file.  (Actually, it goes into a "working copy"
+of the file, and into the real file only when you indicate a desire to
+have that 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
+
+
+
+NETED SPEC                                                        p. 5
+
+After leaving input mode, you are in edit mode.  Here, you may issue
+various "requests" which will allow you to alter the contents of the
+(working) file, re-enter input mode if you wish, and eventually cause
+the file to be stored.  Note that edit mode is entered automatically
+if the argument you supplied to NETED specified an existing file.
+Regardless of how it was entered, being in edit mode is confirmed by
+NETED's outputting a message of the form "Edit".  Editing is performed
+relative to (conceptual) pointer which specifies the current line, and
+many requests pertain to 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 follow, in order intended to be helpful.
+Two important reminders:  the requests may only be issued from edit
+mode, and each one "is a line" (i.e., terminates in a new line /
+carriage return / linefeed is appropriate to the User Telnet being
+employed).  SYNTAX NOTE:  If the request takes an argument, there must
+be at least one space (blank) between request's name and the argument.
+
+1.  n m
+
+For unsigned m, the n(ext) request causes the pointer to be moved
+"down" m lines.  If m is negative, the pointer is moved "up" m lines.
+If m is not specified, the pointer is moved one line.  If the end of
+the file is reached, an "End of file reached by n m" message is output
+by NETED; the pointer is left "after" the last line.
+
+2.  l string
+
+The l(ocate) request causes the pointer to be moved to the net line
+containing the character string "string" (which may contain blanks);
+the line is output.  If no match is found, a message of the form "End
+of file reached by l string" will be output (and the pointer will
+have returned to the top of the file).  The search will not wrap
+around the end of the file; however, if the string was above the
+starting position of the pointer, a repetition of the locate request
+will find it, in view of the fact that the pointer would have been
+moved to the top of the file.  To find any occurrence of the string --
+rather than the next occurrence -- it is necessary to move the pointer
+to the top of the file before doing the locate (see following
+request).
+
+3.  t
+
+Move the pointer to the top of the file.
+
+
+
+NETED SPEC                                                       p. 6
+
+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.  (First new line
+goes after current old line.)
+
+6.  i string
+
+The i(nsert) request cause a line consisting of string (which will
+probably contain blanks) to be inserted after the current line.  The
+pointer is moved to the new line.  Edit mode is not left.
+
+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 causes the current line and the succeeding m - i
+lines to be output.  If m is not specified, only the current line will
+be output.  End of file considerations are the same as with "n".
+
+9.  c /s1/s2/ m g
+
+The c(hange) request is quite powerful, although perhaps a bit complex
+to new users.  In the line being pointed at, the string of characters
+s1 is replaced by the string of characters s2.  If s1 is void, s2 will
+be inserted at the beginning of the line; if s2 is void, s1 will be
+deleted from the line.  Any character not appearing within either
+character string may be used in place of the slash (/) as a delimiter.
+If a number, m, is present, the request will affect m lines, starting
+with the one being pointed at.  All lines in which a change was made
+are 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 will be changed.  If "g" (for "global")
+is present, all occurrences of s1 within a line will be changed.  (If
+s1 is void, "g" has no effect.)  NOTE WELL:  blanks in both strings
+are significant and must be counted exactly.  End of file
+considerations are the same as with "n".
+
+10.  d m
+
+The d(elete) request causes m lines, including the current one, to be
+deleted from the working copy of the file.  If m is not specified, only
+the current line is 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.  (Useful for those who fear crashes and don't want to lose all
+the work performed.)
+
+12.  save
+
+Write out the working copy into the storage hierarchy and exit from
+NETED.
+
+Additional specs:
+
+a.  On Multics, type-ahead is permitted.  This approach is recommended
+for all versions of NETED, but is of course not required as various
+Servers' NCP Implementations may prohibit it; however:
+
+b.  If an error is detected, the offending line is output, and pending
+typeahead (if any) must be discarded (to guard against the possibility
+of the pending request's being predicated on the success of erroneous
+request).
+
+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; indeed, quitting out is the general method of negating
+large amounts of incorrect work and retaining the original file
+intact.
+
+(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 that
+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.
+