<html>
<body>
At 23:22 06/09/2011, Harald Alvestrand wrote:<br>
<blockquote type=cite class=cite cite="">On 08/10/2011 10:29 AM,
Abdulrahman I. ALGhadir wrote: <br>
<blockquote type=cite class=cite cite="">Well in this case the protocol
didn’t give any standard solution way to handle this problem rather
letting it to be treated as vendor wish (shouldn’t the rfc enacts in
making standards) or at least to acknowledge this issue and to push it to
another level e.g. Unicode URI rendering?</blockquote><br>
The group discussed the problem of detecting the presence of domain names
in free text, and the consequences of having domain names display
differently when apps treated them as domain names and when apps treated
them as free text.<br><br>
The conclusion was that detecting domain names in free text is just about
impossible, and that consistent behaviour is important to users; thus,
the WG did not recommend any special treatment for domain names, choosing
rather to live with the results of the existing BIDI
algorithm.</blockquote><br>
Abulrahman,<br><br>
Pleae remember my first question to Vint when we started this WG: was the
WG work intended to address the network technology issues with IDNs or
the users' needs. The response by James Seng that Vint did endorse, our
final consensus, and Harald's position today are consistant: to only
address the network technology issues.<br><br>
If you remember I had many reasons to oppose the WG's orientation for its
lack of intent to support orthotypography (the scripting syntax of
languages). However the RFC 5895 proposition clearly addressed this
issue. It shown that de facto the principle of subsidiarity was the
Internet response to diversity from its very inception. It was
"unusual" but the diversity was to be addressed outside of the
Internet ends. Actually, most probably at the fringes that the IAB
declared out of its scope in response to my appeals. This is why we
introduced the IDNA2010 term to label the coordination of the
needed "outside" definitions, i.e. the equivalent to the
Internet side IDNA2008, this time on the User side. And why we foresaw
IDNA2012 as the place to address the architectural overall
implications.<br><br>
These two IDNA2010 and IDNA2012 work concern other protocols (cf. the
external implications of the WG/PRECIS), the variants (cf. ICANN/WG/VIP),
the implication of the IANA and the support of the registries demanded by
the subsidiary solution, including an overall review of the SDNS
(subsidiary DN system) of which IDNA2008 has firmly established the core
(the current DNS), etc. and necessarily the support of orthotypography
which is mandatory in our French case
(<a href="http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt" eudora="autourl">
http://tools.ietf.org/id/draft-iucg-afra-reports-00.txt</a>).<br><br>
Now, the homographic and variant issues have shown that Unicode is not
sufficent enough to address the needs of the networked use needs. They
call for a WDE (whole digital ecosystem) orthotypography and
canonalization algorithms. The response of the IESG '(we were several to
ask for various reasons) has been to adopt IDNA2008 without investigating
further about the IDNA architecture and the Internet Use needs as did the
AD. Now, we can build. <br><br>
You probably may chose to implement subsidiarity to address diversity in
diverse manners. All of them will necessarily belong to
metacommunications, understanding that there are three communications
strata:<br><br>
- the telecommunications stratum, where the necessary metadata are in the
copper, on a plug to plug basis. Layer 0.Basic services.<br>
- the datacommunications stratum, where the necessary metadata are in the
header of the datagram container. Onionly added and pealed by (ISO 1 to
7) layers on an end to end value added services basis.<br>
- the metacommunications stratum, where the additional metadata are
pouring from everywhere through fringe to fringe intelligent/extended
services protocols.<br><br>
As you know the IETF is not a metacommunications body. <br><br>
In addition, what you ask for is pure orthotypography of the texts used
in an Internet (or any other technology also using domain names) context.
This is pure digital Internetwork orthotypography. It first must be
defined (and this why the IUCG collects descriptions of the different
needs), and then documented in not IETF, non Internet, but in InterUse
protocol terms that may be ported by many different media, including
Unicode if you want - but probably in using some special or user reserved
code-point that you may embed/act upon in applications or though
OPESes.<br><br>
jfc<br><br>
<br><br>
<br><br>
<blockquote type=cite class=cite cite="">
<blockquote type=cite class=cite cite=""> <br>
<br>
<b>From:</b>
<a href="mailto:idna-update-bounces@alvestrand.no">
idna-update-bounces@alvestrand.no</a>
[<a href="mailto:idna-update-bounces@alvestrand.no" eudora="autourl">
mailto:idna-update-bounces@alvestrand.no</a>] <b>On Behalf Of </b>Harald
Alvestrand<br>
<b>Sent:</b> 7/Aug/2011 11:55 PM<br>
<b>To:</b> Abdulrahman I. ALGhadir<br>
<b>Cc:</b>
<a href="mailto:idna-update@alvestrand.no">idna-update@alvestrand.no</a>
<br>
<b>Subject:</b> Re: mixing different direction labels within same
domain<br>
<br>
On 06/21/11 07:55, Abdulrahman I. ALGhadir wrote: <br>
Dear all,<br>
I am just wondering whenever it is permitted or not to have this
case:<br>
<r2l chars><num1>.<num2>.<etc ..><br>
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>
<br>
As you know in case r2l labels the display will be like this<br>
<etc..>.<num1>.<num2><r2l chars><br>
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><br>
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>
<pre> Several stronger statements were considered and
rejected, because</pre><font face="Courier New, Courier"></font><br>
<pre> they seem to be impossible to fulfill within the
constraints of
the</b></pre><font face="Courier New, Courier"></font><br>
<pre> Unicode bidirectional
algorithm</b>.</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>
<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>
<pre> </pre><font face="Courier New, Courier"></font><br>
<pre> </pre><font face="Courier New, Courier"></font><br>
<pre>_______________________________________________</pre>
<font face="Courier New, Courier"></font><br>
<pre>Idna-update mailing
list</pre><font face="Courier New, Courier"></font><br>
<pre><a href="mailto:Idna-update@alvestrand.no">
Idna-update@alvestrand.no</a></pre><font face="Courier New, Courier">
</font><br>
<pre>
<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>