Movatterモバイル変換

Network Working GroupRequest for Comments #98Network Information Center #5744                        Logger Protocol Proposal                          Edwin W. Meyer, Jr.                           Thomas P. Skinner                           February 11, 1971With the ARPA Network Host-to-Host  Protocol  specified  and  atleast  partially  implemented at a number of sites, the question of whatsteps should be taken next arises. There  appears  to  be  a  widespreadfeeling  among  Network  participants  that the first step should be thespecification and implementation of what has  been  called  the  "LoggerProtocol";  the  Computer  Network Group at project MAC agrees. The term"logger" has been commonly used to indicate the basic mechanism to  gainaccess  (to  "login")  to  a  system from a console. A network logger isintended to specify how the existing logger of  a  network  host  is  tointerface to the network so as to permit a login from a console attachedto another host.        To  implement  network  login   capability   now   seems   quitedesirable.In  the first place, it is natural for Network participants towish to learn more about the remote systems  in  the  immediate  fashionafforded  by  direct  use  of  those  systems.  In the second place, thetechnical problems introduced by remote logins are probably less complexthan  those  involved  with  such  further  tasks  as  generalized  filetransfer; thus,  a  Logger  Protocol  could  be  implemented  relativelyquickly,  furnishing  additional  impetus  and  encouragement for takingstill further steps.        In order to furnish at least a basis for discussion (and at mostan  initial  version  of  a  Logger  Protocol),  we  have  prepared thisdocument, which attempts to present a  minimal  set  of  conditions  forbasing  a  Logger  Protocol. This proposal covers only the mechanism foraccomplishing login. What occurs following login is not discussed  here,because  we  feel  more experimentation is necessary before any protocolfor general console communication can be established as standard. In itsabsence,  each  site  should  specify its own experimental standards forconsole communications following login.        Some of the points raised in this document have already  reacheda  certain  level of consensus among network participants while at leastone point is rather new. It should be clearly understood, however,  thatwe  feel  regardless  of  the disposal of particular issues, Networkwide                                                                [Page 1]

