----- Original Message ----- From: "Michel Suignard" <[EMAIL PROTECTED]> To: "Stephane Bortzmeyer" <[EMAIL PROTECTED]>; "Georg Ochsner" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Friday, January 23, 2004 10:31 AM Subject: RE: [idn] IDNs in IE and Google
> Concerning IRI, it is not a matter of 'preference'. If you present > something like a URI containing a host name presented in non ASCII > repertoire, you are in fact using an illegal URI per RFC2396 definition. > At minimum you need to have a clear definition on how such 'extended' > URI (in other words IRI) are mapped to legal URI. This is a big part of > the IRI draft spec currently worked on. The draft is at > http://www.ietf.org/internet-drafts/draft-duerst-iri-05.txt. The same > goes for http, and any other URI schemes presented in browser user > interface. I know the importance of IRI effort. BTW, MSIE/Mozilla seem to support IRI concept in "file:" protocol already. file: protocol URL had been supporting NETBIOS PC Name and File/Directory Pathname in ***LOCAL CHARSET ENCODING***, not in UTF-8 encoding from very long time ago. That works in Windows OS and even in LINUX. Moreover, Most asian HTML homepages are published in local charset encoding like euc-kr, big5 and gb2312 etc. UTF-8-encoded HTML pages are extremely *RARE* in ASIA. Need for backward compatibility to already deployed IRI-concept and Unicode<->Local charset conversion layer may lay another complexity to IRI effort. Just comparing two IRIs won't be a trivial task, if they can be in two diifferent encodings. IMHO, IRI efforts deserve a WG. I will resume tracking the progress of IRI spec.. :-) Soobok Lee
