Mixing scripts

[Kent Karlsson]

John C Klensin wrote:
> <kent.karlsson14 at comhem.se> wrote:
> 
> > It's good to see that (at last) there is support for IDNs.
> > However, I don't find it a good idea to have that IE allows it
> > in one way, Firefox
> > in another, etc. The rules for what is allowed in IDNs and what
> > is not should be common for all (browsers, email clients,
> > etc.). It is clear, I hope, that the current rules-for-all
> > w.r.t. IDNs (laid down in the IDNA related RFCs) are currently
> > not sufficiently restrictive.
> 
> While I agree that this would be desirable in principle, in 
> practice it just won't happen.   First, note that browsers 
> already differ on what to do about abbreviated URLs and have for 
> years.  Some add TLDs, some initiate a searching procedure, some 
> try something and then branch to the search engine of their 
> choices... and some even give the user control over these 
> options.  In addition, different browsers localize to non-ASCII 
> environments in different ways, some more radically than others, 
> so interpretation of slightly-strange names may differ from 
> locality to locality, even for what is nominally the same 
> version of the same browser.  Those differences in behavior 
> occur today even in the absence of IDNs: the batter for uniform 
> UI behavior is long since lost.

I think we are talking past each other. What I was talking about
was the following situation, here set in an "LDH" setting just
for illustration:

One line of browsers (or other kind of domain name client)
reacts to domain names like   domain-name.com  by saying
something like "domain name contains hyphen-minus, 
access to site is blocked". While another line of browsers
are fine with hyphen-minus, but blocks access to sites
that use a domain name with digits (which are fine with the
first line of browsers).

I'm sure that would be something regarded as highly problematic
for "LDH" domain names.

Now, that does not happen for "LDH" domain names, but IIUC,
similar things is exactly what happens between different lines
of browsers and IDNs.

I think that is just as problematic as the "LDH" example above.
The additional restrictions (above current IDN spec) should be
the same for all. I.e. built-in to IDNbis, or related other
rules-for-all,
not added in different ways in different browser lines.

---

As for display of the Punycoded version of an IDN preventing
spoofing (which was mentioned earlier in the thread):
xn--XXXX is (for almost all users) just as impenetrable as an
IP number. As most users won't try to analyse xn--XXXX nor an
IP number, users will have no idea where they lead except by the
self-declaration on the site it leads to, an that may of course
be false (spoofing). Most users (me included) will not really read past
the "xn--", so whether this "xn--<gibberish>" is the same as an
"xn--<othergibberish>" (somehow trusted by the user) or not
will not be obvious the user by just seeing the domain name.
Displaying the punycoded domain name (parts) is just as bad
UI as displaying the IP address (which most people won't read
past "a jumble of numbers").

		/kent k


> In addition, it is not clear to me that complete uniformity is 
> desirable, especially when one moves to environments that are 
> very different from Western European languages, with RtoL ones 
> standing out as particular examples.
> 
>     john
> 
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>