wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec)

[J-F C. Morfin]

At 05:59 04/10/2011, Mark Davis ☕ wrote:
>There are other alternatives. The obvious one is, well, maintaining 
>backwards compatibility. In this case, it would provide that:
>    * Every valid 2003 IDN remains valid under 2008
>    * Additional valid IDNs are allowed under 2008: with either post 
> Unicode 3.2 characters or those unmapped by 2003.
This is exactly what IDNA2003 did not permit and IDNA2003 does permit. However:

- 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.
- 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.

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?

"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.

Best
jfc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20111004/53cf3312/attachment-0001.html>