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

From: Karlsson Kent - keka <[email-masked]>
Date: Fri, 2 Feb 2001 13:20:45 +0100

> -----Original Message-----
> From: D. J. Bernstein [mailto:[email-masked]]
...
> 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.

No, they don't.  I can easily enter a ¨ (a diearesis) or
a ´ (acute accent) on the keyboard, neither of which is
in KC.  Almost(!) all the letters are likely to already be
in KC, but on this keyboard I can generate µ (micro sign)
easily, and µ (micro sign) is not in KC. 

Further, "nameprepping" as it is currently specified maps
all uppercase to lowercase (nearly; it specifies an
extended form of "case *folding*" as per UTR 21, rather than
map to lowercase).  No keyboard should do that.

> (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.)

Current "nameprep" table says:

00AD; ; SOFT HYPHEN; Map out

and there may well be a soft hyphen (or zero width space) in
a URL to make it linebreak in a not too bad way when a visible
copy printed (or when printing/dispaying the source).  Soft hyphens
can (already for some; more in the future) easily be generated
from the keyboard.

> 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!

There are two issues here:

1. There is still no special mode that generates "nameprepped"
strings already from the keyboard, not even strings that are
guaranteed to be KC.

2. As I said in my previous e-mail, the entier domain name
(IDN) should be "nameprepped" before parsing on "." do get
name parts.  KC will map fullwidth full stop to full stop,
and "nameprep" may (if so decided) further map ideographic
full stop to full stop; and that before parsing into name parts
(for ACEing or whatever).  It is not reasonable to require
keyboard mode changes (by the user) for each "." typed in an
IDN. It is even more unreasonable to require new keyboard
modes (from systems providers) that generate "nameprepped" strings.

> > If you paste in text,
> 
> Good UTF-8 domain names will be preserved by copy-and-paste. 
> There's no need for further nameprep.

???

If I paste "Åre" is should sure still be "Åre" that is
pasted in.  The "nameprepped" version is different: "åre";
and *pasting* should not do any such change.

> 
> > Can please the keyboard interfaces be left out of this discussion.
> > 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.

I did participate in producing the latest Swedish keyboard
standard (soon to be published).  It does not specify any
"nameprepping", or KC mapping, nor are there any plans of ever
introducing such things even in a special keyboard mode.
Not that such modes are prevented, but nobody will expect
any such mode, and "Svensson" (Joe User...) would never
use it even in the unlikely event that some system provider
created such a mode and shipped it with the system.  

The IDN working group must *consider* keyboard input, sure.
However, it should not dream of *changing* the way keyboards
work; such things are definitely out of scope for *this* WG.

		Kind regards
		/kent k

---

From: "D. J. Bernstein" <[email-masked]>
Date: 2 Feb 2001 18:10:44 -0000

Uppercase letters will simply be prohibited by registrars. They won't
work in domain names, and users won't type them.

Exception: Uppercase ASCII will have to be allowed for compatibility.
But we don't have this compatibility constraint outside ASCII.

Karlsson Kent - keka writes:
> there may well be a soft hyphen (or zero width space) in a URL

I don't see why. Do you also expect blinking italics in a URL?

Soft hyphens, like uppercase letters, will simply be prohibited. They
won't work in domain names, and users won't type them.

> Soft hyphens can (already for some; more in the future) easily be
> generated from the keyboard.

The goal is for users to easily type good (nameprepped) names. Users can
also type many other things, such as spaces; so what? That doesn't hurt
their ability to type good names.

---Dan

---

From: "Mark Davis" <[email-masked]>
Date: Fri, 2 Feb 2001 20:28:44 -0800

> won't work in domain names, and users won't type them.

We can't lose sight of the fact that people cut and paste text into the
address field in a browser; they don't just type in URLs, especially long
ones.. It is not uncommon for word-processing software to insert
soft-hyphens into text. The user wouldn't even know that some text happened
to contain some when s/he pasted it into the address field.