<div>First, I apologize for not following through my earlier posting and only raising it at this late timing.</div><div><br></div><div><br></div><div>On Mon, Aug 31, 2009 at 8:41 PM, John C Klensin <span dir="ltr"><<a href="mailto:klensin@jck.com">klensin@jck.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; ">
I am confused at this stage as to whether I should insert<br>lowercasing operations in appropriate places or whether I should<br>insert text that prohibits uppercase ACE strings as input to<br>IDNA.</blockquote><div> </div>
</div><div>After pondering over it for some time, I'm leaning towards lowercasing.</div><div><br></div><div>To summarize, we have 3 options on the table right now. I'm trying to tabulate the options according my understanding.</div>
<div><br></div><div>To illustrate, I will use "fältström" as an example. </div><div>puny_decode("fltstrm-5wa1o") -> "fältström"</div><div>puny_decode("Fltstrm-5wa1o") -> "Fältström"</div>
<div><br></div><meta charset="utf-8"><meta charset="utf-8"><div>"Fältström" is an invalid U-label because of the character "F". According to idnabis-defs-10, this makes its punycode encoding "xn--Fltstrm-5wa1o" an invalid A-label. Though invalid, it could still be looked up if the mapping step is employed (because idnabis-mappings-03 lowercases everything) or if the application chooses not to attempt to decode the A-label input to U-label.</div>
<meta charset="utf-8"><div><br></div><div>So, under the current drafts, the following functions evaluate to:</div><div><br></div><div><div>is_valid_a_label("xn--Fltstrm-5wa1o") -> No</div><div>is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> Yes</div>
<div>registration_permitted("xn--Fltstrm-5wa1o") -> No</div><div>lookup_permitted("xn--Fltstrm-5wa1o") -> Yes (if mapping was used, or if application chooses not to decode the A-label) or No (if mapping was not used, and application chooses to decode A-label to U-label.)</div>
<div><br></div></div><div><div><br></div></div><div>Opt 1 - Lowercase A-label before converting to U-label</div><div><br></div><div>is_valid_a_label("xn--Fltstrm-5wa1o") -> Yes</div><div>is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> Yes</div>
<div>registration_permitted("xn--Fltstrm-5wa1o") -> Yes</div><div>lookup_permitted("xn--Fltstrm-5wa1o") -> Yes</div><div> A. If it performs mapping as specified in idnabis-mappings-03, the A-label will be lowercased. Therefore, Yes.</div>
<div> B. If it does not perform mapping, nor does it convert to U-label (idnabis-protocol-14, 5.3 does not mandate doing so)</div><div> and looks up the A-label, then Yes.</div><div> C. If it does not perform mapping, but converts to U-label (according to idnabis-protocol-14, 5.3),</div>
<div> the A-label will be lowercased before punycode decoding. Therefore, Yes.</div><div><br></div><div><br></div><div>Opt 2 - Use case-preserving comparison for A-label comparison</div><div><br></div><div>This is my interpretation of Paul's proposal, which replaces traditional LDH equivalence with case-preserving comparison. This effectively means that A-labels are case sensitive. However, his proposed text does not update the validity of A-labels containing uppercase ASCII characters.</div>
<div><br></div><div><div>is_valid_a_label("xn--Fltstrm-5wa1o") -> No</div><div>is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> No</div><div>registration_permitted("xn--Fltstrm-5wa1o") -> No</div>
<div>lookup_permitted("xn--Fltstrm-5wa1o") -> Yes (if mapping was used, or if application chooses not to decode the A-label.)</div><div><br></div><div><br></div></div><div>Opt 3 - Forbid the use of uppercase in A-label</div>
<div><br></div><div><div>is_valid_a_label("xn--Fltstrm-5wa1o") -> No</div><div>is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> No</div><div>registration_permitted("xn--Fltstrm-5wa1o") -> No</div>
<div>lookup_permitted("xn--Fltstrm-5wa1o") -> No (may still be possible with mapping unless explicitly prohibited by protocol)</div><div><br></div></div><div><br></div><div class="gmail_quote">I believe option 1 (lowercasing) gives the most desirable function results, mainly for compatibility with IDNA2003 and LDH labels.</div>
<div class="gmail_quote"><br></div><div class="gmail_quote">=wil</div>