Re: [idn] IDNA: is the specification proper, adequate, and complete? (was: Re: I-D ACTION:draft-ietf-idn-idna-08.txt)

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

Dear Soobok:

From: "Soobok Lee" <lsb@postel.co.kr>
> I am writing  a draft  about the minimal specification of the
directory-for-8bit-query approach which
> seems simple and straightforward. Most challenging part of my work,  is
how to prove that  the roadmap is correct
> and would not place any obstacles in the future new class IDN efforts.
>
      The new class IDN means an isolated subtree of DNS with the same root
, so you need an interface or some trap scheme to let different class RR can
be treated by the current class with difference data type (for ex. UTF-8 or
legacy encoding). It is like to use "bq--"  as an explicit indicater in
domain  name .
>
> ----- Original Message -----
> From: "tsenglm@計網中心.中大.tw" <tsenglm@cc.ncu.edu.tw>
>  >                      Even it is safe without new plug-in to client ,
but
> > there are some other problems.
>
> > One is that  need more effort on web proxy
> > servers to treat native to UTF-8 conversion .
>
> the conversion may be done on the central forwarding webserver which can
gather
> more contexts from the incoming http requests. Some http proxy maybe strip
the 8th bit off from
> the non-ASCII HOST: header values into ASCII ones.  Even in those cases,
the original
> hostname often can be restored by the forwarding server with simple  "OR
with 0x80" operations.
> Moreover, Hostnames may not be in UTF8 and their  legacy encodings may not
be explicitly specified
> in the http headers.  Such brower behaviors have been well documented
grouped by vendors , OSes and versions
> which context information is, fortunately , available in the incoming http
request headers.
>
        We have some  8bit pass-thru  squid proxy server in our testing bed
. The name from IE browser  pass to proxy server port is legacy encoding
via it  passed thru to resolver in Win2K is  UTF-8 . Althought IE has one
option to always send with UTF-8 from input address bar , but it can not
pass the internal range check of  local native code in IE browser.  The
current situation is legacy encoding is valid passed thru by proxy port.
Many legacy encoding is not always using leading bit  in each byte  (The
second byte of BIG5 , JIS may be 7 bits).
>
> > Another  important
> > interoperability protocol issue is the virtual host of web page , that
is
> > how to pass what kind of identifier (native , utf-8 , ACE or others) to
let
> > a web server to act as the "virtual host" of web page and  will guide
the
> > client  re-direct to the target web page.
>
> Current HTTP/1.1  is still bound to the restriction imposed by ASCII
hostname rules
> over Host: header. Therefore, To be faithful to the current standards,
>  the forwarding webserver SHOULD accept  ASCII-only URL
> which contains no native-encoded IDN and no ACE hostname  in my
suggestion.
>
> If we assume future new class IDN will have  "A,MX,NS,CNAME..." like "IN"
class,
> IDNA and future new class IDN are mutually exclusive options.
>
    To be backward compatible in ASCII encoding of web servers, the
directory-for-8 bit-query  will need "resulting  name replacement " property
in client side.
An ASCII URI to replace the 8bit  new class name  is one of the solution,
the other is to use the  ASCII keyword. May be the ACE encoded name is
another solution.
    Draft of UNAME has been described the approach to let the  legacy or
UTF-8 character comparing without to care TC/SC  and will replace 8 bit
domain name  to the ACE (or ASCII) identifier.

L.M.Tseng