<br><div class="gmail_quote">2009/12/2 Patrik Fältström <span dir="ltr">&lt;<a href="mailto:patrik@frobbit.se" target="_blank">patrik@frobbit.se</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">

Protocol elements, in the broader sense, should only consist of labels<br>
that are stable and &quot;ok&quot; according to IDNA2008, including bidi rules,<br>
PVALID in tables (or context rules ok) etc.<br>
<br>
No upper case, no unallocated, no dissallowed characters etc.<br>
<br>
I am afraid that is the only thing we 100% can guarantee.<br>
<br>
And this was one of the things that was confusing in IDNA2003. Some<br>
people thought mapped codepoints where ok, and got confused in cases<br>
dns returned other codepoints.<br></blockquote><div><br>The mapping phase in IDNA2003 worked. Every implementation of IDNA2003 followed it; it was always predictable. <br><br>It may be the case that it was confusing on the registration side, and it doesn&#39;t hurt to remove it there. So while there isn&#39;t an established benefit, the impact is minimal.<br>

</div><div><br></div><div>On the lookup side, it is different. There has been no hard evidence that mapping was a problem (excluding the 4 deviation characters, since we&#39;re discussing them elsewhere); no figures, no data, just a lot of handwaving. So there is no established benefit to dropping them, and a significant negative impact for dropping them.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="border-left:1px solid rgb(204, 204, 204);margin:0pt 0pt 0pt 0.8ex;padding-left:1ex">
<br>
Then there are boundary cases that might work, depending on use. Very<br>
hard to describe scenarios as many parameters are included in &quot;works&quot;.<br>
PTR records match? Cert match? Spamassassin rules increasing score if<br>
not fqdn is in use? User interface and keyboard mappings?<br>
<br>
    Patrik<br>
<br>
<br>
<br>
On 2 dec 2009, at 16.06, Lisa Dusseault &lt;<a href="mailto:lisa.dusseault@gmail.com" target="_blank">lisa.dusseault@gmail.com</a>&gt;<br>
wrote:<br>
<div><div></div><div><br>
&gt; I&#39;d like to try to unpack some of the different use cases we&#39;re<br>
&gt; talking about a little more.<br>
&gt;<br>
&gt; ISTM that use cases where the person following the link is the person<br>
&gt; who is typing it in, are use cases that locale-dependent mapping might<br>
&gt; be most useful.  If I&#39;m in a locale where Ȱ (x230) is considered to<br>
&gt; be<br>
&gt; the capitalized version of o (ASCII o),  it might very well be most<br>
&gt; helpful to make that mapping.  Use cases where the same user is typing<br>
&gt; in the domain names that then looks them up include:<br>
&gt; - typing links in the address bar<br>
&gt; - typing mail address in the To field of an email<br>
&gt; - Writing a Web page, blog post or email, wherein I check that the<br>
&gt; links work before posting/sending my document<br>
&gt;<br>
&gt; In contrast, the use case where the person looking up the domain<br>
&gt; FȰȰ.example is not the person who typed it in, then in most cases we<br>
&gt; no longer know the intent or locale of the person who typed in the<br>
&gt; domain.  It may be the same locale as the person who is looking up the<br>
&gt; domain but it may not be.  The person who typed in the domain may have<br>
&gt; intended fȱȱ.example or foo.example, and may have tested that before<br>
&gt; sending/posting the link, but we no longer have that information.  Use<br>
&gt; cases include:<br>
&gt; - Following a HTTP link in any Web page, document, blog post, email,<br>
&gt; etc<br>
&gt; - Using a mailto link (explicit or implicit), e.g. when one person<br>
&gt; sends me another person&#39;s email address<br>
&gt;<br>
&gt; We probably would all agree that people follow links while Web<br>
&gt; browsing far more often than they type them in, and even when typing<br>
&gt; in, auto-complete probably drastically reduces the new cases of<br>
&gt; from-scratch mapping and lookup.<br>
&gt;<br>
&gt; However, we probably have quite different assumptions about how much<br>
&gt; Internet activity takes place among users of a consistent locale.  Can<br>
&gt; we assume that Patrik wants ß interpreted as ß because he communicat<br>
&gt; es<br>
&gt; mostly in Swedish with Swedish users and mostly reads Swedish Web<br>
&gt; pages?  Or must we assume that Patrik also gets email from german and<br>
&gt; swiss senders, and also reads Web pages (perhaps in English!) written<br>
&gt; by German users who expected different mappings?  I am sure this<br>
&gt; depends heavily on our model of a user, and whether we&#39;re using<br>
&gt; ourselves as hypothetical examples or not.<br>
&gt;<br>
&gt; One slightly more solid question for browsers is, would it be entirely<br>
&gt; crazy to have different mapping algorithms for typed-in domain names<br>
&gt; than for links followed?  There might be a locale-dependent mapping as<br>
&gt; well as a global mapping.  (I assume that having every established<br>
&gt; locale mapping installed would be complete craziness.)<br>
&gt;<br>
&gt; Another question is: when posted links are followed, how often do we<br>
&gt; know the locale where the link was authored?  Not that the browser<br>
&gt; following the link would necessarily be able to apply the mappings of<br>
&gt; the locale in which it was authored, but would it be slightly better<br>
&gt; to apply a global mapping than a mapping from a different locale?<br>
&gt;<br>
&gt; Do any authoring software clients fix up links as the user types?<br>
&gt; When I type a link in a document, the authoring software often makes<br>
&gt; that link active.  Is there any software that automatedly lower-cases?<br>
&gt; If so, would such software also be likely to map to PVALID characters<br>
&gt; before the doc is finished?<br>
&gt;<br>
&gt; Lisa<br>
&gt;<br>
&gt; On Tue, Dec 1, 2009 at 12:45 PM, Shawn Steele<br>
&gt; &lt;<a href="mailto:Shawn.Steele@microsoft.com" target="_blank">Shawn.Steele@microsoft.com</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; One example I discussed with Patrik yesterday, was whether locale<br>
&gt;&gt; might affect mapping. I&#39;d like to get better insight into the general<br>
&gt;&gt; understanding of that.<br>
&gt;&gt;<br>
&gt;&gt;&gt; 1. Could locale determine whether a PVALID character should be<br>
&gt;&gt;&gt; mapped<br>
&gt;&gt;&gt; into another PVALID character prior to following the rules to turn<br>
&gt;&gt;&gt; into an ALABEL?  I believe the consensus answer is probably SHOULD<br>
&gt;&gt;&gt; NOT<br>
&gt;&gt;&gt; or MUST NOT because that would make domains with that valid<br>
&gt;&gt;&gt; character<br>
&gt;&gt;&gt; unreachable by software using those locale rules.<br>
&gt;&gt;<br>
&gt;&gt; I agree.<br>
&gt;&gt;<br>
&gt;&gt;&gt; 2. Could locale determine whether, or how, a DISALLOWED character is<br>
&gt;&gt;&gt; mapped into a PVALID character prior to getting an ALABEL?<br>
&gt;&gt;<br>
&gt;&gt; No, for several reasons:<br>
&gt;&gt;<br>
&gt;&gt; A) If I email you a link that contains a DISALLOWED character, your<br>
&gt;&gt; machine/environment MUST map it to the same thing my machine did.<br>
&gt;&gt; Otherwise I say &quot;you have funny charges from travelling, visit Bank.org<br>
&gt;&gt;  to correct it.&quot;  You are trying to pay for your flight home so you<br>
&gt;&gt; type &quot;Bank.org&quot; into the computer in the kiosk in the foreign<br>
&gt;&gt; airport, and if it uses different mapping rules you could end up as<br>
&gt;&gt; a phishing site.  You don&#39;t want VISA.com to go to a vı<a href="http://sa.com" target="_blank">sa.com</a> just<br>
&gt;&gt;  because you&#39;re using a Turkish airport browser.<br>
&gt;&gt;<br>
&gt;&gt; B) If I travel myself, I need consistent behavior regardless of the<br>
&gt;&gt; machine I&#39;m using.<br>
&gt;&gt;<br>
&gt;&gt; C) If I see an international advertisement, the domains need to go<br>
&gt;&gt; to the same server, regardless of who and how and where the person<br>
&gt;&gt; is typing in the link.<br>
&gt;&gt;<br>
&gt;&gt; D) A server or relay wouldn&#39;t necessarily know the context the user<br>
&gt;&gt; expected when interpreting a forwarded request.<br>
&gt;&gt;<br>
&gt;&gt; E) It&#39;d be a support nightmare.<br>
&gt;&gt;<br>
&gt;&gt; F) I&#39;m not sure if it is practical to create APIs that enable this<br>
&gt;&gt; distinction.  (We (software community, not just my company) already<br>
&gt;&gt; have problems selecting the correct locale specific behavior for<br>
&gt;&gt; sorting and formatting, etc., so we&#39;d be bound to get it wrong at<br>
&gt;&gt; least some of the time.)<br>
&gt;&gt;<br>
&gt;&gt; -Shawn<br>
&gt;&gt;<br>
&gt; _______________________________________________<br>
&gt; Idna-update mailing list<br>
&gt; <a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
&gt; <a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no" target="_blank">Idna-update@alvestrand.no</a><br>
<a href="http://www.alvestrand.no/mailman/listinfo/idna-update" target="_blank">http://www.alvestrand.no/mailman/listinfo/idna-update</a><br>
</div></div></blockquote></div><br>