doc: Add RFC documents

1 files changed, 563 insertions, 0 deletions

diff --git a/doc/rfc/rfc98.txt b/doc/rfc/rfc98.txt
new file mode 100644
index 0000000..3e8316b
--- /dev/null
+++ b/doc/rfc/rfc98.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Network Working Group
+Request for Comments #98
+Network Information Center #5744
+
+                        Logger Protocol Proposal
+
+                          Edwin W. Meyer, Jr.
+                           Thomas P. Skinner
+                           February 11, 1971
+
+
+        With the ARPA Network Host-to-Host  Protocol  specified  and  at
+least  partially  implemented at a number of sites, the question of what
+steps should be taken next arises. There  appears  to  be  a  widespread
+feeling  among  Network  participants  that the first step should be the
+specification and implementation of what has  been  called  the  "Logger
+Protocol";  the  Computer  Network Group at project MAC agrees. The term
+"logger" has been commonly used to indicate the basic mechanism to  gain
+access  (to  "login")  to  a  system from a console. A network logger is
+intended to specify how the existing logger of  a  network  host  is  to
+interface to the network so as to permit a login from a console attached
+to another host.
+
+        To  implement  network  login   capability   now   seems   quite
+desirable.In  the first place, it is natural for Network participants to
+wish to learn more about the remote systems  in  the  immediate  fashion
+afforded  by  direct  use  of  those  systems.  In the second place, the
+technical problems introduced by remote logins are probably less complex
+than  those  involved  with  such  further  tasks  as  generalized  file
+transfer; thus,  a  Logger  Protocol  could  be  implemented  relatively
+quickly,  furnishing  additional  impetus  and  encouragement for taking
+still further steps.
+
+        In order to furnish at least a basis for discussion (and at most
+an  initial  version  of  a  Logger  Protocol),  we  have  prepared this
+document, which attempts to present a  minimal  set  of  conditions  for
+basing  a  Logger  Protocol. This proposal covers only the mechanism for
+accomplishing login. What occurs following login is not discussed  here,
+because  we  feel  more experimentation is necessary before any protocol
+for general console communication can be established as standard. In its
+absence,  each  site  should  specify its own experimental standards for
+console communications following login.
+
+
+        Some of the points raised in this document have already  reached
+a  certain  level of consensus among network participants while at least
+one point is rather new. It should be clearly understood, however,  that
+we  feel  regardless  of  the disposal of particular issues, Networkwide
+
+
+
+                                                                [Page 1]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+agreement should  be  reached  as  soon  as  possible  on  some  general
+protocol.  This is all the more desirable in view of the fact that it is
+quite likely that  certain  points  which  should  be  covered  in  this
+protocol  will only become apparent during the course of implementation;
+therefore, the sooner a common basis for implementation can be  reached,
+the sooner a more rigorous protocol can be enunciated.
+
+        Before turning to 1) a discussion of the points  with  which  to
+decide  the  protocol should deal, and 2) specifications for the current
+state  of  the  protocolm  we  feel  that  we  should  acknowledge   the
+consideration  that  a  case could be made for avoidingthe difficulty of
+generating a Logger Protocol by simply  declaring  that  each  host  may
+specify  its  own, perhaps unique, preferences for being approached over
+the Network. Although such a course is certainly possible, it  does  not
+seem  to  us  to  be desirable. One reason for avoiding such a course is
+simply that following  it  hamper  general  Network  progress,  in  that
+adressing  the task of interfacing with some 20 systems is bound to more
+time-consuming than to interface with "one"  system,  even  though  each
+indivudual one of the former, multiple interfaces might be in some sense
+simpler than the latter, single interface. Another consideration is less
+pragmatic,  but  nonetheless  important:  agreement on a common protocol
+would tend to foster a sense of Network "community", which would tend to
+be  fragmented  by  the  local option route. After all, the Host-to-Host
+Protocol could have been handled on a per-host basis as well; assumedly,
+one  reason  why it has not had something to do with similar, admittedly
+abstract considerations.
+
+Context
+
+   Structurally, the mechanism serving to login a user over the  Network
+consists  of  two  parts,  one  part at the using host, the other at the
+serving host. The using or local host is the  one  to  which  the  users
+typewriter is directly connected; it contains a modulewhich channels and
+transforms  communications  between  the  Network  connection  and   the
+typewriter. The serving or foreign host provides the service to be used;
+it contains programming that adapts the logger and command system to use
+through the Network rather than a local typewriter.
+
+      There are three different phases to a login through the network.
+
+      1. During the connection phase the users console is connected to
+         the serving logger through the network. This is, of course,
+         the most important phase from the protocol viewpoint.
+
+      2. The second or dialog phase consists of a sequence of exchange
+         between the user and the logger that serves to identify the
+         user and verify his right to use the system. In some hosts,
+         this phase may be minimal or non-existent.
+
+
+
+                                                                [Page 2]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+      3. The admission phase occurs after the user has successfully
+         completed the login dialog. It consists of switching his
+         network typewriter connections from the logger to an entity
+         providing a command processor of some sort. In some hosts
+         this switching may be totally conceptual; in others there
+         may be a real internal switching between entities.
+
+
+The Connection Phase
+
+        The issues involved in specifying a  protocol  for  implementing
+login  can  be  separatedintop  two  major  parts:  how to establish and
+maintain the network connection between the typewriter and  the  logger,
+and how to conduct a dialog after the connection is made. The first part
+is called the Initial Connection Protocol by Harlem and Heafner  in  RFC
+80.  It  in turn consists of two subparts: how to establish a connection
+and how and when to destroy it.
+
+        We endorse the proposal for establishing a  connection  made  in
+RFC  80,  which  we  summarize briefly for convenience. It is a two-step
+process utilizing the  NCP  control  messages  to  effect  a  connection
+between  the logger and the console of a potential user. First, the user
+causes the hosts NCP to send out  a  "request  for  connection"  control
+message  destined  for the serving hosts loggers contact socket. The two
+purposes of this message are to indicate to the logger  that  this  user
+wishes  to initiate a login dialog and to communicate the identifiers of
+the and send socket he wishes to operate for this  purpose.  The  logger
+rejects  this request to free its contact socket. As the second step the
+logger choses  two  sockets  to  connect  to  the  user's  sockets,  and
+dispatches  connection  requests  for  these.  If  the  user accepts the
+connection within a reasonable period, the connection phase is over, and
+the  dialog  phase can begin. If the user does not respond, the requests
+are aborted and the logger abandons this login attempt.
+
+        There is another part to an NCP: when  and  how  to  disconnect.
+There  are  two  basic  situations  when a logger should disconnect. The
+first situation may arise of the serving host's volition. The logger may
+decide  to abandon a login attempt or a logged-in user may decide to log
+out. The second situation may be due to the  using  host's  volition  or
+network  difficulties.  This  situation  occurs  when  the  serving host
+receives a "close connection" control message  or  one  of  the  network
+error  messages signifying that further transmission is impossible. This
+may  happen  for  either  the  "read"   or   the   "write"   connection,
+Disconnecting  involves both the deletion of the network connections and
+the stoppage of any activity at the serving host related to  that  user.
+If  the  login  is  in  progress, it should be abandoned. If the user is
+already logged in, his process should be stopped, since he no longer has
+control over what it is doing. This is not intended to restrict absentee
+
+
+
+                                                                [Page 3]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+(i.e. consoleless) jobs.
+
+The Dialog Phase
+
+        The second major part other than getting  connected  is  how  to
+conduct  the  login dialog. This resolves itself into two parts: what to
+say and in what form to say it. The login dialog generally consist of  a
+sequence  of  exchanges,  a  prompting  by the logger followed by a user
+reply specifying a name, a project, or password. However,  exactly  what
+information  is  desired in what sequence is idiosyncratic to each host.
+Rather than attempt to specify a standard sequence for this  dialog,  we
+have  taken the approach that each host may specify its own sequence, so
+long as it is  expressible  as  an  exchange  of  messages  in  a  basic
+transmission  format.  A  message is a set of information transmitted by
+one of the parties that is sufficient for the other  party  to  reply.By
+host  specification, either the logger or the user sends sends the first
+message of the dialog. After that, messages are  exchanged  sequentially
+until the dialog is completed. In this context "message" has no relation
+to "IMP message".
+
+        The other issue involved in the login dialog is the  format  for
+transmitting  a message. We propose that it be transmitted as a sequence
+of ASCII characters (see Specificarions) in groupings calle  transaction
+blocks.
+
+   1. Character Set, We feel that there should be a standard
+      character set for logging-in. The alternative, requiring a
+      using host to maintain different transformation between its set
+      and of each serving host, is a burden that can only narrow the
+      scope of interhost usage, The character set proposed, ASCII is
+      widely used standard. Each host must define a transformation
+      sufficient to transform an arbitrary character sequence in the
+      host's code into ASCII and back again, without any ambiguity,
+      The definition of ASCII sequences to express characters not
+      contained in ASCII is appropriate.
+
+   2. Transaction Blocks. A message is transmitted as an arbitrary
+      integral number of transaction blocks. A transaction block
+      consists basically of a string of ASCII characters preceeded
+      by a character count. (It also contains a code field. See
+      below.) The count is included as an aid to efficiently
+      assembling a message. Some systems do not scan each character
+      as it is input from the console. Rather, such systems have
+      hardware IO controllers that place input characters into a
+      main memory buffer and interrupt the central processor only
+      when it receives an "action" character (such as "newline").
+      This reduces the load on the central processor. Because such
+      a hardware facility is not available for interpreting
+
+
+
+                                                                [Page 4]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+      network messages this scheme is proposed as a substitute. It
+      helps in two ways. First, a system need take no action until
+      it receives all characters specified in the count. Second, it
+      need not scan each character to find the end of the message.
+      The message ends at the end of the of a transaction block.
+
+Other Issues
+
+        There are several other issues involved in the  area  of  remote
+logins   which  we  feel  should  be  raised,  although  most  need  not
+necessarily have firm agreements reached for an intial protocal.
+
+1.  "Echoplex". Echoplex is a mode of typewriter operation in which
+    all typed material is directed by the computer. A key struck by
+    a user does not print directly. Rather the code is sent to the
+    computer, which "echoes" it back to be printed on the typewriter.
+    To reduce complexity, there is to be no option for network
+    echoplexing (for the login only). A using system having its
+    typewriters operating in echoplex mode must generate a local
+    echo to its typewriters. However, a serving system operating
+    echoplexed should suppress the echo of the input during the login
+    phase.
+
+2.  Correction of Mistakes. During the login dialog the user may make
+    a typing mistake. There is no mistake correction ecplicitly
+    proposed here. If the message in error has not yet been
+    transmitted, the user can utilize the input editing conventions
+    of either the using or the serving host. In the first case, the
+    message is corrected before transmission; in the second, it is
+    corrected at the serving host. If the user has made an
+    uncorrectlable mistake, he should abort the login and try again.
+    To abort, he instructs the local (using) host to "close" one of
+    the connections. The connections are disconnected as specified in
+    the Initial Connection Protocol.
+
+3.  "Waiting". It may happen that the user may get into a login dialog
+    but for some reason does not complete it. The logger is left
+    waiting for a response by the user. The logger should not wait
+    indefinitely but after a reasonable interval (perhaps a minute)
+    abort the login and "close" the connections according to the
+    provisions of the Initial Connection Protocol.
+
+4.  Socket Assignments. The Initial Connection Protocol does not
+    specify the ownership of the sockets to be used by the logger in
+    connecting to the user. (The use code field of the socket
+    identifier determines ownership.) The sockets may belong to the
+    logger or may have an arbitraryuser code not used by another
+    process currently existing at the serving host. Under this initial
+
+
+
+                                                                [Page 5]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+    scheme, it is not possible to implement administratively assigned
+    user codes, because the logger must assign permanent sockets
+    before the identity of the user is verified. A future connection
+    protocol can avoid this problem by implementing a socket
+    connection as a part of the admission phase. The logger would talk
+    to the user over the logger's sockets. Following identification it
+    would transfer the connections to the sockets belonging to the
+    user.
+
+5.  General Console Communications. A companion paper under
+    preparation outlines a protocol for general console communcations
+    between hosts. This paper will seek to adress most of the
+    problems associated with typewriter like communications. This
+    includes discussion of full and half duplex, character escapes,
+    action characters and other pertinent topics. Such a protocol
+    might not be suitable for all terminals and host systems but
+    would include solutions to problems for many. It is not
+    intended as a monolithic standard, but rather as a recommendation
+    for those sites who wish to implement a common protocol. The
+    important point is that we feel quite a bit of actual network
+    usage is required before all the problems are better understood.
+    This is a prerequisite for devising a standard.
+
+
+                             SPECIFICATIONS
+
+Initial Connection Protocol - Connection Phase
+
+      The following sequence is as presented in RFC 80. It  is  restated
+      here for completeness.
+
+1.  To intiate contact , the using process requests a connection of
+    his receive socket (US) to a socket (SERV) in the serving host.
+    By convention, this socket has the 24-bit user number field set
+    to zero. The 8-bit tag or AEN field is set to one indicating
+    the socket gender to be that of a sending socket. There is no
+    restriction on the choice of the socket US other than it be of
+    of the proper gender; in this case a receive socket. As a result
+    the using NCP sends:
+
+                            User -> Server
+
+                   8        32          32         8
+                +-----+------------+------------+-----+
+                | RTS |     US     |   SERV     |  P  |
+                +-----+------------+------------+-----+
+
+
+
+
+
+                                                                [Page 6]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+    over the control link one, where P is the receive link assigned
+    by the user's NCP.
+
+2.  The serving host now has the option of accepting the request for
+    connection or closing the the connection.
+
+    a.  If he sends a close it is understood by the user that the
+        foreign host is unable to satisfy a request for service at
+        this time. The serving host's NCP would send:
+
+                          Server -> User
+
+                   8        32          32
+                +-----+-----------+------------+
+                | CLS |    SERV   |     US     |
+                +-----+-----------+------------+
+
+        with the user's NCP sending the echoing close:
+
+                          User -> Server
+
+                   8        32          32
+                +-----+-----------+------------+
+                | CLS |     US    |    SERV    |
+                +-----+-----------+------------+
+
+    b.  If the serving host is willing to provide service it will
+        accept the connection and immediately close the connection.
+        This results in the the serving host's NCP sending:
+
+                          Server -> User
+
+                   8        32          32
+                +-----+-----------+------------+
+                | STR |    SERV   |     US     |
+                +-----+-----------+------------+
+
+                   8        32          32
+                +-----+-----------+------------+
+                | CLS |    SERV   |     US     |
+                +-----+-----------+------------+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 7]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+        with the user's NCP sending the echoing close. It sends:
+
+                          User -> Server
+
+                   8        32          32
+                +-----+-----------+------------+
+                | CLS |     US    |    SERV    |
+                +-----+-----------+------------+
+
+        It should be mentioned that the echoing closes are required
+        by the host-to-host protocol and not by the logger initial
+        connection protocol.
+
+Character Set
+
+        The character  set  used  in  conducting  the  login  dialog  is
+standard  ASCII  as  documented  in "American National Standard Code for
+Information Interchange", ANS X3,  4-1968,  American  National  Standard
+Institute, October, 1968. A logger at a serving host may demand any kind
+of input that can be  expressed  as  a  string  of  one  or  more  ASCII
+characters. It similarly, it may output any such string.
+
+        All ASCII characters  are  legal,  including  the  graphics  and
+control  characters.  However, it is proposed that the only standard way
+of indicating the end of a console  line  be  the  line  feed  character
+(012).  This  is  in  accordance with an anticipated change to the ASCII
+standard.
+
+       Currently the ASCII standard permits  two  methods  of  ending  a
+line.  One  method  defines  a  single  character,  line  feed (012), as
+incorporating the combined functions of line space and  carriage  return
+to  the  lefthand  margin.  The  second  method, implicitly permitted by
+ASCII, uses the two character sequence  line  feed  (012)  and  carriage
+return (015) to perform the same function.
+
+        There is a proposal  that  the  ASCII  standard  be  changed  to
+include  a  return  to  the  left-hand  margin  in  all  vertical motion
+characters of at least one full space (line feed, vertical tab  and  new
+page). This will disallow the dual character sequence to end a line.
+
+        It is suggested that a character in a hostst character  set  not
+having  any  ASCII  equivalnet be represented by the ASCII two character
+sequence ESC (033) and one of the ASCII  characters.  Each  host  should
+publish a list of the escape sequence it has defined.
+
+
+
+
+
+
+
+                                                                [Page 8]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+Transaction Block Format
+
+        All textual messages exchanged between user and  logger  are  to
+consist of one or more "transaction blocks". Each transaction block is a
+sequence of 8-bit elements in the following format:
+
+                <code> <count> <char1> ... <charn>
+
+<code>     is an 8-bit element that is not interpreted in this
+           protocol. In the proposed general console communications
+           protocol, this field specifies communication modes or
+           special characteristics of this transaction block. Here
+           <code> is to be zero.
+
+<count>    is an 8-bit element that specifies the number of character
+           elements that follow in this transaction block. It is
+           interpreted as a binary integer which has a permissible
+           range between 0 and 127. The most significant bit is zero.
+
+<chari>    is an 8-bit element containing a standard 7-bit ASCII
+           character right-adjusted. The most significant bit is
+           zero. The number of <chari> in the transaction block is
+           governed by the <count> field. A maximum of 127 and
+           minimum of zero characters are permitted in a single
+           transaction block.
+
+        The most significant bit of each  of  these  elements  is  zero,
+effectively   limiting   each   of  these  elements  to  seven  bits  of
+significance. The reason for doing this is twofold: the  eighth  bit  of
+the  <chari> elements is specifically reserved for future expansion, and
+it was desired to limit  all  the  elements  so  as  to  permit  certain
+implementations  to  convert  the incoming stream from 8-bit elements to
+7-bit elements prior to decoding.
+
+        With one exception, there  is  to  be  no  semantic  connotation
+attached  with  the  division  of a logger-user message into one or more
+transaction blocks. The character string comprising the  message  to  be
+transmitted  may  be  divided and apportioned among multiple transaction
+blocks according to the whim of the  sending  host.  If  less  than  128
+characters  in  length,  the message may be sent as a single transaction
+block. The exception is that separate messages may  not  appear  in  the
+same  transaction  block. That is, a message must start at the beginning
+of a transaction block and finish at the end  of  one.  Note  also  that
+there  is  no syntactic device for specifying the last transaction block
+of a message. It  is  presumed  that  the  logger  end  user  both  have
+sufficient  knowledge  of  the  format to know when all of a message has
+arrived
+
+
+
+
+                                                                [Page 9]
+
+RFC 98                  Logger Protcol Proposal                 Feb 1971
+
+
+        Note that the first 8-bits of data transmitted through  a  newly
+established  connection  must  be  a  type code as specified in Protocol
+Document 1. This type code must be sent prior to the  first  transaction
+block and should be discarded by the receiving host.
+
+
+Acknowledgments
+
+        Robert Bressler,  Allen  Brown,  Robert  Metcalfe,  and  Michael
+Padlipsky  contributed  directly  to  the  establishment  of  the  ideas
+presented  here.  Thanks  are  due  Michael  Padlipsky  and  others  for
+editorial comments.
+
+
+       [ This RFC was put into machine readable form for entry ]
+          [ into the online RFC archives by Carl Moberg 1/98 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                               [Page 10]
+