I-D Action:draft-faltstrom-5892bis-02.txt

Simon Josefsson simon at josefsson.org
Mon Feb 21 21:58:38 CET 2011

Mark Davis ☕ <mark at macchiato.com> writes:

> Briefly:

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
>    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
> Unicode.
>    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
>    stability.
>    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:
> http://www.alvestrand.no/pipermail/idna-update/2010-October/006742.html
> Mark
> *— 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.
>> /Simon
>> (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
> http://www.alvestrand.no/mailman/listinfo/idna-update

More information about the Idna-update mailing list