Re: [EAI] Extending IDNA to email

[Nick Teint <[e-mail]>]

2010/3/25 Charles Lindsey <[e-mail]>:
> On Wed, 24 Mar 2010 16:03:03 -0000, Nick Teint <[e-mail]> wrote:
>> That's correct. However, this limitation only applies to addresses
>> that contain non-ASCII characters. IMO it's not worthwhile to preserve
>> case-sensitiveness (which is retained "just in case" there's a system
>> that still needs it) for an expansion of the address space.
>
> I cannot see that is a satisfactory response. RFC 5321 makes it clear that a
> local-part is entitled to be conveyed case-sensitively. It is not a matter
> of "just in case" the final agent needs it - the final agent has absolute
> discretion to insist on it (unless and until RFC 5321 is revised to say
> otherwise).

Most final agents do not insist. The reason RFC 5321 still has this
requirement is backwards compatibility, "just in case".

X-IDNA does not remove this requirement for existing ASCII addresses.
A final agent can insist that the local-part it's being sent is
exactly "xn--Mller-kva" and treat it differently from "xn--mller-kva".
It just can't insist that a used who types "Müller" (German for
"Miller") will end up sending mail to "xn--Mller-kva"; user agents
would usually map "Müller" to "müller" and then to "xn--mller-kva".

Actually, X-IDNA *is* case-sensitive, just as IDNA2008: The mapping to
lowercase is considered a local matter, described in "Mapping
Characters in IDNA" (draft-ietf-idnabis-mappings-xx). If you don't do
it, the conversion to Punycode is case-preserving. Then, however, it
gets complicated: A case-insensitive comparison based on the ASCII
form will compare ASCII chars (encoded as-is in Punycode)
case-insensitively but non-ASCII (encoded as lower case ASCII chars)
chars case-sensitively. Further, case-insensitive comparison is not
well-defined in Unicode and depends on the locale (in Turkey, I/ı and
İ/i form pairs; in Germany, there's ẞ/ß/ss/SS; in France, there's
E/é/è/ê; etc.)

IDNA2008 (much unlike IDNA2003) avoids this mess by assuming that all
internationalised addresses are in lower case. However, this
assumption is not part of the core protocol but an assumption that can
be used by applications when mapping user input to useable strings.
The protocol only requires NFC.

This approach would also work with EAI (UTF8SMTP):

- User Agents are expected to do any mapping. They may take the user's
preferences and expectations into account.
- Mail Handling Services do not do any mapping
- "Registries" should not create local-parts that are unwise, i.e.
that contain characters commonly mapped to other characters
(upper-case letters, chars with a canonical decomposition, etc.)

- In UTF8SMTP, Mail Handling Services MAY complain about non-NFC characters.
- When downgrading using X-IDNA, Mail Handling Services do convert to
ASCII but they do not do any further mapping.

> AFAIR, our EAI extension still preserves that requirement (but
> now it applies to lots of new characters which may well have alternative UC
> and LC versions). So your method could not be used as a downgrade mechanism
> for EAI addresses.

EAI is currently silent about case-sensitivity or mapping.

However, future revisions of EAI will have to approach this issue, as
seen by this example:
Bob wants to send an email to Abdülmecid <abdü[e-mail]>. He
types the email address as "ABDÜ[e-mail]", expecting that
case does not matter. The mail bounces. While Abdülmecid's ISP does
indeed match local-parts case-insensitively, it is located in Turkey.
So it treats "ABDÜLMECID" as equivalent to "abdülmecıd" but not
"abdülmecid".

NT