What has to be stable? (was Fwd: Comments on IDNAbis tables-03)

Patrik Fältström patrik at frobbit.se
Fri Jan 18 11:40:58 CET 2008


On 16 jan 2008, at 22.38, Mark Davis wrote:

> Define the following contributing properties, initially empty. Make  
> the
> rules for ALWAYS and NEVER always include them (and exclude the  
> converse
> ones).
>
>
>   - ALWAYS_INCLUSIONS
>   - NEVER_INCLUSIONS
>
> With each version X of Unicode, update them so to include any  
> characters
> that were in ALWAYS or NEVER according to version X-1, but wouldn't be
> according to X without these properties.

I am for the next revision of the tables document adding text about  
such a solution.

> The updates could be best be done by the Unicode consortium as a  
> separate
> so-called contributing property, but it is perfectly possible for  
> any other
> organization to do it independently if you're nervous about that.

I am not nervous (as you know), and I just want to have a correct list  
somewhere that is the stable reference. In my mind at the moment is  
the following:

- IDNA200x will because of many reasons that are listed in John's  
documents (and discussed in the context of his documents -- not here)  
have potentially more and more detailed registries of things with IANA  
than what IANA already have for IDN today.

- We use a standard IETF IANA Consideration mechanism that say that  
IANA is to use "An appointed expert" to assist them with the IDN  
related issues.

- One of the tables IANA is to keep is each one of the derived  
property values that is calculated according to the algorithm in the  
tables document. For each version of Unicode that is released.

- I have in the non-released draft of my document a new rule (rule I  
-- a rule that I earlier by mistake used for other things that is not  
needed anymore) that are also exceptions. This set of exceptions will  
now to start with be empty. But, in the future it should include the  
difference between what you called ALWAYS and  
IS_OR_HAS_AT_SOME_POINT_IN_TIME_BEEN_ALWAYS (or whatever it was). I.e.  
if some property of a codepoint is changing so that the codepoint  
might move from ALWAYS or NEVER, then that codepoint is added to this  
rule I. So that we are 100% sure what is added to ALWAYS or NEVER will  
always stay there.

- This gives the following responsibilities to the appointed expert:

   1. Ensure that that table that IANA has is created, for example by  
you, when a new version of Unicode is released.
   2. Checking with the previous version of Unicode whether the  
difference is such that he recommends that an update to the tables  
document is to be created with rule I updated.
   3. Ensure ICANN, IETF and Unicode Consortium are continuing to work  
together regarding these tables.

> As
> discussed in earlier email, we've been doing this kind of thing for  
> years
> with the current Unicode identifiers, and there are a very small  
> number of
> characters affected. Note some work needs to be done with each  
> version of
> Unicode anyway, since as new scripts come in, they have to be put in  
> one or
> another buckets.

Yes.

>> b. What differences exists between IDNA2003 and the tables document?
>>
> Well, the easiest way to play with that is to use the utilities I  
> mentioned.

Thanks for this tool Mark!
:
:
> Hope that helps...

It does.

    paf



More information about the Idna-update mailing list