[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] WG last call documents



"Eric A. Hall" <ehall@ehsco.com> wrote:

> The i18n "domain name" specification needs to allow any valid UCS
> character code,

You might be able to argue that it should allow all valid code points,
but I don't see why it's *necessary*.  Since IDNA will be the first
specification to say anything about Unicode characters in domain names,
later specifications will know exactly which code points they must live
without.  It's not as if IDNA's prohibitions will cause incompatibilites
with existing IDN-related standards.  New IDN-related standards will
cause incompatibilities if they attempt to use code points prohibited by
IDNA.

> and must not be restricted to hostname characters.

Domain names in IDNA are not restricted to host name characters.  Only
host names are.  See step 3 of ToASCII.

(If you're concerned about the ASCII control characters and space, which
indeed are prohibited in the current Nameprep draft, then relax, we've
seen the flaw, and those prohibitions are being removed.)

> However, mailbox names are often stored in DNS labels, and under the
> current arrangement, those mailbox names would be normalized and
> lowercased as part of this process.

This problem already exists to some extent with ASCII mailbox names.
Sticking an ASCII mailbox name (which is allowed by RFC 822 to be
case-sensitive) in a domain label (which is defined by RFC 1035 to be
case-insensitive) is already a dubious proposition.

> In essence, the rules which are currently provided impose restrictions
> on any future mailbox name designs which the representative working
> group may come up with in the future.

The email working group has at least two options:  They can either
take IDNA (which was designed for domain labels) and apply it as-is to
mailbox names (even though it wasn't designed for that) and live with
the implications, or they can define their own way of representing
internationalized mailbox names as ASCII strings (which might bear some
resemblance to IDNA and might reuse components).  Either way, they will
interoperate with IDNA just as well (or as badly) as ASCII mailbox names
interoperate with ASCII domain names today.

> there should be a different stringprep profile for i18n "domain names"
> than for "host names"

There effectively is.  Nameprep is the profile for domain names, and
ToASCII adds a few more restrictions for host names.

The case-folding of all domain names (not just host names) is consistent
with the existing DNS, which uses case-insensitive matching for all
domain names (not just host names).

AMC