Errors-to: owner-drums@CS.UTK.EDU
To: John Gardiner Myers <jgm+@CMU.EDU>
Cc: drums@CS.UTK.EDU
Subject: Re: address syntax 
In-Reply-To: Your message of "Mon, 05 Jun 1995 16:44:20 -0400."
             <gjoqmYK00WBwI9xulp@andrew.cmu.edu> 
Date: Tue, 06 Jun 1995 07:50:21 +1000
Message-Id: <2241.802389021@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Mon,  5 Jun 1995 16:44:20 -0400 (EDT)
    From:        John Gardiner Myers <jgm+@CMU.EDU>
    Message-ID:  <gjoqmYK00WBwI9xulp@andrew.cmu.edu>

    There are situations when generating any sort of error is
    simply not possible.

I would suggest that in those cases, the addresses should be
left strictly alone.
    
    If they try to get a document on the standards track which attempts to
    permit ":" characters in rfc822 domains, I and others who deal with
    mail systems will strenuously object on the grounds that the change
    will break a significant portion of the installed base.

This doesn't seem to be a very productive way to approaching
things - you are (now) aware this issue is looming, why not
simply explain your concerns to the IPng group now, and see if
you can convince them to change the ':' to something else.

Why bury your head in the sand, and pretend the issue isn't
going to arise, and then act surprised and indignant later
when it actually does?

Incidentally, there are people out there now writing IPv6
code, who are assuming the currently defined notation for
writing IPv6 addresses (including colons).   If that's ever
to be changed, it makes sense for it to be done as soon as
possible.

Incidentally, I have now a possible fourth solution to this
problem.

It seems that 822 allows ':' inside domain literals (in fact,
it seems to allow almost anything), which was probably a very
intelligent choice - meaning that 822 isn't in any way tied to
any particular form of transport addresses.  If you are parsing
822 headers with your code making assumptions about colons, it
seems to me it is simply broken.

On the other hand, 821 certainly doesn't allow ':' inside its
<dotnum>s - so assuming one won't occur is probably reasonable,
at least until 821 is altered.

A solution might be for IPng to simply define a new protocol,
almost certainly very similar to 821, but with a new definition
of <dotnum> that does permit ':', and of course, with a new port
to run it on.   That would then break no existing implementations,
while allowing many current SMTP servers to run on the new port
without changing any code.   One would assume that IPv4 systems
would continue to use 821 (or drums rewritten 821) on port 25,
whereas IPv6 hosts would use the new one.   (Note, this is an,
at most, half thought out idea, and isn't what I'd like to see
happen if it can be avoided).

kre

ps: I forwarded your message, the one I'm replying to, to the
ipng mailing list, so that the people there are at least aware
that you're out there, lying in wait...