Consensus Call Tranche 3 (Permanence)

[Martin Duerst]

At 06:04 08/10/13, Simon Josefsson wrote:
>Vint Cerf <vint at google.com> writes:
>
>> Consensus Call Tranche 3 (Permanence)
>>
>> Place your reply here: [YES or NO]

YES.

>> COMMENTS:
>
>I believe the permanence requirement should be stronger.  In other
>words, I prefer to remove "unless serious and unanticipated
>circumstances occur.".  With that change, the proposed text is fine with
>me.

I don't care too much about the exact wording, because it seems
that we are all more or less in agreement with what we want:
Ideally, no changes, but nobody is able to completely predict
the future.


>Note that it will _always_ be possible to re-classify characters by
>publishing a new IDNA standard that says "whatever IDNA2008 says, but
>treat code point X as Y because Z".  This approach is more clear for
>implementers, as it is simpler to explain conformance.

It's slightly simpler to say "conforms to IDNAxxxx" than to say
"conforms to IDNA2008 including erratum xyz" (or some such), but
I don't think the later is a serious problem.


>It also sends a strong message to the UTC that if they break the
>normalization operation, they will break IDNA 2008.  PERIOD.  We should
>not allow them to weasel out of a backwards incompatible normalization
>change with reasons such as "well, this can be considered a
>unanticipated circumstance, so you should simply change your
>implementation because it is buggy" which they have done before.

Sending a strong message to any standards organization we depend
upon to be very careful with what they are doing is not a problem.

However, in the three cases I know about (two of them before IDNA2003,
one of them after), the UTC didn't break normalization at all,
on the contrary, it was fixing a bug that was found, after
very careful considerations of the consequences both of fixing
that bug and of not fixing that bug (and in the case of the
bug fix that (in theory) affected IDNA2003, after even looking at
existing implementations and assessing the difficulty for them to
fix the bug, in cases where the source code was available, including
the implementation written by Simon).

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.

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

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.

Regards,    Martin.


>/Simon
>
>> (3) Permanence of DISALLOWED and PROTOCOL-VALID
>>
>> (3.a) Once a character is classified as PROTOCOL-VALID, it
>> will remain in that category for all future versions of the
>> protocol and tables unless serious and unanticipated
>> circumstances occur.  (R.10)
>>
>> (3.b) Once a character is classified as DISALLOWED, it will
>> remain in that category for all future versions of the protocol
>> and tables unless serious and unanticipated circumstances
>> occur.  Note that UNASSIGNED characters are not, for this
>> purpose, DISALLOWED.  (R.5)
>> ------------
>>
>>
>> NOTE NEW BUSINESS ADDRESS AND PHONE
>> Vint Cerf
>> Google
>> 1818 Library Street, Suite 400
>> Reston, VA 20190
>> 202-370-5637
>> vint at google.com
>>
>>
>>
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>_______________________________________________
>Idna-update mailing list
>Idna-update at alvestrand.no
>http://www.alvestrand.no/mailman/listinfo/idna-update


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