Subject: [idn] Re: [idn-nameprep] nameprep and others: hangeulchar

From: John C Klensin <[email-masked]>
Date: Tue, 28 Aug 2001 08:40:50 -0400

--On Tuesday, 28 August, 2001 12:48 +0900 Martin Duerst
<[email-masked]> wrote:

>...
> Overall, I think you are arguing on the base that fillers will
> only be used together with Hangul. But what if people find out
> that they can use it as a kind of space in other scripts?
>...

Just to reinforce Martin's question a bit, _this_ is one of the
key questions of which I fear we keep losing sight as we look at
languages (or even scripts) one at a time.  (Full IDN list
included, since I think there is a general principle here that
everyone should think about.)

Unless we write rules that I think would be unbelievably
complicated and ultimately unsuccessful, the implication of using

	* [most of] Unicode and
	
	* no language tagging on either queries or registrations

is that, if
    L is a character from Latin-1
    C is a character from a Cyrillic script
    H is a character from a Han script
    A is a character from an Arabic script
    K is a katakana character
each of them chosen without restriction from the characters of
those scripts that we permit,

nothing is going to prevent labels of ECHAK, or any of its
permutations.  And, in particular, as Martin indirectly
suggests, if we permit Jamo fillers ("f" below), or Arabic
breaks (non-joiners, "n"), we will almost certainly see
    LLLfLLLL  and
    CCCnCCCC
as people figure out that things they can think about as
embedded spaces are "better" than funny case rules for
catenating multiple-word phrases.

I also just realized (most of you are probably ahead of me),
that I have no idea how LLLAL (or HHHAH) would be rendered if
the character chosen for "A" has different glyphs depending on
its joining position.  But, fortunately, that one is not our
problem.

Arggh.
   john

---

From: "Mark Davis" <[email-masked]>
Date: Tue, 28 Aug 2001 09:35:40 -0700

Well, ECHAK.com (with the substituted characters) wouldn't make much sense.
But neither do the currently permissible following names (generated
randomly):

9XGD5RY4PT0ZAVD7BD3WFBZV4BPJMCRKVWNJBWUPW5SK5BC71E34SG3TF3GZY5Q.com
QWHU884UNCUFTAZLP5P4ZSLKZSYRU5AGS5QLHLRZWVKV3EZXXXE3IHEJCQ0K5AJ.com
H6L8JGU2WKV1RDHYSXBD64Q421T1CRSWPR79RRB0EHATZ23AOIMMB8KKK4NBOA1.com
AZ733L21J15Q2JE2V4XYK5Y4AQJ3I5K2E5OOMFXFQ7TOVBLF4GCJYY3F7PFS5EY.com
ON1HB4ZZEP9XCKNQJ3D2BQ0FM79OU1NEMIYB5FR6R84OBCJJHVAH1781JBKMY18.com
A96FH1ASKQ0W1V8MOQD8PDNWBARY2I5JU4A0IZWGYT2YS5A1308T49WTN9P2L4R.com
4N6YFZNQP7W9ZZYWTNIZKJRFJTFP44F60GW84M5SNGJ7QGIH986GH7SG1JMZPJ1.com
GI5XHTM3Q2SMHGXKGTNIJQBHJG1EJDSQDX6TCH5WKH53V4ZV9YAB5TUH685YNX6.com
3PS2XQFCELAB75GHOXLQZ9SAQWCIDOQU2U62Y4S7LB8EORL8QNFKRIR0BBY1Y2A.com
I3HFH8772PW3CE4NY7MVPITUNOS7Q3I4LBOZNLKM2JSMU8VS9ACWQKBYW10BJ5J.com

The questions we need to focus on are:

- matching. Do two strings represent the same underlying abstract
characters?
- prohibition. Which are the characters that are clearly unsuitable for
inclusion in IDNs.

I believe, as I have said before, that it is too difficult to separate out
the legitimate mixes of scripts and symbols from the 'questionable' ones for
us to do anything. And adding language tags would simply make it more
complicated, not less. (How much good does it do me to know that the second
of the above is French, not German?)

There are tricky edge cases that we need to discuss or get help with. But we
can't let the edge cases prevent us from delivering the 99.9999% solution.

For fillers and joiners, there are a reasonable solutions on the floor. One
may be optimal, but many will work just fine.

Mark
—————

Γνῶθι σαυτόν — Θαλῆς
[http://www.macchiato.com]

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Aug 2001 10:14:22 -0700

At 05:40 AM 8/28/2001, John C Klensin wrote:
>permutations.

Why is it the job of an iDNS standard to prevent users from defining silly 
strings, as long as the strings do not break the DNS?

At 09:35 AM 8/28/2001, Mark Davis wrote:
>complicated, not less.

exactly correct.

Too difficult and, to paraphrase Jeff Case, simply not our problem.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: Dan Ebert <[email-masked]>
Date: Tue, 28 Aug 2001 10:22:15 -0700

While names like you describe (LLLfLLLL, CCCnCCCC, etc.) are possbile
... wouldn't they be rather difficult to type?  I suppose they could be
utilized as click on links, but it seems unlikely that the owner of such
a domain could reasonably expect a user to be able to enter the name in
a browser or email client, etc.  Is it easy to type a 'Jamo filler'
character from a Latin1 OS.  I don't think we should restrict/prohibit
this type of name, but I don't think we need to spend too much time
worrying about nameprep/ACE efficency issues regarding them.

-- 
Dan Ebert      <[email-masked]>       eNIC Corporation
------------------------------------------------------------
I've had a perfectly wonderful evening. But this wasn't it.
   -- Groucho Marx

---

From: John C Klensin <[email-masked]>
Date: Tue, 28 Aug 2001 13:26:11 -0400

--On Tuesday, 28 August, 2001 10:14 -0700 Dave Crocker
<[email-masked]> wrote:

> Why is it the job of an iDNS standard to prevent users from
> defining silly  strings, as long as the strings do not break
> the DNS?

Not the point.   The point is that we need to be _very_ careful
about imposing nameprep or canonicalization rules based on how
particular characters are used or sequenced, at particular
times, in particular languages because they are likely to have
unexpected effects when those characters are used in what you
call "silly strings".   And it implies that we should probably
not try to prohibit particular character sequences because the
"never occur" in normal use of the relevant script to express
the language with which it is typically used.
 
   john

---

From: Dave Crocker <[email-masked]>
Date: Tue, 28 Aug 2001 13:45:51 -0700

At 10:26 AM 8/28/2001, John C Klensin wrote:
>call "silly strings".

ahh.  indeed.  definitely.

that is why nameprep should be limited to the simplest set of rules, rather 
than trying to be sophisticated.

>And it implies that we should probably

I agree entirely!

d/

----------

---

From: Martin Duerst <[email-masked]>
Date: Wed, 29 Aug 2001 12:40:02 +0900

At 08:40 01/08/28 -0400, John C Klensin wrote:
>its joining position.

That problem has been solved, the A does not join except with
other As, so the isolated form is used. A more difficult
problem is the visual order of the letters in the case of
mixed directionality. That's a problem that we have to
identify a solution to. Please see
http://www.ietf.org/internet-drafts/draft-duerst-iri-bidi-00.txt
for a (yet far from complete) proposal. Comments appreciated.

Regards,   Martin.