<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 8/8/2014 11:32 AM, Jefsey wrote:<br>
</div>
<blockquote cite="mid:20140808183257.6495B7C3CB9@mork.alvestrand.no"
type="cite"><br>
<blockquote type="cite" class="cite" cite=""><b>At 02:27
08/08/2014, Andrew
Sullivan wrote:</b><br>
I don't think that's a fair characterization. Nobody is
"second-guessing" anything. It's rather that we -- John,
actually -- discovered that there's a consequence of this case
that we
did not previously understand, and it has uncomfortable
consequences for
the way we had previously relied on Unicode, because it didn't
work the
way we thought. </blockquote>
<br>
Dear Andrew,<br>
May be time to reconsider the idea of an IETF Unicode including
our
exception management through an additional protocol rather than
only by
Patrik's tables? </blockquote>
<br>
<font face="Candara">"Additional protocol" sounds like it's headed
in the right direction. <br>
<br>
There are already several levels to this<br>
</font>
<ul>
<li><font face="Candara">Unicode (repertoire and basic
normalization)</font></li>
<li><font face="Candara">IDNA (including repertoire and context
rules)</font></li>
<li><font face="Candara">Label Generation Rulesets (including
repertoire, context rules and blocked variants)</font></li>
<li><font face="Candara">String Review (case by case)<br>
</font></li>
</ul>
<font face="Candara">Of these, the formulation of Label Generation
Rulesets allow a solution to issues like these that can be used to
address issues like the current one without the need to pick an
arbitrary preferred encoding. They provide ways to specify a
first-come, first-serve, but mutually exclusive selection among
alternatives, which is much less "linguistically damaging" than
blunt restrictions repertoire alone.<br>
<br>
What is missing, but what keeps surfacing in the discussions
around creating the LGR for the Root Zone is the need for
enforceable "best practices" on LGRs.<br>
<br>
If there was an "additional protocol" where problematic cases
could be identified and translated into a binding requirement on
LGRs (and therefore registration policies) to either disallow all
but one of the alternatives, or to have a robust way of mutually
excluding labels from registration (using the blocked variant
mechanism) then it would seem that you get the effect of robust
lookup, without having to arbitrarily play linguistic favorites.<br>
<br>
The same protocol could be applied to handle any new registrations
for the many similar cases of homoglyphs and homographs, whether
across scripts or within scripts. <br>
<br>
Being less "linguistically damaging" it is amenable to be employed
in a wider selection of cases as well.<br>
<br>
A./<br>
<br>
<br>
</font>
</body>
</html>