<br><br><div class="gmail_quote">On Wed, Sep 2, 2009 at 6:50 AM, John C Klensin <span dir="ltr">&lt;<a href="mailto:klensin@jck.com">klensin@jck.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
<br>
--On Tuesday, September 01, 2009 16:01 -0400 Vint Cerf<br>
<div class="im">&lt;<a href="mailto:vint@google.com">vint@google.com</a>&gt; wrote:<br>
<br>
&gt; let&#39;s go with the &quot;make sure the XN-label string is in<br>
&gt; lowercase before converting to U-label&quot;<br>
<br>
</div>Ok.<br>
<br>
I&#39;ve patched the changes into Protocol, making modifications<br>
only where conversion from A-labels to U-labels is discussed.<br>
I&#39;m going to post that version for WG review as soon as I can<br>
get it compiled and submitted.  A version with the remaining<br>
pre-IETF-last call patches (mainly the filling in of Section<br>
numbers) will follow shortly (probably tomorrow) if either there<br>
are no further comments or the comments indicate that this is<br>
ok.   I&#39;ve made no changes to Definitions -- the discussion<br>
doesn&#39;t seem to require them.<br>
<br></blockquote><div><br></div><div>John,</div><div><br></div><div>Thank you for the quick turnaround on this and providing valuable insights, as always.</div><div><br></div><div>I&#39;ve reviewed protocol-15 with respect to this issue and it looks good.</div>
<div><br></div><div>As for the definitions document, I think you&#39;re right that there may not be any changes necessary. In an earlier message, you said that some points in Andrew&#39;s comments at the beginning of the thread have been incorporated. I&#39;ll wait for defs-11 and review it once more.</div>
<div><br></div><div>Related note: in light of the discovery made by James that Punycode can in fact output uppercase characters to represent encoded non-ASCII codepoints, we could go back to idnabis-defs-10, 2.3.2.1 and further qualify &quot;output of the Punycode algorithm&quot;. However, since practically all implementations output to lowercase, I suppose it is not necessary?</div>
<div><br></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Probably Rationale should be extended to discuss this issue and<br>
the reasons for the &quot;require lowercase&quot; statement.  I&#39;d welcome<br>
text on that subject and advice as to where to put it, but will<br>
make something up if I don&#39;t hear from people.<br>
<div><div></div><div class="h5"><br></div></div></blockquote><div><br></div><div>I&#39;m lousy at writing such texts but do the follow bullets capture what you intend to say?</div><div><br></div><div>1. Symmetry constraint between U-label and A-label is a desirable property and key design goal of IDNA2008</div>
<div>2. A-labels, being a subset of LDH-labels are sometimes stored and used without preserving case.</div><div>3. When that happens, we end up with having uppercase characters in the Punycode decoded result, which makes it an invalid U-label.</div>
<div>4. This happens because of the Punycode algorithm preserving the cases of the &quot;basic code points&quot; in the decoding process.</div><div>5. Because the Punycode encoding process (practically) never outputs uppercase characters from valid U-labels, we know that a valid A-label must not contain any uppercase character after the &quot;xn--&quot; ACE prefix.</div>
<div><br></div><div><br></div><div>=wil</div></div>