<br><br><div class="gmail_quote">2009/8/31 Paul Hoffman <span dir="ltr"><<a href="mailto:phoffman@imc.org">phoffman@imc.org</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">At 4:08 AM +0200 8/31/09, jean-michel bernier de portzamparc wrote:<br>
>I think I would support your proposition, but I am not sure I understand "A pair of A-labels MUST be compared using a case-preserving comparison.".<br>
<br>
</div>A comparison between xn--Axdf and xn--axdf would yield "not matched".<br></blockquote><div><br>Here is where I dont understand. This violates the DNS context. DNS comparison rules MUST apply because A-labels are whole ASCII labels.<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;">
<div class="im">
>Moreover, the way you phrase it seems to integrate the case-preservation in the protocol, i.e. in the ACE and not to keep it as a part of its use?<br>
<br>
</div>Uppercase characters are not allowed in the U-labels anyway, so there is no reason to keep them in the A-labels.<br></blockquote><div><br>Uppercase characters are supported but not used by ASCII Domain Name. Once ASCII I do not see why there would be a difference based upon the origin (how do a non-IDNA aware system would know it?).<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;">
<div class="im">
>The rule proposed by Andrew Sullivan seems quite systematic and clear?<br>
><br>
>1. The encoding of A-label1 according to [RFC3492] results in U-label1.<br>
>2. The decoding of U-label2 according to [RFC3492] results in A-label2.<br>
>3. A-label1 is equivalent to A-label2 according to DNS matching rules for labels.<br>
>4. U-label1 is bistring equivalent to U-label2.<br>
<br>
</div>Well, no one spoke up for it. Personally, I find the introduction of A-label2 and U-label2 out of thin air to be confusing.<br></blockquote><div><br>Well, it is the same as the present text, but clearer. It appeals to me by its usual scientific approach. The point is that you seem to disagree with the rule 3. I did not realise that before using that presentation. It shows it well.<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;">
<div class="im">
>We felt it addressed our point "References to the lower/uppercase image can be understood by DNS old-timers, but is confusing to newcomers, as it does not reflect the same functionality and because U-label/A-label lower/uppercase treatment is not the same." since everyone knows that punycode is case preserving.<br>
<br>
</div>I figure it is easier to remove the comparisons to regular-style DNS mapping than to try to show the differences.<br></blockquote><div><br>This is not where we saw the problem. We saw it in an explanation using a non yet fully accepted image by a non-specialist. And a confusion between upper-cases in Ascii and Unicode. We are users, not much interested in the black-magic if we can. We just want:<br>
<br>(1) in real life use no more constraint IRT upper-cases than in ASCII English. <br>(2) IDNA2008 is case insenstive, but we need to have it majuscule sensitive. <br><br>We have no real problem with these needs if the ASCII rule is the same in every case, i.e. XN--ABC-DEF is the same as xn--abc-def. This is what we understand as the protocol (on the wire) part. What the applications can do ("IDNA2008 should prohibit upper-case characters as input even though
user interfaces to applications should probably map those characters"), i.e. "post-wire" is another different non-ACE but ACE-use story.<br><br>Or did I misunderstand the whole thing?<br><br>Portzamparc<br>
an IETF user<br><br><br></div></div>