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

JFC Morfin jefsey at jefsey.com
Sun Oct 2 05:06:28 CEST 2011

At 02:27 02/10/2011, Mark Davis ☕ wrote:
>The third choice, of course, was to maintain backwards compatibility 
>with 2003 for all characters in Unicode 3.2, and just extend the 
>same principles to new characters. That is a much easier migration path...
>We've seen this before. XML 1.1 only had a small 
>breaking-compatibility changes, but those changes were enough to 
>completely doom it.


Your "backwards" compatibility word is correct in terms of usage 
(your part as Unicode), but is architecurally incorrect because what 
you actually want is "forwards" IDNA2003 compatibility, with 
extensions to Unicode 6.1, etc. And this is exactly what IDNA2008 
permits but has not documented yet.

IDNA2003 actually tested a bundle of different concepts. This test 
shown that most of these concepts were OK but that the bundling 
introduced layer violations. The operational IDNA2003 (your need) 
works.The architectural IDNA2003 (the IETF and users' need) does not scale.

>But as you say, that was not the rough consensus of the WG.

To the countrary. And this is why I pushed for  a quick consensus 
and  for working on IDNA2010 (as the technical use of  IDNA2008) and 
then on  IDNA2012 (as the general usage of IDNA2008).

Why? you may recall that after the LCs the AD started to raise good 
architectural questions leading the IESG to not accept RFC 5895 as a 
WG deliverable. These questions and their solutions were of the 
essence but ... outside the WG charter.

It was then an absolute necessity that we establish IDNA2008, so we 
might work on the following steps, rather than keeping discussing 
along our limited charter.

As a result, RFC 5895 was not discussed by the WG as it should have 
had. Therefore, an IDNA2003 section was not included which should 
have documented how developpers could develop a scalable "IDNA2003 
interface" (i.e. a "forewards" adaptibillity at [or with] the user 
application and an IDNA2008 interface with the Internet DNS). Such an 
"IDNA2003 layer" is one of the multiple layers (ML) the IDNA2008 
conformant ML-DNS should support.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20111002/d2d63f42/attachment.html>

More information about the Idna-update mailing list