Re: [idn] Mapping and Prohibit of code points

[Patrik Fältström <paf@cisco.com>]

--On 2002-01-28 09.32 +0800
"=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?="
<tsenglm@cc.ncu.edu.tw> wrote:

> 1. The problems:
>           There are many need about character mapping and prohibition of
> code points that are  more than the draft of nameprep described,  someone
> call them local issue ,  language or area related issue.

They are language, culture and other context dependent, and therefore a
localization issue, not internationalization issue and out of scope for
this wg.

> 2. The  interface before and after IDNA module:
>          To solve these problems, the pre-IDNA approach is not clear,
> especially in the interface.

You mix up a large number of things here. None of them is part of what this
working group is working with.

> Currently,  we can find web navigation of  Realname/Microsoft help to  do
> resolving of   Verisign's IDN testbed.

This binding doesn't exist explicitly. Some web browsers after a NXDOMAIN
response is going to a search system like Realname/Microsoft with the
domainname. That is one thing. Lack of support for the IETF IDN wg results
in the browsers of today is another. None of these have to do with
localization or "interface to IDNA".

> But  that is  one possible
> approach , some character mapping and prohibition can be processed in
> external matching and conversion server.

Yes, but that is done in a layer "above" DNS. Not as a replacement or in
parallell with DNS. Domain name is one thing and keyword another. You mix
them up.

>          IDNA  approach is based on  ACE  encoding for backward
> compatibility ,  we can view the ACE encoding approach is a tunnel
> technology between client and server based on current  LDH-DNS server and
> TLD.

Sort of, but rather from the client application and the registrant as the
encoding is invisible for the server aswell.

>  As discussed in the mailing list , based on exhausted  label
> mapping , some kind of character mapping can be achieved by  multiple RR
> of CNAME/DNAME  ,

Not DNAME. DNAME should not be used. And, you do not do character mapping. 

In DNS you make sure that a client get a response regardless of what the
query is. You might say that the result is the same for the user, but, it
is not translation which is done.

>  such small and simple case can be done in this way .

Yes.

> If  the character mapping is a combination  in label then a  gateway to
> do multiple matching rule  is need to reduce a lot of  label  records.

No. As I explaind on a different thread last week (see the archives), as
soon as you change the matching rules locally, you change the definition of
a RR-Set.

> Actually a gateway combined with the function of  UTF-8 DNS-like server
> may be one of the approach .

No. UTF-8 have nothing to do with this. UTF-8 is just another encoding of
Unicode.

What you really talk about (I think) is how to handle the IDN solution as
soon as possible, before applications have support for IDNA. And, your
proposal is to store whatever garbage the applications will send over the
network in the DNS servers in the encoding the clients happens to use. This
implies BIG5, UTF-8 encoded non-nameprepped Unicode, ISO-8859-1 and many
other charsets.

That should _NOT_ be done, as there is no way of discovering what charset
is used, and this will because of this lead to explicit domain name
infridgement which in turn is treated as trademark infringement.

Further, the application layer protocols can not handle other characters
than LDH, so you loose anyway.

All of this has already been discussed many times on this mailing list.

Especially the definition of RR-Sets. Didn't you see that last week?

> 3.  To  force  some character mapping/prohibition  out of  nameprep and
> call them local issue without using the option concept  is not a good
> solution , but if  it can not be avoid in this architecture ,  then  the
> interface of pre-IDNA  and post-ACE-encoding  MUST be defined clearly .

Maybe, but it is not a work for IETF. IETF do not work with API's.

IETF have not made API's for access to quoted-printable.

> To use ACE-string and  TLD as gateway selection  is in the  range of  DNS
> protocol . By using  HTTP protocol  and web navigation  or another
> protocol  to reach external server to do multiple matching  is out of
> DNS  protocol  and out of the expectation of  DNS manager.

Exactly.

> 4. Which  solution is beter ?  that depends on requirements of user  and
> expectations  of  DNS manager.   All the problem is  "where to do local
> character/string mapping ? "   Annotational multi-case Punycode
> encoding/decoding is a powerful  tool to do such mapping and multiple
> matching  based on a uniform LDH-DNS matching rule.

As I have said earlier, it is discussed in another forum than this wg.
Please stop talking about it here.

   paf