Mixing scripts

[Kent Karlsson]

Martin Duerst wrote (quoting Daniel Yacob):
> >I think that the potential for mischief can be mitigated here
> >with restrictions imposed on the valid use of Ethiopic wordspace.
> >For example a rule that required only Ethiopic symbols to appear
> >left or right of a wordspace. I'm not acquainted with NamePrep or
> >StringPrep, but I expect that they could be enhanced to avoid
> >the problem described.
> 
> There could be such a rule. But the tendency is currently to leave
> 'single-script' rules out of the protocol and have it checked by
> registrars/registries and browsers.

Earlier Michel Suignard wrote:
> Probably another piece of info in the debate:
> http://blogs.msdn.com/ie/archive/2006/07/31/684337.aspx 
> It shows what IE7 does on the UI side. This rule relaxing on script
> mixing was to allow ASCII to be mixed with scripts where confusability
> risk is low. This was done among other to allow Japanese to be mixed
> with ASCII which is a common practice in Japan and quite a few other
> writing system where ASCII can't be easily confused with native
> characters but is also commonly mixed in brand names.
> This is by no mean an endorsement of what should be done at 
> the protocol
> level. The list of 'allowed scripts' can be useful input for 
> the ongoing discussion.


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. 

I can understand that domain name registrars want to have further
restrictions on what they register (at least they want to have the
ability to read the name and see if it "means" anything).

But for interoperability, all clients should use the same rules.
Otherwise we will see such things as "this IDN/URI best used in 
browser-so-and-so". Not something I'd like to see, at least not
in the long run.

	/kent k