<br><div class="gmail_quote">On Tue, Sep 1, 2009 at 2:32 AM, Andrew Sullivan <span dir="ltr"><<a href="mailto:ajs@shinkuro.com" target="_blank">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>On Mon, Aug 31, 2009 at 11:00:40AM -0400, John C Klensin wrote:<br>
<br>
> Without these changes, the definition of U-label is clear, the<br>
> definition of A-label is clear, the two are obviously symmetric,<br>
> and we don't have issues of<br>
> U-label-except-with-some-upper-case-characters. Encouraging the<br>
> latter muddies, and will probably require review, of the other<br>
> definitions.<br>
<br>
</div>Then see the part of my mail that you cut out: since a valid U-label<br>
can never have upper case ascii characters in it anyway, what's the<br>
worry? We've already defined the problem away, it would seem.<br>
<br>
</blockquote><div><br></div><div>Yes, that's what I perceive from reading the drafts too but several ambiguities exist in my mind (see below.)</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I think the problem Wil is identifying is that we haven't really<br>
defined this away, because implementations may choose not to do all<br>
the validation steps, and therefore lookups will be allowed that in<br>
some cases will sometimes succeed, even though they shouldn't. Right?<br><br></blockquote><div><br></div><div>Yes, this is one of the issues I'm trying to raise:</div><div><br></div><div>1. Consistency of lookup behavior when input appears to be an A-label: different applications can be conforming to IDNA2008 and yet produce different results due to the optional punycode decoding step in idnabis-protocol, 5.3.</div>
<div><br></div><div><br></div><div>Other perhaps more subtle points:</div><div><br></div><div>2. If A-labels are not allowed to have uppercase ASCII characters, why do we define case-insensitive comparison for them? An invalid A-label should not be equivalent to a valid one. It should be as Paul suggested, i.e. "case-preserving" (why not just "case-sensitive" as it's more straightforward?)</div>
<div><br></div><div>3. We are "violating" (may be too strong a term, "contradicting" perhaps) the underlying assumptions that DNS labels are case insensitive. There are lots of deployed software that relies on that assumption. Domain names are often presented (and perhaps stored) in uppercase by some registries in Whois and EPP. I'm also worried about potential security issues that may arise if the case insensitivity property is not preserved.</div>
<div><br></div><div>=wil</div></div>