11 Jan
2026
11 Jan
'26
3:04 a.m.
We've gotten pretty far off track here, dealing with combinations
of DECnet and Internet addressing in the same command.
I propose the following for DECnet Finger (client and server)
implementations:
1) A Finger client opens a DECnet connection to object 117 on the
remote node. If the DECnet nodename is unknown, the Finger client
can optionally use a (designated by implmentation-specific method)
"smart" DECnet node which may have a more complete node database,
etc. In the case of failure, report as much useful failure infor-
mation as possible if the connection cannot be established.
2) The Finger client sends a series of characters. These charac-
ters can be:
a) A username.
b) Characters to be matched against personal names.
c) One or more strings beginning with "/" which may
or may not have meaning to the Finger server on
the remote node.
d) An empty string.
3) The Finger client then sends a CR (or whatever the
terminator is, I can't be bothered to drop everything
and look right now).
4) The Finger server on the remote node evaluates the line
received and takes action as follows:
a) Reports information about that username. If it does
not match any username, fall through to b.
b) If the Finger server allows partial name lookups like
this, return a list of username / personal name lines.
It may enforce a limit on the minimum number of char-
acters needed to return the list. If a list is not
returned, report a "No such user" message in an imple-
mentation-specific manner.
c) If the string beginning with "/" is known to the Finger
server as a valid option, treat it accordingly. If not,
silently ignore that string and move onto any additional
strings. It is strongly suggested that server implemen-
tations support a /HELP string to inform the client's
user what options are available.
d) Report information on the system itself, which may or
may not include information on the host, lists of log-
ged-in users, etc. per the Finger server's configur-
ation.
5) The Finger server closes the connection.
Things like nodename (either @, :: or both) are handled in an
implementation-specific manner by the Finger server. It can de-
cide to return an error message, forward the request to another
host for processing (in which case all of the contents of the
line sent in #2 above should be passed along verbatim), etc.
Bear in mind I'm going off of 35-year-old-plus memories of how
this is supposed to work.
Discussion?