Historic scripts as MAYBE?
patrik at frobbit.se
Mon Apr 28 09:37:08 CEST 2008
On 28 apr 2008, at 09.12, Mark Davis wrote:
> *I'll give a concrete case. Let's suppose that in IDNA 2008-U5.2**,
> the IETF
> (through some mechanism) changes PVALID to include MODIFIER LETTER
> RHOTICHOOK (and removed from DISALLOWED). Unicode 5.2 also adds a new
> letter, U+xxxx IMPORTANT THAI CHARACTER, which is thus automatically
> to IDNA 2008-U5.2 as PVALID (it was UNASSIGNED in **IDNA 2008-
> - *Application A implements **IDNA 2008-U5.1**, and it is not
> for 10 years. (Patrik's case)
> - *Application B updates to **IDNA 2008-U5.2**.*
See the previous mail. I take for granted that UTC in the future will
look carefully at how the attributes they set to codepoints (general
category etc). If UTC does, then IETF does not have to update the RFC
when Unicode 5.2 is published.
You point at the case when UTC when creating 5.2 make such a decision
regarding the codepoint so that IETF see it being forced to (a) create
this incompatible change and (b) add the codepoint in question to the
I would call this a big crisis and a situation UTC and IETF should
NEVER put the community in. We can do better than that.
If UTC assigns values that are "good enough", then the IDNA2008
algorithm do _NOT_ have to be updated when Unicode 5.2 is released.
But, I pointed out this situation myself when one codepoint was
changed between Unicode 5.0 and 5.1 and asked whether people wanted
that in the backward compatibility exceptions list of IDNA2008. The
consensus on this list was (my reading) that as IDNA2008 is not
released yet, we can handle this very very very exceptional case. And
I think I saw someone from UTC saying things that I interpreted as
(this is not a quote) "we took into consideration that IDNA2008 was
not released when we made the decision on this change".
These changes should NOT happen!
More information about the Idna-update