Any one of you that are interested in seeing how URL links on page working can goto http://www.neteka.com/MLTest/ If the page is set to the proper charset, there should be no problem clicking the link. If you are saying that some user may set the improper charset so that the links won't work, that is total non-sense because if the user cannot view what is on the page or cannot UNDERSTAND what is on the page(the chinese viewing a Korean page sample), then why is that user ending up looking at that webpage... If UTF8 or 8 bit DNS are implemented properly... links should not be a problem, and there is no need to change the browser behaviour so that it will hide ACE and show IDN on the UI, what happen if someone really wants to put something looks like an ACE on their page then we need another escape sequence for that?? David Leung Chief Technology Officer Neteka Inc. T: (416) 971-4302 http://w!.neteka.com > ----- Original Message ----- > From: "Soobok Lee" <lsb@postel.co.kr> > To: "IETF idn working group" <idn@ops.ietf.org> > Sent: Friday, March 22, 2002 5:04 AM > Subject: Re: [idn] URL encoding in html page > > > > > > ----- Original Message ----- > > From: "Bruce Thomson" <bthomson@fm-net.ne.jp> > > To: "Soobok Lee" <lsb@postel.co.kr>; "IETF idn working group" > <idn@ops.ietf.org> > > Sent: Friday, March 22, 2002 6:29 PM > > Subject: Re: [idn] URL encoding in html page > > > > > > > > What if all the html viewable text is in english, but, only the href > url contains > > > > legacy (korean) encoded hostnames? chinese visitors would see clean > english homepage, > > > > but fail to click through the korean link. > > > > > > > Well, that could happen, but a META tag would solve that so easily. > Personally > > > I often use a simple text editor to deal with HTML, and would find it > easier to > > > use legacy encodings or UTF-8 than cut-and-paste ACE from somewhere. > > > Of course the user could do it either way and it would work. > > > > Yes. Charset META tags help. But, many homepages have assumptions on the > main audience's > > default char encodings and very often omit the META tag for the encoding > like : > > <meta http-equiv="Content-Type" content="text/html; charset=euc-kr"> > > > > Moreover, IDN url would be used in a pure FRAMESET document that defines > frame URLs > > and contains no viewable texts. Such FRAMESET documents often omit charset > META tags. > > (look into the html source of http://www.freeway.co.kr/ ) > > > > AFIAK, 99.99999% of korean homepages have implicit/explicit > > legacy korean encoding (KS_C_5601-1987 or euc-kr). So do most > japanese/chineses homepages. > > UTF8/UCS-2 encodings are rarely used in global WEB publishing. Legacy > encodings > > will dominates even in the future, because it is compact and inexpensive. > > > > IF we want to make IDN truly internationally interoperable, all IDN-aware > webbrowsers/applications > > should contain libaries of all kinds of legacy-to-Unicode conversion > routines. It will burden > > too much memory load on handheld devices like PDA. > > > > Moreover, legacy encodings are revised separately from unicode. We may > face with as toughest > > versioning problems as we did in stringprep/nameprep versioning problems > for newly added unicode points. > > How to guarantee stability and intergrity of IDN operations in the all > combinations of numerous kinds and versions of iDN-aware > > applications and legacy encodings? > > > > Soobok Lee > > > > > > >