scispace - formally typeset
Search or ask a question

Showing papers on "The Internet published in 1977"


Journal ArticleDOI
01 Jan 1977
TL;DR: Another technique for internet routing in which the source of internet packets specifies the complete internet route is considered, which is complicated and overhead increases.
Abstract: As plans for network interconnection develop, the problems of internet routing and addressing become increasingly important. In one popular model of internet addressing, a hierarchical form of network and local (within network) address is used, with the source providing only the destination address while the intermediate network(s) and/or Gateways between networks take care of routing packets to that destination by various paths. This and related techniques requiring some form of routing table and knowledge at intermediate nodes are more fully discussed in [1,2,3].This paper considers another technique for internet routing in which the source of internet packets specifies the complete internet route. When the entire route accompanies each internet packet, no routing decisions or tables are required at Gateways, but the packet format is complicated and overhead increases. In particular, the packet must carry a varying number of intermediate addresses depending on the path and destination [4]. This overhead may be reduced by setting up a fixed route with connection tables [1] when a connection is established.

111 citations


Journal ArticleDOI
TL;DR: Techniques to implement internet addressing, routing, error recovery, and other necessary communication services on top of local network facilities appear feasible without demanding large changes to individual nets.

68 citations


21 Nov 1977
TL;DR: This specification was developed over the course of one year, using the ARPANET mail environment, itself, to provide an ongoing forum for discussing the capabilities to be included and believe that there is enough of a consensus in the Network community in favor of such a standard syntax to make possible its adoption.
Abstract: PREFACE ARPA's Committee on Computer-Aided Human Communication (CAHCOM) wishes to promulgate a standard for the format of ARPA Network text message (mail) headers which will reasonably meet the needs of the various message service subsystems on the Network today. The authors of this document constitute the CAHCOM subcommittee charged with the task of developing this new standard. Essentially, we specify a revision to ARPANET Request for Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC 680, "Message Transmission Protocol". This revision removes and compacts portions of the previous syntax and adds several features to network address specification. In particular, we focus on people and not mailboxes as recipients and allow reference to stored address lists. We expect this syntax to provide sufficient capabilities to meet most users' immediate needs and, therefore, give developers enough breathing room to produce a new mail transmission protocol "properly". We believe that there is enough of a consensus in the Network community in favor of such a standard syntax to make possible its adoption at this time. An earlier draft of this specification was published as RFC #724, "Proposed Official Standard for the Format of ARPA Network Messages" and contained extensive discussion of the background and issues in ARPANET mail standards. This specification was developed over the course of one year, using the ARPANET mail environment, itself, to provide an ongoing forum for discussing the capabilities to be included. More than twenty individuals, from across the country, participated in this discussion and we would like to acknowledge their considerable efforts. The syntax of the standard was originally specified in the Backus-Naur Form (BNF) metalanguage. Ken L. Harrenstien, of SRI International, was responsible for re-coding the BNF into an augmented BNF which compacts the specification and allows increased comprehensibility.

30 citations


12 May 1977
TL;DR: There is enough of a consensus in the Network community in favor of such a standard syntax to make possible its adoption at this time, and it is expected that there is enough breathing room to produce a new mail transmission protocol "properly".
Abstract: Proposed Standard for Message Format / ii PREFACE ARPA's Committee on Computer-Aided Human Communication (CAHCOM) wishes to promulgate an official standard for the format of ARPA Network mail headers which will adequately meet the needs of the various message service subsystems on the Network today. The authors of this RFC constitute the CAHCOM subcommittee charged with the task of developing this new standard; this document presents our current thoughts on the matter and a specific proposal. This document is organized as follows: First, we present a history, of the development of what has become known as the ARPA Network "mail" or "message" service, and the issues which we feel are most pressing-problems for which solutions are lacking today, inhibiting the further development of message subsystems. We then present the specification for the new ARPA Network Message Header standard. This is followed by a References section. Essentially, we propose a revision to Request for Comments (RFC) 561, "Standardizing Network Mail Headers", and RFC 680, "Message Transmission Protocol". This revision removes and compacts portions of the previous syntax and adds several features to network address specification. In particular, we focus on people and not mailboxes as recipients and allow reference to stored address lists. We expect this syntax to provide sufficient capabilities to meet most users' immediate needs and, therefore, give developers enough breathing room to produce a new mail transmission protocol "properly". We believe that there is enough of a consensus in the Network community in favor of such a standard syntax to make possible its adoption at this time. We would like to make clear the status of this proposed standard: The CAHCOM Steering Committee has replaced the Message Service Committee as the ARPANET standards-setting organization in the area of message services. It is expected that the proposal of this CAHCOM subcommittee, when in its final form, will be adopted as an ARPANET standard by CAHCOM. In the interests of making this standard the best possible one, we are distributing this proposal as an RFC. Please send any comments and criticisms to any of the authors of this RFC by 15 June 1977. It is planned that the standard will be officially adopted by 1 September 1977, with hosts expected to accept its syntax by 1 January 1978.

16 citations


Book
01 Jan 1977

15 citations



Journal ArticleDOI
01 Jul 1977
TL;DR: For many users of networks like the ARPANET, an RJE protocol is probably as important in terms of utility as the TELNET (or Virtual Terminal) protocol.
Abstract: For many users of networks like the ARPANET, an RJE protocol is probably as important in terms of utility as the TELNET (or Virtual Terminal) protocol. In fact, the facilities provided by a TELNET and an RJE protocol are probably of most interest to the majority of users of computer networks. For these users, the network provides a fast, cheap telephone surrogate to a variety of computers for RJE and terminal access. The collection (and layers) of protocols that are used to provide these services must be organized to efficiently support a wide variety of applications and user needs. They should not pose an undue software burden on the user.The "official" NETRJE protocol for the ARPANET is built on top of the Telnet and File Transfer Protocols (FTP). A user of NETRJE establishes a Telnet connection using the User NETRJE program on his local host to a Server NETRJE process at the host where he wishes to submit a job (see Figure 1). The user then sends to the Server process appropriate commands to log in, to describe where the job is that is to be submitted, to describe how the job is to be transferred, and to describe what is co be done with output when the job is completed. The Server NETRJE process on the foreign host then uses the FTP to transfer the input file to the foreign host, and then may use FTP again later to send the output back to the user. This protocol is very general and allows a user to submit his input from one host, process it at a second, and send the output to a third.

7 citations


30 Dec 1977

6 citations