RFC 50

Comments on the Meyer Proposal 🎀

Okay bestie, this is RFC 50 💅 It's titled "Comments on the Meyer Proposal," from the Network Working Group, written by E. Harslen and J. Heafner of RANL, dated 4/30/70. It's Request for Comments number 50 ✨ The title block doesn't say what it obsoletes or updates, so there's nothing extra to chase down 🦋

The authors are totally backing the Meyer proposal (Note #46) 🫶 They think it's the most acceptable option to dare, for exactly the reasons he lists: it's simple, it covers most of what the Network is planned to do, it's easy to implement, and it can be extended. It doesn't cover everything people have suggested lately, though. They agree with the stuff that is proposed, and they think the missing features aren't worth fighting over and delaying the spec for 😭

Here's how they respond to the seven issues in Note #47 🌈

1. Okay so, Steve is right that dynamic reconnection will be needed later for fancier Network stuff. The Project MAC people are also right that it's not needed at first 🙈 A better version can be built after some real Network experience and once people know what it's actually for.
2. INT is easy to implement and it's useful 🍓
3. They're into adding a sub-field for an instance tag identifier 🧚 There are two situations where that matters: a) when multiple processes should look totally identical, and b) when one user owns multiple processes and needs to tell them apart. Program parts that shouldn't care about the difference can just ignore the instance tag. Tom's idea of borrowing part of the user number sub-field only shrinks the combined sub-fields from 32 bits down to 24 bits. The problem is still there, bestie 💀
4. The authors disagree with both Steve and MAC. They don't want zero special structure on the transmitted data 🙅‍♀️ They prefer the "message data type" that E. I. Ancona mentions in Note #42, page 1. Note #39, page 2 gives an example of using it, transmit vs broadcast.

On the character set question, they strongly back adopting a standard one from the start, specifically ASCII 💜 They've noticed most sites already suggested ASCII. Is anyone objecting? Speak now or forever hold your peace 👑

5. Word boundary alignment is more attractive than double padding 💅
6. Steve's idea of short-term queueing of RFCs is acceptable as an option ⭐
7. They support the UCC in Note #46 for three main reasons, periodt 🔥
   • a) In general, the user shouldn't need to know the remote socket code of the process they want to talk to.
   • b) The extra duplex connection can give some supervisory control over process behavior, maybe together with the interrupt procedure.
   • c) Most of the other proposed methods require queueing.

They think there must be a standard UCC, but they also encourage parallel experimental UCCs 🦋

They also have two extra comments on Note #46 that weren't repeated in Note #47 💖 First, BLK and RSM are more straightforward than earlier suggestions, and they don't rule out multiplexing over a given link. About links, they point to an example from Bob Kahn where an intermediate IMP goes down and eats someone's RFNM. That shouldn't force a reconnection, bestie 😭

Second, on Note #46, page 6, the claim that the UCC can close connections to a dead process depends on the installation. In their setup, the NCP is told directly when a process fails, because every process, NCP included, talks through one particular software interface 🫶

JFH:hs

[ This RFC was put into machine readable form for entry ] [ into the online RFC archives by Gary Okada 7/97 ]