Re: [idn] IDN refocus, v4

["Eric A. Hall" <ehall@ehsco.com>]

James Seng/Personal wrote:

> i18n domain names - any unicode characters

Any UCS character code (including codes without character representations)

> i18n host names - i18n domain names subjected to prohibited list defined
> in Section 5 of nameprep (host names limitation, space characters,
> control characters, private use, etc)

Must specify normalized characters as the valid range. Non-normalized
characters are valid in domain names but for host names only the
normalized equivalents are valid.

Upper and lowercase have to be valid. Note that my draft required
lowercasing for protocol operations and comparisons although for other
operations the case is not relevant, and the case-neutral "host name"
concept has to be preserved at the end-system applications (regardless of
what happens in the network).

> but is i18n host name sufficient for normal use? as technical
> implementation, maybe. for policy implementation, unlikely. perhaps we
> need a new term for that...

I used the terms STD13 Domain Name, STD13 Host Identifier,
Internationalized Domain Name and Internationalized Host Identifier, which
may be suitable.

> TES is an encoding. CES is an encoding. I am asking if we need more than
> one encoding (either TES or CES). That is my first question.

As stated, I believe that we need 7- and 8-bit TES because the transfer
media offer 7- and 8-bit paths, and it would impose inefficiencies on
those services to choose only one or the other.

> If the answer is that we need more than one encoding, then the next
> question would be how many separate cases do we have, ie, how many
> encodings do we need? (I could argue it is more "fair" to use UTF-32 in
> EDNS labels)

We only need two to start with, since we only have 7- and 8-bit media to
worry about at the moment.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/