draft-klensin-idnabis-protocol-04 section 4.5

[Simon Josefsson]

"Mark Davis" <mark.davis at icu-project.org> writes:

>> > So the bottom line is that the current four IDNA200X drafts only
>> > specify what is allowed at the lowest level(s). The higher levels,
>> > such as HTML, UI and so on, are to be specified in separate specs.
>>
>> Doesn't this approach lead to, for example, that the outcome of X.509
>> certificate chain validation will depend on the locale in which the
>> application is running in?
>
>
> I think that locale-specific preprocessing would be a disaster for
> compatibility. People will expect that what they type in an address bar in
> one location will work in another, or can be pasted into email and work for
> the recipient, and so on. They will get burned by it not working, or even
> worse, that it works but points to somewhere unexpected.
>
> Moreover, for compatibility in environments where IDNA2003 is now used, a
> successful deployment of IDNA200x really also requires a standard,
> locale-invariant, preprocessing specification -- one that maintains as much
> compatibility with IDNA2003 mapping as possible. (Reasons discussed earlier
> on this list.) I don't know if that applies in the case of X.509 or not.
>
> A number of people feel that it is important to get the main IDNA200x spec
> done (or at least well underway) before such a preprocessing specification
> is developed, and that it should thus not be part of the charter. My fear is
> that without such a standard specification being available at the same time
> or shortly thereafter, every implementation will develop its preprocessing
> -- something just a little different from others -- causing a compatibility
> mess.

Now that I understand the situation, I would completely agree with you.

This discussions makes me unsure whether the core 4 specifications can
obsolete RFC 3490.  Some aspects of what's provided by RFC 3490
(guidelines for applications) will not be provided by the new RFC's, it
seems.  I think the WG charter sends a rather different message.

Given that this is a -bis effort, I would prefer having a standard
mapping that is compatible with IDNA2003, to bridge old implementations
to new ones.

/Simon