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

From: Karlsson Kent - keka <[email-masked]>
Date: Thu, 1 Feb 2001 18:58:50 +0100

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:[email-masked]]
> Sent: Thursday, February 01, 2001 5:54 PM
> To: Karlsson Kent - keka; [email-masked]
> 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" <[email-masked]>
> To: <[email-masked]>
> 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:[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: Patrik Fältström <[email-masked]>
Date: Thu, 1 Feb 2001 23:15:14 +0100

At 18.58 +0100 01-02-01, Karlsson Kent - keka wrote:
>However, none of your usage
>at any level (which is good).

I created the confusion by seeing the need that the nameprep is NOT 
done in the resolver libraries or in the DNS server, i.e. somewhere 
between the keyboard and the application layer protocols (out of 
which DNS is one).

   paf

---

From: "Eric A. Hall" <[email-masked]>
Date: Thu, 01 Feb 2001 23:51:40 -0800

Patrik Fältström wrote:

> done in the resolver libraries or in the DNS server,

I agree that the resolver is a bad place to do this. It seems fairly
obvious from a cursory analysis that the best place to do this is in the
application layer in front of the resolver (before gethostbyname). Any app
which calls the API should have done the necessary work before the API is
called. This also applies to DNS-specific apps like nsupdate and dig and
the rest.

However, I think that the use of ACE -- more specifically, the use of a
mechanism which favors backwards compatibility -- pretty much dictates
that the resolver has to do the work. In addition, I think it is pretty
clear that servers will have to do the work against incoming queries as
well. I don't see any way around it.

Since there are no new RRs, classes or EDNS structures to make legacy
applications and resolvers barf on new-style labels, we can pretty much
expect that there will always be some legacy applications that will try to
feed unformatted, un-prepped raw IDNs through a legacy resolver, and that
some of those resolvers will simply treat the data as raw eight-bit data.
The fact is that somebody somewhere is going to click on an IDN URL and
expect that Netscape 3 is going to work with the Windows 3.0 resolver. It
is inescapable. The real problem is that it will also happen with users of
Netscape 6 and Windows 2000, MacOS X, and every other current day
operating system.

In those cases, the un-prepped data will still enter the DNS namespace,
having never been formatted. The DNS servers will have to examine and
reject unformatted data. New DNS resolvers will end up being the first
line of defense to this problem should it emerge.

The need for this will be measured by the amount of effort required to
communicate failure back to the client. If it is a simple match->fail
sequence that uses the same NXDOMAIN errors we already have (and if it
doesn't happen a lot) then it won't be much of a problem. Conversely, if
enough users yell about not being able to resolve IDNs (even though it is
because their patch-current apps/resolvers aren't doing the work) then
there might be sufficient non-technical motivation to introduce an
intermediary solution somewhere within the DNS infrastructure, either at
the server or with patched resolvers.

In short:
  legacy apps+legacy resolvers=server labor
  legacy apps+patched resolver=resolver labor
  new apps=app labor

I'd say spec for the last scenario but implementaions need to be prepared
for all three.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: "Edmon" <[email-masked]>
Date: Fri, 2 Feb 2001 09:48:07 -0500

> I'd say spec for the last scenario but implementaions need to be prepared

Thats exactly why we have prepared the known issues paper in our OpenIDN
forum.  These issues must be dealt with because at the end of the day, its
the user who might not know too much about the discussions here that will be
using the domain names.  Also, if these preparations are not made, IDNs will
not pass the business card test.

Edmon

PS. Though I'd add that I see that there should be a 4th scenario:
new apps + new resolvers = full IDN
and specs should be based on this scenario with "new apps only" as an
intermediate solution.