Logger Protocol Proposal
RFC 98

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions

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.