OFF TOPIC normalization (was Re: Consensus Call Tranche 3 (Permanence))

[Mark Davis]

The UTC *did* what you say it should have done.
It did not revise Unicode 3.2; it changed a *later* version of the Unicode
Standard, *and* issued a corrigendum so that people could either still claim
conformance to U3.2 as it was, or could claim conformance to U3.2 with the
corrigendum. From http://www.unicode.org/versions/corrigenda.html - An
implementation claiming conformance to any version of Unicode in that range
may
 also claim conformance to one or more of the corrigenda applicable to
that version.

Until and if IDNA2003 was revised, it referred to U3.2 without the
corrigendum, and was unaffected by any later corrigendum.

I agree with Martin that in an ideal world, IDNA2003 should have been had an
erratum/corrigendum for that, but none was issued. And now, of course, this
is completely moot, since the effects of the normalization changes from the
UTC are stunningly small compared to the other changes from IDNA2003 to
IDNA2008.

Mark


On Tue, Oct 14, 2008 at 8:45 AM, Simon Josefsson <simon at josefsson.org>wrote:

> We are getting off-topic, so I'll try to finalize this aspect.
>
> Martin Duerst <duerst at it.aoyama.ac.jp> writes:
>
> > It is simply a fact that both implementations and specifications
> > are written by humans. It is a corollary that both implementations
> > and specifications occasionally contain bugs, and that when these
> > bugs are found, one has to carefully think about whether and how
> > to fix them. Treating specs as sacrosanct or written in stone
> > doesn't help at all.
>
> Of course, but the normal approach is to revise the specification and
> let applications and specifications upgrade to it to fix the problem.
> My impression was that the UTC tried to fix existing implementations
> that needed to depend on the unfixed specification.
>
> > In the case at hand, the bug in the normalization operation that
> > (in theory) affected IDNA2003 was carefully considered, and it
> > was concluded that:
> > a) The bug only affected certain character combinations that
> >    did not appear in practice, in particular not in domain names.
>
> IDNA2003 supported profiles, and one of the profiles (SASLPrep) was used
> to prepare passwords rather than domain names.  Passwords may contain
> such strings, although unlikely.
>
> > b) For the (nonexistent, see a)) data where the bug actually
> >    would have affected normalization, the outcome before the
> >    bug fix could lead to different or unexpected behavior for
> >    different implementations because the bug violated a
> >    (pretty obvious) idempotence assumption about normalization
> >    that the designers of IDNA2003 had implicitly made.
> >
> > So in practice, the effect of the bug fix on IDNA2003 was
> > none, and just in case there ever was one, it would have
> > been positive.
>
> Sure, but I'm talking about the process around integrating the fix, not
> the fix itself.
>
> > In conclusion, I think it's good for spec writers to know that
> > implementers expect specs to be stable, and to do everything
> > possible to keep it that way. However, it's also important
> > for implementers to understand that specs aren't infallible,
> > and in case of bug fixes (called "errata" in the case of specs)
> > to look at them with a clear and open mind, rather than to
> > continue to spread FUD.
>
> There were no errata for IDNA2003 in this area.
>
> /Simon
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20081014/03336d92/attachment.htm