RFC 50 (rfc50) - Page 2 of 2

Comments on the Meyer Proposal

       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 ]