RFC 462

Responding to User Needs 💖

okay bestie, this RFC is from way back in the early ARPANET days 🦋 It's RFC 462, titled Responding to User Needs. It was written by Jean Iseli (MITRE) and Dave Crocker (UCLA-NMC), and it's marked as NIC # 14434. The date is February 22, 1973 🌸 The original doesn't list a category or status, and it doesn't say what it obsoletes or updates, so I'm not adding any of that. 🙈

INTRODUCTION ✨

so the ARPANET is going through a glow-up 🌈 It's moving toward a setup where network resources are open to a much bigger crowd of users. That crowd already includes a ton of terminal users who aren't attached to a server site, and they need info about network host services and access characteristics to actually get started. ngl, that's a lot of newcomers who need help 🫶

Up to now, the Resources Notebook has been the main place people went for network-wide info 📓 A separate RFC from the NIC covers the full past and present history, so go read that if you want the whole story 💅 In this one, the authors want to back up the NIC's idea of forming a Working Group focused on User Information and Services 🎀 They also want to bring one specific suggestion to the NIC's proposed meeting.

PROPOSAL 👑

here's the tea: a lot of the problems with missing network info come from having way too many compilation steps 💀 Each step needs a bunch of resources (mostly people!), and every extra step adds delay and new errors. The fix they suggest is to move the gathering of basic info closer to where it actually comes from, and to make that source responsible for both collecting it and keeping it up to date ✨

The "source" is spread all over the Network, so the proposal is to build and implement a distributed, extensible network data-base that holds the info people want. Each server site would make and maintain its own info file locally, at the NIC, or both 🧚 Later on, as a more down-stream step, a way to access those files could be specified and implemented 🦋

People at different sites could use whichever tools feel most comfy and accessible to them. That's giving flexibility 💜

Now the interesting technical part 🤓 It's about making all those different files reachable by an automaton (basically a program, not a person) 🔥 The NIC is already working on smoothing out the interface between NLS and non-NLS files, and the authors think that's a totally reasonable target for this kind of effort ⭐

RFC 462                 Responding to User Needs           February 1973

       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.             9/99 ]