Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rutgers!mcdchg!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.mail.uucp
Subject: Re: Paths and Precedence (Re: Question about From: lines)
Message-ID: <1990Jul11.020522.4456@chinet.chi.il.us>
Date: 11 Jul 90 02:05:22 GMT
References: <11034@alice.UUCP> <KARL.90Jul9143911@giza.cis.ohio-state.edu>
Organization: Chinet - Public Access UNIX
Lines: 58

In article <KARL.90Jul9143911@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes:

>You have just returned to the land of transport-centric addressing.
>I'm really tired of having to know what network someone is using.
>With DNS, I don't have to.  It's silly to have to tell your physical
>postmaster how to find your street -- s/he's just supposed to know
>that.  Email should be treated similarly -- the user isn't supposed to
>have to know or care about how the bits get between here and there.
>You force them to know by encouraging network-specific address forms.

But the DNS really wants the sending postoffice to know that a building
exists at a certain street address or rural route before sending
a message instead of just passing along the necessary information to
the receiving postoffice that may have its own way of doing things.
At least the current methods make it extremely inconvienent to pass that
information around bi-directionally.  Sort of like not being able to
put a street number and a zip code on the same letter.

>[...] and assuming that the machine name
>is an FQDN, it's of the form "f.q.d.n!user," which can be transformed
>to "user@f.q.d.n" with no loss of information; so the only remaining
>difference is in the choice of network punctuation and the ordering of
>the (host,user) pair.  In other words, no semantic difference remains.

*If* the end point is an FQDN.  F.q.d.n!site!user or site!user@f.q.d.n
are subject to all sorts of abuse by the transports.

>You can indicate transport however you want, but it's clear
>that, as a practical matter if not a theoretical one, !-paths
>ultimately result in transport indications.

In dial-up uucp, obviously the transport follows the connectivity, and
the theoretical (and reasonable) domain!user must be converted to
a physical path to some other machine or its not going to go anywhere.
In a uucp-connected subdomain, the tendency seems to be for a.b.c to
actually become c!b!a in the transport but its not necessary.  Neither
is the reverse, given suitable software.

>Kinda silly.

Not as silly as machines that prevent you from using the routing information
that you know will work, or reliably passing it to another site. Given an
f.q.d.n as an anchor point, mail is not transport-centric leaving your site.
After that, its not your problem, or it wouldn't be if there were a reliable
way to specify routing so that mail wouldn't bounce all the time.  Actually,
it would be better not to think of it as routing, but an address in a different
syntax (and it may well be).  A reasonable naming scheme should let you
encapsulate any other scheme within it.  The DNS itself doesn't actually
prevent this, but the current software certainly doesn't handle it well.

To require an FQDN without enforcing some sort of organization among sites
that have no particular reason to be organized is going to result in
a nearly flat address space anyway, so why not just allow .uucp?  Or, perhaps
the internet <-> uucp forwarders could just offer a sub-subdomain name to
their connections.

Les Mikesell
  les@chinet.chi.il.us