Re: Off-topic: @
Bruce Lilly <[email protected]>
| Newsgroups | gmane.ietf.rfc822 |
|---|---|
| Organization | Bruce Lilly |
| Message-ID | <[email protected]> |
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@atatatatatat or atat@atatatatat or atatat@atatatat ... or at@atat@atatat or 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@Rand-Unix were spoken identically.