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

Mark Davis ☕ mark at macchiato.com
Mon Feb 21 21:43:32 CET 2011


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

   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.
> /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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20110221/0c049555/attachment.html>

More information about the Idna-update mailing list