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

Keith Moore <[email protected]> wrote:

> > The current parsing rules allow only ASCII characters, so the rules
> > are going to have to change.
>
> uh, no. putting anything other than ASCII characters in email headers
> is completely unacceptable.

IMAA does *not* put anything other than ASCII characters in email
headers.

Did you stop reading my message right there?  What immediately followed
should have allayed your concern:

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

    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.

If internationalized mail addresses are going to be internationalized
in any sense, then they need to contain non-ASCII characters in some
circumstances.  Not in message headers, but at least in user interfaces.
Wherever non-ASCII addresses are used (not in messages headers), that's
where the new parsing rules will be needed.

Dave Crocker <[email protected]> wrote:

> AMC>          2) Whenever a mail address (or part of a mail address)
> AMC>             is put into an IMA-unaware mail address slot (see
> AMC>             section 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.

IMAA does not expect MTAs to conform to IMAA, or even be aware of IMAA.

IMAA is designed so that software that conforms to IMAA and software
that does not conform to IMAA can interoperate.  Software that does not
conform to IMAA is assumed to see the world in pre-IMAA terms: mail
addresses are ASCII, as specified in all prior standards.

Every piece of mail-related software has the option to continue to abide
by the old rules only, or it can adopt IMAA and abide by its rules too.
There is no meta-requirement that any piece of software must adopt IMAA,
there is merely an incentive: if you don't adopt IMAA, you don't get to
have non-ASCII characters in mail addresses.  For MTAs, which don't come
into contact with regular users, that's not a great incentive.  Regular
users would be perfectly content in a world where MUAs adopt IMAA and
MTAs don't.

This high-level view is not presented in the IMAA draft, but it is
presented in the first two paragraphs of the IDNA spec (RFC 3490), which
the IMAA draft incorporates by reference:

    This document relies heavily on IDNA for both its concepts and
    its justification.  This document omits a great deal of the
    justification and design information that might otherwise be found
    here because it is identical to that in IDNA.  Anyone reading this
    document needs to have first read [IDNA], [PUNYCODE], [NAMEPREP],
    and [STRINGPREP].

Perhaps a future revision of the IMAA draft should copy more of this
material from IDNA.

> AMC>             Given an internationalized mail address, an
> AMC>             equivalent mail address satisfying this requirement
> AMC>             can be obtained by applying ToASCII to the local part
> AMC>             as specified in section 4, changing the at-sign to
> AMC>             U+0040, and processing the domain name as specified
> AMC>             in [IDNA].
> AMC> The mail addresses in message headers are in IMA-unaware slots,
> AMC> and therefore they remain ASCII-only, using the exact same syntax
> AMC> they've always used.  IMAA deliberately makes no change to any
> AMC> existing 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.

The message header protocol is not changed.  It has the exact same
syntax and semantics as it always did.

There are two mail address protocols: ASCII-only mail addresses as
defined by RFCs 821, 822, 2821, 2822; and internationalized mail
addresses as defined by IMAA.  The new address protocol may be used
only in new places (like new user interfaces and new protocols), while
the old address protocol must continue to be used in all the existing
places (like message headers and SMTP commands).  Any software that
deals with both address protocols acts as a gateway, and implements the
gateway functions specified by IMAA.  (I don't mean a mail gateway in
the RFC 1123 sense, just a protocol-to-protocol gateway in the general
sense.)

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

In this case they are.  Section 3.1 "Requirements" *is* the IMAA
protocol.  Sections 2 "Terminology" and 4 "Conversion operations" are
supporting sections that define the terms used in section 3.1.  In
particular, section 4 is just a detailed definition of the terms
"ToASCII" and "ToUnicode".

AMC