Historic scripts as MAYBE?

[Mark Davis]

You misunderstand: I'm not talking about a change by the Unicode consortium.
Let me try to be clearer: I'm talking about the version of *IDNA*. What I
said was:

"Let's suppose that IDNA 2008 is issued based on Unicode 5.1"

vs

"and that in the version [of IDNA 2008 data] corresponding to U5.2" - that
is, in the version of the IDNA data that correspond to Unicode 5.2.

So these are both referring to versions of IDNA data, not Unicode data, and
considering what would happen if we (in this committee, not Unicode)
exceptionally allow characters to change status, AND it happens that the
IANA committee or whoever decides changes to the context/exception tables
adds MODIFIER LETTER RHOTIC HOOK to PVALID, removing it from DISALLOWED.

The rest of the message is trying to consider what the consequences would
be.

Is it clearer now what I'm saying?

Mark


On Sun, Apr 27, 2008 at 11:44 PM, Patrik Fältström <patrik at frobbit.se>
wrote:

>
> On 28 apr 2008, at 06.36, Mark Davis wrote:
>
>  I'll give a concrete case. Let's suppose that IDNA 2008 is issued based
> > on
> > Unicode 5.1, and that in the version corresponding to U5.2, PVALID were
> > updated to include MODIFIER LETTER RHOTIC HOOK (and it was removed from
> > DISALLOWED).
> >
>
> If that change is made in Unicode between 5.1 and 5.2, then from my
> personal point of view, then Unicode Consortium is not keeping the level on
> promise regarding stability that I hope they do.
>
> But if that change has to be made by Unicode Consortium between 5.1 and
> 5.2, then the tables document should be updated in sync with the deployment
> of Unicode 5.2, and I think the codepoint should be added to the backward
> compatibility list as DISALLOWED overriding the change made in Unicode
> Consortium.
>
> But, of course, when the tables RFC is overridden by a new one, then of
> course a decision can be made by the IETF to stay in sync with Unicode
> Consortium and allow a backward incompatible change to the algorithm.
>
> A big, hard decision. Very very very difficult decision to make given the
> implications in the DNS.
>
> I do know though UTC is very very aware of the implications of making
> incompatible changes, including legal implications regarding registrations
> in the DNS. Because we have had this discussion before.
>
>   Patrik
>
>


-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080427/49fea2bc/attachment-0001.html