Logger Protocol Proposal
RFC 98
Document | Type |
RFC - Unknown
(February 1971; No errata)
Updated by RFC 123
|
|
---|---|---|---|
Authors | |||
Last updated | 2013-03-02 | ||
Stream | Legacy | ||
Formats | plain text html pdf htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 98 (Unknown) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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.Show full document text