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" <[EMAIL PROTECTED]> > 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
