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

Tue Dec 21 21:14:46 CET 2010

http://tools.ietf.org/html/draft-faltstrom-5892bis-01

In addition to the previous comments:

When the algorithm presented in RFC 5892 is applied to Unicode 6.0the
result will be different from when it is applied to Unicode 5.2for the
three codepoints discussed in this document.

It should be something like:

When the algorithm presented in RFC 5892 is applied using the property
definitions of Unicode Standard Version 6.0, the result will be different
from when it is applied using the property definitions of Version 5.2. There
are 2,088 new characters in Version 6.0 which change from UNASSIGNED to
another value. In addition, 3 characters defined in Unicode 5.2 have
different values, as described in Section 1.

The next sentence is also untrue (as well as ungrammatical).

IETF consensus

is though that the changes are minor, and that it is important IDNA

standard is aligned with the Unicode Standard.

The IETF had two choices for each of the 3 characters: add it to section G
or let the value change. Both of these choices are "aligned with the Unicode
Standard", because the use of section G to preserve stability is in
alignment with the Unicode Standard. What would be more accurate would be
something like:

IETF consensus is though that the characters are minor, and strict
backwards compatibility of IDNA2008 is not important for minor
characters.

However, it would be better to have the reasoning spelled out in more
detail, and moved to
http://tools.ietf.org/html/draft-faltstrom-5892bis-01#section-2

Mark

*— Il meglio è l’inimico del bene —*

On Mon, Dec 13, 2010 at 20:34, "Martin J. Dürst" <duerst at it.aoyama.ac.jp>wrote:

> Hello John, others,
>
>
> On 2010/12/14 13:05, John C Klensin wrote:
>
>>
>>
>> --On Monday, December 13, 2010 11:30 -0800
>> Internet-Drafts at ietf.org wrote:
>>
>>  A New Internet-Draft is available from the on-line
>>> Internet-Drafts directories.
>>>
>>>        Title           : The Unicode code points and IDNA - Unicode
>>> 6.0     Author(s)       : P. Faltstrom, P. Hoffman
>>>        Filename        : draft-faltstrom-5892bis-01.txt
>>>        Pages           : 4
>>>        Date            : 2010-12-13
>>> ...
>>>
>>
>> I hope the comments that follow are complementary to Martin's,
>> not competitive with them.
>>
>
> They are quite complementary indeed. And I think they definitely should be
> taken into account.
>
> Regards,   Martin.
>
>
>  I believe that they are editorial,
>> rather than substantive, but may be important.
>>
>> (1) The organization of this document almost implies that the
>> three characters identified are the only changes from Unicode
>> 5.2 to Unicode 6.0.  That is not the case.  A lot of new
>> characters have been added and, extrapolating from James's
>> comments, we should be doing at least a pro forma review as to
>> whether all of the others are associated with properties that
>> cause them to be appropriated classified for IDNA purposes.
>> That suggests to me that either:
>>
>>        -- this draft needs a brief summary of the other changes
>>        made in 6.0, number of new characters added, etc.  That
>>        can be done in large measure with some anchoring text
>>        and a citation of a Unicode change summary, but it ought
>>        to be done.
>>
>>        -- the abstract, introduction, and maybe even title need
>>        to be narrowed down to make it clear that the document
>>        addresses _only_ those characters that were defined in
>>        Unicode 5.2 or earlier and whose properties changed in
>>        6.0 in a way that effects IDNA.
>>
>> I'm pretty agnostic about that choice right now (someone could
>> easily persuade me that one or the other was better), but I
>> think it has to be one or the other.
>>
>> (2) I think that, if there is going to be a section titled "IETF
>> Consensus" that the reasoning for the conclusion should be
>> given, even if it is in abbreviated form.  This is an informed
>> decision, not the result of some voting process among the
>> ignorant.
>>
>> (3) The statement in Section 2 that reads "The IETF will produce
>> a new RFC of this type for every change..." is quite significant
>> and a major step, reversing a decision to be deliberately vague
>> on this subject when 5890ff were written.   It also binds us to
>> a strategy that many had hoped would gradually evolve into an
>> IANA activity with some expert support as experience
>> accumulated.  It commits the IETF to producing a new RFC with
>> every version and sub-version of Unicode -- somewhat over one
>> per year if recent patterns continue and my arithmetic is
>> correct.  We have rarely made such commitments and, IMO, have
>> had difficulty consistently supporting them when we have.  I
>> recommend replacing it with a statement that this document is
>> being produced because 6.0 is the first version of Unicode to be
>> released since IDNA2008 was published and leaving the future
>> somewhat more open-ended.
>>
>>    -john
>>
>>
>>
>> _______________________________________________
>> Idna-update mailing list
>> Idna-update at alvestrand.no
>> http://www.alvestrand.no/mailman/listinfo/idna-update
>>
>>
>>
> --
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst at it.aoyama.ac.jp
> _______________________________________________
> Idna-update mailing list
> Idna-update at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/idna-update
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.alvestrand.no/pipermail/idna-update/attachments/20101221/014c071e/attachment.html>