Re: Standardizing on IDNA 2003 in the URL Standard

--On Friday, January 17, 2014 10:56 -0500 Andrew Sullivan
<ajs@anvilwalrusden.com> wrote:

>...
>> If you take IDNA2003, an updated version of Unicode,
>> and assume the same algorithms defined in IDNA2003 apply you
>> have an algorithm that defines just that.
> 
> No, because there aren't algorithms defined in IDNA2003.
> There's a list of code points that are "out"; everything else
> is allowed.  We'd actually have to go over the new code points
> in order to get the new definition you're talking about.

Just to clarify, there is a general assumption about where that
list of exclusions came from and how to derive the mappings
listed in Stringprep.    That assumption is nearly enough true
that people assume they can generate lists equivalent to
Stringprep/Nameprep for Unicode versions after 3.2.  That second
assumption is, I assume, where the "IDNA2003 plus updates" claim
comes from.  The difficulty is that the assumption is not quite
correct: some tuning was done to meet the needs of IDNs that
don't apply to other i18n cases and that tuning is Unicode
3.2-specific.  And that, in turn, is why various of us have
described "IDNA2003 plus updates for later versions" as a
non-specification that has elements of "do what you like and
leave everyone else guessing". 

I agree with your main point, however: IDNA2008 was driven by
two fundamental design decisions different from those underlying
IDNA2003:

	(i) Reversibility of the two label representations for
	the reasons you summarized.
	
	(ii) Shifting from normative tables tied to a version of
	Unicode (i.e., Stringprep/Nameprep) to a rule set
	intended to be largely independent of version changes. 

Just about everything else is either details or side-effects.
Those may still be troublesome, but the above were, and remain,
the main differences between the two generations of IDNA
standards.

    best,
     john

p.s. I know I still owe the lists responses to a couple of other
notes -- will get to them as soon as possible.

Received on Friday, 17 January 2014 16:23:31 UTC