Historic scripts as MAYBE?

[Mark Davis]

Patrik, we had this discussion at great length, some time ago, so I don't
want to repeat it. Let me just hit the high points.

   1. It is vital that the IDNA assignments do not fluctuate across
   releases of Unicode.
   2. The Compatibility category is designed to ensure that.

The Unicode properties are used by a huge number of clients, not just IDN,
and many of them prefer correctness over stability. So while stability is
very important, there will be times where the properties change. Ken sent
out a message with examples of what would have happened in the past.

That is *precisely* the reason for the Compatibility category of characters
in the IDNA table formulation, so that the IDNA properties can remain
absolutely stable even if Unicode has to change a bit in a given release.
There is no "crisis".

What I am talking about is something different; the ability for the IETF
itself (not Unicode) to change the values in the exception table, to a very
limited extent, and only in "exceptional" cases, with the same process as
used to update the CONTEXT tables -- without issuing an obsoleting RFC.

Mark

On Mon, Apr 28, 2008 at 12:37 AM, Patrik Fältström <patrik at frobbit.se>
wrote:

> 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
> > assigned
> > letter, U+xxxx IMPORTANT THAI CHARACTER, which is thus automatically
> > added
> > to IDNA 2008-U5.2 as PVALID (it was UNASSIGNED in **IDNA 2008-U5.1)**.*
> >
> >  - *Application A implements **IDNA 2008-U5.1**, and it is not updated
> >  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 exception
> table.
>
> 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!
>
>   Patrik
>
>


-- 
Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20080428/9634fcc2/attachment.html