Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199506051530.LAA07850@CS.UTK.EDU>
Date:        Mon, 5 Jun 1995 17:14:10 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: address syntax
To: drums@CS.UTK.EDU
In-Reply-To: Message of Sun, 04 Jun 1995 09:35:17 +1000 from Robert Elz
             <kre@munnari.oz.au>

On Sun, 04 Jun 1995 09:35:17 +1000 Robert Elz <kre@munnari.oz.au> said:

>The example you gave is what was intended by "heuristic" I suspect, that
>is, shortcut parsing, not looking at the syntax in detail - if you were,
>then in stripping the leading parts  of the route addr you'd come across
>the  '[' first,  and know  that a  matching ']'  was required,  and that
>stripping between those, wherever found, would always be incorrect.

But  the thing  is, nowadays  a lot  of software  simply throws  away the
source  route, as  allowed  by  1123. While  still  useful  in MTAs  (for
instance for load  balancing, or to forward things like  .UUCP or .BITNET
to  sites that  know how  to handle  it), source  routing is  pretty much
obsolete in application  software. Of course there are  still people with
addresses  like  @xyz.edu:joe@mac23  (unqualified), but  they  invariably
create a lot of trouble for *other* people. If you ask around you'll find
that most server/gateway maintainers view  this as the user's problem and
not something *they* ought to spend  time supporting, least of all if the
source route is in IP form. So,  trashing the source route is very common
and I don't  see why people who develop applications  should want or have
to implement a full-blown parser for something they're only interested in
throwing away. Today the ':' cannot appear in the source address and thus
it is correct to  parse this way. If this is broken  we'll have a serious
problem. In general I find that the  mail RFCs depend too much on special
characters. One gets  the impression that someone looked  at the keyboard
and said hey, we haven't found any special meaning for ';' yet, hmm, what
could we possibly come up with to use  it? On top of that, the meaning of
special  characters  has  been  abundantly overloaded,  which  makes  the
parsers more complex. I don't see that going further in that direction is
a good idea.

  Eric