New version, draft-faltstrom-idnabis-tables-02.txt, available

[Patrik Fältström]

On 20 jun 2007, at 10.12, Michael Everson wrote:

> Harder in what way?
>
> I don't think you can get away with updating without human  
> intervention, discussion, and decision. The writing systems of the  
> world are not tidy.
>
> If you take this notion on board and embrace it, I think you will  
> be more comfortable about updating to future versions of Unicode.

The Unicode Consortium have already today a process when adding  
codepoints to decide on the property values that today exists.

I see a big difference between:

  - Having the IETF use those properties and calculate what  
codepoints can be used in IDN
  - Having IETF ask Unicode Consortium to define a new property,
    and learn how to evaluate for every codepoint added what property
    value it should have

So, starting to have rules for individual codepoints will be a  
completely different kind of thing than an algorithm based on  
existing properties, and one of the reasons IDNA is locked today to  
Unicode 3.2.

I.e. I am extremely nervous implications will be that IDNA200x vill  
be locked to Unicode 5.0 because of this (or 5.1 or whatever fixed  
version) just like IDNA we have today.

I was hoping the existing properties would be enough for doing  
IDNA200x, and I have still not given up. If the Unicode people tell  
me that is not possible, then things changes quite drastically.

Yes, I have heard you personally (and others) say that one have to  
have exceptions here and there, but I have still been hoping we do  
not have to have that. We have sort of had this discussion before,  
but never really dived into the question of "what happens if we do  
NOT have the exceptions, how bad is that" and compare with the  
implications of doing inspection on codepoint level. Is it worth it  
(regardless of what path we choose)?

This is definitely the time when we should have the discussion.

      Patrik