Comments on draft-ietf-idnabis-defs-10

[Wil Tan]

2009/8/31 Patrik Fältström <patrik at frobbit.se>

> On 30 aug 2009, at 21.54, Patrik Fältström wrote:
>
> > On 30 aug 2009, at 20.22, Wil Tan wrote:
> >
> >> However, if certain characters in an A-label have
> >> been uppercased, the Punycode decoding algorithm (due to its mixed-
> >> case
> >> annotation feature) may produce invalid U-label because the ASCII
> >> characters
> >> will be in capital letter form.
> >
> > Can you give examples of when this happens? I can not see this
> > result in the punycode algorithm. I also just did some tests with
> > mixed ascii, latin and chinese characters, and can not reproduce.
>
> I still do not understand what the problem is, and I am waiting for
> someone to give examples of the above scenario.
>
> I.e. if you have U-label 1:
>
> - fältström
>
> turn it into an A-label:
>
> - xn--fltstrm-5wa1o
>
> randomly casefold the characters:
>
> - xN--fLtStRm-5Wa1O
>
> turn into U-label:
>
> - fäLtStRöm
>
> This only differs in the casing of the ascii characters, i.e. still
> follows the matching rules for DNS for ascii, and have exact matches
> for the rest.
>
> So, casefold of the ascii in the A-label only result in casefold of
> the ascii in the U-label.
>

The problem is that, according to idnabis-defs-10, 2.3.2.1:

  .. an A-label must be capable of being produced by conversion from
  a U-label and a U-label must be capable of being produced by
  conversion from an A-label.


xN--fLtStRm-5Wa1O is not a valid A-label. If the conversion from A-label to
U-label would first lowercase the A-label before applying Punycode decoding,
that symmetry constraint could be met.


=wil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20090831/f8886cf1/attachment.htm