Various people may want different things; that doesn't mean that all desires can be simultaneously satisfied -- one has to balance the importance. And to balance, one needs to have a clear statement as to the pros and cons.<br>
<br>There is a distinct cost to making DISALLOWED be permanent, once assigned. While I would expect the number of future exceptional characters to be very small, I posed the following question:<br><br><div style="margin-left: 40px;">
> For example, as an exception, suppose that <code><a href="http://unicode.org/cldr/utility/character.jsp?a=02DE" target="_blank">U+02DE</a></code> ( ˞ ) MODIFIER LETTER <span class="nfakPe">RHOTIC</span>
HOOK were to to be added in some future version to the exception list,
because it was found to be needed for a particular African language.
This would involve changing from DISALLOWED to ALLOWED. What would be
the practical problem that this causes?<br><br></div>Let's suppose that it was *your* language at stake, and you could not us som vry ky lttr -- you wouldn't xactly lik it. So we have to weigh the advantage, if any, of an unyielding filter on the client side against the ability to make an exceptional, but perhaps necessary, change in the future.<br>
<br>You say "Patrik's statements about what a developer would want (a stable list of
what is prohibited so they can filter) seems logical to me." But what is the case to be made for that? I'm not hearing any concrete examples. Why is this so important that it be set in stone? I fully understand the requirement of backwards compatibility for *valid* labels, but not for (only some) *invalid* ones.<br>
<br>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 <span class="nfakPe">RHOTIC</span>
HOOK (and it was removed from DISALLOWED). U5.2 also adds a new assigned character, U+xxxx IMPORTANT THAI CHARACTER.<br><ul><li>Application A implements the u5.1 version, and never changes (Patrik's case). </li><li>Application B updates to the U5.2 version.</li>
</ul>Application A will disallow some perfectly valid U5.2 labels; labels that Application B allows. That is, it will disallow both RHOTIC HOOK and IMPORTANT THAI CHARACTER. Application B will allow both of them. What advantage is it to functionally distinguish between these two characters? Why is it vital for Application B or A to do so?<br>
<br>Mark<br><br><div class="gmail_quote">On Sun, Apr 27, 2008 at 8:39 PM, Paul Hoffman <<a href="mailto:phoffman@imc.org">phoffman@imc.org</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;">
<div class="Ih2E3d">At 7:42 PM -0700 4/27/08, Mark Davis wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
True, but remember that there is no bright line with "archaic/historic".<br>
</blockquote>
<br></div>
I took inclusion in Chapter 14 of TUS to be a bright enough line. Maybe you're saying it isn't.<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
If you mean: "nobody uses it", then no script qualifies!<br>
</blockquote>
<br></div>
I do not mean that at all. I mean "another qualified standards body has defined it for us".<div class="Ih2E3d"><br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I have gotten no reply back from my message of 5 days ago ("Re: Stability of valid IDN labels"). Without some concrete user scenerios making a compelling case, all we have a bald statement about unnamed "application creators". That is hardly the way to go about doing a specification.<br>
</blockquote>
<br></div>
We disagree. Patrik's statements about what a developer would want (a stable list of what is prohibited so they can filter) seems logical to me. You might code differently, of course. If we go down a path where we require that developers code in a certain fashion, that makes the spec much more fragile.<br>
</blockquote></div><br><br clear="all"><br>-- <br>Mark