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