1 files changed, 283 insertions, 0 deletions
diff --git a/doc/rfc/rfc49.txt b/doc/rfc/rfc49.txt
new file mode 100644
index 0000000..c64b09a
--- /dev/null
+++ b/doc/rfc/rfc49.txt
@@ -0,0 +1,283 @@
+
+
+
+
+
+
+NWG/RFC 49      Conversations with Steve Crocker (UCLA)
+
+                          Edwin W. Meyer, Jr.
+                            MIT Project MAC
+                             April 25, 1970
+
+
+   (Both my personal opinions and those that I believe represent a
+   consensus of the Network Working Group at Project MAC are presented
+   here.  The pronouns "I" and "we" are used to distinguish between
+   these.)
+
+
+On April 21 and 23 Thomas P. Skinner and I had telephone conversations
+with Steve Crocker at UCLA relating to the network protocol,
+specifically regarding our proposal in NWG/RFC 46.  The following items
+were discussed.  (I hope that Steve will pardon me if I happen to
+misparaphrase him.)
+
+1) Steve stated that he felt that a need for dynamic reconnection would
+later be recognized by the network participants.  However, because of a
+lack of consensus, it will not be included in the initial
+implementation.  (We at Project MAC favor this approach of not including
+it initially.)
+
+
+2) Steve supported the implementation of the INT network command
+described in NWG/RFC 46.
+
+This command allows a process that has agreed to accept interrupts over
+a socket connection to be reliably interrupted by the process at the
+other end.  The interrupt causes a process to abey its current execution
+and execute a procedure that it has specified as the INT handler.  (The
+NCP does not specify the INT handler.  That is the function of higher
+level protocols.)
+
+The INT command is designed specifically for use by a third level User
+Control and Communication (UCC) protocol to implement a "quit" signal.
+Under such a protocol, both the requestor and the created process agree
+that an INT related to a specific socket connection and transmitted over
+the NCP control link to the created process is the standard "quit"
+signal.  The created process provides an INT handler that implements
+this "quit" function.  (This does not preclude a different
+interpretation of INT by other third level protocols.)
+
+Although many systems implement the "quit" as a control character in the
+Teletype input stream, systems such as CTSS, Multics, and others
+implement it as a 200 ms spacing on the line.  We at MAC think that the
+
+
+
+                                                                [Page 1]
+
+NWG/RFC 49      Conversations with Steve Crocker (UCLA)
+
+
+first method is an undesirable implementation within the network (while
+the second is impossible).  I put forth several reasons why (and I think
+Steve agreed).
+
+(a) The link over which the quit character is to be transmitted may be
+blocked.
+
+(b) While the interrupt is most effectively implemented within the NCP,
+it is undesirable for the NCP to place any particular structure on the
+data being transmitted.  (See discussion below.)  This would be required
+if the NCP were to scan a data stream for a control character.
+
+(c) Scanning the input stream greatly reduces NCP efficiency in a
+subsystem where speed is critical to effective operation.
+
+Steve pointed out that the implementation of INT as a "quit" should not
+necessarily preclude a HOST's interpretation of a control character in
+the input stream from also acting as a "quit".
+
+
+3) Steve is opposed both to including the instance tag in the socket
+identifier and reserving a null field in the identifier for future
+definition.  He cited several reasons:
+
+(a) Multiple processes of a single user should be indistinguishable to a
+foreign process.  (I agree with this in certain cases when processes are
+co-ordinated in joint action.  But what about the case where two
+processes of the same user both want to independently use the network?)
+
+(b) A process wishing to connect to one of a foreign user's processes
+does not know the instance tag of the particular process that he wants,
+and he can't easily find out.
+
+(c) If an instance tag should later prove desirable it could be added
+with some difficulty.  (I claim that something as fundamental as the
+length of a socket identifier will prove very resistant to change.)
+
+Tom stated that perhaps the low order three bits of the user code could
+be reserved for later interpretation as an instance tag.  He doesn't
+think that a separate field is of great importance.
+
+Steve's arguments seem to have merit.  Perhaps Tom's suggestion is the
+way to go.  I am currently undecided on this matter.
+
+
+4) We all (Steve and MAC) seem to agree that at the NCP level there
+should be no special structure imposed on the data transmitted.  To an
+NCP all data to be transmitted are bit strings of arbitrary length.  One
+
+
+
+                                                                [Page 2]
+
+NWG/RFC 49      Conversations with Steve Crocker (UCLA)
+
+
+happy result is that the difficult question of character sets does not
+have to be resolved at this protocol level.  To include a character set
+specification at the NCP level would delay agreement on the protocol and
+make this character set more resistant to change.  (If there is to be a
+standard character set, we prefer ASCII.  After all, it is the prefered
+standard of our sponsoring organization.)
+
+We also agree with Steve that there should be no optional echoing of
+messages at the NCP protocol level.  (This is also the position of the
+SDC people in RFC 44.)
+
+
+5) Shoshani, Long, and Landsberg also state (RFC 33) that they prefer to
+align messages to end on a word boundary as opposed to double padding.
+Steve agrees with us in not liking double padding.
+
+
+6) In our proposal (RFC 46) we suggest that RFCs be queued only for open
+sockets, that RFCs to inactive or connected sockets are to be
+automatically rejected via the CLS command.  Steve proposes that RFCs to
+these sockets be briefly queued.  If the socket remains in an
+unacceptable state for a specific interval after the RFC comes in, it is
+rejected.  This scheme allows certain types of network command
+interaction involving critical races to be implementable.  Such a scheme
+of limited queueing does not seem unreasonable to me.
+
+
+7) Steve, Tom, and I discussed strategies for a User Control and
+Communication (UCC) Protocol.  Steve said that he disliked our UCC
+strategy (RFC 46) because it requires maintaining two full-duplex
+connections to the requestor process and switching between them.
+
+Steve put forth an alternate proposal: a process wishing to create a
+user process at a foreign HOST issues RFCs to sockets 0 and 1 belonging
+to the user whose process he wishes to create.  If these sockets are
+inactive, the NCP automatically directs these requests to the foreign
+HOST's logger process.  The logger accepts connection and performs the
+login ritual.  If successful, the logger creates a user process and lets
+go of the usurped sockets so that the created process may use them to
+communicate with the requestor process.  (I note that this does not use
+reconnection at a network level, since the logger uses sockets belonging
+to the ultimate user.  However, it does involve internal reconnection.)
+
+Tom and I objected to this because it introduces UCC protocol into the
+NCP level.  (The NCP must direct all RFCs to inactive sockets 0 and 1 to
+a logger process.)  I made a quick suggestion that perhaps our two
+proposals could be combined such that the requestor issues a
+"signalling" RFC to a "signal" socket of the UCC process.  The UCC
+
+
+
+                                                                [Page 3]
+
+NWG/RFC 49      Conversations with Steve Crocker (UCLA)
+
+
+rejects the RFC but remembers who is calling.  It then tries to connect
+two sockets of the process to be created to the requestor's sockets, and
+conducts the login ritual through these.  Steve liked this and suggested
+that I write it up.
+
+Following the conversation, I thought of several disadvantages to this
+UCC strategy:
+
+(a) If the control sockets at a created process are limited to 0 and 1,
+there is the possibility that a rightful user may not be able to
+communicate with a foreign UCC because the UCC already is using those
+sockets to communicate with an imposter.  The logger will discover this
+and turn off the imposter, but this is an aggravating security breach.
+A malicious process could issue simultaneous multiple requests to tie up
+the sockets and prevent access to a rightful user.  A better solution is
+to allow any socket pair of the potential user process to act as the
+control path.  This permits the UCC to conduct simultaneous
+interrogations of competing requestors.
+
+(b) A disadvantage of both Crocker's and the combined UCC is that the
+user to be logged in is specified by supplying a socket belonging to a
+particular user.  The logger must now make the additional check that the
+user it is logging in actually belongs to the socket pair it is talking
+over.  This seems the reverse of the prefered process: to identify a
+user and then determine the user code for his socket identifiers.
+
+(c) The user may not know the socket user code of the user he wishes to
+log in at the foreign HOST.  (After all, there is no basic reason why
+the requestor and created processes should have the same user code so
+long as the requestor satisfies the foreign logger.)
+
+(d) In the combined strategy, there is no way for the requestor to
+specify which socket user code it wants.  The only assumption that the
+UCC can make is that the requestor process wishes to log in a process
+having the same socket user code as itself.  (This may not seem very
+important, but I envision a scheme in which a local process exists to
+allow consoles attached to the local HOST to login at a foreign HOST
+without being logged in locally.)
+
+(e) The idea of allowing a process to masquerade within the network as
+another process (even with the best of intentions) by using its socket
+user code introduces a potentially dangerous security breach.  I think
+that it should be a basic protocol law that NO PROCESS WHATSOEVER may
+request or accept connections or transmit or receive data over a socket
+having a user code not its own.  This does not apply to an NCP process
+which has responsibility for such transmission, nor does it prevent a
+priviliged process from closing or rejecting connections between a
+foreign process and another local process.
+
+
+
+                                                                [Page 4]
+
+NWG/RFC 49      Conversations with Steve Crocker (UCLA)
+
+
+I still think that the UCC proposal we advanced in RFC 46 is a good
+workable scheme.  It does not require socket reconnection (either
+expressly throughout the network or implicitly within an NCP), nor do
+any of the objections raised above apply.  The only particular
+disadvantage I see is that it requires the requestor process to maintain
+and switch between two full-duplex connections.  I don't see this as a
+serious hindrance.  I would like the comments of the network
+participants on this point in particular.
+
+Fortunately the UCC is a third level protocol.  The second level NCP can
+be specified before we reach final agreement on a UCC, provided that the
+NCP allows implementation of a workable UCC.
+
+Steve expressed the thought that there need not be an initial standard
+UCC, that there might be several UCCs.  We at MAC disagree.  If we are
+all to talk to each other, and not between limited subsets of HOSTs
+within the network, there must be an initial standard UCC which
+EVERYBODY implements.  (Steve is of course correct that there can be
+other experimental UCCs also implemented.)
+
+It is theoretically possible for each HOST to provide multiple sets of
+software to allow a requestor process to communicate with the loggers at
+HOSTs implementing different UCCs.  I don't think that it will work this
+way in practice.  Each HOST will implement the UCC protocol that is most
+agreeable to it, and will provide one set of software so that a
+requestor process can communicate only with those HOSTs which implement
+similar UCCs.
+
+I don't think that there is much enthusiasm at Project MAC for
+implementing a non-standard UCC just so we can talk to ourselves.  We
+want to implement a single UCC supported at all installations, so that
+we can log in to all HOSTs using this protocol, and that users at all
+foreign HOSTs can log in to us.
+
+       [ This RFC was put into machine readable form for entry ]
+       [ into the online RFC archives by Altair Petrofsky 7/97 ]
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                                                                [Page 5]
+