Adam,
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.
AMC> It's the first requirement listed in section 3 "Requirements and
AMC> applicability".
Sorry for expecting to garner all the rules from the normative syntax and
algorithm section. I'm not used to having to look into a Requirements
sections to understand basic parsing rules.
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.
AMC> The current parsing rules allow only ASCII characters, so the rules
AMC> are going to have to change. But they can be changed without breaking
AMC> things. IMAA is based on the principle of not breaking things. That's
AMC> where requirement 2 comes in:
AMC> 2) Whenever a mail address (or part of a mail address) is
AMC> put into an IMA-unaware mail address slot (see section
AMC> 2), it MUST contain only ASCII characters.
You put a great deal of effort into designing features that work around the
delivering MTA's not knowing that it is dealing with IMAA. Yet now you are
requiring that knowledge.
AMC> Given an
AMC> internationalized mail address, an equivalent mail address
AMC> satisfying this requirement can be obtained by applying
AMC> ToASCII to the local part as specified in section 4,
AMC> changing the at-sign to U+0040, and processing the domain
AMC> name as specified in [IDNA].
AMC> The mail addresses in message headers are in IMA-unaware slots, and
AMC> therefore they remain ASCII-only, using the exact same syntax they've
AMC> always used. IMAA deliberately makes no change to any existing
AMC> protocol.
It looks to me like you very much _do_ make a change. The fact that you then
hope some component will do an equivalence to regular at-sign does not alter
this.
AMC> Requirement 1 has an effect only in places where non-ASCII mail
AMC> addresses are allowed, like user interfaces and new protocols.
Requirements are not protocol specifications.
Simplicitly facilitates adoption and interoperability. Multiple forms
for the same syntactic constructs do not make for simplicity.
AMC> True, but sometimes it makes sense for computers and computer
AMC> programmers to work harder in order to make things easier for the users.
If RFC2822 and RFC2821 were user interface specifications, I might agree with
you.
d/
--
Dave Crocker <dcrocker-at-brandenburg-dot-com>
Brandenburg InternetWorking <www.brandenburg.com>
Sunnyvale, CA USA <tel:+1.408.246.8253>