On Thu October 6 2005 15:33, Dave Crocker wrote:
Paul Hoffman wrote:
It probably seemed so simple when we started using it...
Since the original form was both "@" and " at " it wasn't all that
simple, even then. Having to parse several characters ahead, for
detecting the mailbox/host separator, was a royal pain in those days.
Not at all clean.
Worse than that. The original (see RFC 561) was <SP> AT <SP> only, and
space was subsequently permitted within words (RFC 724 et seq until RFC
2822 eliminated it) or even within atoms (RFC 733 et seq ...), so
at at at at at at at at
could be
at(_at_)atatatatatat
or
atat(_at_)atatatatat
or
atatat(_at_)atatatat
...
or
at(_at_)atat@atatat
or
at(_at_)atatat@atat
...
(RFC 733 routing, syntax subsequently changed by RFC 822)
The original " at " coupled with subsequent introduction of space
within words and of routing led to unresolvable parsing ambiguities -- no
amount of lookahead would help. Good riddance to " at ". The commercial
at symbol was introduced in either RFC 680 or 724, and " at " and @ were
considered equivalent (modulo the unresolvable ambiguities noted above)
until RFC 822 eliminated " at ".
And with the DNS and ISO country code TLDs, the situation could have
become worse (at is the ISO country code domain for Austria).
It wasn't until RFC 822, a dozen years after RFC 561, that the problems
with " at " were removed from the specification. The original form
having been <user> <SP> AT <SP> <host>, the change to the commercial at
symbol WAS a simple and natural way to resolve the ambiguities that
cropped up (and remember, we're talking about the ARPANET days, so
there were none of the charset/language/naming issues to whine about).
DCrocker at Rand-Unix and DCrocker(_at_)Rand-Unix were spoken identically.