Errors-to: owner-drums@CS.UTK.EDU
Message-Id: <199506060113.VAA25393@CS.UTK.EDU>
Date:        Tue, 6 Jun 1995 02:44:14 +0200
From: Eric Thomas <ERIC@SEARN.SUNET.SE>
Subject:     Re: address syntax
To: Robert Elz <kre@munnari.oz.au>
cc: John Gardiner Myers <jgm+@CMU.EDU>, drums@CS.UTK.EDU
In-Reply-To: Message of Tue, 06 Jun 1995 10:21:19 +1000 from Robert Elz
             <kre@munnari.OZ.AU>

On Tue, 06 Jun 1995 10:21:19 +1000 Robert Elz <kre@munnari.OZ.AU> said:

>Maybe. It could have also been recognising that IPv4 may not be the only
>kind of transport address that would be needed and deliberately allowing
>for that. In any case, as it  is permitted, IPv6 can happily use it, and
>any 822 code that "breaks" was broken already.
>
>    Like: joe@abc.[192.36.125.6].def
>
>This one was more probably an oversight (...) In any case, deleting that
>abomination is certainly something worth doing.

I'm sorry, but I fail to understand  the logic. Most of my code breaks on
both     source    routes     containing    colons,     and    on     the
joe@abc.[192.36.125.6].def example.  By breaking  I don't mean  of course
that the program  crashes, but that it rejects the  address as invalid or
doesn't parse it correctly or whatever. I  fail to see what allows you to
call the first  example a clear design objective, making  my code broken,
while  the second  example  is  an abomination  that  is certainly  worth
deleting from the standard. I'm sorry, but looking at the RFC I don't see
anything that makes the first more or less legal than the second. My code
is equally  broken in both cases.  The only difference is  that you can't
find any use for the second form now, just as 10 years ago no one saw any
use for the  first form. So if you  want to look at it from  the red tape
perspective, there is no basis for allowing one and not the other. Now if
you want to be more pragmatic, the hard reality is that many applications
will break if you introduce IPv6  source routes, and I'm specifically not
talking about applications which exploit IPv6  and need to be changed for
this anyway,  but about innocent  high level applications  which couldn't
care less about socket address structures and just deal with mail folders
and host  names. These  applications which  used to  work fine  will stop
working even  though they're  not making  use of  IPv6, all  that because
someone inadvertently allowed all sorts of nonsensical things in the RFCs
13 years ago,  and a committee has decided that  preserving the purity of
the original BNF was more important than a smooth transition. This sounds
like another reason to migrate to MSDN, if you ask me.

If  you want  my  personal opinion,  source routes  with  host names  are
deprecated but possibly useful in MTAs for load balancing and handling of
various local  things, and source  routes with  IP addresses are  at best
useful in emergencies to notify people  who need to take action to repair
name servers,  at worst they  qualify as brain damage.  Breaking existing
applications  to  introduce  a  brain damaged  subform  of  a  deprecated
function doesn't make much sense to me. What I'm trying to get at is that
not allowing IPv6 source routes  in dotted-whatever format is unlikely to
impact anyone. It's not available today,  so you just tell people that as
they convert to IPv6, they must join the civilized world and discover the
Name Server if they want to  use source routing, which they shouldn't use
in the  first place.  On the other  hand, breaking  existing applications
will  cost very  real  money  in the  form  of  programmers hunting  old,
forgotten  parsing routines  and figuring  a  way to  fix them,  helpdesk
people  acting as  a buffer  between unsympathetic  vendors and  confused
users, and people not getting their  work done. The cost of reengineering
applications that depend  on IP source routes (and that  would need to be
modified to support IPv6 source routes  anyway) is probably 3-4 orders of
magnitude less.

  Eric