[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] Mapping and Prohibit of code points
----- Original Message -----
From: "Patrik Fältström" <paf@cisco.com>
>
> > 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.
>
The possibility of external NON-LDH-name server is existed
. It is isolated from current LDH-DNS server or cooperated by layer upon
LDH-DNS server or to replace it or in parallel can not be easily
predicated.
> > 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?
>
I think you talk a solution that TWNIC/CNNIC have been used in
transition state, to a registry , the original name that is registered is
independent of any encoding , that will be there. Try to support service
in testbed can find many important issue. I have implement an experimental
Virtual Domain Name system that based on RACE , but support any query of
UTF-8, BIG5 , RACE because they can be identified without language tag ,
but mixed BIG5 , GB is not so easy to differentiate them as you point-out,
if it is suported by HTTP protocol with lang-tag and used for browser ,
there are no problems, that is the system you called keyword approach and
now I think Realname/MicroSoft/VeriSign used in resolving by web
navigation. Unfortunately , that is only my personal experimental system to
try to solve TC/SC problems.
Why I mention UTF-8 here , because based on current BIND DNS
technology that can do character mapping easily . If these server are
isolated from current LDH-DNS server , it can be a layer-2 server , it also
can be a gateway to do character mapping .
Whether it is a Layer-2 server betwwen AP and IDNA nameprep or
it is a gateway between resolver and LDH-DNS server that is not so
important. Even I know the solution existed in multi-case AMC-Z encoding ,
but nameprep and IDNA fixed to refused to support it . I still want to
solve our TC/SC problems first or we should to avoid to use the
non-suporting scheme.
> > 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.
>
To do matching by nameprep and ACE conversion then by LDH
server with single matching rule or to do multiple matching in higher layer
or gateway then do single matching in LDH DNS server is not so boundary
clearily . To us , we can select any approach to solve the problems that
are initiated from UNICODE and this IDN WG.
May be the current nameprep should be a local issue.
L.M.Tseng