Subject: Re: [idn] Problems in normalisation and matching

From: Dan Oscarsson <[email-masked]>
Date: Tue, 02 Jul 2002 08:30:53 +0200

>First, the Nameprep/Stringprep is designed to handle domain names on a _per
>label_ basis. Before some IDNs going thru Nameprep, it is already broken up
>into its individual labels so Nameprep arent the place to fixed.
>
>The place where IDNs get broken down into label is in IDNA. What IDNA now
>specify is that to break down IDNs into their label, you look for this set
>of separators (U+002E, U+3002, U+FF0E, U+FF61). (See IDNA Requirement 1)
>

IDNA does define how to handle labels, not complete domain names.

A domain name can be used in many places and are included in many
protocols. For example it is used in HTTP, SMTP and HTML.

Today there exist many restrictions on "hostnames" due to simplify
handling of domain names by software and make them easier to
identify by users. To make this possible the restrictions
do not allow normal separator characters in a name and have labels
separated by ONE separator character.
Now when we expand the allowed characters in a domain name, then
allowed characters and syntax should follow the same rules:
- The labels of a domain name is separated by "full stop" U+002E
  and are written from left to right with least significant label
  first.
  Other characters or display form may be used in user interfaces
  but have to be converted into standard form in protocols.
- Separator characters like SPACE (U+0020) may not be used.
  (this results in that a domain name cannot use NFKC as it
   decomposes non-spacing accents into a space character followed
   by a combining accent making simple parsing difficult).

It is important to separate the standard way a domain name is written
in protocols from the free form way it can be written when
interacting with users. In protocols we want a form that can easily
be parsed and identified.

   Dan

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 2 Jul 2002 14:35:53 +0000

>   but have to be converted into standard form in protocols.

IDNA says virtually nothing about how IDNs are to be represented in
new protocols.  New protocols can use the ASCII representation, or an
unconstrained Unicode representation (like UTF-8), or can define their
own more restricted representation (for example, nameprepped UTF-8 using
only U+002E as separator).

Although IDNA says that the other dot characters must be recognized as
dots, it does not say that they must be allowed in new protocols.  If a
new protocol forbids the other dot characters, recognizing them as dots
will be a no-op.

IDNA says that old protocols must use the ASCII representation, using
only U+002E as dots.

There has never been a consensus on a particular non-ASCII
representation for use in new protocols, and we don't need one in order
to start deploying IDNA.  That's why IDNA is silent on that issue.

AMC