11 Jan
2026
11 Jan
'26
9:53 a.m.
On 2026-01-10 23:11, Thomas DeBellis wrote:
Ok, so you're talking about putting "STREAM" in the "magic 16
bytes"
or whatever it is that can be set by an application using DECnet? I had
thought you meant it should be on the command line.
True, but that requires the host database to be populated and for
sites to keep it up-to-date.
Seems reasonable. Dual-stack (or more-stack) implementations just have
to
recognize their own name in whatever it might be. Like the previous
item,
not mandatory, not prohibited.
IPv6 and its use of :: is also going to be a can of worms. I'm hoping
to
avoid IPv6 until I'm beyond caring. 8-}
One of us had our terminology confused. I blame X11 semantics. Or some
antics.
To me, "finger client" is the thing that the user is using to ask a
remote
"finger server" about user(s) on it.
Since we have multiple implementations, we don't know what options a
remote
finger server might implement (or not).
This is similar to both FTP and SMTP, where the client can ask the
server
what commands it supports. Grated, those are back-and-forth interactive
dia-
logs, compare to the "write a line and get a response back" operation of
Finger. But it is still good to know the capabilities of the remote
host.
Here's a simple example, from VMS to
RSTS/E:
SPCVXA::$ finger @spc11d
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:22, 9 Jobs, 63
Max.
Uptime 7 02:47:29, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
9 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
SPCVXA::$ finger @spc11d/nocputime
[SPC11D.DECnet]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:22, 8 Jobs, 63
Max.
Uptime 7 02:47:38, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login ST Location TTType
1 SYSTEM 1,2 ERRCPY Det SR - Detached -
2 SYSTEM 1,2 MAILQ Det SR - Detached -
3 SYSTEM 1,2 OMS Det SL - Detached -
4 SYSTEM 1,2 PBS... Det SL - Detached -
5 SYSTEM 1,2 EVTLOG Det SL - Detached -
6 SYSTEM 1,2 MESMAN Det SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 ^C PiDP-11 Console VT100
8 SYSTEM 1,2 FINSRV Det RN - Detached -
SPCVXA::$ finger @spc11d/wumpus
[SPC11D.DECnet]
?FINGER - Unrecognized command qualifier '/WUMPUS'.
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 03:23, 8 Jobs, 63
Max.
Uptime 7 02:48:04, since Monday, 4-Jan-1926 00:35
05-Sep-24 - Your message could be here! Edit FINGER$:FINGER.MSG to
change it.
Job Username PPN Progrm Term Login CPU ST Location
TTType
1 SYSTEM 1,2 ERRCPY Det 00:00 SR - Detached -
2 SYSTEM 1,2 MAILQ Det 00:01 SR - Detached -
3 SYSTEM 1,2 OMS Det 00:05 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:12 SL - Detached -
5 SYSTEM 1,2 EVTLOG Det 00:00 SL - Detached -
6 SYSTEM 1,2 MESMAN Det 00:00 SL - Detached -
7 TERRY 20,254 DCL KB0: 01:10 21:38 ^C PiDP-11 Console
VT100
8 SYSTEM 1,2 FINSRV Det 00:00 RN - Detached -
In the case of RSTS/E Finger, it warns you about unknown qualifiers
but
then proceeds to give you what it thought you asked for. In my draft
spec
it was "return an error and close the connection".
Again, returning a useful error and continuing vs. returning a useful
error
and closing the connection is an implementation-specific issue. However,
if
poor-man's routing is being used, other than removing its own host info
from
the command line, it should pass the rest of the command line (including
qualifiers it doesn't know about) to the next host.
My implementations don't care about positions of qualifiers -
"finger/wumpus @spc11d" and "finger @spc11d/wumpus" are treated
the same. This is the "be liberal in what you accept, be con-
servative in what you send" philosophy. But the draft could state
that qualifiers have to appear to the right of any other items on
the line sent to the Finger server. I can certainly rewrite my
clients to always put them at the end, but still accept them if
they appear elsewhere.
BTW, VMS finger interoperates with Unix Finger, and will also
act as a smarthost for DECnet-only clients like RSTS/E. Unix has
its own set of configuration options. Here's 2BSD with its default
rule of "Refuse to list all users":
SPCVXA::$ finger @spc11e.glaver.org
[SPC11E.GLAVER.ORG]
must provide username
SPCVXA::$ finger terry(a)spc11e.glaver.org
[SPC11E.GLAVER.ORG]
Login: terry Name: Terri Kennedy
Directory: /home/terry Shell: /bin/tcsh
On since Thu Jan 8 23:48 on console, idle 1 day 3:17
Last login Thu Jan 8 23:51 on ttyp0 from gate.glaver.org
No Plan.
And I think that should be an implementation option as well, whether a
host will list all users or only by username.
Right now, while both VMS and RSTS/E Finger support /HELP, they go and
get
the help file info from another process that is doing "help finger" as a
DCL
command, and it is quite slow.
That is something my implementations need to fix, as at the time they
were
written, 56Kbit or slower links were common. I'll probably change
"/help" to
just send basic help information, and at the end either say "use
/help=foo to
get additional information about the /foo option", or just say "use
/fullhelp
to get the whole help data".
It has certainly exposed some interoperability issues in my code. I
don't
know why both RSX and -20 are getting that spew from spcvxa:: or
spcvxb::
listing all of the qualifiers when they just sent a blank line. I
suspect
the VMS implementation may not treat all 3 line endings in your draft as
valid line endings.
I definitely want to fix these issues in my code (starting with RSTS/E
Finger as it's better-behaved already and it's all code I wrote).
However, I'd like to see what agreement we can come to on the use of
qualifiers, leaving certain things up to the implementation, and
whatever
other points I raised above (3:35 AM now, so time for bed). Feel free to
cogitate and let me know what you think, and I'll look at it sometime
tomorrow, likely at night.
BTW, here's the configuration file for my current RSTS/E Finger. It is
parsed by the Finger server. On VMS Finger, the parts of this that are
supported are handled by conditional compilation (ick!). The only
Byzantine
part of this are the 1/2/3 lines which contain a coded value for the de-
faults when neither /foo nor /nofoo is supplied by a Finger client.
These
are documented in the .doc file (will likely be a PDF for new releases)
and I'll attach that part below the sample config file.
$ type finger.cnf
! Configuration file for finger. See additional comments at end.
H SPC11D PDP-11/70
O SPC Memorial PDP-11/70
R SPCVAX
M @FINGER$:FINGER.MSG
W 0
N 0
L 0
1 143
2 3575
3 15
Q
!
! Sample finger configuration file. You *must* follow this format or you
! will get errors. The first column must be either an exclamation point
! (!) or one of the characters H, O, R, M, W, N, L, 1, 2 or 3, in any
or-
! der. The file scan is terminated when a line starting with Q is found.
!
! The usage of the letters is as follows:
!
! H - The string beginning in column 3 is the local host name, with any
! other comments (such as CPU type) desired.
! O - The name of the local organization (your company or department
name).
! R - The node name of a host to service requests for nodes not known
lo-
! cally. Note: This is used for DECnet lookup, and must be in a
format
! considered valid by DECnet. It is rejected if it is either "0" or
the
! local host name, but subtle errors can occur by having two nodes
each
! configured to be the router for the other.
! M - Message of the day, either a text string or a filename prefaced
with
! an @-sign to type the contents of that file.
! W - The minimum number of non-wildcard characters allowed for lookups.
A
! value of 0 will allow any match, 1 needs at least one non-wild
char-
! acter, etc.
! N - Flag for whether nodename is considered in the mail From: match.
0=no,
! 1=yes.
! L - Flag whether finger should disable reporting mail information.
0=report
! unread count and subjects from sender, 1=report unread count,
disable
! subjects, 2=disable both count and subjects. Why is this flag
called
! 'L'? If you know the way LJK feels about mail read receipts, you'd
know.
! 1 - The default command qualifiers, part 1 of 3
! 2 - The default command qualifiers, part 2 of 3
! 3 - The default command qualifiers, part 3 of 3
! Q - End of configuration file (quit)
----
1 - Value for command defaults, part 1. This keyword is the sum of
the
following values:
/interactive 1
/batch 2
/network 4
/system 8
/version 32
/message 128
Example: 1 143
2 - Value for command defaults, part 2. This keyword is the sum of
the
following values:
/job 1
/username 2
/ppn 4
/personalname 8
/imagename 16
/terminal 32
/logintime 64
/cputime 128
/state 256
/size 512
/location 1024
/tttype 2048
/priority 4096
/runtimesystem 8192
Example: 2 3575
3 - Value for command defaults, part 3. This keyword is the sum of
the
following values:
/bypass 1
/plan 2
/mail 4
/area 8
Example: 3 15
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.
I agree. I really want to interoperate happily with as much as I can,
although I think Bitnet is a lost cause at this time. 8-}
It's funny that VMS Finger took the long away around from Columbia to
me,
while a bunch of other projects (like C-Kermit) came directly. Columbia
did "flim-flam" me once, when they asked if I would "provide a
UUCP-over-IP
connection to another site in Colombia".
I didn't read that carefully enough and thought they were asking for a
duplicate UUCP feed (I was running a top-10 Usenet server at the time)
for
themselves, not for Colombia the country. I'd said I would do it, so I
did.
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.
It's just been a really bad day, with a bunch of software projects all
clamoring for my time as well as the other stuff that is Retired Life
that
saps all your free time (and then some).
-------------------------
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.
If it's in the metadata, then it isn't an issue. My misunderstanding.
Although in the case you're describing, sending /STREAM to an RSX sys-
tem from a -20 would just be ignored. Or are you describing what could
happen if a user on RSX said "finger node::somebody /stream" to a -20,
in which case the situation you describe might happen. Although if the
-20 tried to stream to RSX, wouldn't RSX abort the connection?
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)
Both VMS and RSTS/E allow it:
VMS:
SPCVXA::$ dir 41.503"system topsecret"::
Directory 41.503"system password"::SYS$SYSROOT:[SYSMGR]
ACCOUNTNG.DAT;5 CLUE$HISTORY.DATA;1 CLUE$LAST_SPCVXB.LIS;1
CXX_REPOSITORY.DIR;1 EVL.LOG;114
FMG_LOCAL_PARAM_LIBRARY.KNL;1 FTP_SERVER.LOG;5
LAN$ACP.LOG;123
RSTS/E:
SPC11D::$ dir 41.503"system topsecret"::
Directory 41.503::SYS$SYSROOT:[SYSMGR]
Name .Typ Size Prot Access Date Time UIC
ACCOUNTNG.DAT;5 177/270 < 56> 17-Sep-24 17-Sep-24 00:01
[000001,000004]
CLUE$HISTORY.DATA;11/9 < 56> 04-Jan-26 31-Dec-23 16:55
[000001,000004]
CLUE$LAST_SPCVXB.LIS;1 2/9 < 56> 04-Jan-26 04-Jan-26 01:18
[000001,000004]
CXX_REPOSITORY.DIR;1 1/9CP < 40> 01-Jan-24 01-Jan-24 00:54
[000001,000004]
So I think it should be optional in implementations - not mandatory*,
not prohibited.
* "Fruity Oaty Bar", if you get the reference.
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:
The paradigm is that you remove whatever you action. So if from
TOMMYT::, I do a FINGER MIM::VENTI2::SLOGIN, then the MIM:: is removed
from the application data stream and MIM:: only sees VENTI2::SLOGIN. 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.
Application level routing is optional. Should this be stated more
emphatically? For Tops-20, it mainly exists for debugging odd cases to
determine robustness. Poor man's routing is a holdover from previous
versions of Tops-20 DECnet that didn't have it. Tops-20 removed Poor
man's routing for the terminal server. Hooks exist for FAL, but I have
those turned off. 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.
Transparent 'smart host' or Poor Man's routing was actually
implemented
for Tops-20, I believe by Larry Campbell. It's all off now. Regarding
switches, the paradigm is that you are talking to the finger client on
the remote host. All finger clients will reject switches they don't
know about and I think they are supposed to do that. 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.
Funny you
should say that, I have a number of domestic chores stacked
up, but strangely the Mrs. isn't angry with me, _yet_. Then again, she
may be one of the most patient individuals I've ever seen. Not like
me; I'm your typical southern Italian (Naples)
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(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
_______________________________________________
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