ps: IRI is not a generic term for internationalization. it refers to a work-in-progress by W3C.
-James Seng
Soobok Lee wrote:
----- 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
