Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ames!ptsfa!ihnp4!inuxc!iuvax!bsu-cs!dhesi
From: dhesi@bsu-cs.UUCP
Newsgroups: comp.mail.misc
Subject: Re: Precedence in network mail addresses
Message-ID: <631@bsu-cs.UUCP>
Date: Sat, 16-May-87 16:14:07 EDT
Article-I.D.: bsu-cs.631
Posted: Sat May 16 16:14:07 1987
Date-Received: Sun, 17-May-87 08:49:53 EDT
References: <588@bsu-cs.UUCP> <958@xanth.UUCP> <559@smidefix.liu.se>
Reply-To: dhesi@bsu-cs.UUCP (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Lines: 51

In article <559@smidefix.liu.se> lel@ida.liu.se (Lennart Lovstrand) responds
to my solution for the current confusion about precedence in mail
addresses, which was to introduce symbols that would force precedence,
as follows:
>The solution is NOT to introduce more symbols.  There are many enough
>already, thank you.

Perhaps an analogy with programming languages will help.  Count
the number of different arithmetic operators, then tell me why
they must include parentheses too.  It simply isn't a question
of whether or not you have enough symbols;  it's a question of
whether or not the symbols you have do what you want.  Currently
there is no symbol for forcing precedence.

>                  ...What is needed is the conformance to a single
>standard, whenever possible, and for the Mail Transfer Agents to
>otherwise do intelligent full translations from the transmitting net's
>standard to the receiving net's.

This ignores the reason why the concept of "layering" is so important,
as is the concept of "device independence".  To expect a single
component of a software system--especially a software system that
spans numerous countries, cultures, and operating systems--to understand
every little addressing detail of every component, is unrealistic.
It makes more sense to leave the decoding of local addresses to
local software.

The nice thing about UUCP has been that it was so easy to get on it.
Adding the ability to force precedence would allow any network to use
any internal address format and still be part of a bigger network.  I
see no reason why [e!f!g]a@b.c should not be a valid address, where
a@b.c is a site with a registered domain address, and e!f!g is a path
on a smaller network feeding from site a.  But intermediate nodes
should NOT have to interpret the "e!f!g" part of the address.  (In
place of square brackets, choose another symbol if necessary.)

To put it more simply: 

        there ought to be a way of taking an arbitrary network address,
        and making it look like a single site by bracketing it.

Thus I should be able to say "[a$b&c!d#f]@host.DOMAIN", and let "host"
handle the decoding of the "[a$b&c!d]" and hand the message on to the
server for the network that uses the addres format "a$b&c!d#f".  No
other node has any business trying to interpret "a$b&c!d#f", or
insisting on converting it (usually incorrectly) to "b.c.d.f.a" or
whatever, just because it wants everything to be separated by dots or
percent signs.  Leave the interpretation of local syntax to the local
sites!
-- 
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi