RE: [idn] Fast nameprep vs. slow nameprep

[Karlsson Kent - keka <keka@im.se>]

I agree (nearly) with your examples (usage scenarios), though
they only cover the browser/e-mail program/... user side;
not the DNS manager side (which I think D.J. and Patrik
were more concerned with).  However, none of your usage
scenarios have anything to do with the keyboard interface
at any level (which is good).  Even in the first one, the
user is done typing the entier URL well before any
nameprep or ACE processing is done.  Similarly for the
DNS manager side, whether one uses a GUI program specific
for DNS management or uses plain text zone files or whatever,
the keyboard handling is far removed from any nameprep or
ACE processing in any reasonable system.

Regarding scenario A: neither "nameprepping" or "ACE"ing
requires the input to be UTF-8 do they?  It may be, e.g.,
UTF-16 at that stage.

Regarding scenario C: "nameprepping" should be done on
the entire IDN, which can then map fullwidth full stop
to full stop (and possibly ideographic full stop to
full stop) before parsing into name "parts".

		/kent k


> -----Original Message-----
> From: Mark Davis [mailto:markdavis34@home.com]
> Sent: Thursday, February 01, 2001 5:54 PM
> To: Karlsson Kent - keka; idn@ops.ietf.org
> Subject: Re: [idn] Fast nameprep vs. slow nameprep
> 
> 
> 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.
> 
> 
> 
>