Dave Crocker <dhc(_at_)dcrocker(_dot_)net> wrote:
AMC> The current IMAA draft requires that full-width "@" be recognized
AMC> as a separator between the local part and the domain part
In spite of reading the imaa spec a number of times, I entirely missed
that bit of subtlety.
It's the first requirement listed in section 3 "Requirements and
3. Requirements and applicability
IMAA conformance means adherence to the following four
1) In an internationalized mail address, the following
characters MUST be recognized as at-signs for separating the
local part from the domain name: U+0040 (commercial at),
U+FF20 (fullwidth commercial at).
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.
The current parsing rules allow only ASCII characters, so the rules
are going to have to change. But they can be changed without breaking
things. IMAA is based on the principle of not breaking things. That's
where requirement 2 comes in:
2) Whenever a mail address (or part of a mail address) is
put into an IMA-unaware mail address slot (see section
2), it MUST contain only ASCII characters. Given an
internationalized mail address, an equivalent mail address
satisfying this requirement can be obtained by applying
ToASCII to the local part as specified in section 4,
changing the at-sign to U+0040, and processing the domain
name as specified in [IDNA].
The mail addresses in message headers are in IMA-unaware slots, and
therefore they remain ASCII-only, using the exact same syntax they've
always used. IMAA deliberately makes no change to any existing
Requirement 1 has an effect only in places where non-ASCII mail
addresses are allowed, like user interfaces and new protocols.
Simplicitly facilitates adoption and interoperability. Multiple forms
for the same syntactic constructs do not make for simplicity.
True, but sometimes it makes sense for computers and computer
programmers to work harder in order to make things easier for the users.
In IDNA, it was decided that it would be too annoying for CJK users to
have to switch input modes back and forth for every dot in a CJK domain
name. The same rationale applies to the at-sign in email addresses.