[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] 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" <michelsu@windows.microsoft.com>
To: "Stephane Bortzmeyer" <bortzmeyer@nic.fr>; "Georg Ochsner" <georg@ochsner.de>
Cc: <idn@ops.ietf.org>
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