Mark Davis ☕
mark at macchiato.com
Mon Feb 21 21:43:32 CET 2011
A. The Unicode technical
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
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.
*— 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.)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update