Adam,
RB> For instance, one of the issues that has been discussed on the
RB> IMAA list is whether full-width at should be recognized in an
RB> internationalized mail address.
full-width _where_?
AMC> Roy was using the word "at" not as a preposition, but as the name of a
AMC> character.
AMC> The current IMAA draft requires that full-width "@" be recognized
AMC> as a separator between the local part and the domain part of an
Oh.
In spite of reading the imaa spec a number of times, I entirely missed that
bit of subtlety.
1. Herein lies a useful meta-lesson about the benefits of starting with the
narrowest scope possible: It helps uncover different expectations.
2. As to the particulars of idea of allowing a second separator, let me
suggest that breaking existing Internet mail will not be conducive to global
adoption. And altering the parsing rules for addresses is a good way to break
Internet mail.
This disparity also suggests a confusion between user presentation, versus
interchange format. It is occasionally noted that the problem with having data
be so "directly" readable by users is that people think they are looking at a
user presentation format. Alas, RFC2822 and RFC2821 are about
computer-to-computer interchange, not human presentation. (There is quite a
bit of human-to-human interchange, particularly in 2822, but that is different
from human presentation.)
For those with any interest in history, I'll note that we used to allow a
second separator (" at ") between local-part and domain, but simplified it 20
years ago, to keep the parsing simpler.
Simplicitly facilitates adoption and interoperability. Multiple forms for the
same syntactic constructs do not make for simplicity.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>