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

Dave Crocker <[email protected]> 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
applicability".

    3. Requirements and applicability

    3.1 Requirements

        IMAA conformance means adherence to the following four
        requirements:

         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
protocol.

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.

AMC