[idn] Mapping and Prohibit of code points

[=?utf-8?B?dHNlbmdsbUDoqIjntrLkuK3lv4Mu5Lit5aSnLnR3?= <tsenglm@cc.ncu.edu.tw>]

Dear Patrik Fältström & all:
                   I think to change a subject may be more good .
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.
2. The  interface before and after IDNA module:
         To solve these problems, the pre-IDNA approach is not clear,
especially in the interface.
Currently,  we can find web navigation of  Realname/Microsoft help to  do
resolving of   Verisign's IDN testbed. But  that is  one possible approach ,
some character mapping and prohibition can be processed in external matching
and conversion server.
         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.  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  ,  such small and simple case can be done in this way . 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.  Actually a
gateway combined with the function of  UTF-8 DNS-like server may be one of
the approach .
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 .  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.

L.M.Tseng

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.


----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>

> IDNA specifies what goes on the wire between two applications. Not what
> libraries, functions etc are to be developed to reach that goal.
>
> The functions specified in the IDNA draft is a functional specification on
> what must happen with the strings. Not a specification of functions which
> should exist in libc or such.
>
> My personal guess is that we will see ToUnicode and ToAscii functions in
> libraries which already take care of charset conversion. Like the Text
> Encoding Converter from Apple. (see
>
http://developer.apple.com/techpubs/macos8/TextIntlSvcs/TextEncodingConvers
> ionManager/TEC1.5/TEC.38.html)
>
> Similar modules will certainly be developed as perl libraries and what
not.
>
> Many of them probably takes a native charset as input (such as BIG-5 or
> ISO-8859-1) and not some encoding of Unicode.
>
> IETF extremely rarely develops API's.
>
>   paf
>
>