Re: IDNs in IE and Google

Dont confuse ability to have "non-english characters in URL like file:" 
with IRI. The former "support" in MS is not IRI.

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