From: utzoo!decvax!duke!harpo!npoiv!alice!physics!gill
Newsgroups: net.general
Title: Re: new mail syntax standard published - (nf)
Article-I.D.: physics.159
Posted: Sat Aug 21 00:47:14 1982
Received: Sat Aug 21 06:08:06 1982

#R:cbosgd:-254400:physics:16800001:000:8936
physics!gill    Aug 21 00:44:00 1982

The report "Domain Naming Convention for Internet User Applications"
(RFC 819), besides being the most poorly written piece of computer
documentation I have ever seen (why is it that committees always want to give
their document that "mechanically generated" tone?), is deeply flawed.

It's time to open discussion. As far as I'm concerned, nothing has been
"decided." While DOD sites may be under the committee's thumb, I
don't think the rest of the world is going to accept a "standard"
which not only fails to address any of the hard problems, but actually
prevents their eventual solution.

What is a mail destination address (MDA from now on)?

	A MDA is a way of uniquely specifying the destination of a message
	to a human being.

	In the context of computer mail, it is a way of unique specifying
	the destination of a message to a computer user.

What makes one format of MDA better than another? I believe the goals
are few and simple:

	a) Universality of name. No matter where the sender is,
	   my address is the same. I shouldn't have to sign my letters
	   "alice!gill OR gill@mc." Local abbreviations should only be a
	   means to aid human authors in generating the full MDA.

		Why is this important? I can think of two reasons:

		i) I can tell someone how to reach me without knowing
		   what system or network the sender is on.

		ii) No matter how my message is routed, the information
		    of how to reach me is never corrupted (819's
		    scheme of modifying from/to fields at network
		    boundries belongs in a Freshman's C- computer
		    science essay). Thus, when my message is
		    mis-routed,	the MDA remains robust enough to
		    get the message to me anyway.

		People who oppose universal addresses on historical grounds
		should be wary of confusing human design decisions
		with purely technical ones. The reasons we don't always
		dial long phone numbers is because its hard on the
		fingers and mind and also because the older technologies
		limited the routing of a "local" call. Using a computer
		mailer, it is not unreasonable to demand all addresses be
		full length. The translation of "joe" to his address on
		earth is a job to which our machines are quite well suited.

	b) The MDA should contain only as much informatin as neeeded to
	identify the recipient. This leaves the door open for future
	enhancements such as dynamic routing. The .NETWORKNAME in RFC 819
	closes this door by adding non-pertinant information, thus
	straight-jacketing the operation of all future mail programs.

		It would seem the committee members haven't paid very
		much attention to the large number of multiply connected
		systems. At MIT, most of the UNIX systems are accessable via
		both by our local CHAOSNET and by UUCP. The idea that
		I need two seperate addresses on a single computer just
		doesn't make sense. Multiple parentage is NOT a subject
		to be put off for "future investigation." It is a pressing
		problem which is currently being handled in ad-hoc ways.
		RFC 819 would force us to abandon all hope of freeing
		the author from the requirement to know the network
		topology.

		The conceptual error in RFC 819 is very fundamental. It
		claims that UUCP, ARPA, etc. are environments in
		which computer systems operate. They are instead nothing but
		transport mechanisms, not at all indicative of
		the various adminstrative contours which the RFC strives
		to represent. Instead of substituting administrative
		topology for physical topology, they have substituted
		transport topology.

		When a system upgrades to higher performance network, it
		should not be necessary to send out address corrections
		for other systems to take advantage of the new capablity.

	c) The MDA should in some way be isomorphic to the ways people
	   locate each other in the non-computer world.

		The wherabouts of a collegue are independant of which
		interstate I must traverse to visit his house. It is
		also independant of whether I take a car or a hot air
		balloon. Similarly, I should be required to know neither
		the path taken by my message NOR to what type of computer
		network he is connected.

		Instead of making the MDA format be determined by the
		hierarchy of computers, let's make it dependant on the
		hierarchy of people.

What is the topology of computer users?

	Though time has seen a vast increase in the number of computer
users, what has resulted is an increased width, not depth of
the hierarchy. At the fringes of this tree are people. The
next level up is the group. The definition of a "group" is easy:

	a collection of computer users with unique names and a
	capability of avoiding future name collisions.

A group may use several computers, but the users either know each other
well enough, or are somehow centrally administered, such that no names
are ever duplicated. Corporate departments or school projects are
examples of groups.

	Next comes the organization:

	Organizations are to groups as groups are to users; there are
sufficiently few groups in an organization such that the group names
can be unique.

Eaxmples of organizations would be MIT, UCB, TI, BBN.

Though I presently see no need for more levels, they may become necessary.
Perhaps when two companies have the same name, we'll classify them by
their field of interest (i.e. what they make).

What of diversified corporations, or consultants assosciated with many firms?
Multiple parantage is staring us in the face. Let's deal with it now.

Since our definition of an MDA does not dictate network type or routing,
we can have multiple names for a particular human without fear of
jamming any physical path. Corporations which work in several fields will
have entries in each of those fields. People who are members of several groups
can have entries in each of those groups.

With "future investigation" behind us, let us describe a possible syntax.

How about:

	user . group . organization

When the decision is made to add another level, the entire network will
have to appened another "domain." This is inevitable if we want to maintain the
"universality" of addresses. Since it may someday be better to route a message
around the world to get next door, and since mistakes will inevitably happen,
it is important to attach a complete address to that message. As
messages may hop from deep inside one part of the administrative hierarchy
to another, incrementally building the address as the message passes
by will not work. This is the fundamental mistake of RFC 819. Network
topology is independant of the adminstrative topology. One cannot
depend in any way on the former to specify locations in the latter.

Adding levels isn't as horrible as it sounds. I presently don't see a need
for more than 3 levels. Perhaps when there is a PC in every pot
we may need 4. Trees grow rather exponentially, you know.

The user interface, of course, will not require the author to specify
(or know) full blown addresses. In a mechanism similar to the UCB
per-user alias file, a mailer will be able to interpret the per author
context of a name at each level. What is important, however, is that
when the message enters the hostile network environment, it have a
dog license around its neck so that anyone who comes accross it knows
where it should go.

Routing:

	Routing will require a distributed dynamic map. It is not necessary
for all systems to know of each other, but instead mearly in which
direction to send unresolved addresses. Instead of taking the easy
way out and adding .UUCP to an address, one can easily imagine
a system whereby frequent addresses and routes are cached on local systems with
"misses" being refered to more knowledgable machines. To petrify
the route in the address is asking the human to be the cache instead of the
computer.

	A mechanism should be provided to explicitly specify the route
of a message (for testing and bootstrapping new systems). This should
go in a totally different place than the address.

To summarize, there are five basic flaws with RFC 819:

	i) It retains the coupling of administrative and network topologies.

	ii) It prevents intelligent routing to systems reachable by
	    several paths.

	iii) It necessary to specify several addresses for a
	     single user on a system connected to several networks.

	iv) The optimal address of a destinee is dependent on where the sender
	    is, and thus not something the destinee can communicate
	    independant of network topology.

	v) Messages are extremely vulnerable to loss at inter network
	   interfaces.

	I do not plan to implement nor support RFC 819 addresses on
any of the machines I administer. The present address formats are much more
clumsy, but at least they don't have the gall to dictate the future.

	Gill Pratt

	...alice!gill OR gill@mc


	Constructive Criticism and Judicious Editing by

	Pace Willisson

	...mhtsa!physics!pace OR pace@mc