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.<br><ol><li>It is vital that the IDNA assignments do not fluctuate across releases of Unicode.</li>
<li>The Compatibility category is designed to ensure that.</li></ol>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.<br>
<br>
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".<br><br>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.<br>
<br>Mark<br><br><div class="gmail_quote">On Mon, Apr 28, 2008 at 12:37 AM, Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 28 apr 2008, at 09.12, Mark Davis wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
*I'll give a concrete case. Let's suppose that in IDNA 2008-U5.2**, the IETF<div class="Ih2E3d"><br>
(through some mechanism) changes PVALID to include MODIFIER LETTER<br></div>
RHOTICHOOK (and removed from DISALLOWED). Unicode 5.2 also adds a new<div class="Ih2E3d"><br>
assigned<br>
letter, U+xxxx IMPORTANT THAI CHARACTER, which is thus automatically added<br>
to IDNA 2008-U5.2 as PVALID (it was UNASSIGNED in **IDNA 2008-U5.1)**.*<br>
<br>
- *Application A implements **IDNA 2008-U5.1**, and it is not updated<br>
for 10 years. (Patrik's case)<br>
*<br></div>
- *Application B updates to **IDNA 2008-U5.2**.*<br>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
If UTC assigns values that are "good enough", then the IDNA2008 algorithm do _NOT_ have to be updated when Unicode 5.2 is released.<br>
<br>
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".<br>
<br>
These changes should NOT happen!<br><font color="#888888">
<br>
Patrik<br>
<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Mark