simon at josefsson.org
Mon Feb 21 21:58:38 CET 2011
Mark Davis ☕ <mark at macchiato.com> writes:
Thanks for summarizing. Your arguments are compelling to me because I
care about stability/compatibility between implementations because I see
it interact with security systems that perform domain name comparation.
I didn't understand John's argument that we have an incompatibility
regardless of what we do -- John, could you explain what incompatibility
we would have if we follow Mark's suggestion below?
> A. The Unicode technical
> committee<http://www.unicode.org/consortium/memblogo.html> is
> strongly in favor of stability for labels, that is:
> 1. *If a label is valid according to IDNA2008 under Unicode version V,
> then it is also valid under Unicode version V+1.*
> 2. Maintaining stability in the face of changes in underlying property
> changes is *not* rocket science. Unicode has done for years that with its
> definition for recommended programmatic identifiers.
> B. IDNA2008 provides for this capability. That is done by adding character
> to Section G.
> 1. For Unicode 6.0, this would involve adding one character, U+19DA NEW
> TAI LUE THAM DIGIT ONE as PVALID.
> 2. Ideally, this process would simply be automatic in IDNA2008, requiring
> no change in the RFC with any version of Unicode, and based purely on
> Unicode properties. The WG declined to do this, but did maintain the
> capability of doing this manually with Section G.
> C. If it is not done, then an implementation of IDNA2008 on a newer version
> of Unicode disallows strings that were valid under previous versions of
> 1. The argument is made that this character is not important, so it
> doesn't matter.
> 2. While this particular characters is of very low frequency, in our
> view, that is cherry-picking, and makes testing and comparison of
> implementations more difficult.
> 3. There is no harm at all to adding this character, and thus providing
> 4. It also sets a very bad precedent; IDNA2008 resulted in a large
> incompatible change for IDNA, but people can deal with a one-time large
> change. Additional instability on top of that is not welcome, especially for
> no good reason.
> See also:
> *— Il meglio è l’inimico del bene —*
> On Sun, Feb 20, 2011 at 07:14, Simon Josefsson <simon at josefsson.org> wrote:
>> Mark Davis ☕ <mark at macchiato.com> writes:
>> > That would work fine for me, with a slight change to wording.
>> >> Mark Davis also contributed to the document, but do not believe the
>> >> description of the issues in this document is optimal.
>> > =>
>> >> Mark Davis also contributed to the document, but does not believe the
>> >> solution for the issues discussed in this document is optimal.
>> Mark, what solution would you have preferred? I may have missed your
>> position from earlier discussion, but if we are close to a IETF-wide
>> last call on this it may be useful re-iterate your point succinctly to
>> see if others agree.
>> Personally I feel uncomfortable with changes that takes us from two
>> different compliant IDNA algorithms to three different compliant IDNA
>> algorithms depending on when in time you implemented the standards:
>> IDNA2003, IDNA2008-original, IDNA2008-revised. This is damaging from a
>> security perspective. I don't know what the alternative is though.
>> (If we consider non-compliant IDNA algorithms, there is also two other
>> IDNA2003 variants in wide use: 1) with improper PR-29 fix, and 2) with
>> improper dot-separation. On the client-side, the non-compliant
>> implementations are probably more common than compliant IDNA2003.)
> Idna-update mailing list
> Idna-update at alvestrand.no
More information about the Idna-update