<br clear="all">Mark<br>
<br><br><div class="gmail_quote">On Sat, May 30, 2009 at 15:10, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
--On Saturday, May 30, 2009 11:19 -0700 Paul Hoffman<br>
<div class="im"><<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>> wrote:<br>
<br>
> I earlier criticized the -00 draft for not being technically<br>
> correct. Here are my proposed changes for that. Basically,<br>
> replace "NFC and some NFKC-like actions but avoid touching the<br>
> characters that are allowed in IDNA2008 but weren't allowed in<br>
> IDNA2003" with "protect the characters that are allowed in<br>
> IDNA2008 but weren't allowed in IDNA2003, then do NFKC".<br>
<br>
</div>Paul,<br>
<br>
I think there is at least one fundamental difference here, but<br>
it may be accidental so I should ask and see if it brings us a<br>
little closer.<br>
<br>
There have been several comments on the list (I think first from<br>
Martin) to the effect that there are compatibility mappings<br>
supported as part of NFKC that we fundamentally don't need. For<br>
example, the many "mathematical" characters that are essentially<br>
font variations on undecorated Latin ones almost certainly have<br>
no appropriate place in domain names: they are hard or difficult<br>
to type in most environments, they don't exist as distinct<br>
glyphs in most of the fonts one would expect to see in URLs,<br>
etc. If they have any practical value at all, it would be to do<br>
mischief.<br>
<br>
The glyph problem adds to the risk that a user will see little<br>
boxes or question marks, naively proceed, and discover that they<br>
masked a known-hostile domain. So the risk isn't entirely<br>
theoretical.</blockquote><div><br>How would the example you cite be different from my seeing a box
standing for a Malayalam character, where I have no Malayalam font? I don't think that you've given any concrete cases -- so at this point, you have not established that it is a practical problem, nor which characters would be at issue, nor what the magnitude is. So I think it is, at this point, pretty much theoretical.<br>
<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>
<br>
In the data that Erik and Mark have provided from time to time,<br>
I don't believe we saw any evidence that those characters are in<br>
actual, practical, use in, e.g., URLs.</blockquote><div><br>It's been on my plate for some time to do a thorough analysis. (That plate's been pretty full lately.) I agree that if some set of characters simply are not in current use that there is no need to map them for compatibility; but we have to be very sure of what that set actually is. Your assumption has been case mapping + width, but we need actual data.<br>
<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>
<br>
On that basis, Martin (and others) have suggested that we be<br>
selective about the compatibility mappings we support, focusing<br>
on those that can be typed and have some useful effect and<br>
avoiding those that, like the above, serve no purpose other than<br>
possibly to increase risk.<br>
<br>
Do you believe there is actually a reason to map those<br>
characters, as the way you suggest applying NFKC would do? And,<br>
if so, can you explain why?<br>
<font color="#888888"><br>
john<br>
</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Idna-update mailing list<br>
<a href="mailto:Idna-update@alvestrand.no">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>