Subject: Re: [idn] Re: Is space allowed in a hostname?

From: Dan Oscarsson <[email-masked]>
Date: Tue, 09 Jul 2002 15:46:19 +0200

>From: John C Klensin <[email-masked]>

>That said, I claim that I do understand the issues and that
>several other people in the WG also understand them and have
>understood them more or less all along.  And, based on that
>understanding, I don't believe that revisiting NFKC is going to
>get us anywhere.  That isn't because NFKC is right or wrong, but
>because its selection involves tradeoffs, that _no_ alternative
>is without similar tradeoffs, and that there are no rational
>criteria for selecting one set of tradeoffs over another.  

It may be to late to do something about NFKC. NFKC is difficult and
at least I have never gotten any answer from those I have asked what
NFKC changed compared to NFC. I have therefore tried to read the
Unicode tables to see what it means, and I do think it goes to
far for domain names.

As IDNA combines this with lower caseing using the Unicode "full
lower casing" which results in for example German s sharp into ss,
we get an even worse situation.

While it could be OK for IDNA to use this definition of
domain names and matching of them, I is bad if makes it
impossible to use a standard based on NFC and rules
allowing for example German s sharp to not match ss, in
a new class or other technique to get UCS into DNS.

I have seen drafts refering to IDNA/NAMEPREP to define
what characters are allowed in a domain name. That is bad as
it makes it difficult for us to change things later on.

    Dan

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Jul 2002 11:13:29 -0400

> a new class or other technique to get UCS into DNS.

Dan,

It seems to me that there are two separate issues here, which
ought to be separated.   Let's suppose we go down the "new
class" path, more or less as outlined in my draft (just because
it is the only I-D in the pile, not because it is either
complete or correct).  Other examples could fit equally well,
but would be harder for me to explain.

Issue #1 is whether we can have internationalization in that
Class and not use IDNA (or, given Eric's distinction, not using
IDNA-with-nameprep).  The answer had better be "yes", or we are
in serious trouble.   I have made repeated suggestions that IDNA
be explicitly narrowed so that it does not apply to Classes (and
maybe RR labels) that have not been invented yet.  That change
is intended to make sure we don't run into "I already have a
conforming legacy use that your changing away from IDNA will
destroy" complaints or other problems with defining such a Class
in an appropriate way.   I think that fix is easy, beneficial,
and, with regard to anything now being contemplated, harmless
and that we should just make it.

Issue #2 is whether such a new Class specification would be
stuck with the current definition of stringprep, even if it
didn't use IDNA (or IDNA-with-nameprep).  While I would hope
that the answer would be that stringprep would be usable, it is
ultimately just a reference list of tables and transformations.
That implies that a new protocol specification could, if needed,
reference a different (not-in-stringprep) table if that were
sufficiently important, or we could harmlessly add more tables
to a stringprep-bis without impacting nameprep at all.

So, while I am worried about the first issue --i.e., making sure
we don't overconstrain ourselves for no good reason-- I don't
see the second as being a big issue right now.  When there are
proposals to do other things, let's see what they need and act
accordingly.

And, if NFKC doesn't seem to be appropriate for those
hypothetical future approaches, then I would encourage you, and
anyone else who is interested, to try to convince the Unicode
Consortium of that observation and to try to get them started on
a different normalization table with different rules and
different applicability.  I don't think it is likely that the
IETF will be convinced to base a protocol on a table no one has
produced, nor that it will be willing to start producing its own
tables of this sort, but, if there were a different choice that
were well-defined, I think you could get people to look at it.

     john

---

From: Soobok Lee <[email-masked]>
Date: Wed, 10 Jul 2002 01:07:54 +0900

On Tuesday 09 July 2002 22:46, Dan Oscarsson wrote:
 
> far for domain name.

By definition, NFKC = "compatibility decomposition" + NFC .
This "compatibility decomposition" can be partitioned into
groups of script-specific compatibility equivalences, and IMO, each group 
has its own degree of appropriateness in the context of domain name.
For example, only with NFKC, compatibility  ideographic character (Kc)
can be mapped to its equivalent unified ideographic character (Ku).
Kc and Ku share the same glyph, but often have different readings and origins. 
That  mapping is OK. However, NFKC does not unify a certain pairs of TC/SC 
which are purely in font-variant relations (like between italic/subscript A 
and normal A) and share the same meanings and readings.
When applied to hangul compat jamos (u+33??), NFKC makes errors.
When NFKC maps circled "A" into bare "A", it may be useless or unnecessary
in domain name context.

Ideal IDN name normalization was carved to fit in NFKC.
"if you sleep in a bed which is shorter than you, you should bend your 
legs every  night ?  or  buy new bed ?"  Stringprep/nameprep teach us
to bend our legs.  :-)

Soobok Lee

---

From: John C Klensin <[email-masked]>
Date: Tue, 09 Jul 2002 13:00:25 -0400

--On Wednesday, 10 July, 2002 01:07 +0900 Soobok Lee
<[email-masked]> wrote:

>....
> groups of script-specific compatibility equivalences, and IMO,
> each group  has its own degree of appropriateness in the
> context of domain name. For example, only with NFKC,
> compatibility  ideographic character (Kc) can be mapped to its
> equivalent unified ideographic character (Ku). Kc and Ku share
> the same glyph, but often have different readings and origins. 
> That  mapping is OK. However, NFKC does not unify a certain
> pairs of TC/SC  which are purely in font-variant relations
> (like between italic/subscript A  and normal A) and share the
> same meanings and readings. When applied to hangul compat
> jamos (u+33??), NFKC makes errors. When NFKC maps circled "A"
> into bare "A", it may be useless or unnecessary in domain name
> context.

Ok.   We have established, if it wasn't obvious already, that
NFKC is an easy target.   That doesn't make it "wrong", it just
means that, in the tradeoff decisions that were made, some of
the consequences may be unfortunate for particular applications
and/or languages.  

But being able to explain what is wrong with it when viewed from
particular perspectives does not, ultimately, help.  There are
two things that are much more important:

(i) Demonstrating that there is a variant of NFKC (or something
else that does the same job) that is better across the entire
range of scripts and languages, not just a scripts or two or a
handful of characters.

(ii) Getting that variant reviewed and approved by a recognized
standards body with global scope and competence to do this type
of evaluation.  My guess is that the IETF is no closer to taking
on that role than it was a half-dozen years ago, i.e., no chance
at all (and for the same good reasons).

Absent such a proposal, in written form, and significant motion
toward approval by such a standards body, it is nearly a waste
of time to complain about NFKC: "no alternative" unfortunately
outvotes all other possible answers.

> "if you sleep in a bed which is shorter than you, you should
> bend your  legs every  night ?  or  buy new bed ?"
> Stringprep/nameprep teach us to bend our legs.  :-)

Bending is far better than the version in which your legs are
simply cut off to fit.

regards,
    john