home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 1 / rfc0050.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  4.0 KB  |  113 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                                                   E. Harslen
  8.                                                   J. Heafner
  9. Network Working Group                             RANL
  10. Request for Comments:    50                       4/30/70
  11.  
  12.  
  13.                      Comments on the Meyer Proposal
  14.                      ------------------------------
  15.  
  16. We find the Meyer proposal (Note #46) to be the most acceptable
  17. to dare, for exactly the reasons that he enumerates; viz., simple,
  18. suffices for most planned uses of the Network, easy to implement,
  19. can be extended.  It does not encompass everything that has been
  20. suggested recently, however, we do agree with the items that are
  21. proposed and we feel that the missing features are probably not
  22. worth doing battle over and thus delaying the specification.
  23.  
  24. We make the following comments on the seven issues rasied in
  25. Note #47.
  26.  
  27.    1)  We agree with Steve that dynamic reconnection will later
  28.        be required for more sophisticated uses of the Network.
  29.        We also agree with the Project MAC people that it
  30.        unnecessary initially.  A better job can be done of dynamic
  31.        reconnection given some Network experience and the specific
  32.        needs of its use.
  33.  
  34.    2)  INT is easy to implement and serves a useful purpose.
  35.  
  36.    3)  We favor including a sub-field for instance tag identifier.
  37.        We see the need for both cases; a) where multiple processes
  38.        should appear indistinguishable, and b) where a given
  39.        user owning multiple processes must distinguish among
  40.        them.  Those program parts that should not distinguish
  41.        among processes should simply ignore the instance tag.
  42.        Tom's suggestion to use part of the user number sub-field
  43.        merely reduces the combined length of sub-fields from 32
  44.        bits to 24 bits; the problem remains.
  45.  
  46.    4)  We disagree with both Steve and MAC in that no special
  47.        structure should be imposed on the data transmitted.  We
  48.        prefer the "message data type" mentioned by E. I. Ancona,
  49.        Note #42, page 1.  An example of its use was cited in
  50.        Note #39, page 2, transmit vs broadcast.
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58.                                                                 [Page 1]
  59.  
  60.        With regard to a standard character set, we strongly
  61.        support adopting one in the beginning, and in particular
  62.        ASCII.  We have observed that most sites have previously
  63.        suggested ASCII.  Is there anyone who objects?
  64.  
  65.    5)  Word boundary alignment is more attractive than double
  66.        padding.
  67.  
  68.    6)  Steve's suggestion of short-term queueing of RFCs is
  69.        acceptable as an option.
  70.  
  71.    7)  We support the UCC in Note #46 for three principle reasons:
  72.  
  73.        a)  In general the user should not know the remote socket
  74.            code of the process to whom he wishes to communicate.
  75.  
  76.        b)  The additional duplex connection can provide some
  77.            superfisory control over process behavior, possibly
  78.            in conjunction with the interrupt procedure.
  79.  
  80.        c)  Most of the other proposed methods demand queueing.
  81.  
  82.       We think there must be a standard UCC, yet we encourage
  83.       parallel experimental UCCs.
  84.  
  85. We make two additional comments on Note #46 that were not reiterated
  86. in Note #47.
  87.  
  88. BLK and RSM are more straightforward than previous suggestions and
  89. they do not deny multiplexing over a given link.  With regard to
  90. the use of links, we refer to an example given by Bob Kahn where
  91. an intermediate IMP goes down and eats some's RFNM.  This
  92. should not necessitate reconnection.
  93.  
  94. In Note #46, page 6, the statement that the UCC has the ability
  95. to close connections to a dead process is installation dependent.
  96. In our particular case the NCP is notified directly of process
  97. failure due to the particular software interface through which all
  98. processea, including NCP, must communicate.
  99.  
  100.  
  101. JFH:hs
  102.  
  103.        [ This RFC was put into machine readable form for entry ]
  104.           [ into the online RFC archives by Gary Okada 7/97 ]
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.                                                                 [Page 2]
  112.  
  113.