Re: [idn] Fast nameprep vs. slow nameprep

["Mark Davis" <markdavis34@home.com>]

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" <keka@im.se>
To: <idn@ops.ietf.org>
Sent: Thursday, February 01, 2001 05:25
Subject: RE: [idn] Fast nameprep vs. slow nameprep



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:djb@cr.yp.to]
> Sent: Tuesday, January 30, 2001 10:22 AM
> To: idn@ops.ietf.org
> 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.