Consensus Call Tranche 3 (Permanence)

[Martin Duerst]

At 15:45 08/10/14, Simon Josefsson 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.

Okay, glad you agree with this.

>My impression was that the UTC tried to fix existing implementations

Thanks for telling us what went wrong in your opinion.
I don't think that impression is too wrong, I think many
people from the UTC tried to ask implementers
to just fix the implementations.


>that needed to depend on the unfixed specification.

See below for that big.


>> 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,

Well, that was nameprep, but that's just a detail.

>and one of the profiles (SASLPrep) was used
>to prepare passwords rather than domain names.  Passwords may contain
>such strings, although unlikely.

Yes, although highly, highly unlikely. The probability was
probably several factors (or even magnitudes) higher than
for domain names, but several magnitudes higher than 0 is
still 0.


>> 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.

Okay. So your position would be: Fix (issue an erratum) for
IDNA 2003, then we'll fix the implementations. Very understandable.
The problem was that some of the people who would have been in
positions in the IETF to initiate such errata acted as if
the specs they depended on had no other choice than to be
cast in stone, and that the Unicode Consortium messed up
when they fixed an obvious bug in the spec.


>> 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.

So our conclusion here would be that there should have been?
I would definitely agree with that.

Regards,    Martin.



#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:duerst at it.aoyama.ac.jp