RFC 98                  Logger Protcol Proposal                 Feb 1971agreement should  be  reached  as  soon  as  possible  on  some  generalprotocol.  This is all the more desirable in view of the fact that it isquite likely that  certain  points  which  should  be  covered  in  thisprotocol  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  todecide  the  protocol should deal, and 2) specifications for the currentstate  of  the  protocolm  we  feel  that  we  should  acknowledge   theconsideration  that  a  case could be made for avoidingthe difficulty ofgenerating a Logger Protocol by simply  declaring  that  each  host  mayspecify  its  own, perhaps unique, preferences for being approached overthe Network. Although such a course is certainly possible, it  does  notseem  to  us  to  be desirable. One reason for avoiding such a course issimply that following  it  hamper  general  Network  progress,  in  thatadressing  the task of interfacing with some 20 systems is bound to moretime-consuming than to interface with "one"  system,  even  though  eachindivudual one of the former, multiple interfaces might be in some sensesimpler than the latter, single interface. Another consideration is lesspragmatic,  but  nonetheless  important:  agreement on a common protocolwould tend to foster a sense of Network "community", which would tend tobe  fragmented  by  the  local option route. After all, the Host-to-HostProtocol could have been handled on a per-host basis as well; assumedly,one  reason  why it has not had something to do with similar, admittedlyabstract considerations.Context   Structurally, the mechanism serving to login a user over the  Networkconsists  of  two  parts,  one  part at the using host, the other at theserving host. The using or local host is the  one  to  which  the  userstypewriter is directly connected; it contains a modulewhich channels andtransforms  communications  between  the  Network  connection  and   thetypewriter. The serving or foreign host provides the service to be used;it contains programming that adapts the logger and command system to usethrough 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  implementinglogin  can  be  separatedintop  two  major  parts:  how to establish andmaintain the network connection between the typewriter and  the  logger,and how to conduct a dialog after the connection is made. The first partis called the Initial Connection Protocol by Harlem and Heafner  in  RFC80.  Itin turn consists of two subparts: how to establish a connectionand how and when to destroy it.        We endorse the proposal for establishing a  connection  made  inRFC  80,  which  we  summarize briefly for convenience. It is a two-stepprocess utilizing the  NCP  control  messages  to  effect  a  connectionbetween  the logger and the console of a potential user. First, the usercauses the hosts NCP to send out  a  "request  for  connection"  controlmessage  destined  for the serving hosts loggers contact socket. The twopurposes of this message are to indicate to the logger  that  this  userwishes  to initiate a login dialog and to communicate the identifiers ofthe and send socket he wishes to operate for this  purpose.  The  loggerrejects  this request to free its contact socket. As the second step thelogger choses  two  sockets  to  connect  to  the  user's  sockets,  anddispatches  connection  requests  for  these.  If  the  user accepts theconnection within a reasonable period, the connection phase is over, andthe  dialog  phase can begin. If the user does not respond, the requestsare 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. Thefirst situation may arise of the serving host's volition. The logger maydecide  to abandon a login attempt or a logged-in user may decide to logout. The second situation may be due to the  using  host's  volition  ornetwork  difficulties.  This  situation  occurs  when  the  serving hostreceives a "close connection" control message  or  one  of  the  networkerror  messages signifying that further transmission is impossible. Thismay  happen  for  either  the  "read"   or   the   "write"   connection,Disconnecting  involves both the deletion of the network connections andthe 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 isalready logged in, his process should be stopped, since he no longer hascontrol 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  toconduct  the  login dialog. This resolves itself into two parts: what tosay and in what form to say it. The login dialog generally consist of  asequence  of  exchanges,  a  prompting  by the logger followed by a userreply specifying a name, a project, or password. However,  exactly  whatinformation  is  desired in what sequence is idiosyncratic to each host.Rather than attempt to specify a standard sequence for this  dialog,  wehave  taken the approach that each host may specify its own sequence, solong as it is  expressible  as  an  exchange  of  messages  in  a  basictransmission  format.  A  message is a set of information transmitted byone of the parties that is sufficient for the other  party  to  reply.Byhost  specification, either the logger or the user sends sends the firstmessage of the dialog. After that, messages are  exchanged  sequentiallyuntil the dialog is completed. In this context "message" has no relationto "IMP message".        The other issue involved in the login dialog is the  format  fortransmitting  a message. We propose that it be transmitted as a sequenceof ASCII characters (see Specificarions) in groupings calle  transactionblocks.   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  remotelogins   which  we  feel  should  be  raised,  although  most  need  notnecessarily 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.                             SPECIFICATIONSInitial Connection Protocol - Connection Phase      The following sequence is as presented inRFC 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  isstandard  ASCII  as  documented  in "American National Standard Code forInformation Interchange", ANS X3,  4-1968,  American  National  StandardInstitute, October, 1968. A logger at a serving host may demand any kindof input that can be  expressed  as  a  string  of  one  or  more  ASCIIcharacters. It similarly, it may output any such string.        All ASCII characters  are  legal,  including  the  graphics  andcontrol  characters.  However, it is proposed that the only standard wayof indicating the end of a console  line  be  the  line  feed  character(012).  This  is  in  accordance with an anticipated change to the ASCIIstandard.       Currently the ASCII standard permits  two  methods  of  ending  aline.  One  method  defines  a  single  character,  line  feed (012), asincorporating the combined functions of line space and  carriage  returnto  the  lefthand  margin.  The  second  method, implicitly permitted byASCII, uses the two character sequence  line  feed  (012)  and  carriagereturn (015) to perform the same function.        There is a proposal  that  the  ASCII  standard  be  changed  toinclude  a  return  to  the  left-hand  margin  in  all  vertical motioncharacters of at least one full space (line feed, vertical tab  and  newpage). This will disallow the dual character sequence to end a line.        It is suggested that a character in a hostst character  set  nothaving  any  ASCII  equivalnet be represented by the ASCII two charactersequence ESC (033) and one of the ASCII  characters.  Each  host  shouldpublish a list of the escape sequence it has defined.                                                                [Page 8]

RFC 98                  Logger Protcol Proposal                 Feb 1971Transaction Block Format        All textual messages exchanged between user and  logger  are  toconsist of one or more "transaction blocks". Each transaction block is asequence 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  ofsignificance. The reason for doing this is twofold: the  eighth  bit  ofthe  <chari> elements is specifically reserved for future expansion, andit was desired to limit  all  the  elements  so  as  to  permit  certainimplementations  to  convert  the incoming stream from 8-bit elements to7-bit elements prior to decoding.        With one exception, there  is  to  be  no  semantic  connotationattached  with  the  division  of a logger-user message into one or moretransaction blocks. The character string comprising the  message  to  betransmitted  may  be  divided and apportioned among multiple transactionblocks according to the whim of the  sending  host.  If  less  than  128characters  in  length,  the message may be sent as a single transactionblock. The exception is that separate messages may  not  appear  in  thesame  transaction  block. That is, a message must start at the beginningof a transaction block and finish at the end  of  one.  Note  also  thatthere  is  no syntactic device for specifying the last transaction blockof a message. It  is  presumed  that  the  logger  end  user  both  havesufficient  knowledge  of  the  format to know when all of a message hasarrived                                                                [Page 9]

RFC 98                  Logger Protcol Proposal                 Feb 1971        Note that the first 8-bits of data transmitted through  a  newlyestablished  connection  must  be  a  type code as specified in ProtocolDocument 1. This type code must be sent prior to the  first  transactionblock and should be discarded by the receiving host.Acknowledgments        Robert Bressler,  Allen  Brown,  Robert  Metcalfe,  and  MichaelPadlipsky  contributed  directly  to  the  establishment  of  the  ideaspresented  here.  Thanks  are  due  Michael  Padlipsky  and  others  foreditorial comments.       [ This RFC was put into machine readable form for entry ]          [ into the online RFC archives by Carl Moberg 1/98 ]                                                               [Page 10]