wrt IDNA2008 migration (was: IDN processing-related security considerations for draft-ietf-websec-strict-transport-sec)
J-F C. Morfin
jfc at morfin.org
Tue Oct 4 10:30:02 CEST 2011
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>
More information about the Idna-update
mailing list