Errors-to: owner-drums@CS.UTK.EDU
To: Eric Thomas <ERIC@SEARN.SUNET.SE>
Cc: John Gardiner Myers <jgm+@CMU.EDU>, drums@CS.UTK.EDU
Subject: Re: address syntax 
In-Reply-To: Your message of "Tue, 06 Jun 1995 02:44:14 +0200."
Date: Tue, 06 Jun 1995 14:15:53 +1000
Message-Id: <2337.802412153@munnari.OZ.AU>
From: Robert Elz <kre@munnari.oz.au>

    Date:        Tue, 6 Jun 1995 02:44:14 +0200
    From:        Eric Thomas <ERIC@SEARN.SUNET.SE>

    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.

Frankly, what might cause problems for your parser, or any
other parser, wasn't high on my list of criteria for deciding
that.

Its possible that allowing almost anything in domain literals
in 822 was just laziness, not wanting to have to define a
whole other set of rules just for this one case - however
all those rules were in 821, which was being written at the
same time, it would have been pretty easy to copy them, even
with the different syntax.

I kind of suspect this may have been deliberate, for three
reasons.  First, the difference between 821 and 822, which
may seem to be just accident, but which I find hard to believe.
The two docs have the same author, defining the two things so
differently is a bit hard to see as chance.   Second, it has
been suggested to me, that the UK greybook (is the colour right?)
which was based on rfc733 actually allowed other kinds of
addresses, not IPv4 addresses, to be put in the domain-literal
(nb: it is not called an "address" which is more evidence).
I would expect (ie: be 99% sure) that any such usage would have
been known at the time 822 was written.   Third, in 733, the
alternatives are a name (pre-cursor of domain name), or a
number (pre-cursor of IP address), and there the meaning of
the field was quite explicit.   Its hard to see how this could
accidentally be omitted from 822.

So, I conclude that allowing flexible text inside domain
literals was probably no accident at all, and what's more
that they weren't allowed in 821 was also no chance, the
theory being, I suppose, that if an X.25 address appeared
there you'd be using some kind of X.25 mailer, and not SMTP.

The embedded literals in domain names on the other hand may
also have been deliberate, but if it was, clearly shows now
that the designers had no idea how the DNS would be (later)
developed.   This concept now has no conceivable use, I can't
even imagine what it was supposed to have ever possibly meant.
Its because of that that I presume that allowing this in the
syntax was quite possibly an oversight, rather than intentional.
Whatever, its clear now that this form is absolutely useless,
and may as well be dropped, and that failing to support it
is not a problem.

If you really want to know the answers to these questions, as
best that anyone knows, I'd suggest asking Dave Crocker.


    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.

I am not sure the latter is true.   When 822 was written,
even more so than today, the existance of different net
technologies, with different addressing structures, was
very well known.   Planning for that would have been a
very intelligent thing to do, and the protocol designers
back then seem to me to have been considerably more rational
people than most we encounter today.

For the rest of your message - I suspect I agree that source
routes containing any kind of domain literals are probably
unnecessary (source routes are close to useless now that
mailers exist that ignore them, domain literals are still
useful, but only in rare cases, combining the two seems like
folly to me).   I wouldn't object to prohibiting all domain
literals from source routes.

I also was one (of a number) of people who argued in the IPng
group for changing the ':' to something else - the uses of
':' in domain-literals, and in URLs being the two major
problematic cases.   Of course, then I hadn't realised

Third, I am not one who believes that (even widespread) use of
broken code should be allowed, of itself, to determine the
course of the standards.   822 very clearly allows any chars
at all (almost) in domain-literals.  If you're not writing code
that has to interpret the domain literal, knowing anything
about what is inside it seems like a very poor idea to me.
Assuming it won't have some particular character is just as
bad.  (nb: the spec also allows '(' ')' '@', and lots more!)

This isn't what I'd consider to be a good enough reason to
prohibit ':' containing IPv6 addresses in domain-literals.
Especially not when the world has years to prepare for these
things to appear.   In that time there will be lots of other
changes to mail standards for sure - these days UA's that
don't at least understand MIME are basically useless, as there
are others that insist in sending (encoded) MIME bodies
containing even what was simple text - if your UA can't
read MIME and decode it, there are people whose mail you might
never be able to read.   People do upgrade their UA's.

kre