Message-Id: <v03005620ad739f1151be@[205.214.160.40]>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Date: Tue, 19 Mar 1996 08:37:50 -0800
To: drums@cs.utk.edu
From: Dave Crocker <dcrocker@brandenburg.com>
Subject: addr-spec (local-part@domain)

Interesting set of comments about this noble string.

	Some folks seem to be taking The Word of The Spec as law.  This
gets a bit odd when different interpretations are possible.  (Just like
other sorts of religion, no?)  When there is contention about
interpretation or when the spec deviates substantively from common
practise, we ought to be pretty flexible about changing the spec.

	As with most of what we debate, I suggest that we consider, in order:

-  What makes sense, that is, what do we actually WANT?
-  Then ask what established practise is, to assess damage of changing.
-  Then ask whether it's worth changing the spec.

	The mere fact that the current spec leads folks down one path or
another is important in assessing established practise, but not in
assessing what we actually want.

Domain Names with Spaces:

	I  suggest that it makes no sense to have a domain name include
spaces or comments or anything other than the usual unbroken set of
fields-separated-by-periods or, of course, the laudable bracketted numeric
address.  Certainly the full freedom to do spectacularly creative quoting
has been demonstrated to be of no benefit at all.

Dots in Specials:

	The idea of removing dots from specials is at least interesting and
well might be the right answer, though it fundamentally changes the
intended lexical analyzer/parser model that RFC733 defined.  (More on that
in a later message.)

Quoting:

	I suggest we find a way to make the syntax call for nicely simple
encoding forms.  The use of quotation marks and backslashes was not
intended to produce bizarre combinations but, rather, to make things
visually simple.  Having alternating sub-strings be quoted or not just
doesn't help and it definitely hurts.  The reason that one, single, quoted
string wasn't mandated (e.g., for local-part) was to allow long strings to
be wrapped easily.

Local part:

	Now there is one really scary item that is cropping up, namely
restriction on the information that can be put into local-part.  Local-part
is the business of the system referenced in the domain part.  It is no one
else's business, except to ensure that the local-part string can be
distinguished and carried throughout global Internet mail.

	Interpretation of domain is the business of Internet mail.
Local-part is not.  It is, in fact, absolutely essential that this be true,
because it is the only thing that has saved Internet mail addressing from
falling on its face.  The X.400 world demonstrated the error of trying to
specify all the details globally.  It was only an accident that Internet
mail did not commit the same error.

	For example, I would not have been able to create the (blankety
blank) percent-hack and achieve reasonably comfortable off-net email
relaying, for CSNet and others, when the Internet had no standards for it.
In those days, there was only the concept of direct connectivity.  In other
words, we win hugely by keeping the left-hand side's interpretation as
strictly a local matter and worry ONLY about a syntax that can pass through
the (rest of the) net.

	The problem with discussions such as those involving the percent
hack is that they miss the distinction between relaying and gatewaying.
Gateways must get into end-system issues, since they must mess with the
message contents.  Relays must NOT mess with the contents and that includes
local-part.   RFC1123 had to deal with the percent hack because of
gatewaying.  We probably don't, or at least should be careful to keep it
out of the "core" Internet email discussions.

d/

--------------------
Dave Crocker                                              +1 408 246 8253
Brandenburg Consulting                               fax: +1 408 249 6205
675 Spruce Dr.                                   dcrocker@brandenburg.com
Sunnyvale CA 94086 USA                         http://www.brandenburg.com

Internet Mail Consortium                 http://www.imc.org, info@imc.org