vint at google.com
Mon Feb 21 22:00:10 CET 2011
one of the intentions of IDNA2008 was to generate tables of valid characters
automatically based solely on properties of Unicode characters independent
of specific versions. The modification to Section G causes changes that are
Unicode version specific and this violates the motivation for developing
IDNA2008 as a replacement for IDNA2003.
The tension is between maintaining a view of Internet use of Unicode that
propagates the properties of older versions of Unicode rather than deriving
validity from whatever the current version of it happens to be. I appreciate
the stability argument you make but at the same time, propagating old
"errors" seems somehow in bad taste from the engineering perspective.
On Mon, Feb 21, 2011 at 3:43 PM, Mark Davis ☕ <mark at macchiato.com> wrote:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Idna-update