Comments on the Meyer Proposal
RAND's comments on the Meyer proposal and related protocol choices.
Harslen, E. and J. Heafner, "Comments on the Meyer Proposal", RFC 50, DOI 10.17487/RFC0050, April 1970, <https://www.rfc-editor.org/info/rfc50>.
@misc{rfc50,
series = {Request for Comments},
number = 50,
howpublished = {RFC 50},
publisher = {RFC Editor},
doi = {10.17487/RFC0050},
url = {https://www.rfc-editor.org/info/rfc50},
author = {E. Harslen and J. Heafner},
title = {{Comments on the Meyer Proposal}},
pagetotal = 2,
year = 1970,
month = apr,
} RFC text
E. Harslen
J. Heafner
Network Working Group RANL
Request for Comments: 50 4/30/70
Comments on the Meyer Proposal
------------------------------
We find the Meyer proposal (Note #46) to be the most acceptable
to dare, for exactly the reasons that he enumerates; viz., simple,
suffices for most planned uses of the Network, easy to implement,
can be extended. It does not encompass everything that has been
suggested recently, however, we do agree with the items that are
proposed and we feel that the missing features are probably not
worth doing battle over and thus delaying the specification.
We make the following comments on the seven issues rasied in
Note #47.
1) We agree with Steve that dynamic reconnection will later
be required for more sophisticated uses of the Network.
We also agree with the Project MAC people that it
unnecessary initially. A better job can be done of dynamic
reconnection given some Network experience and the specific
needs of its use.
2) INT is easy to implement and serves a useful purpose.
3) We favor including a sub-field for instance tag identifier.
We see the need for both cases; a) where multiple processes
should appear indistinguishable, and b) where a given
user owning multiple processes must distinguish among
them. Those program parts that should not distinguish
among processes should simply ignore the instance tag.
Tom's suggestion to use part of the user number sub-field
merely reduces the combined length of sub-fields from 32
bits to 24 bits; the problem remains.
4) We disagree with both Steve and MAC in that no special
structure should be imposed on the data transmitted. We
prefer the "message data type" mentioned by E. I. Ancona,
Note #42, page 1. An example of its use was cited in
Note #39, page 2, transmit vs broadcast.
With regard to a standard character set, we strongly
support adopting one in the beginning, and in particular
ASCII. We have observed that most sites have previously
suggested ASCII. Is there anyone who objects?
5) Word boundary alignment is more attractive than double
padding.
6) Steve's suggestion of short-term queueing of RFCs is
acceptable as an option.
7) We support the UCC in Note #46 for three principle reasons:
a) In general the user should not know the remote socket
code of the process to whom he wishes to communicate.
b) The additional duplex connection can provide some
superfisory control over process behavior, possibly
in conjunction with the interrupt procedure.
c) Most of the other proposed methods demand queueing.
We think there must be a standard UCC, yet we encourage
parallel experimental UCCs.
We make two additional comments on Note #46 that were not reiterated
in Note #47.
BLK and RSM are more straightforward than previous suggestions and
they do not deny multiplexing over a given link. With regard to
the use of links, we refer to an example given by Bob Kahn where
an intermediate IMP goes down and eats some's RFNM. This
should not necessitate reconnection.
In Note #46, page 6, the statement that the UCC has the ability
to close connections to a dead process is installation dependent.
In our particular case the NCP is notified directly of process
failure due to the particular software interface through which all
processea, including NCP, must communicate.
JFH:hs
[ This RFC was put into machine readable form for entry ]
[ into the online RFC archives by Gary Okada 7/97 ]
ISO Plain Language
On this page
§1Why RAND Supports the Proposal
Harslem and Heafner call the Meyer proposal the most acceptable to date because it is simple, sufficient for most planned network uses, easy to implement and extensible. They agree that it does not include every suggested feature, but do not think the missing features justify delaying the specification.
The authors prefer a simple proposal that can meet most planned needs and be extended later. They do not want to delay a specification to include every proposed feature.
§1Comments on Specific Features
The authors agree that dynamic reconnection may be needed for more advanced uses later, but is unnecessary at first. They support the INT command and an instance-tag subfield so users can distinguish multiple processes when needed. They favor a message data type for transmitted data and support ASCII as a standard character set.
They prefer word-boundary alignment to double padding and accept short-term queueing of requests for comments as an option. They support a standard UCC, while also encouraging parallel experiments, and say the user should not need to know a remote process's socket code.
The authors support several design choices, including ASCII, instance tags and the INT command. They also argue that a user should not need to know a remote process's socket code to contact it.
§1Flow Control and Local Implementation
The authors say BLK and RSM are more straightforward than earlier suggestions and do not prevent multiplexing over a link. They also say that the ability of a UCC to close connections to a dead process depends on the installation.
At RAND, the NCP is notified directly when a process fails because of the software interface through which all processes, including the NCP, communicate.
The authors prefer BLK and RSM for their straightforwardness and compatibility with multiplexing. They note that handling a failed process depends on how each installation's software works.