Comments on draft-ietf-idnabis-defs-10

Wil Tan wil at cloudregistry.net
Mon Aug 31 14:31:09 CEST 2009


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/6b55078f/attachment.htm 


More information about the Idna-update mailing list