While it is an interesting observation, the discussion of (right or wrong) behavior of specific commerical/non-commerical software are better done outside this wg.
The discussion of the how URL is to be encoded and how Host: field are to be handled is probably more relevant so lets get back to that. -James Seng ----- Original Message ----- From: "Edmon Chung" <[EMAIL PROTECTED]> To: "tsenglm@�p������.���j.tw" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Tuesday, March 26, 2002 11:18 PM Subject: Re: [idn] Web navigation for IDN resolving > This is a rather interesting and serious observation. Does it not therefore > mean that RealNames/MS is effectively hijacking all IDN requests through an > IE browser? > > ----- Original Message ----- > From: "tsenglm@�p������.���j.tw" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > Sent: Tuesday, March 26, 2002 5:09 AM > Subject: Re: [idn] Web navigation for IDN resolving > > > > Dear Yves Arrouye: > > Thanks your descriptions. I think this message from Mr. > YangWoo > > Ko ([EMAIL PROTECTED]) is the key point: > > I am still wondering what "looks like a domain name" means > > > > > > > > The DNS lookup happened *before* the string was URL-encoded and passed > to > > > Autosearch, which only happen after a failure. > > The ASCII Domain Name (even without dot) will be put to do DNS > > lookup first, but IDN domain name will not . The IDN will be intercepted > to > > auto.search.msn.com directly without doing DNS lookup. That means the > IDN > > input with native coded string without http:// protocol head will be > > interpreted as "not a legal domain name" by IE. > > The server of Realname can not found these IDN in non contract > > supporting, so it is an error for Realname or IDN resolving, but the > return > > error cause the halting of browser will disturb the further regular > > processing of these UTF-8 IDN. That is my understanding of these strange > > processing to IDN . > > > > L.M.Tseng > > > > > > > > >
