<html>
<body>
Dear Abdulrahman, dear Slim,<br><br>
we try to consolidate all the post-IDNA2008 points that are now to be
addressed at Internet technology level (including those with an impact on
the protocols but belonging to the architectural level that we plan to
consolidate further on). This mostly concerns inputs from IANA, IAB,
IETF/WG/IDNA2008, IETF/WG/PRECIS, ICANN/WG/VIP, UNICODE, IUCG, IUTF,
ALFA, ITU, John Klensin, Andrew Sullivan, Paul Hoffman, Vint Cerf, etc.
The target is to help them all to consistently work in being aware of all
the issues and in using the same terms with the same meaning.<br><br>
The current version of this compilation is at
<a href="http://iucg.org/wiki/IDNS_Common_Glossary" eudora="autourl">
http://iucg.org/wiki/IDNS_Common_Glossary</a>.<br><br>
Once we have compiled all the potocol level issues we will propose all
the concerned parties to consolidate them into a common Draft to
everyone's benefit and for us to complete the design of an ML-DNS
prototype implementation, i.e. a multi-layer, multi-prupose
(intertechnology), multi-orthotypography IDNA2008 conformant
front-end of the IDNA2008 stabilised Internet DNS.<br><br>
Among the points we noted there is the Bidi issue
<a href="http://iucg.org/wiki/Bidi_discussion" eudora="autourl">
http://iucg.org/wiki/Bidi_discussion</a> that you raised on 2/14/2010.
Harald's response is at the IDNA2008 level (on the Internet side). The
question now is to know how to address it at the use level: I would be
interested in a description of the problem which could permit a solution
at protocol, use or architural level. <br><br>
I thank you if you can help us.<br>
jfc<br><br>
<br>
At 22:55 07/08/2011, Harald Alvestrand wrote:<br>
<blockquote type=cite class=cite cite="">On 06/21/11 07:55, Abdulrahman
I. ALGhadir wrote: <br>
<blockquote type=cite class=cite cite="">Dear all,<br>
I am just wondering whenever it is permitted or not to have this
case:<br>
<r2l chars><num1>.<num2>.<etc
..></blockquote>This particular case has all labels legal, but the
overall display name will display very oddly (as noted). The oddity is
caused by our inability to mandate whole-domain tests, as described in
the RFC.<br><br>
It is logical for the administrator of <etc ..> to forbid
registration of leading-numeric labels if it anticipates R2L labels at
the next level down, and it is logical for application writers to simply
reject such names because they are going to confuse the users (much in
the spirit of Firefox' refusal to do mixed-script names), but the RFC
does not require them to do so.<br><br>
<blockquote type=cite class=cite cite="">As you know in case r2l labels
the display will be like this<br>
<etc..>.<num1>.<num2><r2l chars></blockquote>I
think the display will depend on the direction of <etc> and whether
it is in an RTL context or an LTR context, but I'm still not confident of
my ability to execute the BIDI algorithm in my head.<br>
<blockquote type=cite class=cite cite="">As you see both of them have
different display order which isn’t the same as network order.<br>
And I know it is mentioned in the RFC <br>
<br><br>
<br>
<pre> Several stronger statements were considered and
rejected, because</pre><font face="Courier New, Courier"></font><br><br>
<pre> they seem to be impossible to fulfill within the
constraints of
the</pre><font face="Courier New, Courier"></font><br><br>
<pre> Unicode bidirectional
algorithm.</pre><font face="Courier New, Courier"></font> <br>
And one of the statement is <br>
<br>
o The sequence of labels should be consistent with network
order.<br>
This proved impossible -- a domain name
consisting of the labels<br>
in network order) L1.R2.R3.L4 will be
displayed as L1.R3.R2.L4 in<br>
an LTR context. (In an RTL context,
it will be displayed as<br>
L4.R3.R2.L1)<br>
<br><br>
<br>
<pre> </pre><font face="Courier New, Courier"></font> <br>
And I have tried two implemented tools (well I don’t know if they follow
the RFC fully or not).<br>
<br><br>
<a href="http://unicode.org/cldr/utility/idna.jsp?a=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9#notes">
http://unicode.org/cldr/utility/idna.jsp?a=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9#notes</a>
<br><br>
<a href="http://mct.verisign-grs.com/conversiontool/convertServlet?input=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9&type=UTF8" eudora="autourl">
http://mct.verisign-grs.com/conversiontool/convertServlet?input=%D8%B1%D8%A7%D8%A6%D8%AF888.999.%D8%A7%D9%84%D8%B3%D8%B9%D9%88%D8%AF%D9%8A%D8%A9&type=UTF8</a>
<br>
<br>
<br>
Abdulrahman,<br><br>
<br>
<pre>
_______________________________________________
Idna-update mailing list
<a href="mailto:Idna-update@alvestrand.no">Idna-update@alvestrand.no</a>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a>
</pre><font face="Courier New, Courier"></font></blockquote><br>
_______________________________________________<br>
Idna-update mailing list<br>
Idna-update@alvestrand.no<br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" eudora="autourl">
http://www.alvestrand.no/mailman/listinfo/idna-update</a></blockquote>
</body>
</html>