Consensus Call Tranche 3 (Permanence)

[Simon Josefsson]

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