<font face="georgia,serif">> <meta charset="utf-8"><span class="Apple-style-span" style="font-family: arial; ">Others, including me, have some discomfort with preserving these previous (mis)classifications without exception.</span></font><div>
<font face="georgia,serif"><br></font></div>That has not proved to be a problem with Unicode identifiers. None of the characters listed in under <span class="Apple-style-span" style="font-family: monospace; white-space: pre-wrap; font-size: medium; ">Other_ID_*</span>, are problematic for Unicode identifiers, for example. Nor would they be problematic for IDNA2008 if it had been instituted back in 2002, with such an automatic rule for adding to Section G.<div>
<br></div><div>However, I can appreciate your position, which I think would be:<div><div><div><ul><li>Maintain stability of labels (i.e., once valid, always valid) unless there is a compelling reason not to.</li></ul></div>
<div><div><div>It is different than what is the position taken in draft-faltstrom-5892bis-02.txt, however.</div></div></div></div></div></div><div><br></div><div><div><div><div><div><div><font face="georgia, serif">Mark<br>
<br><i>— Il meglio è l’inimico del bene —</i></font><br>
<br><br><div class="gmail_quote">2011/2/21 Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div>there is a user side to this - and it isn't simple either. In one view, user expectations about the fitness of a character for use in domain names is sometimes tied to its linguistic function (e.g. is it a "letter" in the Unicode sense as opposed to, say, a "symbol"?</div>

<div><br></div><div>Unicode workers have misclassified characters in the past, leading to valid registrations which might later be considered invalid because the character has been reclassified in a later version of Unicode. Or we have the cases of the sharp-S where the addition of a character makes the earlier mapped practice a surprise because of the (new) introduction of, in this case, a lower case version of sharp-S. </div>

<div><br></div><div>I am not trying to revisit old debates as much as I am trying to highlight the continuing difficulty of dealing with reclassifications. Additions of new characters is the easier case but changes are really troubling. If they are allowed and registrations permitted and then there are changes in Unicode giving them properties invalidating their validity for use in domain names, we have to decide whether to promulgate the previous condition (allowing what is now under the Unicode properties an invalid character) or to alter the derived table (from the IDNA2008 rules) and thus make invalid an earlier registration. If user intuition favors the invalidation (ie it would not be expected that this would be a valid character for domain names) then promulgating the previous classification is counter-intuitive. On the other hand, previously allowed registrations that are invalidated lead to other kinds of confusion. In the end, the IETF or at least the working group has treated these cases idiosyncratically because of the ambiguity in deciding what will be least confusing in some sense.</div>

<div><br></div><div>We could adopt the view that once decided, even if Unicode versions change properties, we will keep persistent all earlier classifications - that is how I interpret Mark's position. Others, including me, have some discomfort with preserving these previous (mis)classifications without exception.</div>

<div></div></blockquote></div><br></div></div></div></div></div></div>