Re: treatment of U+002E that is produced by NFKC

[Simon Josefsson]

"Erik van der Poel" <address@hidden> writes:

>> Interesting.  As far as I can tell from RFC 3490, I think the libidn
>> behaviour is what follows from the specification.  The specification
>> doesn't say anything about treating U+2024 as a label separator that I
>> could find.  Do you agree with this?
>
> Yes, I agree.

Ok, good.

>> If so, I think the first step is
>> to update the RFC, and when that is done we can adapt the new behaviour
>> in libidn.
>
> Sure, that is one way to deal with this. Libidn users may not be
> clamoring for a resolution. Other implementations may be in more of a
> rush to resolve the conflict. (I work for Google.)

Actually, I think libidn users want libidn to implement the RFCs
faithfully.  The default mode of libidn should not go beyond that until
the RFCs are updated.

>> If libidn implements RFC 3490 incorrectly, we should definitely fix
>> that.  Right now I don't understand what part of RFC 3490 we implement
>> incorrectly.  So please explain further how the RFC 3490 language and
>> libidn differ.
>>
>> I think one could argue more convincingly that MSIE/Firefox implements
>> RFC 3490 incorrectly here.  U+2024 isn't a label separator according to
>> RFC 3490, but they treat it as if it were.
>
> Yes, one could certainly argue that MSIE and Firefox implement RFC
> 3490 incorrectly, particularly if you read section 4 steps 4) and 5)
> carefully. However, I also believe that MSIE and Firefox chose a
> reasonable behavior and that it seems somewhat unlikely that they will
> change their behavior, given that the IDNA200X discussions already
> appear to be moving in their direction.

I'd be interested to hear how IDNA200x will solve the backwards
compatibility issues if it is changing fundamental properties like this.
As far as I can tell, that handling will be non-trivial (or IDNA200x is
broken by design), and I believe it is premature to implement partial
solutions of it until that has been sorted out.

/Simon