11 Jan
2026
11 Jan
'26
3:50 a.m.
On 2026-01-10 21:09, Thomas DeBellis wrote:
You are restating part of what is in the DECnet Finger
specification
that Johnny and I put together.
Have a look at it and let me know what you think. This is what the
RSX11 and Tops-20 implementations code against.
It can be found on VENTI2::DECNET-FINGER-SPECIFICATION.TXT for
anonymous NFT.
That should be the basis for the discussion as I will be happy to keep
it up to date, but I believe it addresses most of what you refer to,
below.
A few observations:
1) How is a request for streaming output on an otherwise-
empty request differentiated from a request for info
on a user named STREAM? I suggest /STREAM for this rea-
son.
2) I suggest allowing explicit area.node:: syntax.
3) "Application Level Routing" - neither RSTS/E nor VMS
DECnet allow HOST1::HOST2::USER syntax. There is also
the issue of passing the complete command line or edit-
ing it. If we are HOST1::, do we remove HOST1:: from
the command line before passing it along? I think so,
but this also complicates interoperability as discussed
in the following paragraph:
This also gets into DECnet / TCP/IP interoperability,
which I think should be deferred to a second revision
to the spec, or an addendum to it.
4) I'd like to see my bit on optional "/foo" command line
options added, including silently ignoring unknown ones,
except for /HELP which should return a list of the op-
tions the Finger server supports. We may decide that op-
tions must be at the end of the line after any username,
nodename, etc. All received arguments must be passed
along intact to any subsequent host when doing multi-
hop Finger processing, either via a locally-configured
smart host or application level routing.
That's all I see for now, but I have spent way too much time
on this already today, my housemate is upset with me, and I
still have tons of other stuff to do and likely won't get to
sleep until 5 AM again.
I'll be glad to discuss the items I raised above, but I am
going to need to limit the back-and-forth to two 60-minute
periods per day, or I won't get anything else done.
On 1/10/26 9:04 PM, Terri Kennedy wrote:
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?
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se