<br><div class="gmail_quote">On Wed, Sep 2, 2009 at 1:05 AM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com">ajs@shinkuro.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Sep 02, 2009 at 12:45:05AM +1000, Wil Tan wrote:<br>
> 2. If A-labels are not allowed to have uppercase ASCII characters, why do we<br>
> define case-insensitive comparison for them? An invalid A-label should not<br>
> be equivalent to a valid one. It should be as Paul suggested, i.e.<br>
> "case-preserving" (why not just "case-sensitive" as it's more<br>
> straightforward?)<br>
<br>
</div>This one's easy: we're stuck with what DNS does. A-labels are all LDH<br>
labels, and LDH labels compare for equivalence according to the<br>
case-insensitive matching rules defined as part of DNS (see STD13).<br>
Attempting to invent special rules for A-label matching will have the<br>
bizarre result that an IDNA-aware application will not match two<br>
"identical" DNS labels, even though an IDNA-oblivious application will<br>
match them.<br>
<div class="im"><br>
</div></blockquote><div><br></div><div>Agreed. I'm not actually advocating special rules for A-label matching, just pointing an inconsistency where label1 is a valid A-label, and is equivalent to label2 which is an invalid A-label.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">> 3. We are "violating" (may be too strong a term, "contradicting" perhaps)<br>
> the underlying assumptions that DNS labels are case insensitive. There are<br>
> lots of deployed software that relies on that assumption. Domain names are<br>
> often presented (and perhaps stored) in uppercase by some registries in<br>
> Whois and EPP. I'm also worried about potential security issues that may<br>
> arise if the case insensitivity property is not preserved.<br>
<br>
</div>Well, we haven't violated that, precisely because no valid A-label<br>
has, at least, an ASCII capital letter that will remain in the<br>
translation back to a U-label. But the upper-cased version (or any<br>
mixed-case version) of the same A-label will still be DNS equivalent.<br>
It just won't be an A-label, it seems.<br>
<br></blockquote><div><br></div><div>If the A-label qualification is just a definition, it wouldn't matter much. But it's how we define registration and lookup behavior where A-label is concerned that I'm afraid this could cause unintended consequences in software implementations.</div>
<div><br></div><div>As it is currently defined, IDNA2008 protocol allows a conforming applications to behave in different ways (even without mapping).</div><div><br></div><div><br></div>On Wed, Sep 2, 2009 at 1:10 AM, Vint Cerf <span dir="ltr"><<a href="mailto:vint@google.com">vint@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
andrew, the problem with that last point is that the two labels will<br>match in DNS but produce different U-label on conversion. </blockquote><div><br></div><div>One of those U-label is not valid though (since it contains uppercase characters.)</div>
<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
I think that<br>is not a good outcome.<br>downcasing would solve that wouldn't it?<br></blockquote><div><br></div><div>I do think it would gives us the best compromise between the U/A-label symmetry and being compatible with LDH matching rules. That said, I do recognize that it is a change to the core protocol and that alone warrants more thorough reviews.</div>
<div><br></div><div>I'm all for a path of least change, even if it is a compromise as long as we understand the implications and make them clear in the specs.</div><div><br></div><div>=wil</div></div>