In an earlier message, John C Klensin <john-ietf@xxxxxxx> wrote:
Part of the problem in that case was that, because JANET used
little-endian names internally, the big-endian foo.ucl.ac.uk (in
DNS order) had to be be mapped into uk.ac.uck.foo (in JANET
order) and vice versa. That mapping was trivial as long as one
could run a simplistic "whichever end the TLD was on had to be
the big side" test. When "CS" was introduced, blew up that
simple test. In the JANET case, it failed since there were
strings that could be TLDs at both ends of the string, i.e., in
principle, cs.ucl.ac.uk could have been a string that was
already in JANET order and that would appear in the DNS order as
uk.ac.ucl.cs.
I tried getting Peter Kirstein to comment on this, but he's unfortunately
currently away, so I'll voice my own opinions here and please bear with me
because Peter's knowledge far exceeds mine. After all, I was only a terrible
teenager at the time.
IMHO you cannot compare today's challenges with the way things were handled
in 1989 or so...
JANET was using NRS, not DNS. NRS was a static mapping of UK computer
addresses in NRS format, ie. UK.AC.SOMEPLACE.SOMECOMPUTER to X.3 PAD numbers
accessed over X.25. NRS pre-dated the DNS. Getting e-mail in and out of the
UK made use of several gateways that on the UK side we need to know, and on
the other end of the line people either needed to know, or you'd send to a
gateway that would know.
There were several gateways in the UK:
EARN RELAY - located at Rutherford Appleton Labs as a path to BITNET (UKACRL
node)
EAN RELAY - to X.400 & other European Networks
UK.AC.UCL.CS.NSS - the precursor to nsfnet-relay.ac.uk - satellite link to
the Internet
UK.AC.UKC - University of Kent at Canterbury's UUCP service
Back in those days, you could route your email specifically - something
which very few mailers allow today.
For example, I could send email to an Internet address foo@xxxxxxxxxxx as:
To: foo%com.bar.foo@xxxxxxxxxxxxxxxx
or
to: foo%foo.bar.com%CUNYVM@xxxxxxxxxxxxxxxx (this one crossing the pond via
BITNET & bridging to the Internet via cuny)
Note that the NSS Relay used to reverse the addressing automatically. In the
early days, it used to try and check which way the addressing was. Then came
CS and you are correct in saying that it caused problems. But the problems
were not nearly as serious as you say. Rules were changed that you simply
needed to write the address in the correct order for your email to be
delivered.
For those that have a historical interest (and would perhaps like to get
inspired technically to resolve possible future problems with gTLDs), I
suggest you read the excellent document written by Tim Clark of Warwick
University back in those days. It used to be my email bible for quite a
while and a few copies still float around the net.
You can find a dusty copy here:
http://iubio.bio.indiana.edu/soft/help/old/email-gateways.txt
Last but not least, IMHO the issue of mit@ai is a non issue. I think we need
to come to terms that the age of a resolver trying out every known local
domain/sub-domain is dying out. From now on, you'll need to provide an exact
host/domain name. It is not the first and not the last habit to die on the
Internet. Take bang! paths, for example: dead. hostname.uucp - dead. And I
also think that what web browsers try to do by suggesting a page when you
just type "somefooplace" -> opens somefooplace.com is also a "feature" that
will need to die to ensure stability. There are simply too many
"somefooplace" on the internet, and now "somefooplace" might even be
.somefooplace
Or ISPs might even resolve locally "somefooplace" to "somefoobarplace" -
clearly there is no limit to foo.
Warm regards,
Olivier
--
Olivier MJ Crepin-Leblond, Ph.D.
E-mail:<ocl@xxxxxxx> | http://www.gih.com/ocl.html
http://www.nsrc.org/codes/country-codes.html
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf