<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=Content-Type content="text/html; charset=utf-8">
<meta name=Generator content="Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.apple-style-span
{mso-style-name:apple-style-span;}
span.il
{mso-style-name:il;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=EN-US link=blue vlink=purple>
<div class=Section1>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:black'>A question about this:<o:p></o:p></span></p>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif";
color:black'>>However, it is possible and conformant to UBA to have a higher
level protocol that reorders labels in a domain name, >and in the path, and
in the query, because it allows for such specialized overrides specifically. So
you could take the >following internal string with characters from left to
right</span></span><span style='color:black'><o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:black'>How hard is it to make higher level(a standard sort of) either to
be part of Unicode or something else for recognizing strings of type
<something>@<something> , <protocol>://<something> ,.. all
of IRI strings?.<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:black'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:black'>Abdulrahman,<o:p></o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'><o:p> </o:p></span></p>
<p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";
color:#1F497D'> <o:p></o:p></span></p>
<div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'>
<p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span
style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> mark.edward.davis@gmail.com
[mailto:mark.edward.davis@gmail.com] <b>On Behalf Of </b>Mark Davis ?<br>
<b>Sent:</b> 14/Feb/2010 11:23 PM<br>
<b>To:</b> Michel Suignard<br>
<b>Cc:</b> Shawn Steele; Slim Amamou; Abdulrahman I. ALGhadir;
idna-update@alvestrand.no; Aharon (Vladimir) Lanin<br>
<b>Subject:</b> Re: Protocol Action: 'Right-to-left scripts for IDNA' to
Proposed Standard<o:p></o:p></span></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<p class=MsoNormal>A few comments on remarks here:<o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>><span class=apple-style-span><span style='font-size:
10.0pt;font-family:"Arial","sans-serif"'>Well as we know the IDNA protocol
didn't adapt </span></span><span class=il><span style='font-size:10.0pt;
font-family:"Arial","sans-serif";background:#FFFFCC'>bidi</span></span><span
class=apple-style-span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> algorithm
(UAX #9) fully. They disallowed all </span></span><span class=il><span
style='font-size:10.0pt;font-family:"Arial","sans-serif";background:#FFFFCC'>bidi</span></span><span
class=apple-style-span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'> markers
(LRM,RLM,...) which are they used to solve problems from this kind.</span></span><o:p></o:p></p>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal>> <span class=apple-style-span><span
style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Well I don't think so
it can be done in UAX#9 (well if URI has its own rules) the UAX#9 does know
about the nature of characters (Neutral,RTL,LTR,week..) the context direction
etc.. and thus there are possible ways to fix this issues in UAX#9 rather than
IDNA itself.</span></span><o:p></o:p></p>
</div>
<p class=MsoNormal><o:p> </o:p></p>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>Changing UAX#9 (aka UBA) at this point would
be very difficult, because of stability concerns. We've seen before where very
minor changes to it have caused many problems for users, because it changes the
layout of existing documents. While not impossible, one would have to make a
very good case for the change, and be prepared to demonstrate, with compelling
data, that the benefit would be worth the cost.</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>The UBA was designed for plain text, not
special syntax. And no matter how it was structured, it was always clear that
one would need to be able to override the default; to that end, the marks and
overrides were added. Because those are disallowed in IDNA, this tool is not
available, however. The reason to not allow those in IDNA was because of
the opportunity for constructing, artificially, very confusable IRIs.</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-size:10.0pt;
font-family:"Arial","sans-serif"'>(BTW Looking back at it, one of the problems
with the UBA was that it tried to do too much. There is a tension between
heuristics and predictability, and if we could go back in time and redo it, one
of the things I'd change would be to reduce the heuristics, especially around
numbers, so as to make it more predictable for users.)</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>However,
it is possible and conformant to UBA to have a higher level protocol that
reorders labels in a domain name, and in the path, and in the query, because it
allows for such specialized overrides specifically. So you could take the
following internal string with characters from left to right</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>http://a.B.C.d/e/F/G/h?i=J&K=l&M=n&o=P</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>and
have them display</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>...F/e/d.C.B.a//:http</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>This
would be possible, but is not necessarily a good idea. The problem comes in the
interaction between those environments that (a) look for IRIs and handle them
this way, and (b) environments that don't parse for IRIs, or don't recognize
them or their fragments, or don't display them in the 'new' way once they have
them. There is already the issue of display being different in RTL vs LTR
paragraphs; you don't want typing in one environment within RTL to give yet
different results than in another within RTL.</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>And
we know that recognizing IRIs (and fragments thereof) occurring in plain text
is difficult. You don't want <a href="http://PAYPAL.JOE.com">PAYPAL.JOE.com</a>
to appear as <a href="http://PAYPAL.JOE.com">PAYPAL.JOE.com</a> in my
email, and <a href="http://JOE.PAYPAL.com">JOE.PAYPAL.com</a> in the
address bar, and so on.</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>So
any design for having a special ordering for IRI BIDI elements has to take a
host of issues into account. I'm not saying that it can't be done, but it is a
big job, and any transition has be be extremely carefully considered. Various
people in Unicode have considered it at one time or another, but we've just
never seen a clear path forward.</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
<div>
<p class=MsoNormal><span class=apple-style-span><span style='font-family:"Arial","sans-serif"'>Mark</span></span><o:p></o:p></p>
</div>
<div>
<p class=MsoNormal><o:p> </o:p></p>
</div>
</div>
</div>
<pre>
-----------------------------------------------------------------------------------
Disclaimer:
This message and its attachment, if any, are confidential and may contain legally
privileged information. If you are not the intended recipient, please contact the
sender immediately and delete this message and its attachment, if any, from your
system. You should not copy this message or disclose its contents to any other
person or use it for any purpose. Statements and opinions expressed in this e-mail
are those of the sender, and do not necessarily reflect those of the Communications
and Information Technology Commission (CITC). CITC accepts no liability for damage
caused by this email.
</pre></body>
</html>