Re: FYI: BOF on Internationalized Email Addresses (IEA)

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>