<html>
<body>
At 05:59 04/10/2011, Mark Davis ☕ wrote:<br>
<blockquote type=cite class=cite cite="">There are other alternatives.
The obvious one is, well, maintaining backwards compatibility. In this
case, it would provide that:
<ul>
<li>Every valid 2003 IDN remains valid under 2008
<li>Additional valid IDNs are allowed under 2008: with either post
Unicode 3.2 characters or those unmapped by 2003. </blockquote>
</ul>This is exactly what IDNA2003 did not permit and IDNA2003 does
permit. However:<br><br>
- this demand belong to the user side. Therefore, someone must develop it
on the user side, as RFC 3958 exemplifies it. I am not alone and buzy:
Unicode could do it.<br>
- there may be other demands that a strict statu quo: this is why
adequate developments on the user side must support multiple solutions.
And why, to answer the questions of Lisa Dussault, the IDNinA is to be
replaced first by an IDNApplication. IDNA2003 did not
architecturally scale, but IDNinA also does not scale.<br><br>
Now, you and I can keep ourself repeating this non-exchange for years,
until users have defacto changed from the Internet2003 to their
Internet20XX. It is true that IDNA2008 has changed the status of the
Unicode consortium contribution to the Internet architecture. Why is
Unicode not taking advantage from it to bring other contribution. For
example, why is Unicode not participating to the ICANN/VIP work?
<br><br>
"IDNA201XX" will have to support variants and, more generaly,
orthotypography. This going to call for the support of
"netlocale" new kind of files. Will this be through a
grassroots, an ICANN, an IETF, an Unicode or a joint effort? To permit is
the "IDNA2010" basic concepts of the IUI "plugged layers
on the user side" (Internet PLUS) are to be identified, tested,
validated (ML-DNS), within the IDNA architectural framework. Or just
delayed in implementing some on the Host side, like with the
"Google+". Or in joing efforts.<br><br>
Best<br>
jfc<br>
</body>
</html>