<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<style id="owaParaStyle">P {
MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</style>
</head>
<body fPStyle="1" ocsi="0">
<div style="FONT-FAMILY: Tahoma; DIRECTION: ltr; COLOR: #000000; FONT-SIZE: 13px">
<div>We already have a "lot" of variation in different environments :( And they don't always match the user expectations either, unfortunately, so this is a nasty problem.</div>
<div> </div>
<div>IMO the best we can do would be to clarify what is expected when displaying an IDN/IRI, then at least the "desired" behavior is clear. Unfortunately there may still be variations though, but hopefully at least people would be able to get a consistent
behavior "in the address bar."</div>
<div> </div>
<div>We've had lots of feedback that basically indicates the UBA isn't what is expected for domain names, and is very confusing to users. At this time, it'd be pretty hard to make anything less confusing or worse :(.</div>
<div> </div>
<div>-Shawn</div>
<div style="FONT-FAMILY: Times New Roman; COLOR: #000000; FONT-SIZE: 16px">
<hr tabindex="-1">
<div style="DIRECTION: ltr" id="divRpF259781"><font color="#000000" size="2" face="Tahoma"><b>From:</b> Vint Cerf [vint@google.com]<br>
<b>Sent:</b> Sunday, February 14, 2010 12:25 PM<br>
<b>To:</b> Mark Davis ☕<br>
<b>Cc:</b> Michel Suignard; Slim Amamou; Shawn Steele; Aharon (Vladimir) Lanin; Abdulrahman I. ALGhadir; idna-update@alvestrand.no<br>
<b>Subject:</b> Re: Protocol Action: 'Right-to-left scripts for IDNA' to Proposed Standard<br>
</font><br>
</div>
<div></div>
<div>Mark,
<div><br>
</div>
<div>thanks for this - my sense is that almost anything we try to do is defeated in cut and paste scenarios where context may be lost.</div>
<div><br>
</div>
<div>vint</div>
<div><br>
</div>
<div><br>
<div>
<div>On Feb 14, 2010, at 3:23 PM, Mark Davis ☕ wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">A few comments on remarks here:
<div><br>
</div>
<div>><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span">Well as we know the IDNA protocol didn't adapt <span style="BACKGROUND-COLOR: rgb(255,255,204)" class="il">bidi</span> algorithm (UAX #9)
fully. They disallowed all <span style="BACKGROUND-COLOR: rgb(255,255,204)" class="il">bidi</span> markers (LRM,RLM,...) which are they used to solve problems from this kind.<br>
</span>
<div><br>
</div>
<div>> <span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span">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></div>
<span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span"><br>
</span>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span">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></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span"><br>
</span></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span">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></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span"><br>
</span></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span">(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></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; FONT-SIZE: 13px" class="Apple-style-span"><br>
</span></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">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></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">http://a.B.C.d/e/F/G/h?i=J&K=l&M=n&o=P</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">and have them display</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">...F/e/d.C.B.a//:http</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">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></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">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" target="_blank">PAYPAL.JOE.com</a> to appear as <a href="http://PAYPAL.JOE.com" target="_blank">
PAYPAL.JOE.com</a> in my email, and <a href="http://JOE.PAYPAL.com" target="_blank">
JOE.PAYPAL.com</a> in the address bar, and so on.</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">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></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span"><br>
</span></font></div>
<div><font class="Apple-style-span" face="arial, sans-serif"><span style="BORDER-COLLAPSE: collapse" class="Apple-style-span">Mark</span></font></div>
<div><span style="BORDER-COLLAPSE: collapse; FONT-FAMILY: arial,sans-serif; COLOR: rgb(51,51,51); FONT-SIZE: 13px" class="Apple-style-span"><br>
</span></div>
</div>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
http://www.alvestrand.no/mailman/listinfo/idna-update<br>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>