Re: Services and top-level DNS names (was: Re: Update of RFC 2606)

["Olivier MJ Crepin-Leblond" <[e-mail]>]

In an earlier message,  John C Klensin <[e-mail]> 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 [e-mail] as:
To: [e-mail]

or

to: [e-mail]-relay  (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:<[e-mail]> | http://www.gih.com/ocl.html
http://www.nsrc.org/codes/country-codes.html

_______________________________________________
Ietf mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ietf