<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>Hi Johnny,</p>
<p>These are all great points, but I fear you and I are talking
apples and oranges. Let me address the mail part first.<br>
</p>
<p>There is no intention in my part to use either the PUP or CHAOS
protocols for data transport for many reasons. They are (or
where) local area only; experiments in broadband, with no
routing. I have no hosts that speaks them; with the exception of
ITS, I am unlikely to. The PANDA distribution doesn't appear to
have the drivers and the Digital one certainly wouldn't. One or
the other may not be compatible with Tops-20's multi-net
implementation.</p>
<p>So this is really about a minor enhancement to the Directory Name
Service. Let me explain; the default PANDA distribution will
mysteriously hang when trying to resolve a NAT'ed TCP/IP host or
DECnet (and presumably for PUP, too). This causes mail delivery
to take far longer than I or my few users care to wait as well as
appear to hang the usual suspects, TELNET and FINGER. The problem
is that these utilities are all wired to use the HSTNAM module
which uses CHIVES instead of DEC's (incomplete GTHST%) resolver.</p>
<p>When trying to resolve a name to address, CHIVES will wait a long
time for a response from an authoritative DNS server. So, you can
hack HSTNAM to partially prefer GTHST% (which I've done) and put
the hosts in SYSTEM:HOSTS.TXT, but this is not the best idea. The
correct thing to do is either put the entries of your NAT'ed hosts
in the DNS server or have a local zone file. The zone file is a
common RFC specified format which CHIVES and everything else will
parse, but I've found the documentation to be 'unfortunate'. In
any event, I put all my local hosts in a ZONE file, so that part
works. Mostly.</p>
<p>However, when sending DECnet email, I noticed that network
delivery agent was hanging in a GTDOM%, which is the monitor
interface to CHIVES. What? Using CHIVES to resolve a DECnet
address?? It's actually the correct thing to do, almost. Tops-20
has a very rich email delivery service that will speak SMTP over
anything, MAIL11 and whatever BITNET wanted. It handles also
handles Unix formatted addresses and can do mailing lists.</p>
<p>Early work on DNS was done in part at MIT, which had a number of
20's (MIT-XX, MIT-EECS) and certain ideas were adopted into DNS
from that platform, notably the MX record, which is used for mail
hosts and relays. So the mail system is using HSTNAM to determine
whether there are any relays for the host, which is a very
sensible thing to do. And it hangs because none of the HECnet
nodes are in a zone file.</p>
<p>Review of RFC's and CHIVES shows that DNS still has a record type
for CHAOS; no surprise given the above. At the theoretical level,
this can be adopted to use DECnet area.node addresses. You'd
simply be adding an additional record type; instead of 'C' (for
CHAOS), 'D' for DECnet suggests itself. Building the zone file
from your database is straightforward; I'd just be asking you to
send me some additional data in the form of quoted switches for
SETNOD, viz: /OWNER:"Thomas DeBellis".</p>
<p>Now, instead of hanging waiting for a HECnet node resolve which
will never come (or have the wrong IP based address), the right
thing would happen. For now, what I've done is mutilate the
mailing system to determine whether the host is on DECnet and
don't do the GTDOM% resolve (because there will never be any host
or MX records). However, this means that all of the benefits of
MX are lost and routing has to be handled by a fully knowledgeable
host (in the form of mailing lists).</p>
<p>The call is basically an inter-process communication event to
CHIVES. It wouldn't be going out to the Internet (or DECnet) for
anything; just hitting a zone file. However, piggybacking DNS on
DECnet doesn't look to be that hard, either. I probably wouldn't
bother. Properly implemented, this allows a 20 to route mail
between HECnet and the Internet, but also to other DECnet's (say
whatever those Italians are doing). You don't need to bridge the
transports to get it right.<br>
</p>
<p>MAIL11 is good for what it is, but it has it's drawbacks which I
need not elaborate to you as well as other deficiencies that I've
never brought up. You <u>always</u> want to try SMTP first, if
only for the better error recovery. There was an SMTP DECnet
client for the VAX, I'm fairly sure. Also, incoming MAIL11 can be
forwarded to other platforms (and this was extensively done). But
that means that you have to use the resolver, which means you hang
if something isn't in the DNS or you go with my hack (which
probably would have horrified MRC).<br>
</p>
<div class="moz-cite-prefix">My hope is to make all of this part of
a distribution for hobbyist Tops-20. While he was alive, MRC took
all my fixes to Galaxy into PANDA as well as FTP and was waiting
for my completed server. I'd like to return the favor and publish
the 60 or so fixes that I've done since his passing.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"> --T<br>
</div>
<blockquote type="cite"
cite="mid:0bb3dd70-a7c6-343c-15e1-8eaa342d2112@softjar.se">
<hr width="100%" size="2">On 5/4/20 7:24 PM, Johnny Billquist
wrote:<br>
<br>
On 2020-05-05 00:29, Thomas DeBellis wrote:
<br>
<blockquote type="cite">Second, some issues with MAIL-11 and
DECnet SMTP on Tops-20 have caused me to believe that one
solution would be to expand the DNS service (CHIVES) to handle A
and MX records for DECnet. That's not actually that big a
stretch; the DNS specification has 16 bit data types for CHAOS,
which would be trivially re-usable for Phase IV DECnet.
However, I'm finding the current documentation to be a chore to
wade through. The source code incomplete in certain
functionality.
<br>
</blockquote>
<br>
I seriously doubt you'd ever get this to play. Not only do I think
that CHAOS, even though it technically exists, are tested or
supported by any name server today. I also can't really see how
you think adding DNS would solve any problems you might have with
MAIL11.
<br>
<br>
You would only be able to use DNS over Internet, while any node on
HECnet will not be visible anywhere there, unless someone decides
to register a domain, and then somehow populate this domain with
all the information from HECnet, which then also needs to be
maintained. But only your machines would ever even try to go there
then to find the address of other machines.
<br>
<br>
And anyone externally would then have to address mails to this
domain in order for it to reach hosts on HECnet, but you'd have to
have MX records for each node pointing to some mail gateway or
other. But internally you would not want to make use of these MX
records, since on DECnet, you'll be directly talking to the end
destination, unless you have an explicit hop path in the mail
address, in which case you even less want to involve something
like MX.
<br>
<br>
And also, anyone externally would not be trying to look for MX
records under the CHAOS class, but still under IN, which would
then fail, as the DECnet nodes would not have addresses in the IN
class.
<br>
<br>
So it would be even more exclusively to your implementation only,
and not usable by anyone else.
<br>
<br>
Sorry for shooting this down, but this is about as (or even less)
useful than implementing SMTP under DECnet. You would be able to
talk to yourself, and nobody else.
<br>
<br>
<blockquote type="cite">Assuming I get this figured out, what I
would do is modify SETNOD to parse a fuller version of Johnny's
database. In addition to building the binary file for
importation into Tops-20's DECnet node name hash table, it would
also build a binary TBLUK% table for use by COMND% instead of
.CMNOD and also a zone file that CHIVES could parse for the DNS
records.
<br>
</blockquote>
</blockquote>
</body>
</html>