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

["Soobok Lee" <lsb@postel.co.kr>]

Thanks for your interests.

My directory-for-8bit-query approach is just a short-term kludge and I hope we can
prove that  it  serves well  as a seamless migration path to  NEW CLASS IDN.
I hope we could publish  the directory approach as a small part of the entire picture of
the standardization roadmap to new class IDN which appears to  require
 more years of research and preparations  from our experienecs in this WG.

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.

My comments continues..

----- 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.


> 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.


Soobok Lee