tables document [Re: IDNA comments]

Paul Hoffman phoffman at imc.org
Sat Jul 12 20:38:06 CEST 2008


At 9:12 AM +0200 7/12/08, Patrik Fältström wrote:
>  >   3. "It should be suitable for newer revisions of Unicode, as long 
>>  as the
>>    Unicode properties on which it is based remain stable."
>>    Replace by
>>    "This is suitable for any newer versions of Unicod as well. 
>>  Changes in
>>    Unicode properties that do not affect the outcome of this process 
>>  do not
>>    affect IDN. For example, a character can move from So to Sm, or 
>>  from Lo to
>>    Lu, without affecting the table results. Moreover, even if such 
>>  changes were
>>    to result, the BackwardCompatible list (2.2.3.) will be adjusted to
>>    ensure the stability of the results."
>
>Thanks. I will though probably in the last sentence not say "...will 
>be..." but instead "...can be..." as my view is that at the point in 
>time where such an unfortunate incompatibility is detected, this 
>document has to be updated. At that update one can choose to either 
>add the codepoint to 2.2.3 or not (in reality, choose to add to 2.2.3 
>and update the document or not update the document but accept the 
>incompatibility).
>
>Ok with people?

The "can be" works for me. Using "will be" makes it sound more like 
it is acceptable for TUC to make unacceptable changes.

>  >   8. Sort the following by value instead of code point, for clarity.
>>    Ideally each value would be in its own subsection: PVALID, 
>>  CONTEXTO,...
>>
>>       002D; CONTEXTO  # HYPHEN-MINUS
>>       ...
>>       3007; PVALID    # IDEOGRAPHIC NUMBER ZERO
>>       303B; CONTEXTO  # VERTICAL IDEOGRAPHIC ITERATION MARK
>>       30FB; CONTEXTO  # KATAKANA MIDDLE DOT
>
>Hmm...what do people think here? I can see reasons to have the 
>codepoints (in the same script) "close" to each other (as it is now), 
>while still of course understand this suggestion.

The list is not long enough for either ordering to be much of a problem.

>Should also the appendix be sorted in a different way (add an Appendix
>B in addition to existing Appendix A)?

A second appendix would be more confusing. I think the current 
appendix is barely readable as it is. Fortunately, it is 
non-normative.


More information about the Idna-update mailing list