simon,<div><br></div><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><br></div><div>vint</div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Mon, Feb 21, 2011 at 4:34 PM, Simon Josefsson <span dir="ltr"><<a href="mailto:simon@josefsson.org">simon@josefsson.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">Patrik Fältström <<a href="mailto:patrik@frobbit.se">patrik@frobbit.se</a>> writes:<br>
<br>
> On 21 feb 2011, at 21.58, Simon Josefsson wrote:<br>
><br>
>> I didn't understand John's argument that we have an incompatibility<br>
>> regardless of what we do<br>
><br>
> Either we have stability in the algorithm (as now proposed) or we have<br>
> stability in the table which is the result of the calculation of the<br>
> algorithm.<br>
><br>
> IDNA2008 is defined as being an _algorithm_ that should be stable, so<br>
> an application can apply it regardless of what version of Unicode we<br>
> talk about.<br>
><br>
> Because the algorithm is based on property values that now changes for<br>
> three codepoints, the result of the calculation is not stable.<br>
><br>
> The alternative would be to change the algorithm, and that would make<br>
> the codepoints not change, but the algorithm changes.<br>
><br>
> IDNA2003 was a table based solution.<br>
><br>
> IDNA2008 is an algorithm based solution.<br>
<br>
</div>I don't follow this -- Mark is not proposing to change the algorithm.<br>
If I understand him, he proposes to add U+19DA to section G in order to<br>
make the IDNA2008 algorithm produce stable results independent of<br>
Unicode version.<br>
<br>
Again, what practical incompatibility is there in following Mark's<br>
proposal?  An illustration would go a long way to convince me here, as I<br>
believe Mark has illustrated that by _not_ adding another exception to<br>
the list of exceptions, we will create two incompatible IDNA2008<br>
algorithms: IDNA2008 with Unicode 5.2/6.0 vs IDNA2008-with-RFC5892bis<br>
with Unicode 6.0.<br>
<font color="#888888"><br>
/Simon<br>
</font><div><div></div><div class="h5">_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br></div>