rfc98.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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]