One thing that I think has people a bit tied up in knots is the way that stability is being handled in the current drafts. In the drafts, labels with assigned characters will be either valid forever, invalid forever, or in limbo (eg valid now but could change to invalid later). The limbo situation arises when there is a CONTEXT character, because the rules could be tightened in the future. Labels with UNASSIGNED characters can move into one of these three classes.<br>
<br>For the vast bulk of characters, there is no problem; the property-based allocation works fine. But for the very small set of exceptional characters, there is an issue. Because the "invalid forever" rule is in the drafts, we get tied up in figuring out whether this or that very exceptional character should be moved to CONTEXT or PVALID, because it is set in stone once IDNA200x comes out. However, I think with a small change to the mechanisms in the drafts, we can improve the overall stability and avoid having to make some rash decisions; and this change will improve the stability situation in the ways that matter.<br>
<br><br>For us, and many other organizations, the key requirement is the stability of <i>valid</i> labels: once a label is valid, it is valid forever. Stability of invalid labels is actually not in play anyway; as new characters get assigned, once-invalid labels become valid, and on a regular basis as ever more characters are added to Unicode. If, exceptionally, a character migrates from DISALLOWED to CONTEXT, that really doesn't cause a problem for software since we *must* be able to handle invalid labels becoming valid, anyway (because of new assigned characters).<br>
<br><div style="margin-left: 40px;">Note: the migration from CONTEXT to PVALID is effectively already allowed in the drafts; it just means loosening the context rules until they have no effect.<br></div><br>The flip side is that we <i>really</i> don't want valid labels to become invalid. That <i>does</i> cause a problem for software, and is worth major efforts to avoid. Look at all the work we had to do in BCP 47, for example. To fix that problem, what we would have to do is have stability for context rules, so that once a character gets a context rule, no future version of the rule can further restrict the labels that it can appear in.<br>
<br>So, my proposal is to:<br><br>1) allow characters to migrate from DISALLOWED to CONTEXT.<br>2) disallow CONTEXT rules from becoming more restrictive.<br><br>We already need to have a mechanism (though not fully fleshed out yet) for handling the CONTEXT rules; procedurally the step of doing #1 can be added to that mechanism. In both of these cases, we want the mechanism to be very conservative in making changes.<br clear="all">
<br>-- <br>Mark