Comments on draft-ietf-idnabis-defs-10

[Vint Cerf]

wil,

that is where I am ending up too - what do others think?

v

On Aug 31, 2009, at 8:31 AM, Wil Tan wrote:

> First, I apologize for not following through my earlier posting and  
> only raising it at this late timing.
>
>
> On Mon, Aug 31, 2009 at 8:41 PM, John C Klensin <klensin at jck.com>  
> wrote:
> I am confused at this stage as to whether I should insert
> lowercasing operations in appropriate places or whether I should
> insert text that prohibits uppercase ACE strings as input to
> IDNA.
>
> After pondering over it for some time, I'm leaning towards  
> lowercasing.
>
> To summarize, we have 3 options on the table right now. I'm trying  
> to tabulate the options according my understanding.
>
> To illustrate, I will use "fältström" as an example.
> puny_decode("fltstrm-5wa1o") -> "fältström"
> puny_decode("Fltstrm-5wa1o") -> "Fältström"
>
> "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.
>
> So, under the current drafts, the following functions evaluate to:
>
> is_valid_a_label("xn--Fltstrm-5wa1o") -> No
> is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> Yes
> registration_permitted("xn--Fltstrm-5wa1o") -> No
> 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.)
>
>
> Opt 1 - Lowercase A-label before converting to U-label
>
> is_valid_a_label("xn--Fltstrm-5wa1o") -> Yes
> is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> Yes
> registration_permitted("xn--Fltstrm-5wa1o") -> Yes
> lookup_permitted("xn--Fltstrm-5wa1o") -> Yes
>   A. If it performs mapping as specified in idnabis-mappings-03, the  
> A-label will be lowercased. Therefore, Yes.
>   B. If it does not perform mapping, nor does it convert to U-label  
> (idnabis-protocol-14, 5.3 does not mandate doing so)
>      and looks up the A-label, then Yes.
>   C. If it does not perform mapping, but converts to U-label  
> (according to idnabis-protocol-14, 5.3),
>      the A-label will be lowercased before punycode decoding.  
> Therefore, Yes.
>
>
> Opt 2 - Use case-preserving comparison for A-label comparison
>
> 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.
>
> is_valid_a_label("xn--Fltstrm-5wa1o") -> No
> is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> No
> registration_permitted("xn--Fltstrm-5wa1o") -> No
> lookup_permitted("xn--Fltstrm-5wa1o") -> Yes (if mapping was used,  
> or if application chooses not to decode the A-label.)
>
>
> Opt 3 - Forbid the use of uppercase in A-label
>
> is_valid_a_label("xn--Fltstrm-5wa1o") -> No
> is_equivalent("xn--Fltstrm-5wa1o", "xn--fltstrm-5wa1o") -> No
> registration_permitted("xn--Fltstrm-5wa1o") -> No
> lookup_permitted("xn--Fltstrm-5wa1o") -> No (may still be possible  
> with mapping unless explicitly prohibited by protocol)
>
>
> I believe option 1 (lowercasing) gives the most desirable function  
> results, mainly for compatibility with IDNA2003 and LDH labels.
>
> =wil

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090831/8544688b/attachment-0001.htm