That's a good point. I would point out however, that if my browser isn't updated at least every few months for security problems, I have a *whole* lot more to worry about than whether I can see mixed scripts or not, so the lag is in practice not that bad. And I see baking it into the protocol (IDNA) as the least flexible of these in terms of delay, since that takes years to change.
<br><br>Mark<br><br><div><span class="gmail_quote">On 12/21/06, <b class="gmail_sendername">Gervase Markham</b> <<a href="mailto:gerv@mozilla.org">gerv@mozilla.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Mark Davis wrote:<br>> I am not yet, however, so sure that it should be baked into the<br>> protocol. This is a pretty big hammer, and it may be better to leave it<br>> to the registrars and/or the user-agents, which have a lot more
<br>> flexibility. It is very simple for a user-agent to have a mixed-script<br>> test, and then loosen it for particular languages where the spoofing<br>> opportunities don't arise (eg mixing Latin and Devanagari).
<br><br>There's one big difference between implementing the mix test in browsers<br>and implementing it at the registry level. If you implement it in<br>browsers, then decide that a loosening is necessary in a particular
<br>case, you need to update 1 billion+ installed bits of software before<br>you can sell the new IDNs. That would probably take, based on past<br>experience, about four or five years.<br><br>If you implement it at a registry policy level, you can start immediately.
<br><br>Gerv<br></blockquote></div><br>