[HECnet] Re: DECnet Finger Specification (Possible re-post) and Tops-20 Finger Setup Documentation (New)

On 2026-01-11 09:36, Johnny Billquist wrote: Welcome to sitting on a standards body*. I did some of that in my DECUS days. * It's a lot easier if the body is dead, because 1) if it's dead, you're less likely to roll off and 2) if it's dead, it is also likely that nobody cares because the body is dead al- ready. 8-} Sounds like a plan. Agreed. I would just add that optional arguments (which the RFC hand- waves as "Query Tokens" and only mentions in passing (but does not de- scribe the function of) the /W token, so there are other possible arg- uments, which a given server implementation may or may not implement. Can we agree that one or more optional "tokens" (/foo) MAY appear in the query, that implementations SHOULD ignore tokens they do not under- stand/implement, SHOULD implement a /HELP token, and MUST pass the com- plete query (after removing their own name), including any tokens, in- cluding /HELP to the next host (if any). To clarify, if a system that receives a Finger query is just "passing it along", it should not re- spond to /HELP itself, but just pass it along as well. Agreed, subject to my comments on RFC 1288 above. I'd also add that "An implementation MAY decide to forward the re- quest to another DECnet node if it does not have an node definition for the host being queried. Yup. At least since the UK moved off Grey Book (where the CS system at Foo University was uk.ac.foou.cs instead of cs.foou.ac.uk - we used to joke that "they drive on the wrong side of the Internet, too". 8-) Gatewaying is implementation-specific and MAY be provided. If it is provided, it SHOULD follow the appropriate rules for left-to-right and right-to-left parsing as described above. I'd never heard of streaming until this discussion came around the first time (2024). I've always written lines as records in my imple- mentation. This is entirely a matter of how the user command line is parsed by the Finger client. It SHOULD be free to parse things however it likes. but MUST only send a properly-formed query to a Finger server. Back in the day, we had DECnet, BITNET, and TCP/IP (and some other protocols). So you could say "finger user(a)node.decnet" (and use "fin- ger user@node::" as a shortcut). Likewise for "finger user(a)node.bitnet" - these were all treated as ".decnet" and ".bitnet" pseudo-TLDs. This is also what PMDF (see prior references to Ned Freed) does. Unless there were cases where DECnet host FOO::. BITNET host FOO, and TCP/IP host foo.example.com differed, you could just say "finger user@host" and Finger would figure out the appropriate transport by querying the host tables / DNS in that order - DECnet, BITNET, and TCP/IP. This made it easy for users (who often didn't know what sort of network connection was used to talk to their buddy Fred on host foobar). "finger fred@foobar" would just Do The Right Thing. But note that all this optional work MUST be done entirely on the user's local finger client, and what gets emitted as a Finger comm- and line MUST be appropriate for the next hop's Finger server. It SHOULD reject a message it considers ill-formed with an appropriate error message. To summarize, in addition to supporting canonical DNS (user@foo. example.com) and DECnet (FOO::USER) address forms, a client MAY support any other syntax, including (perhaps) user- or system-wide mappings (for example, FOO::ERNIE -> FOO::ERNEST, or even joe@ oldjob.example.com -> Joseph.Lastname(a)otherjob.blah.org). This all happens in the client, and as a server implementer you don't need to worry about it at all. All I'm asking for on the server side is: 1) If acting as a smarthost, remove your node from the command line (if it wasn't already) and pass it along to the next host. *** Otherwise *** 2) Support whatever restrictions the server wants as to whether lists of logged-in users can be provided, whether queries must match a specific username or can provide a list of users, decide to show .plan (or site equivalent) data, etc. 3) At the implementations choice, handle unknown qualifiers via one of these methods (from most preferred to least preferred): a) Report "Unknown command qualifier /FOO" for each unknown qualifier, one per line, but return the requested informa- tion (see the example below). b) As a) above, except exit without returning any user infor- mation after reporting errors as in a) above. c) Silently ignore unknown qualifiers and return output for the requested information. 4) Implement the qualifier /HELP which will provide (at a mini- mum) the list of supported qualifiers. Example of 3a: $ finger terry@spc11d/wumpus/fuzzy/noxact [SPC11D.DECnet] ?FINGER - Unrecognized command qualifier '/WUMPUS'. ?FINGER - Unrecognized command qualifier '/FUZZY'. ?FINGER - Unrecognized command qualifier '/NOXACT'. SPC11D RSTS/E, Monday, 11-Jan-1926 21:25 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console VT100 Default directory: _SY0:[20,254] Logged in since: Monday, 4-Jan-1926 01:11 Mail: (no new mail) Plan: Half of "The Bob & Terry Show", 1993-present The user's Finger client is stripping off the first host (DECnet or DNS, let's forget about BITNET) and so your: finger spc11d::terry@mim.softjar.se gets turned into "open a connection to the finger server on mim.soft- jar.se and send it the query 'spc11d::terry'". Whether or not it de- cides to forward that request is an implementation and/or site-specif- ic determination. As an example, while debugging this with the folks at FNAL, it was important that their public-facing servers not allow unrestricted DECnet Fingering of the various internal hosts, some of which held classified data. Are you actually seeing blank lines in the output, or is this just the way this message was formatted? The implementation stuff as I've described it above is how RSTS/E Finger currently operates (modulo a few bugs, which I'll fix) and we can have a DECnet "bake-off" at some point in the future, once we've settled on a spec. The point I tried (and failed miserably) to make in earlier emails is that whatever form of address the user gives the finger client on their system is immaterial (beyond being something that generally makes sense to users on that system) but what actually gets send as a command line to a remote Finger server has to match the canonical format, as described in the DECnet/E finger draft and (hopefully) as amended by me above. I'm going to need to implement logging (as defined in the draft spec). More interesting is what I get back when I try fingering MIM:: from SPCPI2:: (running the same finger as SPC11D): SPCPI2::$ finger mim:: [MIM.DECnet] Unknown option: /IAM="TERRY~SPCPI2" User FINGER not found! SPCPI2::$ finger mim::billquist [MIM.DECnet] User BILLQUIST/IAM="TERRY~SPCPI2" not found! The "/IAM" business I mentioned previously and that needs to go away (never send, ignore on receipt). But I'm not sure why the first request is being treated as a request for user "FINGER", unless my RSTS/E client is mistakenly sending a request that had the string "FINGER" in it. Johnny, does your server log these requests? "finger spc11d::terry" works here from spcpi2: SPCPI2::$ finger spc11d::terry [SPC11D.DECnet] SPC11D RSTS/E, Monday, 11-Jan-1926 21:52 Job Username PPN Progrm Term Login CPU ST Location TTType 7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console VT100 Default directory: _SY0:[20,254] Logged in since: Monday, 4-Jan-1926 01:11 Mail: (no new mail) Plan: Half of "The Bob & Terry Show", 1993-present I'm wondering if we're using different end-of-line characters or something. Yup. It was wilder when we could add BITNET transport and MS-DOS Finger servers to the equation. Yes, my MS-DOS Finger server did do next-hop. At one time I also had Netware as a transport. All long dead and gone protocols. If you were "on" MIM and not just passing through the finger request, you'd just say "finger spc11d::terry". If you said "finger terry(a)mim.soft- jar.se" you'd get an error unless you actually had a user named terry. Not sure I follow. But then again, cross-network routing is a more complicated issue. Let's get the basic DECnet interoperability done first. Just about all of that is in the client, in what it decides to do with the user's command line (but which it must convert into the stan- dard format). "Your client's broken" reports should only pertain to the client emitting incorrect standard-format commands (which, in the case of RSTS/E Finger, is doing the unwanted /IAM business). "Your server's broken" reports can cover a wider range of subjects. Ideally, I'd like to see other DECnet servers behave about the same as the RSTS/E one (aside from any breakage I need to fix, like why Johnny's Finger client can't request info on a specific username and always gets the "who is logged in" display). The enhancements I sug- gested above in #1-4 for servers are a request for things which are mostly optional in the existing implementations. The only MUST from the above list is #4, implementing /HELP. If Ned Freed was still alive we could sic him on them, but sadly not. Google has a zillion screwball requirements for mail, many of which are undocumented. And they don't do anything with spam reports (I think that abuse@ goes directly into the bitbucket).