11 Jan
2026
11 Jan
'26
3:36 p.m.
This became more confused and complicated than I anticipated.
So I'll try and rephrase this, and hopefully people can agree, and if
not we can take it from there.
First of all we have the TCP/IP finger protocol.
This is defined in RFC 1288.
This protocol talks over TCP, with the server listening on port 79. A
client opens the connection and sends a one line query, terminated by
CR+LF. The query as such is basically in the form user@host2@host1,
where all the parts are optional. However, note that the username is the
leftmost component before the first @, and the host to communicate to is
the rightmost component, after the last @.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed right to left, and the
optional username is the leftmost part. Any host that talks finger over
TCP really should follow this RFC. Anything else is fundamentally bad,
and I hope all would agree with that.
Next we have finger over DECnet.
There are no formal standard for this. But there have existed
implementations since the 80s. Thomas tried to summarize how it should
work, which is aligned with those old implementations, and is also what
both him and me have tried to follow.
This protocol then talks over DECnet, with the server defined as the
DECnet object 117. A client opens the connection and sends a one line
query. The query as such is basically in the form host1::host2::user,
where all the parts are optional. However, note that the username is the
rightmost component, after the last ::, and the host to communicate to
is the leftmost component, before the first ::.
Forwarding from host1 to host2 is up to host1 if it will do it or not.
But it really means that hosts are processed left to right, and the
optional username is the rightmost part. Any host that talks finger over
DECnet really should follow this spec. Anything else is pretty bad, and
I hope all would agree with that.
So that's the basics. It's pretty straight forward, and I hope very
uncontroversial. However, please note the complete different parsing
order of hosts and usernames in TCP/IP and DECnet. This is important!
Before I go on I want to make a small comment on the topic of streaming
connections in DECnet. DECnet is inherently packet based. Some operating
systems provide an abstraction to streams on top of this, but not all
OSes do. And this stream abstraction is not the same thing as TCP, and
it is important to understand this. If your host pretends you use a
stream, it can still arrive as packets on the peer side. There is no
explicit stream type, and the packing/unpacking of data from a stream
into packets are done at a layer above DECnet itself. This became
obvious when me and Thomas were doing some initial work on
interoperability between TOPS-20 and RSX. The problem being that Thomas
was letting TOPS-20 treat the connection as a stream, and we got into
trouble on the RSX side.
TOPS-20 were just putting all the data to send into one packet in the
end. In RSX when receiving, you give a buffer with a size where received
data should be placed. And if the packet contain more data than fits in
the buffer, the remaining data is not kept, but discarded, and you get a
data overrun status in the receive.
So it's not actually a problem with streaming as such, but the size of
packets you might end up with. If TOPS-20 streams would just limit the
actual eventual packet to no more than some certain size, RSX will play
just fine. The fact that TOPS-20 pretend it's a stream is not a problem.
The problem is identical if you use packets, and just use a packet size
that is larger than what the receiver is expecting.
So if there is a way for any streaming abstraction layer to just say
what the maximum size of the packets should be, then by all means, run
with a stream if you want to, and it will work fine (just let me know
what your upper limit is set to, and I can adjust the RSX code
correspondingly).
Ok. Final part. Things become "interesting" when you start mixing TCP/IP
and DECnet. Since TCP/IP requests do hosts and users processing right to
left, and DECnet requests do hosts and users processing left to right,
and they also use different separators between hosts and usernames, how
do you get this to mix?
Terri's example:
finger terry@spc11d::
is a complete mess. How should this be parsed. If we go by TCP/IP
standard, anything to the right of the last @ should be the host, which
is "spc11d::". But that's not a host you would find in DNS.
But it's also not useful to process according to DECnet, because then we
say that everything before the first :: is the node, which would be
"terry@spc11d", which is clearly not a DECnet node.
So, please, drop that. That is pretty obviously illegal, no matter which
way you want to look at it.
What I did in RSX is, what I think, the only reasonable way to do this
right. So the request would be:
finger spc11d::terry
Which of course is a DECnet request. If you somehow wanted to involve
TCP/IP in this, the format would be
finger spc11d::terry@mim.softjar.se
as an example. And this will work on any system on TCP/IP that talks
finger (could be any Unix host in the world). It do not need to know or
understand anything about DECnet at all. Because it talks TCP/IP, and it
picks the rightmost host after the last @ as the machine to connect to,
and it passes to that the request "spc111d::terry", which is then up to
Mim.SoftJAR.SE to understand and do anything with. Which boils down to
the same DECnet request as the first example above.
And guess what, here is how it looks on my MAC, right now:
Gromit:/Users/bqt> finger spc11d::terry@mim.softjar.se
[mim.softjar.se]
[SPC11D::]
SPC Memorial PDP-11/70
SPC11D PDP-11/70, RSTS V10.1-L, Monday, 11-Jan-1926 09:29, 8 Jobs, 63 Max.
Uptime 7 08:54:20, 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:06 SL - Detached -
4 SYSTEM 1,2 PBS... Det 00:14 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 -
Gromit:/Users/bqt>
So I can actually finger a RSTS/E host from a MAC. How fun isn't that?
(Don't ask me why I'm not getting information about Terry, though,
because I get the exact same result if I just do a "finger
spc11d::terry" on Mim directly.
Maybe an example with VENTI2 would be more fun:
Gromit:/Users/bqt> finger venti2::slogin@mim.softjar.se
[mim.softjar.se]
[VENTI2::]
SLOGIN Thomas DeBellis 8 EMACS 9:58 44 iSnack.Jute:
Development, Larg
9 EXEC 11:55. 45 iSnack.Jute: Logging,
Wide
10 EXEC 10:58. 46 iSnack.Jute:
Secondary Testing
11 SYSDPY 10:02 47 iSnack.Jute: Testing
and Debug
12 EXEC 43:24. 50 Neptune.Jute: STAR
Testing, Sm
14 EXEC **:**. 51
IUUGAA4-Wireless.Jute: Bedroom
15 KERMIT 36:50 52 iSnack.Jute: CKermit
Testing
16 VIKING 23 Batch: Kermit
Loopback Testing
No new mail, last read on Sat 3-Jan-2026 4:12PM
Gromit:/Users/bqt>
It is pretty neat, if I ask me. :-)
If you do this on MIM, it will by default first try to process DECnet
nodes, so it will take the first node name, up to the first :: as the
node to connect to, and then pass everything after that to the server,
meaning "terry(a)mim.softjar.se" as the query. Now, if spc11d don't talk
TCP/IP, you'll get an error here. But if it do talk TCP/IP, and is
following the RFC, it will understand that query just fine, and should
do the right thing without any funniness.
If, on MIM, you actually want
spc11d::terry@mim.softjar.se to be doing the TCP/IP part first, then you
need to add a switch to make it so. And then it will be the same as any
other TCP/IP finger client, and work the same as described in that bit
above. So still all good.
Any other notations will break either the RFC or the DECnet finger spec.
Now, as I said before, I'm not going to force anyone to change their
code. But I really do find it broken to have code which tries to decide
if something is TCP/IP or DECnet by guessing and some heuristics. And
since the inherent order of hosts are in the opposite directions in
TCP/IP and DECnet, no heuristics in the world can actually make this
actually work right according to the two specs. You'll have to break
compatibility with one or the other protocol.
Up to everyone of you how you want to look at that. But I can tell you
that the RSX implementation will continue to try and follow both specs.
So TCP/IP hostnames will never be assumed for a node that ends with ::,
and DECnet nodenames will never be assumed for something that starts
with @. And this is also true for mail. And that is also how the mail
relaying on MIM is doing things, and how you can send mail from HECnet
to the internet by saying
MIM::user@host
And send mail from the internet to hosts on HECnet by
node::user@Mim.SoftJAR.SE
And please be aware that gmail reception is broken, and they don't
accept mails from HECnet because of that. Nothing I can do about it.
gmail basically do not accept mails with a from address in the form of
"node::user"@mim.softjar.se, although it is correct according to RFC
5321. Google apparently don't care that they are violating the RFC.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol