Subject: RE: [idn] Fast nameprep vs. slow nameprep

From: Karlsson Kent - keka <[email-masked]>
Date: Thu, 1 Feb 2001 14:25:54 +0100

I'm not sure where the idea of doing "nameprepping" in the keyboard
'interface' came from. I'm not sure what interface is meant here,
but it appears that "the same level(s) as where dead key handling
and IME switching is done" is what's intended.

I find any suggestion to do "nameprepping" or even "ACE"ing in the
'keyboard interface' to be out of the question.  Do you expect system
providers to make a special "IDN mode" for the keyboards?  Why?
And why would that solve anything?  If you paste in text, the keyboard
handling is not involved after the "cmd-v" (or whatever). Why should
the keyboard handling be changed to map out soft hyphens (alt-- on
some keyboards), and map Å to å in some new "IDN mode"? Do you expect
some "automagic" switching between these modes? Or is Joe User
expected to change to "IDN mode" for entering IDNs (and out again
after)? Neither will work!

Can please the keyboard interfaces be left out of this discussion.
It's far out of scope for the IDN WG.  "nameprepping" must be done
at some other place than in the keyboard handling!

		/kent k

> -----Original Message-----
> From: D. J. Bernstein [mailto:[email-masked]]
> Sent: Tuesday, January 30, 2001 10:22 AM
> To: [email-masked]
> Subject: Re: [idn] Fast nameprep vs. slow nameprep
> 
> 
> There are five possible approaches under discussion:
> 
>    (1) [...]
>        The keyboard interface has to help users type good names.
...
> 
>    (2) [...]
>        This lets us leave the keyboard interface alone, at the expense
>        of putting nameprep into a huge number of programs. Yuck.
...
>    (3) [...]
>        The keyboard interface has to help users type good names.
...
>    (4) [...]
>        The keyboard interface has to help users type good names and
>        convert them to ACE.
...
>    (5) [...]
>        This lets us leave the keyboard interface alone.

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 1 Feb 2001 08:53:55 -0800

I agree that the term is confusing. I think part of the issue is that
different people may have different usage models in mind. Let's look at some
specific scenarios, starting with a browser. This might reveal where we have
different models in mind.

Scenario A.
User opens browser, types in the URL in the Address field, hits return.
  - S/he has typed in using some default character set.
Browser takes contents of Address field, and:
1. Converts to UTF-8 if not already
2. Applies NamePrep to the results, field at a time.
  - If something is wrong, signals to user and stops.
3. Applies *ACE to result, field at a time.
  - If something is wrong, signals to user and stops.
4. Uses the results as it would have formerly.

Scenario B.
A web page contains a link such as

<a href="http://標準萬國碼.Юникод.org/Ιούνικοντ.html">Hotel Reservation Form</a>

[The non-latin text examples are not real -- just for the sake of example.]

When the user clicks on the visual representation of this link, the browser
will take the URL and apply NamePrep/*ACE (signalling if the result is
invalid) as above.

Scenario C.
A web page contains a link such as

<a href="http://bq--xyz.bq--rmp2.Ιούνικοντ/Юникод.html">Hotel Reservation
Form</a>

[The ACE examples are not real -- just for the sake of example.]

This is an interesting case. In processing a URL field by field, if a field
already contains an ACEd result, the browser could leave it alone. If it is
not valid, it will not match a host name. A somewhat user-friendlier
approach would be to check it for NamePrep/ACE validity and signal that at
an earlier stage.

Note: From what I recall of the discussion, given a URL like
href="http://標準萬國碼.Юникод.org/Ιούνικοντ.html">, the browser would only apply
NamePrep/ACE to "標準萬國碼.Юникод.org", and NOT to "Ιούνικοντ.html". The segment
"Ιούνικοντ.html" would represented by encoded in UTF-8, with any bytes
outside of [21..7E] using %xx notation.
[http://www.w3.org/TR/charmod/#sec-URIs]

Mark

----- Original Message -----
From: "Karlsson Kent - keka" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, February 01, 2001 05:25
Subject: RE: [idn] Fast nameprep vs. slow nameprep

/kent k

...
...
...
...

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Feb 2001 13:29:43 -0500

note that in the case of your scenario B - a URL within a web page
will be in the document character set, which might or might not be
UTF-8.  so it might also need translation in addition to nameprep
and ACE.

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Feb 2001 23:29:51 -0000

Karlsson Kent - keka writes:
> Do you expect system
> providers to make a special "IDN mode" for the keyboards?

It seems that no effort is necessary for European locales: the existing
keyboard interfaces already produce KC-normalized strings.

(I have no idea why you're worried about soft hyphens. Why would a user
type a soft hyphen inside a domain name? The keyboard interface doesn't
have to remove them; they simply won't work.)

In Japan, on the other hand, we've heard that users already have to
change keyboard modes to type domain names. Otherwise they don't even
get the right dot!

> If you paste in text,

Good UTF-8 domain names will be preserved by copy-and-paste. There's no
need for further nameprep.

> It's far out of scope for the IDN WG.

Wrong. The whole point of IDNs is to let users read and write non-ASCII
characters in domain names. The entire path from keyboard to computer to
screen---as the charter says, ``the use of such names by humans''---is
within the scope of the IDN WG.

---Dan

---

From: Dan Ebert <[email-masked]>
Date: Thu, 01 Feb 2001 17:40:05 -0800

> UTF-8.  so it might also need translation in addition to nameprep

It seems to me that there would also be a possible (probable?) need for
translation from an OS character set (Big 5, GB 2312, ISO8859-x, etc.)
to UTF-8  (and to ACE?) when a user types a multilingual domainname into
a browser's location bar.

-- 
Dan Ebert    [email-masked]    eNIC Corporation

---

From: Keith Moore <[email-masked]>
Date: Thu, 01 Feb 2001 20:50:20 -0500

> a browser's location bar.

I concur.

Keith

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 2 Feb 2001 10:16:30 +0800

I suggest reading the I-D IDNA (or IDNRA) draft. This issue has been
discussed in the I-D.

-James Seng

---

From: [email-masked]
Date: Thu, 1 Feb 2001 21:20:34 -0500 (EST)

I just got back from a weeklong vacation in japan. It seems to me that
everyone I met there gets email thru their cell phone. Text entry is menu
based with kanji selected via a joystick like nub.

Possible issues include;
How much memory does an implementation of name prep require?
What encoding do these wireless devices use?
Can they even handle ACE?
Should we even worry?

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 2 Feb 2001 10:39:15 +0800

You have underestimated the capability of the phone.

Put it this way. If a phone can handle input in romanji with fonts for a
few thousand kanji using a 12-key number pad, with 120x320 TFT color
screen capable of doing java and games and video conferencing, I am not
sure if nameprep is an issue should they decided to do it.

-James Seng

---

From: "James Seng/Personal" <[email-masked]>
Date: Fri, 2 Feb 2001 10:38:17 +0800

Put it this way. If a phone can handle input in romanji with fonts for a
few thousand kanji using a 12-key number pad, with 120x320 TFT color
screen capable of doing java and video conferencing and gaming, I am not
sure if nameprep is an issue should they decided to do it.

-James Seng

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 1 Feb 2001 19:54:16 -0800

I believe I sent this out before, but just in case people hadn't seen it:

http://www.macchiato.com/unicode/normalization_footprint.htm

Mark