See my responses, below.  They are just opinions, as a 'ruling' kind of defeats the purpose of being friendly which is what finger was supposed to be about.  At least, that's what we thought at Columbia.

So I don't mind putting this aside for now.  It is a hobby after all and I will be busy getting the latest Kermit-20 release up on the Internet, anyway.

---

On 1/10/26 9:50 PM, Terri Kennedy wrote:

  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 reason.

The difference lays in considering what is application data and what is meta-data.  A server is under no obligation to do anything with the meta-data, which is to be found in the connection attributes.  So the optional DATA attribute is only used to condition buffering for the client.  The USER attribute is to log the remote user making the query, not the local user.  The user information being requested is always passed in on the connection as application data.  So user STREAM would show up to the client's input buffer as "STREAM^M" (or ^J).

A potential concern with a /STREAM switch is that the user could then issue it and break an RSX connection.  Unless debugging is on, the connection attributes will not be seen and cannot be invoked from the command line.

  2) I suggest allowing explicit area.node:: syntax.

I think that could be made an option, but what is it buying you?  The whole point of the symbolic host name is to not have to remember that stuff.

Tops-20, in particular, is pretty fascist about not allowing a user issued numeric DECnet specification.  The mail system will parse numerics, but this is only to allow visual compatibility with IP syntax.  It must use a PANDA modification to turn the number into a DECnet host name which is the only thing the monitor will allow.

But you really don't get anything out of it.  You still can't identify a node that hasn't be defined in the HECnet data base and recently loaded from MIM:: (which I do on a regular basis).  I think I could change the parser to allow area.node, but like VMS, the finger client is an accumulation of decades of changes.  And stuff for PUP: Ethernet and MIT CHAOS-NET.  Like you, I am tempted to give it the old heave ho and start from scratch like I've done with the FTP server and the node management utility (SETND2)  

  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 editing 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 options the Finger server supports. We may decide that options 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.

We can all push back and have a think.  That's really fine.  Again, it's a hobby, so no rush.  I also stumbled over some bugs while doing all this, but that's not any news...

---

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.

---

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@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se

_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se

_______________________________________________
HECnet mailing list -- hecnet@lists.dfupdate.se
To unsubscribe send an email to hecnet-leave@lists.dfupdate.se